December 2024 - ghc-devs

Account request
by Vekhir 21 Dec '24

21 Dec '24

Good evening, After registering on gitlab.haskell.org, the site directed me to send an email to you, so you can approve the request. My focus is related to bringing new GHC releases to Arch Linux. Kind regards, Vekhir

2 1

Re: Feedback on potential change in boot library
by Andrew Lelechenko 21 Dec '24

21 Dec '24

On Thu, 28 Nov 2024 at 14:51, Andreas Klebinger via ghc-devs <ghc-devs(a)haskell.org> wrote: > For example we should probably not upgrade point releases from text-2.1.1 > to text-2.1.2 as the addition of `show` causes breakage and there seem to > be no bug fixes in the release, unless the library authors request us to do > so. There are quite a few bug fixes in text-2.1.2 actually, e. g., fixing the atomicity of putStrLn which is quite a significant improvement. I struggle to see how addition of `Data.Text.show` can break much, given that `Data.Text` is almost universally imported qualified. Returning to the original question, I’m in favour of bumping boot libraries aggressively. From the perspective of boot libraries maintainers other arrangements are both discouraging and detrimental for quality. If the only way to get feedback for a new release of, say, `bytestring` is to wait 6 months until the next major release of GHC and then wait until a new GHC gains a significant traction, then we are doomed to have bugs lurking forever. And it’s also hugely unsatisfying to spend lots of work on a new release, knowing that an average user would not benefit from it in the next few years. It could make sense to have a stricter policy when releasing a last-in-series GHC, where cost of introducing new bugs / incompatibilities is much higher (because it entails making an otherwise unplanned release). But for mid-series releases I’d recommend bumping minor versions of boot libraries as soon as possible. Best regards, Andrew

3 2

GHC 9.10.2 preparation
by Ben Gamari 20 Dec '24

20 Dec '24

Hi all, Preparations are currently underway on GHC 9.10.2. We currently have roughly 100 commits backported with another few dozen backport candidates. If you have a merge request which you want to be backported please do make sure it bears the ~"backport needed:9.10" label. Additionally, we plan on performing the following boot library version bumps: Cabal 3.12.0.0 -> 3.12.1.0 Cabal-syntax 3.12.0.0 -> 3.12.1.0 bytestring 0.12.1.0 -> 0.12.2.0 array 0.5.7.0 -> 0.5.8.0 deepseq 1.5.0.0 -> 1.5.1.0 directory 1.3.8.3 -> 1.3.9.0 filepath 1.5.2.0 -> 1.5.4.0 hpc 0.7.0.1 -> 0.7.0.2 process 1.6.19.0 -> 1.6.25.0 text 2.1.1 -> 2.1.2 unix 2.8.5.1 -> 2.8.6.0 exceptions 0.10.7 -> 0.10.9 Win32 2.14.0.0 -> 2.14.1.0 Naturally, if we find that any of these upgrades could cause significant ecosystem disruption then we may reconsider and notify the list. If things go according to plan, we expect that a prerelease will be ready by mid-January 2025, with a final release coming a few weeks later. Naturally, we will continue to report status updates on the tracking ticket [1] and will keep ghc-releases apprised if plans change. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/-/issues/25433

1 0

Lift instance cause GHC build error: unknown symbol with CFFI
by Minh Le 20 Dec '24

20 Dec '24

Hi everyone, I’m building a floating-point library for Clash that uses FloPoCo. The library integrates with the MPFR library via the hmpfr Haskell bindings to perform accurate software simulations of floating-point operations. I’ve encountered build errors related to linking the MPFR library: Windows: unknown symbol 'mpfr_add' in Arithmetic.o. Linux: symbol lookup error: undefined symbol 'mpfr_custom_get_size_wrap'. Interestingly, cabal repl works as expected, but cabal build fails. This suggests a linking issue specific to the build process. Steps to Reproduce Clone the repository: https://github.com/yourcomrade/FloPoCoFloat. Install MPFR: Windows: pacman -S mingw-w64-clang-x86_64-mpfr Linux: sudo apt install libmpfr6 libmpfr-dev Check out the Error_branch. Build the project using cabal build. Expected Behavior The project should compile without errors. Notably, if cabal build fails, I would expect cabal repl to fail too, but that’s not the case. Additional Info OS: Windows 11, Ubuntu WSL 5.15 Tools: GHC 9.8.2, Cabal 3.10.3, GCC 11.4 Relevant discussion: Cabal issue: https://github.com/haskell/cabal/issues/10651 I have a discussion with Cabal maintainer and he suspects that is GHC linking issue. Does anyone have insights into resolving this issue? Any help would be appreciated. Kind regards, Minh

2 3

Using ghc-debug with ghc
by Matthew Pickering 20 Dec '24

20 Dec '24

Hi, If anyone needs to debug ghc with ghc-debug enabled I just updated the `wip/ghc-with-debug` branch. You can cherry-pick the commit from there onto your branch and the resulting compiler will have ghc-debug enabled. Thanks to Hannes and Rodrigo for contributing updates in the past which I have squashed and force pushed. Matt

1 0

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