- ghc-devs - Haskell.org

[ANNOUNCE] GHC 9.12.1-rc1 is now available
by Zubin Duggal 29 Nov '24

29 Nov '24

The GHC developers are very pleased to announce the availability of the release candidate for GHC 9.12.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. We hope to have this release available via ghcup shortly. GHC 9.12 will bring a number of new features and improvements, including: * The new language extension [OrPatterns] allowing you to combine multiple pattern clauses into one. * The [MultilineStrings] language extension to allow you to more easily write strings spanning multiple lines in your source code. * Improvements to the OverloadedRecordDot extension, allowing the built-in `HasField` class to be used for records with fields of non lifted representations. * The [NamedDefaults] language extension has been introduced allowing you to define defaults for typeclasses other than `Num`. * More deterministic object code output, controlled by the `-fobject-determinism` flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details * GHC now accepts type syntax in expressions as part of [GHC Proposal #281]. * The WASM backend now has support for TemplateHaskell. * ... and many more A full accounting of changes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. Cheers, Zubin [release notes]: https://downloads.haskell.org/ghc/9.12.1-rc1/docs/users_guide/9.12.1-notes.… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.1-rc1 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [OrPatterns]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-o… [MultilineStrings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-m… [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-v… [NamedDefaults]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-e…

1 0

GHC 9.12.1 updates and rc1 status
by Zubin Duggal 27 Nov '24

27 Nov '24

Hi all, We had planned to release 9.12.1-rc1 today. Unfortunately, we discovered a few regressions and bugs which need to be fixed before we can publish a release candidate, including #25382, #25375 and !13633. I am currently waiting for some of these fixes to land in master before backporting them to the release branch. I will try to have the release candidate out on Monday the 25th. The final release is currently scheduled for December 6th. We will inform you if there are any changes to this schedule. Cheers, Zubin.

1 1

labeling MVar and STM data structures
by Kazu Yamamoto 21 Nov '24

21 Nov '24

Hello, I'm seeking of the source of the bug that my server based on Warp gets not-responding. "listThreads" shows that IOManager is blocked on a MVar permanently: 2 IOManager on cap 0: ThreadBlocked BlockedOnForeignCall 3 IOManager on cap 1: ThreadBlocked BlockedOnMVar 4 TimerManager: ThreadBlocked BlockedOnForeignCall IOManager should have the BlockedOnForeignCall reason since it's calling epoll_wait(). It's quit hard to debug this bug since I don't understand which MVar blocks IOManager of 3. Users can register MVar operations to IOManager while IOManager itself is using MVars internally. To make this kind of debugging easier, I would like ask GHC developers to extend MVar to hold its label and provide "labelMVar" like "labelThread". The same mechanism should be provided for STM as well. "BlockReason" should contain the target label. What do you think? Background: https://github.com/haskell/network/issues/590 --Kazu

3 3

[ANNOUNCE] GHC 9.12.1-alpha3 is now available
by Zubin Duggal 15 Nov '24

15 Nov '24

The GHC developers are very pleased to announce the availability of the third alpha release of GHC 9.12.1. Binary distributions, source distributions, and documentation are available at [downloads.haskell.org][]. We hope to have this release available via ghcup shortly. GHC 9.12 will bring a number of new features and improvements, including: * The new language extension [OrPatterns] allowing you to combine multiple pattern clauses into one. * The [MultilineStrings] language extension to allow you to more easily write strings spanning multiple lines in your source code. * Improvements to the OverloadedRecordDot extension, allowing the built-in `HasField` class to be used for records with fields of non lifted representations. * The [NamedDefaults] language extension has been introduced allowing you to define defaults for typeclasses other than `Num`. * More deterministic object code output, controlled by the `-fobject-determinism` flag, which improves determinism of builds a lot (though does not fully do so) at the cost of some compiler performance (1-2%). See #12935 for the details * GHC now accepts type syntax in expressions as part of [GHC Proposal #281]. * The WASM backend now has support for TemplateHaskell. * ... and many more A full accounting of changes can be found in the [release notes][]. As always, GHC's release status, including planned future releases, can be found on the GHC Wiki [status][]. We would like to thank GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, the Haskell Foundation, and other anonymous contributors whose on-going financial and in-kind support has facilitated GHC maintenance and release management over the years. Finally, this release would not have been possible without the hundreds of open-source contributors whose work comprise this release. As always, do give this release a try and open a [ticket][] if you see anything amiss. [release notes]: https://downloads.haskell.org/ghc/9.12.1-alpha3/docs/users_guide/9.12.1-not… [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.1-alpha3 [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new [OrPatterns]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0522-o… [MultilineStrings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-m… [GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-v… [NamedDefaults]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-e… Cheers, Zubin

1 0

Under which circumstances are the elements of a linked list laid next to each-other in memory?
by Hécate 13 Nov '24

13 Nov '24

Hi everyone, I was asked at work today why I went for Vector instead plain old List in order to store an API result that is quite small. While writing my reasons (pointer indirection, conversion to Aeson's internal representation of a JSON array using Vector), I remember that I heard that in some cases, GHC would be able to lay down in memory the elements of a linked list next to each other. I don't think this gets rid of the pointer-chasing, but I'm interested to know more about the circumstances in which linked lists are optimised. Does anyone know if there is a wiki page or something that I could read on the topic of linked list optimisation **other than fusion**? Cheers, Hécate -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

4 3

GHC CI
by Simon Peyton Jones 12 Nov '24

12 Nov '24

Dear GHC devs Is something stuck in CI? https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13553 has been stalled for 9 hrs. I have not seen that before. Thanks Simon

6 5

GHC 9.12 release schedule and submodule status
by Zubin Duggal 11 Nov '24

11 Nov '24

Hi all, (This is a resend of an email I sent a short while ago. I seem to have messed up some email headers that might trip up some filters so I'm resending it to be safe. You only need to read one of these if you recieved my previous email) I'm writing to your in your role as a maintainer of one of the GHC boot packages. This is an update on the 9.12 release schedule. We plan to have the release out by the end of the month (ideally on 29/11/24), with an alpha/rc every week from now until the release is finalised: | Date | Event | | ----------------- | -------- | | Nov 15 2024 | alpha 3 | | Nov 22 2024 | release candidate | | Nov 29 2024 | final | Additionally, this is the final call for any submodule bumps that may be desired. The current status of the submodules is described in this spreadsheet, under the GHC 9.12 tab: https://docs.google.com/spreadsheets/d/19WeWjXPh8Q64qoe3fjs8AswpTHk6uLBD8WG… If any version that is not listed in the spreadsheet is desired, please notify me and ensure that a release is tagged and uploaded to hackage as soon as possible. I would like to finalise the state of submodules by the first release candidate. This email is individually addressed to the maintainers of all the boot libraries, as best as we could collate such a list. If you are aware of any changes to the list of GHC boot packages maintainers, please let us know. We aim to have a more systematic process for such communications with library maintainers for releases in the future. Once we finalise such a process we will let you know. Thanks for all your work, Zubin.

1 0

GHC 9.12 release schedule and submodule status
by Zubin Duggal 11 Nov '24

11 Nov '24

Cc Bcc: Subject: 9.12 schedule and submodule status Hi all, I'm writing to your in your role as a maintainer of one of the GHC boot packages. This is an update on the 9.12 release schedule. We plan to have the release out by the end of the month (ideally on 29/11/24), with an alpha/rc every week from now until the release is finalised: | Date | Event | | ----------------- | -------- | | Nov 15 2024 | alpha 3 | | Nov 22 2024 | release candidate | | Nov 29 2024 | final | Additionally, this is the final call for any submodule bumps that may be desired. The current status of the submodules is described in this spreadsheet, under the GHC 9.12 tab: https://docs.google.com/spreadsheets/d/19WeWjXPh8Q64qoe3fjs8AswpTHk6uLBD8WG… If any version that is not listed in the spreadsheet is desired, please notify me and ensure that a release is tagged and uploaded to hackage as soon as possible. I would like to finalise the state of submodules by the first release candidate. This email is individually addressed to the maintainers of all the boot libraries, as best as we could collate such a list. If you are aware of any changes to the list of GHC boot packages maintainers, please let us know. We aim to have a more systematic process for such communications with library maintainers for releases in the future. Once we finalise such a process we will let you know. Thanks for all your work, Zubin.

1 0

Lint performance
by Simon Peyton Jones 08 Nov '24

08 Nov '24

Friends -dcore-lint is switched off in our compile-time tests testsuite/tests/perf/compiler But I'm making some changes whose primary effect will be on Lint. How can I get a before-vs-after analysis of the tess in perf/compiler, with -dcore-lint switched on? Locally would be fine.. does not have to be in CI Thanks! Simon

2 1

Haskeline test failed in GHC 9.4.5
by DashiellWill 07 Nov '24

07 Nov '24

Hi all, I'm currently getting an error while testing the Haskeline library via `cabal test`. (GHC version: 9.4.5, Platform: x86_64) I get this: tests/RunTTY.hs:106 expected: ["tests/dummy-\206\188\206\177\207\131/\r\n\207\130\206\181\207\129\207\132 bar\r\n0:tests/dummy-\206\188\206\177\207\131/"] but got: ["tests/dummy-\206\188\206\177\207\131/\r\nbar \207\130\206\181\207\129\207\132\r\n0:tests/dummy-\206\188\206\177\207\131/"] The specific test in question is related to tab completion. The test case is defined as follows: tabCompletion :: Invocation -> Test tabCompletion i = "tab completion" ~: [ utf8Test i [ utf8 "tests/dummy-μ\t\t" ] [ prompt 0, utf8 "tests/dummy-μασ/" <> nl <> utf8 "ςερτ bar" <> nl <> prompt' 0 <> utf8 "tests/dummy-μασ/" ] ] It seems that the functionality of the TabCompletion is correct, but the order of the displayed files after tab completion does not match the expected output. Then, I ran the `haskeline-examples-Test` program directly and manually typed "tests/dummy-μ\t\t". The results were indeed inconsistent with the expected output: 0:tests/dummy-μασ/ bar ςερτ 0:tests/dummy-μασ/ Could anyone shed some light on the potential cause of this issue? Is there a problem with the expected value? For example, there are variations in the expected output across different environments? Thanks, Dashiell

1 0