From ben at well-typed.com Wed Sep 13 19:43:49 2023 From: ben at well-typed.com (Ben Gamari) Date: Wed, 13 Sep 2023 15:43:49 -0400 Subject: GHC 9.8.1-alpha4 status Message-ID: <87zg1pq2oc.fsf@smart-cactus.org> Hi all, As noted in the 9.8.1 milestone, 9.8.1-alpha4 was slated for today. Unfortunately, ICFP travel has taken a bit more time than I anticipated and currently it is looking unlikely that the release will be ready today. Moreover, there are some rather important boot library fixes which are in the process of being merged upstream as we speak. For this reason, I have am delaying 9.8.1-alpha4. The current schedule is: * 19 Sept 2023 (next Tuesday): alpha 4 * 27 Sept 2023 (8 days later): release candidate * 4 Oct 2023 (7 days later): final release Apologies for the late notice. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Wed Sep 20 04:54:14 2023 From: ben at well-typed.com (Ben Gamari) Date: Wed, 20 Sep 2023 00:54:14 -0400 Subject: [ANNOUNCE] GHC 9.8.1-alpha4 is now available Message-ID: <87sf79o362.fsf@smart-cactus.org> The GHC developers are very pleased to announce the availability of the third alpha prerelease of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-alpha4 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeAbstractions` language extension, allowing types to be bound in type declarations [TypeAbstractions]. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes]. This alpha includes roughly 40 new commits relative to alpha 3, including what we believe should be nearly the last changes to GHC's boot libraries. 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. Happy compiling, ~ Ben [TypeAbstractions]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst [release notes]: https://downloads.haskell.org/ghc/9.8.1-alpha4/docs/users_guide/9.8.1-notes.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From bryan at haskell.foundation Wed Sep 20 14:07:01 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Wed, 20 Sep 2023 17:07:01 +0300 Subject: Release of GHC-9.6.3 is now being prepared Message-ID: You can follow or comment on the progress of the release at https://gitlab.haskell.org/ghc/ghc/-/issues/23759. -Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Fri Sep 22 22:34:54 2023 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 22 Sep 2023 19:34:54 -0300 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha4 is now available In-Reply-To: <87sf79o362.fsf@smart-cactus.org> References: <87sf79o362.fsf@smart-cactus.org> Message-ID: - #21570, Linker broken on M1 Mac, occurs on 9.8.1-alpha4. I have updated the bug. My guess is that it was never addressed as the info needed tag was never removed after the required info was supplied. It might be good to have a test for this. - On Wed, Sep 20, 2023 at 1:54 AM Ben Gamari wrote: > > The GHC developers are very pleased to announce the availability of the > third alpha prerelease of GHC 9.8.1. Binary distributions, source > distributions, and documentation are available at > > https://downloads.haskell.org/ghc/9.8.1-alpha4 > > GHC 9.8 will bring a number of new features and improvements, including: > > * Preliminary support the `TypeAbstractions` language extension, > allowing types to be bound in type declarations [TypeAbstractions]. > > * Support for the `ExtendedLiterals` extension, providing syntax for > non-word-sized numeric literals in the surface language > [extended-literals] > > * Improved rewrite rule matching behavior, allowing limited matching of > higher-order patterns > > * Better support for user-defined warnings by way of the `WARNING` > pragma [warnings] > > * The introduction of the new `GHC.TypeError.Unsatisfiable` > constraint, allowing more predictable user-defined type errors > [unsatisfiable] > > * Implementation of the export deprecation proposal, allowing module > exports to be marked with `DEPRECATE` pragmas [deprecated-exports] > > * The addition of build semaphore support for parallel compilation; > with coming support in `cabal-install` this will allow better use of > parallelism in multi-package builds [jsem] > > * More efficient representation of info table provenance information, > reducing binary sizes by over 50% in some cases when > `-finfo-table-map` is in use > > A full accounting of changes can be found in the [release notes]. > This alpha includes roughly 40 new commits relative to alpha 3, > including what we believe should be nearly the last changes to GHC's > boot libraries. > > 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. > > Happy compiling, > > ~ Ben > > [TypeAbstractions]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst > [extended-literals > ]: > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst > [unsatisfiable]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst > [warnings]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst > [deprecated-exports > ]: > > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst > [jsem]: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst > [release notes]: > https://downloads.haskell.org/ghc/9.8.1-alpha4/docs/users_guide/9.8.1-notes.html > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From george.colpitts at gmail.com Fri Sep 22 23:22:14 2023 From: george.colpitts at gmail.com (George Colpitts) Date: Fri, 22 Sep 2023 20:22:14 -0300 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha4 is now available In-Reply-To: References: <87sf79o362.fsf@smart-cactus.org> Message-ID: It seems unlikely that the current tests wouldn't find this bug. Is it the case that the tests are never run on aarch64-darwin Macs? On Fri, Sep 22, 2023 at 7:34 PM George Colpitts wrote: > > - > #21570, Linker broken on M1 Mac, occurs on 9.8.1-alpha4. I have > updated the bug. My guess is that it was never addressed as the info needed > tag was never removed after the required info was supplied. It might be > good to have a test for this. > > - > > > > On Wed, Sep 20, 2023 at 1:54 AM Ben Gamari wrote: > >> >> The GHC developers are very pleased to announce the availability of the >> third alpha prerelease of GHC 9.8.1. Binary distributions, source >> distributions, and documentation are available at >> >> https://downloads.haskell.org/ghc/9.8.1-alpha4 >> >> GHC 9.8 will bring a number of new features and improvements, including: >> >> * Preliminary support the `TypeAbstractions` language extension, >> allowing types to be bound in type declarations [TypeAbstractions]. >> >> * Support for the `ExtendedLiterals` extension, providing syntax for >> non-word-sized numeric literals in the surface language >> [extended-literals] >> >> * Improved rewrite rule matching behavior, allowing limited matching of >> higher-order patterns >> >> * Better support for user-defined warnings by way of the `WARNING` >> pragma [warnings] >> >> * The introduction of the new `GHC.TypeError.Unsatisfiable` >> constraint, allowing more predictable user-defined type errors >> [unsatisfiable] >> >> * Implementation of the export deprecation proposal, allowing module >> exports to be marked with `DEPRECATE` pragmas [deprecated-exports] >> >> * The addition of build semaphore support for parallel compilation; >> with coming support in `cabal-install` this will allow better use of >> parallelism in multi-package builds [jsem] >> >> * More efficient representation of info table provenance information, >> reducing binary sizes by over 50% in some cases when >> `-finfo-table-map` is in use >> >> A full accounting of changes can be found in the [release notes]. >> This alpha includes roughly 40 new commits relative to alpha 3, >> including what we believe should be nearly the last changes to GHC's >> boot libraries. >> >> 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. >> >> Happy compiling, >> >> ~ Ben >> >> [TypeAbstractions]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst >> [extended-literals >> ]: >> >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst >> [unsatisfiable]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst >> [warnings]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst >> [deprecated-exports >> ]: >> >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst >> [jsem]: >> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst >> [release notes]: >> https://downloads.haskell.org/ghc/9.8.1-alpha4/docs/users_guide/9.8.1-notes.html >> _______________________________________________ >> Haskell-Cafe mailing list >> To (un)subscribe, modify options or view archives go to: >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> Only members subscribed via the mailman list are allowed to post. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Sat Sep 23 00:33:58 2023 From: ben at well-typed.com (Ben Gamari) Date: Fri, 22 Sep 2023 20:33:58 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha4 is now available In-Reply-To: References: <87sf79o362.fsf@smart-cactus.org> Message-ID: <87wmwhn2xa.fsf@smart-cactus.org> George Colpitts writes: > It seems unlikely that the current tests wouldn't find this bug. Is it the > case that the tests are never run on aarch64-darwin Macs? > The tests are certainly run; see, for instance, the 9.8.1-alpha4 release pipeline [1]. The problem is that #21570 requires very particular (mis)configuration of the host toolchain (e.g. Richard had multiple, incompatible toolchains in PATH). We can usually side-step this sort of misconfiguration by disabling the `configure` script's ld-override logic, since we using anything but Apple's linker is generally a bad idea on Darwin. This measure (!8437) is present in the 9.8 branch so I can only guess that something else is wrong. Perhaps you could open a ticket and attach config.log? Cheers, - Ben [1]: https://gitlab.haskell.org/ghc/ghc/-/jobs/1668689 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From carter.schonwald at gmail.com Sat Sep 23 17:06:15 2023 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sat, 23 Sep 2023 13:06:15 -0400 Subject: [Haskell-cafe] [ANNOUNCE] GHC 9.8.1-alpha4 is now available In-Reply-To: <87wmwhn2xa.fsf@smart-cactus.org> References: <87sf79o362.fsf@smart-cactus.org> <87wmwhn2xa.fsf@smart-cactus.org> Message-ID: George can you share the generated settings file? On Fri, Sep 22, 2023 at 8:34 PM Ben Gamari wrote: > George Colpitts writes: > > > It seems unlikely that the current tests wouldn't find this bug. Is it > the > > case that the tests are never run on aarch64-darwin Macs? > > > The tests are certainly run; see, for instance, the 9.8.1-alpha4 release > pipeline [1]. > > The problem is that #21570 requires very particular (mis)configuration > of the host toolchain (e.g. Richard had multiple, incompatible > toolchains in PATH). We can usually side-step this sort of > misconfiguration by disabling the `configure` script's ld-override > logic, since we using anything but Apple's linker is generally a bad > idea on Darwin. This measure (!8437) is present in the 9.8 branch so I can > only > guess that something else is wrong. > > Perhaps you could open a ticket and attach config.log? > > Cheers, > > - Ben > > > [1]: https://gitlab.haskell.org/ghc/ghc/-/jobs/1668689 > _______________________________________________ > Haskell-Cafe mailing list > To (un)subscribe, modify options or view archives go to: > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > Only members subscribed via the mailman list are allowed to post. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Mon Sep 25 16:22:41 2023 From: ben at well-typed.com (Ben Gamari) Date: Mon, 25 Sep 2023 12:22:41 -0400 Subject: GitLab upgrade later today Message-ID: <87pm26mddd.fsf@smart-cactus.org> Hi all, I will be performing a GitLab upgrade later this evening (likely around 18:00 EDT). I expect this will take only a few minutes. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From bryan at haskell.foundation Mon Sep 25 19:30:06 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Mon, 25 Sep 2023 22:30:06 +0300 Subject: [ANNOUNCE] GHC 9.6.3 is now available Message-ID: The GHC developers are happy to announce the availability of GHC 9.6.3. Binary distributions, source distributions, and documentation are available on the release page. https://www.haskell.org/ghc/download_ghc_9_6_3.html This release is primarily a bugfix release addressing a few issues found in the 9.6 series. These include: * Disable Polymorphic Specialisation (a performance optimisation) by default. It was discovered that Polymorphic Specialisation as currently implemented in GHC can lead to hard to diagnose bugs resulting in incorrect runtime results. Users wishing to use this optimisation despite the caveats will now have to explicitly enable the new `-fpolymorphic-specialisation` flag. For more details see #23469 as well as #23109, #21229, #23445. * Improve compile time and code generation performance when `-finfo-table-map` is enabled (#23103). * Make the recompilation check more robust when code generation flags are changed (#23369). * Addition of memory barriers that improve soundness on platforms with weak memory ordering. * And dozens of other fixes. A full accounting of changes can be found in the [release notes]. As some of the fixed issues do affect correctness users are encouraged to upgrade promptly. We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake pool, Well-Typed, Tweag I/O, Serokell, Equinix, SimSpace, 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 [GHC ticket] if you see anything amiss. Enjoy! -Bryan [release notes]: https://downloads.haskell.org/~ghc/9.6.3/docs/users_guide/9.6.3-notes.html [GHC ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new From ben at well-typed.com Mon Sep 25 22:33:30 2023 From: ben at well-typed.com (Ben Gamari) Date: Mon, 25 Sep 2023 18:33:30 -0400 Subject: GitLab upgrade later today In-Reply-To: <87pm26mddd.fsf@smart-cactus.org> References: <87pm26mddd.fsf@smart-cactus.org> Message-ID: <87a5t9nart.fsf@smart-cactus.org> Ben Gamari writes: > Hi all, > > I will be performing a GitLab upgrade later this evening (likely around > 18:00 EDT). I expect this will take only a few minutes. > The upgrade is complete. As always, let me know if anything looks amiss. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Wed Sep 27 23:04:50 2023 From: ben at well-typed.com (Ben Gamari) Date: Wed, 27 Sep 2023 19:04:50 -0400 Subject: GHC 9.8.1-rc1 delayed Message-ID: <87msx7kyk1.fsf@smart-cactus.org> Hi all, Due to a rather late-breaking boot library mix-up I will need to delay the 9.8.1 release candidate by at least two days. I will provide a more specific timeline tomorrow when there is more clarity on what needs to happen to resolve the situation. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From bryan at haskell.foundation Thu Sep 28 06:56:06 2023 From: bryan at haskell.foundation (Bryan Richter) Date: Thu, 28 Sep 2023 09:56:06 +0300 Subject: How do you keep tabs on commits that fix issues? Message-ID: I am not sure of the best ways for checking if a certain issue has been fixed on a certain release. My past ways of using git run into certain problems: The commit (or commits!) that fix an issue get rewritten once by Marge as they are rebased onto master, and then potentially a second time as they are cherry-picked onto release branches. So just following the original commits doesn't work. If a commit mentions the issue it fixes, you might get some clues as to where it has ended up from GitLab. But those clues are often drowning in irrelevant mentions: each failed Marge batch, for instance, of which there can be many. The only other thing I can think to do is look at the original merge request, pluck out the commit messages, and use git to search for commits by commit message and check each one for which branches contain it. But then I also need to know the context of the fix to know whether I should also be looking for other, logically related commits, and repeat the dance. (Sometimes fixes are only partially applied to certain releases, exacerbating the need for knowing the context.) This seems like a mechanism that can't rely on trusting the author of the original set of patches (which may be your past self) and instead requires a deep understanding to be brought to bear every time you would want to double check the situation. So it's not very scalable and I wouldn't expect many people to be able to do it. Are there better mechanisms already available? As I've said before, I am used to a different git workflow and I'm still learning how to use the one used by GHC. I'd like to know how others handle it. Thanks! -Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgbailey at gmail.com Thu Sep 28 21:54:41 2023 From: jgbailey at gmail.com (Justin Bailey) Date: Thu, 28 Sep 2023 14:54:41 -0700 Subject: How do you keep tabs on commits that fix issues? In-Reply-To: References: Message-ID: I would also love to know how to do this. I don't often contribute to GHC, but I follow bug fixes closely. In fact, the one time I did contribute ( https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10245), it turned out i was duplicating work already done elsewhere! If I had known how to understand if the issue I wanted fixed ( https://gitlab.haskell.org/ghc/ghc/-/issues/22516) was backported, it would have saved me and the maintainers' time. On Wed, Sep 27, 2023 at 11:56 PM Bryan Richter via ghc-devs < ghc-devs at haskell.org> wrote: > I am not sure of the best ways for checking if a certain issue has been > fixed on a certain release. My past ways of using git run into certain > problems: > > The commit (or commits!) that fix an issue get rewritten once by Marge as > they are rebased onto master, and then potentially a second time as they > are cherry-picked onto release branches. So just following the original > commits doesn't work. > > If a commit mentions the issue it fixes, you might get some clues as to > where it has ended up from GitLab. But those clues are often drowning in > irrelevant mentions: each failed Marge batch, for instance, of which there > can be many. > > The only other thing I can think to do is look at the original merge > request, pluck out the commit messages, and use git to search for commits > by commit message and check each one for which branches contain it. But > then I also need to know the context of the fix to know whether I should > also be looking for other, logically related commits, and repeat the dance. > (Sometimes fixes are only partially applied to certain releases, > exacerbating the need for knowing the context.) This seems like a mechanism > that can't rely on trusting the author of the original set of patches > (which may be your past self) and instead requires a deep understanding to > be brought to bear every time you would want to double check the situation. > So it's not very scalable and I wouldn't expect many people to be able to > do it. > > Are there better mechanisms already available? As I've said before, I am > used to a different git workflow and I'm still learning how to use the one > used by GHC. I'd like to know how others handle it. > > Thanks! > > -Bryan > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Thu Sep 28 22:09:41 2023 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 28 Sep 2023 22:09:41 +0000 Subject: How do you keep tabs on commits that fix issues? In-Reply-To: References: Message-ID: I know if I backport anything I use 'git cherry-pick -x' which puts a reference to the original commit in the message. I am not sure how general that is though Alan On Thu, 28 Sept 2023 at 21:55, Justin Bailey wrote: > I would also love to know how to do this. I don't often contribute to GHC, > but I follow bug fixes closely. In fact, the one time I did contribute ( > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10245), it turned out > i was duplicating work already done elsewhere! If I had known how to > understand if the issue I wanted fixed ( > https://gitlab.haskell.org/ghc/ghc/-/issues/22516) was backported, it > would have saved me and the maintainers' time. > > On Wed, Sep 27, 2023 at 11:56 PM Bryan Richter via ghc-devs < > ghc-devs at haskell.org> wrote: > >> I am not sure of the best ways for checking if a certain issue has been >> fixed on a certain release. My past ways of using git run into certain >> problems: >> >> The commit (or commits!) that fix an issue get rewritten once by Marge as >> they are rebased onto master, and then potentially a second time as they >> are cherry-picked onto release branches. So just following the original >> commits doesn't work. >> >> If a commit mentions the issue it fixes, you might get some clues as to >> where it has ended up from GitLab. But those clues are often drowning in >> irrelevant mentions: each failed Marge batch, for instance, of which there >> can be many. >> >> The only other thing I can think to do is look at the original merge >> request, pluck out the commit messages, and use git to search for commits >> by commit message and check each one for which branches contain it. But >> then I also need to know the context of the fix to know whether I should >> also be looking for other, logically related commits, and repeat the dance. >> (Sometimes fixes are only partially applied to certain releases, >> exacerbating the need for knowing the context.) This seems like a mechanism >> that can't rely on trusting the author of the original set of patches >> (which may be your past self) and instead requires a deep understanding to >> be brought to bear every time you would want to double check the situation. >> So it's not very scalable and I wouldn't expect many people to be able to >> do it. >> >> Are there better mechanisms already available? As I've said before, I am >> used to a different git workflow and I'm still learning how to use the one >> used by GHC. I'd like to know how others handle it. >> >> Thanks! >> >> -Bryan >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davean at xkcd.com Thu Sep 28 22:12:53 2023 From: davean at xkcd.com (davean) Date: Thu, 28 Sep 2023 18:12:53 -0400 Subject: How do you keep tabs on commits that fix issues? In-Reply-To: References: Message-ID: Yah, I get very confused with how ghc manages commits. I've ended up searching for the patches at times. I'd love a sensible approach. On Thu, Sep 28, 2023, 17:55 Justin Bailey wrote: > I would also love to know how to do this. I don't often contribute to GHC, > but I follow bug fixes closely. In fact, the one time I did contribute ( > https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10245), it turned out > i was duplicating work already done elsewhere! If I had known how to > understand if the issue I wanted fixed ( > https://gitlab.haskell.org/ghc/ghc/-/issues/22516) was backported, it > would have saved me and the maintainers' time. > > On Wed, Sep 27, 2023 at 11:56 PM Bryan Richter via ghc-devs < > ghc-devs at haskell.org> wrote: > >> I am not sure of the best ways for checking if a certain issue has been >> fixed on a certain release. My past ways of using git run into certain >> problems: >> >> The commit (or commits!) that fix an issue get rewritten once by Marge as >> they are rebased onto master, and then potentially a second time as they >> are cherry-picked onto release branches. So just following the original >> commits doesn't work. >> >> If a commit mentions the issue it fixes, you might get some clues as to >> where it has ended up from GitLab. But those clues are often drowning in >> irrelevant mentions: each failed Marge batch, for instance, of which there >> can be many. >> >> The only other thing I can think to do is look at the original merge >> request, pluck out the commit messages, and use git to search for commits >> by commit message and check each one for which branches contain it. But >> then I also need to know the context of the fix to know whether I should >> also be looking for other, logically related commits, and repeat the dance. >> (Sometimes fixes are only partially applied to certain releases, >> exacerbating the need for knowing the context.) This seems like a mechanism >> that can't rely on trusting the author of the original set of patches >> (which may be your past self) and instead requires a deep understanding to >> be brought to bear every time you would want to double check the situation. >> So it's not very scalable and I wouldn't expect many people to be able to >> do it. >> >> Are there better mechanisms already available? As I've said before, I am >> used to a different git workflow and I'm still learning how to use the one >> used by GHC. I'd like to know how others handle it. >> >> Thanks! >> >> -Bryan >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From klebinger.andreas at gmx.at Thu Sep 28 22:26:37 2023 From: klebinger.andreas at gmx.at (Andreas Klebinger) Date: Fri, 29 Sep 2023 00:26:37 +0200 Subject: How do you keep tabs on commits that fix issues? In-Reply-To: References: Message-ID: Personally I try to include fixes #1234 in the commit so then I can just check which tags contain a commit mentioning the issue. If the issue isn't mentioned in the commit I usually look at the issue -> look for related mrs -> look for the commit with the fix -> grep for the commit message of the commit or look for the marge MR mentioned on the mr. Am 28/09/2023 um 08:56 schrieb Bryan Richter via ghc-devs: > I am not sure of the best ways for checking if a certain issue has > been fixed on a certain release. My past ways of using git run into > certain problems: > > The commit (or commits!) that fix an issue get rewritten once by Marge > as they are rebased onto master, and then potentially a second time as > they are cherry-picked onto release branches. So just following the > original commits doesn't work. > > If a commit mentions the issue it fixes, you might get some clues as > to where it has ended up from GitLab. But those clues are often > drowning in irrelevant mentions: each failed Marge batch, for > instance, of which there can be many. > > The only other thing I can think to do is look at the original merge > request, pluck out the commit messages, and use git to search for > commits by commit message and check each one for which branches > contain it. But then I also need to know the context of the fix to > know whether I should also be looking for other, logically related > commits, and repeat the dance. (Sometimes fixes are only partially > applied to certain releases, exacerbating the need for knowing the > context.) This seems like a mechanism that can't rely on trusting the > author of the original set of patches (which may be your past self) > and instead requires a deep understanding to be brought to bear every > time you would want to double check the situation. So it's not very > scalable and I wouldn't expect many people to be able to do it. > > Are there better mechanisms already available? As I've said before, I > am used to a different git workflow and I'm still learning how to use > the one used by GHC. I'd like to know how others handle it. > > Thanks! > > -Bryan > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From moritz.angermann at gmail.com Thu Sep 28 22:34:51 2023 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Fri, 29 Sep 2023 06:34:51 +0800 Subject: How do you keep tabs on commits that fix issues? In-Reply-To: References: Message-ID: I usually end up looking at the source I’m actually compiling and checking if the expected changes are in the source or not. If not, I end up backporting stuff to the source at hand. As this is often for compilers that are way past their end of life cycle (e.g. 8.10), there seems little point in the overhead of upstreaming it. I do agree with Alan that chery-pick -x is often the right approach to keep track of where things originally came from. I also agree with Andreas that having the ticket ids in the coming message helps when searching. Moritz On Fri, 29 Sep 2023 at 6:27 AM, Andreas Klebinger wrote: > Personally I try to include fixes #1234 in the commit so then I can just > check which tags contain a commit mentioning the issue. > > If the issue isn't mentioned in the commit I usually look at the issue > -> look for related mrs -> look for the commit with the fix -> grep for > the commit message of the commit or look for the marge MR mentioned on > the mr. > > Am 28/09/2023 um 08:56 schrieb Bryan Richter via ghc-devs: > > I am not sure of the best ways for checking if a certain issue has > > been fixed on a certain release. My past ways of using git run into > > certain problems: > > > > The commit (or commits!) that fix an issue get rewritten once by Marge > > as they are rebased onto master, and then potentially a second time as > > they are cherry-picked onto release branches. So just following the > > original commits doesn't work. > > > > If a commit mentions the issue it fixes, you might get some clues as > > to where it has ended up from GitLab. But those clues are often > > drowning in irrelevant mentions: each failed Marge batch, for > > instance, of which there can be many. > > > > The only other thing I can think to do is look at the original merge > > request, pluck out the commit messages, and use git to search for > > commits by commit message and check each one for which branches > > contain it. But then I also need to know the context of the fix to > > know whether I should also be looking for other, logically related > > commits, and repeat the dance. (Sometimes fixes are only partially > > applied to certain releases, exacerbating the need for knowing the > > context.) This seems like a mechanism that can't rely on trusting the > > author of the original set of patches (which may be your past self) > > and instead requires a deep understanding to be brought to bear every > > time you would want to double check the situation. So it's not very > > scalable and I wouldn't expect many people to be able to do it. > > > > Are there better mechanisms already available? As I've said before, I > > am used to a different git workflow and I'm still learning how to use > > the one used by GHC. I'd like to know how others handle it. > > > > Thanks! > > > > -Bryan > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Fri Sep 29 15:23:15 2023 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 29 Sep 2023 11:23:15 -0400 Subject: How do you keep tabs on commits that fix issues? In-Reply-To: References: Message-ID: <871qehknq7.fsf@smart-cactus.org> Bryan Richter via ghc-devs writes: > I am not sure of the best ways for checking if a certain issue has been > fixed on a certain release. My past ways of using git run into certain > problems: > > The commit (or commits!) that fix an issue get rewritten once by Marge as > they are rebased onto master, and then potentially a second time as they > are cherry-picked onto release branches. So just following the original > commits doesn't work. > > If a commit mentions the issue it fixes, you might get some clues as to > where it has ended up from GitLab. But those clues are often drowning in > irrelevant mentions: each failed Marge batch, for instance, of which there > can be many. > > The only other thing I can think to do is look at the original merge > request, pluck out the commit messages, and use git to search for commits > by commit message and check each one for which branches contain it. But > then I also need to know the context of the fix to know whether I should > also be looking for other, logically related commits, and repeat the dance. > (Sometimes fixes are only partially applied to certain releases, > exacerbating the need for knowing the context.) This seems like a mechanism > that can't rely on trusting the author of the original set of patches > (which may be your past self) and instead requires a deep understanding to > be brought to bear every time you would want to double check the situation. > So it's not very scalable and I wouldn't expect many people to be able to > do it. > > Are there better mechanisms already available? As I've said before, I am > used to a different git workflow and I'm still learning how to use the one > used by GHC. I'd like to know how others handle it. > In general Marge leaves a helpful comment with the final SHA on each pull request they merge to master. If I want to know whether an issue is fixed in a stable branch, I will typically: 1. find the issue, which should have a reference to the merge requests which fixed it 2. from the merge request, find the final commit SHA from Marge's comment 3. look for references to that commit SHA in the appropriate branch. (3) works because in general we cherry-pick backports with the `-x` flag, which causes a "(cherry-picked from ...)` comment to be appended to the commit message. Moreover, reverts should also mention the commit being reverted. Does this help? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Fri Sep 29 16:20:35 2023 From: ben at well-typed.com (Ben Gamari) Date: Fri, 29 Sep 2023 12:20:35 -0400 Subject: GHC 9.8.1-rc1 delayed In-Reply-To: <87msx7kyk1.fsf@smart-cactus.org> References: <87msx7kyk1.fsf@smart-cactus.org> Message-ID: <87y1gpj6ia.fsf@smart-cactus.org> Ben Gamari writes: > Hi all, > > Due to a rather late-breaking boot library mix-up I will need to delay > the 9.8.1 release candidate by at least two days. I will provide a more > specific timeline tomorrow when there is more clarity on what needs to > happen to resolve the situation. > Hi all, After yet another false-start it is looking like a release will likely be feasible today. Do expect an announcement later within a few hours. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at well-typed.com Fri Sep 29 21:55:37 2023 From: ben at well-typed.com (Ben Gamari) Date: Fri, 29 Sep 2023 17:55:37 -0400 Subject: [ANNOUNCE] GHC 9.8.1-rc1 is now available Message-ID: <87v8bsk5ka.fsf@smart-cactus.org> The GHC developers are very pleased to announce the availability of the release candidate of GHC 9.8.1. Binary distributions, source distributions, and documentation are available at https://downloads.haskell.org/ghc/9.8.1-rc1 GHC 9.8 will bring a number of new features and improvements, including: * Preliminary support the `TypeAbstractions` language extension, allowing types to be bound in type declarations [TypeAbstractions]. * Support for the `ExtendedLiterals` extension, providing syntax for non-word-sized numeric literals in the surface language [extended-literals] * Improved rewrite rule matching behavior, allowing limited matching of higher-order patterns * Better support for user-defined warnings by way of the `WARNING` pragma [warnings] * The introduction of the new `GHC.TypeError.Unsatisfiable` constraint, allowing more predictable user-defined type errors [unsatisfiable] * Implementation of the export deprecation proposal, allowing module exports to be marked with `DEPRECATE` pragmas [deprecated-exports] * The addition of build semaphore support for parallel compilation; with coming support in `cabal-install` this will allow better use of parallelism in multi-package builds [jsem] * More efficient representation of info table provenance information, reducing binary sizes by over 50% in some cases when `-finfo-table-map` is in use A full accounting of changes can be found in the [release notes]. This candidate includes roughly 20 new commits relative to alpha 4, including what we believe should be nearly the last changes to GHC's boot libraries. As always, GHC's release status 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. Happy compiling, ~ Ben [TypeAbstractions]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0425-decl-invis-binders.rst [extended-literals]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0451-sized-literals.rst [unsatisfiable]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0433-unsatisfiable.rst [warnings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0541-warning-pragmas-with-categories.rst [deprecated-exports]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0134-deprecating-exports-proposal.rst [jsem]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0540-jsem.rst [release notes]: https://downloads.haskell.org/ghc/9.8.1-alpha4/docs/users_guide/9.8.1-notes.html [status]: https://gitlab.haskell.org/ghc/ghc/-/wikis/GHC-status -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: