- ghc-devs - Haskell.org

CLC Elections January 2025
by Andrew Lelechenko 27 Jan '25

27 Jan '25

Core Libraries Committee seeks nominations for three expiring seats (including my own). I’m specifically sending this email to ghc-devs, because im my opinion CLC can benefit from representatives of GHC team. # What is CLC? CLC is a volunteer body, primarily tasked with management of API of `base` package, but also owning so-called Core Libraries and responsible for PVP. You can find out more at https://github.com/haskell/core-libraries-committee/ # Who should apply? Anyone who meets the following criteria should apply: * Candidates should have enough bandwidth to review merge requests to `base` on a semi-frequent basis (~3-4 per month), and sustain this for their 3 years term in a healthy manner. * Candidates should be able to contribute opinions and analysis to issues raised by the community as a part of the CLC proposal process on a semi-frequent basis (~7 per month). * Candidates should be good communicators, and at least be able to articulate to the CLC team when they will be available vs. unavailable. * Candidates should be productive, and be able to follow through on merge requests and conversations to their completion in a diligent and timely manner. We encourage any and all who satisfy these requirements to apply. Please note that we are not looking for the biggest galaxy brain in the room -- quite the opposite. We are looking for productive, motivated individuals who want to help support the ecosystem that we love. As such, we hope to build a broad sample of the community. # How can I apply? To apply for one of these positions, send an email to clc.nominations.2025(a)gmail.com that consists of the following data: * The subject “CLC Election September 2025 - {your name}”. * Why you think you’re a good fit given the above criteria. * If applicable, please point us to some code you’ve written. Please apply before Feb 2. Best regards, Andrew

1 1

History of DH contributions
by Vladislav Zavialov 21 Jan '25

21 Jan '25

Dear GHC devs, I’ll be soon publishing a task breakdown for DH (as I see it). In addition to the planned changes, I decided to include the recent history of related work (2018–2024) in the form of links to specific proposals, issues, and commits. Here’s an example of what a single section is going to look like: https://discourse.haskell.org/uploads/default/optimized/2X/4/4954f5fac0a03e… and there will be about 50 of such sections. However, as the volume of GHC commits and issues is too high for me to go through all of them, I had to limit the scope and focus on my own work. If you have any DH-related contributions that you want represented, please let me know and I’ll try to find a place to include a reference. Vlad

1 0

[PSA]: Correctness issue in GHC-9.12
by Andreas Klebinger 17 Jan '25

17 Jan '25

A bug in 9.12.1 was reported and confirmed (ghc bug https://gitlab.haskell.org/ghc/ghc/-/issues/25653) which can lead to incorrect runtime results in compiled programs. In particular this seems to happen for sub-word divisions with a known divisor when optimizations are enabled and affects at least the x86 backend, although it’s likely that other backends are also affected. We plan to release a bug fix release 9.12.2 in the near future to address this issue and recommend people do not upgrade until then.

1 0

gitlab.haskell.org maintenance 2025-01-10
by Bryan Richter 11 Jan '25

11 Jan '25

Hi folks, In about 24 hours, I will perform some maintenance on gitlab.haskell.org. I will be addressing the frequent disk outages by improving how partitions are used. This will only require a system restart, so you can expect some short downtime.

2 5

Approving gitlab account for creating an issue
by Liisi Kerik 05 Jan '25

05 Jan '25

Hi, Could you please approve my gitlab account (@LiisiKerik)? I recently ran into a performance problem (ghc plugins make builds very slow on Windows) and would like to create an issue about this. Best regards, Liisi Kerik

2 1

Account request
by Vekhir 22 Dec '24

22 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 22 Dec '24

22 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 21 Dec '24

21 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 21 Dec '24

21 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