- ghc-devs - Haskell.org

posix_spawnp
by Simon Peyton Jones 19 Dec '24

19 Dec '24

When I do `./hadrian/build test` I get lots of these failures /home/simonpj/code/HEAD-20/_build/stage1/lib/../bin/ghc-iserv: createProcess: posix_spawnp: does not exist (No such file or directory) Any ideas of what might be causing this? It cripples my ability to locally test my build Thanks Simon

2 3

GitLab Account Approval Request
by Kazutaka Matsuda 19 Dec '24

19 Dec '24

Dear GHC developers, I am Kazutaka Matsuda. I would like to report an issue with type checking. Could you approve my request for a GitLab account (kztk)? Best regards, Kazutaka Matsuda

2 1

Feedback on potential change in boot library
by Ben Gamari 17 Dec '24

17 Dec '24

tl;dr. We propose that GHC more aggressively bump its boot library dependencies. Hello all, Historically, GHC minor releases have been quite conservative in bumping boot library versions, generally defaulting to retaining the versions used in the GHC-x.y.1 release unless * a request is made by a boot library maintainer, or * we discover an issue which warrants a bump The motivation for this policy is both to * minimize the potential for regressions in correctness and performance, and * reduce the potential for end-user breakage due to interface changes as even minor releases can result in considerable impact (e.g. #25411, #22633) While this policy has served us well, its conservative nature demands the vigilence of both GHC and upstream maintainers to ensure that bumps that are truly necessary do not fall through the cracks. As the flaws of this process have been more apparent recently (e.g. #24597), we have done a bit of reflection on how we might improve the status quo. Concretely, I would like feedback on the adopting the following policy going forward: > Unless guidance is provided otherwise by a library maintainer, a GHC > x.y.z release will attempt to ship the newest minor version of each > boot libray in the same major series shipped with GHC x.y.1. I believe this policy would leave less room for human error and open opportunities for automated checking. On the other hand, the more aggressive bumping of submodules may mean that users are hit with more (usually minor) compatibility issues when moving between minor GHC releases. How do others feel about this? We are particularly interested to hear from boot library maintainers but feedback from packagers and users is also very much welcome. Cheers, - Ben

9 12

GHC 9.12.1 is now available
by Zubin Duggal 16 Dec '24

16 Dec '24

The GHC developers are very pleased to announce the 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. * Experimental support for the RISC-V platform with the native code generator. * ... 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/docs/users_guide/9.12.1-notes.html [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status [downloads.haskell.org] https://downloads.haskell.org/ghc/9.12.1 [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…

2 3

Save the date: Haskell Ecosystem Workshop and Haskell Implementors' Workshop 2025
by Andreas Herrmann 15 Dec '24

15 Dec '24

Save the date for the Haskell Ecosystem Workshop and the Haskell Implementors' Workshop taking place on June 5 & 6 2025 near Zurich, Switzerland, hosted by the Haskell Foundation at the OST (Eastern Switzerland University of Applied Sciences) in Rapperswil, and co-located with ZuriHac (June 7-9). Expect a more detailed announcement, registration, and a call for proposals in early 2025. The Haskell Ecosystem Workshop is a workshop organized by the Haskell Foundation for those who want to gain a deeper understanding of the Haskell tooling ecosystem, whether to better leverage those tools or to become contributors. The Haskell Implementors' Workshop is a community event for people involved in the design and development of Haskell implementations, tools, libraries, and supporting infrastructure to share their work and to discuss future directions and collaborations with others. In the past the Haskell Implementors' Workshop used to be co-located with ICFP (International Conference on Functional Programming), next year it will be co-located with ZuriHac to be accessible to a broader audience. Contact Jose Calderon, executive director of the Haskell Foundation, if you have any questions regarding the Haskell Ecosystem Workshop. Contact Andreas Herrmann, program chair for the Haskell Implementors' Workshop 2025, if you have any questions regarding the Haskell Implementors' Workshop.

1 0

Re: setNumCapabilities 257 crashes a program
by Artem Leshchev 06 Dec '24

06 Dec '24

My GitLab account was approved, so I have posted this bug to https://gitlab.haskell.org/ghc/ghc/-/issues/25560 -- Artem Leshchev

1 0

setNumCapabilities 257 crashes a program
by Artem Leshchev 06 Dec '24

06 Dec '24

Hi, I was going to report this bug on GitLab as wiki suggests, but this requires my account to be manually approved, so I'm going to write it down here. (But if you can approve "matshch" on GitLab I will appreciate it.) Consider the next program: import GHC.Conc main = setNumCapabilities 257 Compiling it with recent GHC and running it causes segmentation faults sometimes, depending on the compiler version and the environment. Here is the setup that works for me every time: $ printf "import GHC.Conc\nmain = setNumCapabilities 257" | docker run -i --rm haskell:9.10.1-bullseye runghc; echo $? 139 I first discovered this issue in Nix builds, and the next setup also crashes every time for me (it uses GHC 9.6.6 under the hood): $ nix run nixpkgs/b681065d0919f7eb5309a93cea2cfa84dec9aa88#ghc -- -threaded conc.hs; ./conc [1] 311106 segmentation fault (core dumped) ./conc For this fail I have a stack trace that is showing that crash happens somewhere in RTS: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000049d34f in assignNurseriesToCapabilities () [Current thread is 1 (LWP 311106)] (gdb) bt #0 0x000000000049d34f in assignNurseriesToCapabilities () #1 0x000000000049d96c in storageAddCapabilities () #2 0x000000000047eaea in setNumCapabilities () #3 0x000000000041042d in base_GHCziConcziSync_setNumCapabilities1_info () #4 0x0000000000000000 in ?? () I have tried reproducing it with GHCup versions of GHC and have found that it requires more capabilities to cause a crash. If you bump the setNumCapabilities argument to 259, it causes the program to crash under both ghc and runghc of versions 9.6.6, 9.8.4 and 9.10.1. I have also encountered cases (with 258 capabilities IIRC) when it crashes not on every program launch, and also noticed that ghci and runghc looks more susceptible to the problem. I first discovered this issue while upgrading our platform to NixOS 24.11, builds were failing on hedgehog tests. As I have discovered, it was seeing that our build machine has 256 cores, planning to run 256 workers, so it set capabilities to number of cores + 2 (so 258 in our case) to make some room for IO threads, and was crashing as I have shown above. -- Artem Leshchev

1 0

Updating the migration guide for GHC 9.12
by Teofil Camarasu 05 Dec '24

05 Dec '24

Hi folks, With GHC 9.12 around the corner, I just wanted to give folks a gentle nudge to continue filling out the 9.12 migration guide <https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.12>. Ideally we would have an entry for each change that can break user code. And each entry would explain: - what the change is - what error messages caused by the change look like - how users can fix their code Though if you are aware of a breaking change and don't have the time to fill out a full entry, a stub is also appreciated and I (or someone else) can try to fill out the rest. I was also wondering if we should better integrate the migration guide into our processes. Maybe it should be mentioned in the MR template, so entries are added as part of the MR flow? I think that's the point when folks have stuff paged in and have the most context, but I also don't want to add extra hoops to jump through. Any thoughts? Cheers, Teo

2 1

Re: Missing Enum instance for IoSubSystem
by Ben Gamari 05 Dec '24

05 Dec '24

Ben Gamari <ben(a)smart-cactus.org> writes: >> On Wed, Dec 04, 2024 at 10:44:13AM +0000, Tom Ellis wrote: >>> There is test in place to confirm that the API of base does not change >>> accidentally. >> [...] >> >> Just so everyone here is in the loop: >> >> My guess is that the CLC will consider this an unapproved change that >> should be reverted before release. >> > Unfortunately it appears that the situation is a bit worse than just an > Enum instance. > Thankfully it appears I was wrong here. The additional changes I report below are approved under CLC#263. The only problem here is the missing `Enum` and `Show` instances for `IoSubSystem`. I have amended the merge request (!13683) to address this. Cheers, - Ben

1 0

Missing Enum instance for IoSubSystem
by Adithya Kumar 04 Dec '24

04 Dec '24

Hi all, In ghc 9.12-alpha the Enum instance for IoSubSystem no longer exists. I don't see this change mentioned anywhere in the docs (release notes/changelog) here: https://downloads.haskell.org/ghc/9.12.1-alpha1/docs/users_guide/9.12.1-not… Was this change intended or was it a refactoring issue? The datatype itself was moved from GHC.Internal.RTS.Flags to GHC.Internal.IO.SubSystem. The enum instance was earlier defined in GHC.Internal.RTS.Flags but now isn't defined in either of the modules. Best, Adithya

3 7