- ghc-devs - Haskell.org

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 09 Nov '24

09 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

GitLab Account Approval
by DashiellWill 07 Nov '24

07 Nov '24

I'm looking to get my gitlab account approved. user name: dashiell

1 0

giving a label to a thread
by Kazu Yamamoto 06 Nov '24

06 Nov '24

Hi all, GHC 9.6 provides listThreads. This is very useful to check thread leaks on network servers. Thanks. Users cannot label threads if fundamental functions fork threads without labelling. A good example is "timeout". If there are many threads without label, the debugging gets harder. So, I would like to ask to label threads in libraries shipped with GHC. --Kazu

2 1

[ANNOUNCE] GHC 9.12.1-alpha1 is now available
by Zubin Duggal 05 Nov '24

05 Nov '24

The GHC developers are very pleased to announce the availability of the first 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]. * ... 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-alpha1/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-alpha1 [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

2 2

Allow `base < 5` for package `array`
by Lei Zhu 05 Nov '24

05 Nov '24

Hi, I'm preparing the next `array` release for the coming ghc 9.12. The process seems boring because I just need to loosen the upper bound of the `base`, and then make a release. Shall I have a larger range like `base < 5` or are there any restriction in the `base`, so we have to bump the version one by one? Thanks, Lei Zhu

3 2

Re: ghc-devs Digest, Vol 255, Issue 3
by Lei Zhu 03 Nov '24

03 Nov '24

Hi Zubin, I'll do the r2 release as you advised. Thanks, Lei Zhu On Sun, Nov 3, 2024 at 8:02 PM <ghc-devs-request(a)haskell.org> wrote: > Send ghc-devs mailing list submissions to > ghc-devs(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > or, via email, send a message with subject or body 'help' to > ghc-devs-request(a)haskell.org > > You can reach the person managing the list at > ghc-devs-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ghc-devs digest..." > > > Today's Topics: > > 1. Allow `base < 5` for package `array` (Lei Zhu) > 2. Re: Allow `base < 5` for package `array` (Zubin Duggal) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 3 Nov 2024 16:37:09 +0800 > From: Lei Zhu <julytreee(a)gmail.com> > To: ghc-devs(a)haskell.org > Subject: Allow `base < 5` for package `array` > Message-ID: > <CAGfc3OtzHGKqN3-6RtwA2Q_iMHMQLZjd5= > mQQ80fGSON5R5eYg(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi, > > I'm preparing the next `array` release for the coming ghc 9.12. > The process seems boring because I just need to loosen the > upper bound of the `base`, and then make a release. > > Shall I have a larger range like `base < 5` or are there any > restriction in the `base`, so we have to bump the version > one by one? > > Thanks, > Lei Zhu >

1 0

What makes C++ FFI painful?
by Hécate 01 Nov '24

01 Nov '24

Hi devs, Pardon me for the naïve question. I know that C++ FFI is *hard* in Haskell. From the perspective of an end-user I have heard that `text`'s new UTF-8 validation caused problems when released, as it relied on C++ code, but I never had any problems with it personally. From the GHC perspective, what makes C++ a difficult language to interface with? Cheers, Hécate -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

3 3