From facundo.dominguez at tweag.io  Mon Dec  2 15:14:56 2024
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Mon, 2 Dec 2024 12:14:56 -0300
Subject: Cannot get nightly builds of GHC
Message-ID: <CADvOm+oJnr6CS94GjUV+q3H8m1O7nT0Z_zJ5QnHvAJiQXqEK-Q@mail.gmail.com>

Dear devs,

Nightly builds of Liquid Haskell seem to be failing because
https://ghc.gitlab.haskell.org gives 502 bad gateway. LH needs
https://ghc.gitlab.haskell.org/ghcup-metadata/ghcup-nightlies-0.0.7.yaml

Is there anyone I should tell about it?

Thanks,
Facundo

-- 
All views and opinions expressed in this email message are the
personal opinions of the author and do not represent those of the
organization or its customers.

From ben at smart-cactus.org  Mon Dec  2 22:05:54 2024
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 02 Dec 2024 17:05:54 -0500
Subject: GitLab downtime in 55 minutes
Message-ID: <8734j5oi4n.fsf@smart-cactus.org>

Hi all,

At 18:00 EST I will take GitLab down for a few minutes to complete a
filesystem migration, hopefully at last freeing us from the disk space
issue which has been plauguing us lately.

I will sent notification when the migration is finished and things are
back to normal.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241202/ebf2c0d1/attachment.sig>

From ben at smart-cactus.org  Mon Dec  2 22:57:36 2024
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 02 Dec 2024 17:57:36 -0500
Subject: Beginning of GitLab maintenance
Message-ID: <87zfldn16g.fsf@smart-cactus.org>


Just a reminder that GitLab will be going down in just a moment.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241202/aa40fe2f/attachment.sig>

From ben at smart-cactus.org  Mon Dec  2 23:02:21 2024
From: ben at smart-cactus.org (Ben Gamari)
Date: Mon, 02 Dec 2024 18:02:21 -0500
Subject: Beginning of GitLab maintenance
In-Reply-To: <87zfldn16g.fsf@smart-cactus.org>
References: <87zfldn16g.fsf@smart-cactus.org>
Message-ID: <87wmghn0y5.fsf@smart-cactus.org>

Ben Gamari <ben at smart-cactus.org> writes:

> Just a reminder that GitLab will be going down in just a moment.
>
I have finished the migration. GitLab service should now be back to
normal.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241202/f3f9d1de/attachment.sig>

From ben at well-typed.com  Tue Dec  3 00:52:22 2024
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 02 Dec 2024 19:52:22 -0500
Subject: GHC 9.8.4 is now available
Message-ID: <87mshd611p.fsf@smart-cactus.org>


The GHC developers are happy to announce the availability of GHC 9.8.4.
Binary distributions, source distributions, and documentation are
available on the [release] page.

This release is a small release fixing a few issues noted in 9.8.3,
including:

* Update the `filepath` submodule to avoid a misbehavior of
  `splitFileName` under Windows.

* Update the `unix` submodule to fix a compilation issue on `musl` platforms

* Fix a potential source of miscompilation when building large projects
  on 32-bit platforms

* Fix unsound optimisation of `prompt#` uses

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 [ticket] if you see
anything amiss.

Happy compiling!

- Ben


[release]: https://www.haskell.org/ghc/download_ghc_9_8_4.html
[ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
[release notes]: https://downloads.haskell.org/~ghc/9.8.4/docs/users_guide/9.8.4-notes.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241202/cf30987d/attachment.sig>

From adi.obilisetty at gmail.com  Wed Dec  4 09:36:39 2024
From: adi.obilisetty at gmail.com (Adithya Kumar)
Date: Wed, 4 Dec 2024 15:06:39 +0530
Subject: Missing Enum instance for IoSubSystem
Message-ID: <CAMh=VimhKEVsb_RHGfknHQg1dc383X+whbPQ0f1015acASGdNw@mail.gmail.com>

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-notes.html

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241204/9df696d2/attachment.html>

From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk  Wed Dec  4 10:13:41 2024
From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 4 Dec 2024 10:13:41 +0000
Subject: Missing Enum instance for IoSubSystem
In-Reply-To: <CAMh=VimhKEVsb_RHGfknHQg1dc383X+whbPQ0f1015acASGdNw@mail.gmail.com>
References: <CAMh=VimhKEVsb_RHGfknHQg1dc383X+whbPQ0f1015acASGdNw@mail.gmail.com>
Message-ID: <Z1ArVQYWOM0WZza/@cloudinit-builder>

As a core libraries committee member I can say this was probably not
intentional (at least, I wouldn't have voted for it).  Perhaps it is
related to:

https://github.com/haskell/core-libraries-committee/issues/289

But the situation is strange, because it seems like the instance was
removed in 2022:

https://gitlab.haskell.org/ghc/ghc/-/commit/85b0f87a298c8e54b06a8f8c6ce88669c5cad3bc#f7c61f967f2b5c4951224837ae809183449da146_116_105

So I don't understand why it still seems to exist in base-4.20.0.1:

https://hackage.haskell.org/package/base-4.20.0.1/docs/GHC-RTS-Flags.html#t:IoSubSystem

and why the source location still seems to contain it:

https://hackage.haskell.org/package/ghc-internal-9.1001.0/docs/src/GHC.Internal.RTS.Flags.html#IoSubSystem

Tom



On Wed, Dec 04, 2024 at 03:06:39PM +0530, Adithya Kumar wrote:
> 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-notes.html
> 
> 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

> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From zubin at well-typed.com  Wed Dec  4 10:17:06 2024
From: zubin at well-typed.com (Zubin Duggal)
Date: Wed, 4 Dec 2024 15:47:06 +0530
Subject: Missing Enum instance for IoSubSystem
In-Reply-To: <Z1ArVQYWOM0WZza/@cloudinit-builder>
References: <CAMh=VimhKEVsb_RHGfknHQg1dc383X+whbPQ0f1015acASGdNw@mail.gmail.com>
 <Z1ArVQYWOM0WZza/@cloudinit-builder>
Message-ID: <6qv367stneidxor6my6luxi6j7ym2wb4l4zttw5wvskp44vvgi@dj4vnyctlewh>

>But the situation is strange, because it seems like the instance was
>removed in 2022:
>
>https://gitlab.haskell.org/ghc/ghc/-/commit/85b0f87a298c8e54b06a8f8c6ce88669c5cad3bc#f7c61f967f2b5c4951224837ae809183449da146_116_105
>
>So I don't understand why it still seems to exist in base-4.20.0.1:


That patch only landed in April 2024

From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk  Wed Dec  4 10:21:54 2024
From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 4 Dec 2024 10:21:54 +0000
Subject: Missing Enum instance for IoSubSystem
In-Reply-To: <6qv367stneidxor6my6luxi6j7ym2wb4l4zttw5wvskp44vvgi@dj4vnyctlewh>
References: <CAMh=VimhKEVsb_RHGfknHQg1dc383X+whbPQ0f1015acASGdNw@mail.gmail.com>
 <Z1ArVQYWOM0WZza/@cloudinit-builder>
 <6qv367stneidxor6my6luxi6j7ym2wb4l4zttw5wvskp44vvgi@dj4vnyctlewh>
Message-ID: <Z1AtQlMuLZqw7NzL@cloudinit-builder>

On Wed, Dec 04, 2024 at 03:47:06PM +0530, Zubin Duggal wrote:
> > But the situation is strange, because it seems like the instance was
> > removed in 2022:
> > 
> > https://gitlab.haskell.org/ghc/ghc/-/commit/85b0f87a298c8e54b06a8f8c6ce88669c5cad3bc#f7c61f967f2b5c4951224837ae809183449da146_116_105
> > 
> > So I don't understand why it still seems to exist in base-4.20.0.1:
> 
> That patch only landed in April 2024

Ah, that would explain it.  Is there a way of seeing in the repo the
commit from which a release was made?  I don't see any tags
corresponding to released versions (although I do see ghc-9.7-start,
ghc-9.9-start, etc.).

Tom


From zubin at well-typed.com  Wed Dec  4 10:30:03 2024
From: zubin at well-typed.com (Zubin Duggal)
Date: Wed, 4 Dec 2024 16:00:03 +0530
Subject: Missing Enum instance for IoSubSystem
In-Reply-To: <Z1AtQlMuLZqw7NzL@cloudinit-builder>
References: <CAMh=VimhKEVsb_RHGfknHQg1dc383X+whbPQ0f1015acASGdNw@mail.gmail.com>
 <Z1ArVQYWOM0WZza/@cloudinit-builder>
 <6qv367stneidxor6my6luxi6j7ym2wb4l4zttw5wvskp44vvgi@dj4vnyctlewh>
 <Z1AtQlMuLZqw7NzL@cloudinit-builder>
Message-ID: <uya3bav7qxwhpokuo4ojjai6rkdcdk6nu5khzmporr3wjmsyab@ugqenizv6xwo>

You can see the branches and tags the commit was a part of.
For this commit, that is the branches ghc-9.12 and master
and the tags ghc-9.12.1-alpha1 ghc-9.12.1-alpha2 ghc-9.12.1-alpha3 ghc-9.12.1-rc1 ghc-9.13-start

So this commit hasn't made it into any release yet and will
be first released in GHC 9.12

On 24/12/04 10:21, Tom Ellis wrote:
>On Wed, Dec 04, 2024 at 03:47:06PM +0530, Zubin Duggal wrote:
>> > But the situation is strange, because it seems like the instance was
>> > removed in 2022:
>> >
>> > https://gitlab.haskell.org/ghc/ghc/-/commit/85b0f87a298c8e54b06a8f8c6ce88669c5cad3bc#f7c61f967f2b5c4951224837ae809183449da146_116_105
>> >
>> > So I don't understand why it still seems to exist in base-4.20.0.1:
>>
>> That patch only landed in April 2024
>
>Ah, that would explain it.  Is there a way of seeing in the repo the
>commit from which a release was made?  I don't see any tags
>corresponding to released versions (although I do see ghc-9.7-start,
>ghc-9.9-start, etc.).
>
>Tom
>
>_______________________________________________
>ghc-devs mailing list
>ghc-devs at haskell.org
>http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk  Wed Dec  4 10:35:36 2024
From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 4 Dec 2024 10:35:36 +0000
Subject: Missing Enum instance for IoSubSystem
In-Reply-To: <uya3bav7qxwhpokuo4ojjai6rkdcdk6nu5khzmporr3wjmsyab@ugqenizv6xwo>
References: <CAMh=VimhKEVsb_RHGfknHQg1dc383X+whbPQ0f1015acASGdNw@mail.gmail.com>
 <Z1ArVQYWOM0WZza/@cloudinit-builder>
 <6qv367stneidxor6my6luxi6j7ym2wb4l4zttw5wvskp44vvgi@dj4vnyctlewh>
 <Z1AtQlMuLZqw7NzL@cloudinit-builder>
 <uya3bav7qxwhpokuo4ojjai6rkdcdk6nu5khzmporr3wjmsyab@ugqenizv6xwo>
Message-ID: <Z1AweK23IaF+/9yO@cloudinit-builder>

On Wed, Dec 04, 2024 at 04:00:03PM +0530, Zubin Duggal wrote:
> You can see the branches and tags the commit was a part of.
> For this commit, that is the branches ghc-9.12 and master
> and the tags ghc-9.12.1-alpha1 ghc-9.12.1-alpha2 ghc-9.12.1-alpha3 ghc-9.12.1-rc1 ghc-9.13-start

Ah, it seems I needed to do `git fetch --tags` to get all the tags.

Thanks,

Tom



From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk  Wed Dec  4 10:44:13 2024
From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 4 Dec 2024 10:44:13 +0000
Subject: Missing Enum instance for IoSubSystem
In-Reply-To: <6qv367stneidxor6my6luxi6j7ym2wb4l4zttw5wvskp44vvgi@dj4vnyctlewh>
References: <CAMh=VimhKEVsb_RHGfknHQg1dc383X+whbPQ0f1015acASGdNw@mail.gmail.com>
 <Z1ArVQYWOM0WZza/@cloudinit-builder>
 <6qv367stneidxor6my6luxi6j7ym2wb4l4zttw5wvskp44vvgi@dj4vnyctlewh>
Message-ID: <Z1Ayfbfkk1WFtqTH@cloudinit-builder>

On Wed, Dec 04, 2024 at 03:47:06PM +0530, Zubin Duggal wrote:
> > But the situation is strange, because it seems like the instance was
> > removed in 2022:
> > 
> > https://gitlab.haskell.org/ghc/ghc/-/commit/85b0f87a298c8e54b06a8f8c6ce88669c5cad3bc#f7c61f967f2b5c4951224837ae809183449da146_116_105
> > 
> > So I don't understand why it still seems to exist in base-4.20.0.1:
> 
> That patch only landed in April 2024

There is test in place to confirm that the API of base does not change
accidentally.  The test correctly caught the removal of this instance:

https://gitlab.haskell.org/ghc/ghc/-/commit/1adc6fa43e0c2f577c15f560d767c7af9eec2c04#2ca7b1d6bb24cd05ca30a428efb924268c8dbc51_11689_11690

Howewer, the commit was nontheless merged with the commit message

> Accept changes to base-exports
>
> All the changes are in fact not changes at all.
>
> Previously, the IoSubSystem data type was defined in GHC.RTS.Flags and
> exported from both GHC.RTS.Flags and GHC.IO.SubSystem. Now, the data
> type is defined in GHC.IO.SubSystem and still exported from both
> modules.
>
> Therefore, the same exports and same instances are still available
> from both modules.

In retrospect, that sounds incorrect, doesn't it?

(I believe we now rule out
https://github.com/haskell/core-libraries-committee/issues/289 as
implicated)

Tom

From tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk  Wed Dec  4 17:53:15 2024
From: tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk (Tom Ellis)
Date: Wed, 4 Dec 2024 17:53:15 +0000
Subject: Missing Enum instance for IoSubSystem
In-Reply-To: <Z1Ayfbfkk1WFtqTH@cloudinit-builder>
References: <CAMh=VimhKEVsb_RHGfknHQg1dc383X+whbPQ0f1015acASGdNw@mail.gmail.com>
 <Z1ArVQYWOM0WZza/@cloudinit-builder>
 <6qv367stneidxor6my6luxi6j7ym2wb4l4zttw5wvskp44vvgi@dj4vnyctlewh>
 <Z1Ayfbfkk1WFtqTH@cloudinit-builder>
Message-ID: <Z1CXC1OdprAuh768@cloudinit-builder>

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.

I don't speak here officially for the CLC in this matter (despite
being one of seven CLC members) but I have brought this matter to the
attention of the rest of the committee in the below ticket, and the
above is my best guess at what their opinion on the matter will be.

https://github.com/haskell/core-libraries-committee/issues/311

Tom

From teofilcamarasu at gmail.com  Thu Dec  5 09:40:10 2024
From: teofilcamarasu at gmail.com (Teofil Camarasu)
Date: Thu, 5 Dec 2024 09:40:10 +0000
Subject: Updating the migration guide for GHC 9.12
Message-ID: <CAPBO51EjSXCf5dMvxYBqFZdOnmw26RZ9rz76XFPfUVh3UyEchQ@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241205/8f844985/attachment.html>

From ben at smart-cactus.org  Thu Dec  5 16:01:08 2024
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 05 Dec 2024 11:01:08 -0500
Subject: Missing Enum instance for IoSubSystem
In-Reply-To: <notmuch-sha1-e17cf6bbe87557b5aa811879517a692828195ac4>
References: <CAMh=VimhKEVsb_RHGfknHQg1dc383X+whbPQ0f1015acASGdNw@mail.gmail.com>
 <Z1ArVQYWOM0WZza/@cloudinit-builder>
 <6qv367stneidxor6my6luxi6j7ym2wb4l4zttw5wvskp44vvgi@dj4vnyctlewh>
 <Z1Ayfbfkk1WFtqTH@cloudinit-builder> <Z1CXC1OdprAuh768@cloudinit-builder>
Message-ID: <87ttbi3ys6.fsf@smart-cactus.org>

Ben Gamari <ben at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241205/14177f9e/attachment.sig>

From allbery.b at gmail.com  Thu Dec  5 16:04:01 2024
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 5 Dec 2024 11:04:01 -0500
Subject: Updating the migration guide for GHC 9.12
In-Reply-To: <CAPBO51EjSXCf5dMvxYBqFZdOnmw26RZ9rz76XFPfUVh3UyEchQ@mail.gmail.com>
References: <CAPBO51EjSXCf5dMvxYBqFZdOnmw26RZ9rz76XFPfUVh3UyEchQ@mail.gmail.com>
Message-ID: <CAKFCL4Wq0s-_fVXjObTkS6Grxj4tJocBSB=kTwpKwH_JL2THJw@mail.gmail.com>

For what it's worth, Cabal is now recommending that migration information
be included in PRs' changelog entries.

On Thu, Dec 5, 2024 at 4:40 AM Teofil Camarasu <teofilcamarasu at gmail.com>
wrote:

> 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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241205/4d3bdf9c/attachment.html>

From matshch at avride.ai  Fri Dec  6 14:51:47 2024
From: matshch at avride.ai (Artem Leshchev)
Date: Fri, 6 Dec 2024 08:51:47 -0600
Subject: setNumCapabilities 257 crashes a program
Message-ID: <CAJ4XOgJLFuxccjzOCGzpCdKrdGZ4-LdUnHEDVJm26kEepXcO3Q@mail.gmail.com>

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

From matshch at avride.ai  Fri Dec  6 16:51:32 2024
From: matshch at avride.ai (Artem Leshchev)
Date: Fri, 6 Dec 2024 10:51:32 -0600
Subject: setNumCapabilities 257 crashes a program
Message-ID: <CAJ4XOgJby9UOVi=yFT5m7Sxnu5Q6=HyWpvFHVY9-A=445s7wuA@mail.gmail.com>

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

-- 
Artem Leshchev

From andreash87 at gmx.ch  Sun Dec 15 16:55:43 2024
From: andreash87 at gmx.ch (Andreas Herrmann)
Date: Sun, 15 Dec 2024 17:55:43 +0100
Subject: Save the date: Haskell Ecosystem Workshop and Haskell Implementors'
 Workshop 2025
Message-ID: <CA+ouDUjCiq-ppyxdppA69GTDrZZR2tZ546g-70b=ARc7z3DnBQ@mail.gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241215/ebaac786/attachment.html>

From zubin at well-typed.com  Mon Dec 16 10:20:54 2024
From: zubin at well-typed.com (Zubin Duggal)
Date: Mon, 16 Dec 2024 15:50:54 +0530
Subject: GHC 9.12.1 is now available
Message-ID: <ekr3carfz5nni3ttotg4vxycmzvo7y3xgdm75mooxbmrmud5s6@mfajegzz3jxw>

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-or-patterns.rst
[MultilineStrings]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst
[GHC Proposal #281]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst
[NamedDefaults]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241216/d281d956/attachment.sig>

From shayne.fletcher.50 at gmail.com  Mon Dec 16 13:10:40 2024
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Mon, 16 Dec 2024 08:10:40 -0500
Subject: GHC 9.12.1 is now available
In-Reply-To: <ekr3carfz5nni3ttotg4vxycmzvo7y3xgdm75mooxbmrmud5s6@mfajegzz3jxw>
References: <ekr3carfz5nni3ttotg4vxycmzvo7y3xgdm75mooxbmrmud5s6@mfajegzz3jxw>
Message-ID: <CAMsAzy_PWx866aVQ8jvK62k2OzBY7XR2uyub_eGyeRUHyq=QSg@mail.gmail.com>

There does not appear to be a ghc-9.12.1-release branch?

On Mon, Dec 16, 2024 at 5:21 AM Zubin Duggal <zubin at well-typed.com> wrote:

> 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-or-patterns.rst
> [MultilineStrings]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst
> [GHC Proposal #281]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst
> [NamedDefaults]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
Shayne Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241216/2fb105c3/attachment.html>

From zubin at well-typed.com  Mon Dec 16 13:19:17 2024
From: zubin at well-typed.com (Zubin Duggal)
Date: Mon, 16 Dec 2024 18:49:17 +0530
Subject: GHC 9.12.1 is now available
In-Reply-To: <CAMsAzy_PWx866aVQ8jvK62k2OzBY7XR2uyub_eGyeRUHyq=QSg@mail.gmail.com>
References: <ekr3carfz5nni3ttotg4vxycmzvo7y3xgdm75mooxbmrmud5s6@mfajegzz3jxw>
 <CAMsAzy_PWx866aVQ8jvK62k2OzBY7XR2uyub_eGyeRUHyq=QSg@mail.gmail.com>
Message-ID: <6v25dh46mmobe7eqekltrkoldqvgwfyzeoglnyaqqxzofzyni3@lzx2xomhgwr3>

Ah sorry, I accidentally called the tag ghc-9.12.1 instead
of ghc-9.12.1-release.

The correct tag should be pushed now.

On 24/12/16 08:10, Shayne Fletcher wrote:
>There does not appear to be a ghc-9.12.1-release branch?
>
>On Mon, Dec 16, 2024 at 5:21 AM Zubin Duggal <zubin at well-typed.com> wrote:
>
>> 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-or-patterns.rst
>> [MultilineStrings]:
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst
>> [GHC Proposal #281]:
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst
>> [NamedDefaults]:
>> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
>
>-- 
>Shayne Fletcher

From shayne.fletcher.50 at gmail.com  Mon Dec 16 13:20:02 2024
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Mon, 16 Dec 2024 08:20:02 -0500
Subject: GHC 9.12.1 is now available
In-Reply-To: <6v25dh46mmobe7eqekltrkoldqvgwfyzeoglnyaqqxzofzyni3@lzx2xomhgwr3>
References: <ekr3carfz5nni3ttotg4vxycmzvo7y3xgdm75mooxbmrmud5s6@mfajegzz3jxw>
 <CAMsAzy_PWx866aVQ8jvK62k2OzBY7XR2uyub_eGyeRUHyq=QSg@mail.gmail.com>
 <6v25dh46mmobe7eqekltrkoldqvgwfyzeoglnyaqqxzofzyni3@lzx2xomhgwr3>
Message-ID: <CAMsAzy-rbAF0Uadm0m=r+cXT-W6Zx5gZOR30k4R736gJy+PVqw@mail.gmail.com>

On Mon, Dec 16, 2024 at 8:19 AM Zubin Duggal <zubin at well-typed.com> wrote:

> Ah sorry, I accidentally called the tag ghc-9.12.1 instead
> of ghc-9.12.1-release.
>
> The correct tag should be pushed now.
>

Thank-you!

>
> On 24/12/16 08:10, Shayne Fletcher wrote:
> >There does not appear to be a ghc-9.12.1-release branch?
> >
> >On Mon, Dec 16, 2024 at 5:21 AM Zubin Duggal <zubin at well-typed.com>
> wrote:
> >
> >> 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-or-patterns.rst
> >> [MultilineStrings]:
> >>
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0569-multiline-strings.rst
> >> [GHC Proposal #281]:
> >>
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0281-visible-forall.rst
> >> [NamedDefaults]:
> >>
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0409-exportable-named-default.rst
> >> _______________________________________________
> >> ghc-devs mailing list
> >> ghc-devs at haskell.org
> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >>
> >
> >
> >--
> >Shayne Fletcher
>


-- 
Shayne Fletcher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241216/3d28f26e/attachment.html>

From bryan at haskell.foundation  Tue Dec 17 13:13:25 2024
From: bryan at haskell.foundation (Bryan Richter)
Date: Tue, 17 Dec 2024 15:13:25 +0200
Subject: Feedback on potential change in boot library
In-Reply-To: <db88c569-366c-4c4d-af5b-779e3acc6790@gmx.at>
References: <87serdu516.fsf@smart-cactus.org>
 <051942f7-f840-4ed5-84a8-689c5321b7d9@glitchbra.in>
 <c0cc8858-6e3d-481b-be9f-c13b80e027a2@well-typed.com>
 <Z0btJQq6K2Jbe7GQ@cloudinit-builder>
 <CAP1qinaSWeXx-Ttnzn7O3ieNHcUTfZ+WUUZa-EAL7e+uMcpyoQ@mail.gmail.com>
 <db88c569-366c-4c4d-af5b-779e3acc6790@gmx.at>
Message-ID: <CACUTo6y+XwoQNifrb67T17_nuKv-7xxpx-LeZhC+aTGXoqYEfg@mail.gmail.com>

I'd like to add a third option to Andreas' list.

It seems the current policy is both too lax and too strict: Minor versions
are never incorporated, but when they are, it is despite the fact they are
known to create breakage. This is what I've gathered from Ben's comment
that head.hackage caught the 9.8.3 breakage.

So the third option:

## Always bump minor versions, unless they are known to cause breakage.

(1) "Known to cause breakage" is subject to further specification, but at
the very least, head.hackage can already be used for this purpose.

Tangentially, regardless of hard-and-fast rules, exceptions should be
allowed if justified. This is also subject to further specification, but
again at the very least, justification should be a mix of release manager's
discretion, user needs, and library maintainer wishes. This might be
stating the obvious, but it's only obvious if it's actually stated.

On Thu, 28 Nov 2024 at 14:51, Andreas Klebinger via ghc-devs <
ghc-devs at haskell.org> wrote:

> > Breaking changes caused by new exports could be mitigated with a library
> package or a GHC plugin with such auto refactoring functionality :
>
> All of this is true. But from my side the worry here is less the effort
> required to fix such issues.
> Rather it's that users need to take any action at all when
> upgrading from ghc-9.X.Y to ghc-9.X.Y+1 in order for their projects to
> continue to compile.
>
> Our goals here are:
> * Ensure bug fix releases of libraries are shipped with GHC without
> requiring maintainer attention.
> * Try to keep breakage for users minimal.
>
> In concept the idea of only bumping sumperminor versions makes sense, as
> those typically don't contain any breaking changes.
> But after looking through some of the changelogs of boot libraries it
> seems like *many* bug fixes are currently released as minor
> releases. As a consequence I don't see applying this policy only to
> superminor versions as productive unless the release practices
> of boot libraries change significantly which seems unlikely.
>
> Similarly in theory we can disregard concerns about breakage with a
> reference to best practices or paint users as responsible for open
> imports. But that won't change the fact that it's common practice to use
> open imports and as a result there will be breakage from such
> changes.
>
> So this leaves us with:
>
> ## Always bump minor versions [unless there are objections].
>
> This ensures bug fixes make it into releases reliably with little
> maintainer burden, but will result in breakage for some projects
> when upgrading from ghc-X.Y.Z to ghc-X.Y.Z+1.
>
> Breakage from such issues tends to be immediately observed as tied to a
> ghc upgrade, and as such we tend to more reliably hear of it.
>
> ## Never bump minor versions [unless explicitly requested by maintainers
> of the library, or deemed necessary by ghc maintainers].
>
> This reduces breakage from added imports, but means ghc might ship at
> times with libraries which contain bugs for which a fix already existed. It
> is hard to accurately judge the cost/benefit of this approach. As such bugs
> typically are discovered once applications are deployed and as ghc devs we
> might never hear of issues caused this way.
>
> Some projects are also locked into boot library versions, and might want
> to use newer versions for non-bugfix reasons.
>
> -----------------
>
> Personally I think we should bump minor versions by default despite it
> occasionally causing breakage. However I think we should also be willing to
> avoid a bump if it causes a large amount of known breakage while not
> providing any bug fixes.
>
> 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.
>
>
>
>
>
>
> Am 28/11/2024 um 08:44 schrieb Imants Cekusins:
>
> On Wed, 27 Nov 2024 at 11:58, Tom Ellis <
> tom-lists-haskell-cafe-2023 at jaguarpaw.co.uk> wrote:
>
>> Thanks Adam,
>>
>> I'm not too familiar with the GHC-side requirements here, but I wonder
>> if we can approach this issue from a different direction: is there
>> something we can do to help boot libraries avoid breaking changes?
>>
>> Tom
>>
>
>
> Breaking changes caused by new exports could be mitigated with a library
> package or a GHC plugin with such auto refactoring functionality :
>
> * Uniquely qualify (i.e., leave no different modules similarly qualified
> in the same module) each imported module and each imported symbol.
>
> This refactoring should be possible in code which already compiles.
> It would not require syntax / grammar changes.
>
> Something similar to smuggler2 package.
>
> _______________________________________________
> ghc-devs mailing listghc-devs at haskell.orghttp://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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241217/4c30ec16/attachment.html>

From simon.peytonjones at gmail.com  Wed Dec 18 16:24:31 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 18 Dec 2024 16:24:31 +0000
Subject: posix_spawnp
Message-ID: <CAJKmMz81zJeP3PHKCrRsG7iFc2AJ7fnbVvvrMH=xqE1CZXJxyw@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241218/a2cbfe9b/attachment.html>

From minhxecole at gmail.com  Thu Dec 19 05:11:20 2024
From: minhxecole at gmail.com (Minh Le)
Date: Thu, 19 Dec 2024 06:11:20 +0100
Subject: Lift instance cause GHC build error: unknown symbol with CFFI
Message-ID: <CAJpKSkUNmNW-+dMpZuHxWqSc6ZRP32KJQkSg7v+V7Bcx422R6A@mail.gmail.com>

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

From kztk at tohoku.ac.jp  Thu Dec 19 10:05:54 2024
From: kztk at tohoku.ac.jp (Kazutaka Matsuda)
Date: Thu, 19 Dec 2024 19:05:54 +0900
Subject: GitLab Account Approval Request
Message-ID: <CADmLQBUtLgB_V9NcvYoz7QGJ+e9n-Uc5mBcEARCfA-eGgwJ4vw@mail.gmail.com>

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

From allbery.b at gmail.com  Thu Dec 19 10:07:17 2024
From: allbery.b at gmail.com (Brandon Allbery)
Date: Thu, 19 Dec 2024 05:07:17 -0500
Subject: GitLab Account Approval Request
In-Reply-To: <CADmLQBUtLgB_V9NcvYoz7QGJ+e9n-Uc5mBcEARCfA-eGgwJ4vw@mail.gmail.com>
References: <CADmLQBUtLgB_V9NcvYoz7QGJ+e9n-Uc5mBcEARCfA-eGgwJ4vw@mail.gmail.com>
Message-ID: <CAKFCL4Vm_7z=NB1oZxjJG-dzC7_x=8HQ06LXE2uNiyM41ZH_pA@mail.gmail.com>

Approved.

On Thu, Dec 19, 2024 at 5:06 AM Kazutaka Matsuda <kztk at tohoku.ac.jp> wrote:

> 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
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
brandon s allbery kf8nh
allbery.b at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241219/547baa8c/attachment.html>

From ben at smart-cactus.org  Thu Dec 19 13:45:34 2024
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 19 Dec 2024 08:45:34 -0500
Subject: posix_spawnp
In-Reply-To: <CAJKmMz81zJeP3PHKCrRsG7iFc2AJ7fnbVvvrMH=xqE1CZXJxyw@mail.gmail.com>
References: <CAJKmMz81zJeP3PHKCrRsG7iFc2AJ7fnbVvvrMH=xqE1CZXJxyw@mail.gmail.com>
Message-ID: <87bjx77pna.fsf@smart-cactus.org>

Simon Peyton Jones <simon.peytonjones at gmail.com> writes:

> 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)
>
Hmm, interesting.

Does /home/simonpj/code/HEAD-20/_build/stage1/lib/../bin/ghc-iserv
exist?

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241219/77763399/attachment.sig>

From simon.peytonjones at gmail.com  Thu Dec 19 17:37:26 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 19 Dec 2024 17:37:26 +0000
Subject: posix_spawnp
In-Reply-To: <87bjx77pna.fsf@smart-cactus.org>
References: <CAJKmMz81zJeP3PHKCrRsG7iFc2AJ7fnbVvvrMH=xqE1CZXJxyw@mail.gmail.com>
 <87bjx77pna.fsf@smart-cactus.org>
Message-ID: <CAJKmMz_jFq27uz6OTv-Wj_46WXrn5UfNUpNCEM7QXNr5jZKeyg@mail.gmail.com>

Does /home/simonpj/code/HEAD-20/_build/stage1/lib/../bin/ghc-iserv
exist?


bash$   ls  /home/simonpj/code/HEAD-20/_build/stage1/lib/../bin
check-exact  count-deps  ghc ghc-pkg   haddock  hpc     lint-codes unlit
check-ppr    dump-decls  ghc-iserv-dyn ghc-toolchain-bin  hp2ps    hsc2hs
 runghc


So it seems that the answer is no.

What now?

SImon

On Thu, 19 Dec 2024 at 13:45, Ben Gamari <ben at smart-cactus.org> wrote:

> Simon Peyton Jones <simon.peytonjones at gmail.com> writes:
>
> > 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)
> >
> Hmm, interesting.
>
> Does /home/simonpj/code/HEAD-20/_build/stage1/lib/../bin/ghc-iserv
> exist?
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241219/2bd878e4/attachment.html>

From ben at smart-cactus.org  Thu Dec 19 18:08:40 2024
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 19 Dec 2024 13:08:40 -0500
Subject: Lift instance cause GHC build error: unknown symbol with CFFI
In-Reply-To: <CAJpKSkUNmNW-+dMpZuHxWqSc6ZRP32KJQkSg7v+V7Bcx422R6A@mail.gmail.com>
References: <CAJpKSkUNmNW-+dMpZuHxWqSc6ZRP32KJQkSg7v+V7Bcx422R6A@mail.gmail.com>
Message-ID: <875xnf7dgw.fsf@smart-cactus.org>

Minh Le <minhxecole at gmail.com> writes:

> Hi everyone,
> I’m building a floating-point library for Clash that uses FloPoCo.

Very cool; I've not heard of FloPoCo prior to this; that looks like a
nice set of cores.

> 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.
>
Indeed that is intriguing. Indeed you have the right `extra-libraries`
entries in your Cabal file.

> This suggests a linking issue specific to the build process.
>
I have tried to reproduce this but it would seem that the repository is
missing the FPFloat module.

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241219/15932890/attachment.sig>

From minhxecole at gmail.com  Thu Dec 19 18:16:33 2024
From: minhxecole at gmail.com (Minh Le)
Date: Thu, 19 Dec 2024 19:16:33 +0100
Subject: Lift instance cause GHC build error: unknown symbol with CFFI
In-Reply-To: <875xnf7dgw.fsf@smart-cactus.org>
References: <CAJpKSkUNmNW-+dMpZuHxWqSc6ZRP32KJQkSg7v+V7Bcx422R6A@mail.gmail.com>
 <875xnf7dgw.fsf@smart-cactus.org>
Message-ID: <CAJpKSkXzccQQJECa6zfKr7GE=8iid3TE+GWXLTZPNttSJxnhyA@mail.gmail.com>

Hi Ben,
The missing module FPFloat is something related in the naming of the
file. Currently, I am developing this library in Window and test it
with both Window and Linux WSL. In Linux, it has stricter naming, so
that you have to rename file fpfloat.hs and proto.hs into FPFloat.hs
and Proto.hs. It is mentioned in the discussion in the Cabal issue,
which I have included the link.
Kind regards,
Minh


On Thu, Dec 19, 2024 at 7:08 PM Ben Gamari <ben at smart-cactus.org> wrote:
>
> Minh Le <minhxecole at gmail.com> writes:
>
> > Hi everyone,
> > I’m building a floating-point library for Clash that uses FloPoCo.
>
> Very cool; I've not heard of FloPoCo prior to this; that looks like a
> nice set of cores.
>
> > 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.
> >
> Indeed that is intriguing. Indeed you have the right `extra-libraries`
> entries in your Cabal file.
>
> > This suggests a linking issue specific to the build process.
> >
> I have tried to reproduce this but it would seem that the repository is
> missing the FPFloat module.
>
> Cheers,
>
> - Ben



-- 

☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆☆

Le Hoang Minh
Handphone: +31 684054062
Email: MinhXecole at gmail.com

From ben at smart-cactus.org  Thu Dec 19 18:20:22 2024
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 19 Dec 2024 13:20:22 -0500
Subject: posix_spawnp
In-Reply-To: <CAJKmMz_jFq27uz6OTv-Wj_46WXrn5UfNUpNCEM7QXNr5jZKeyg@mail.gmail.com>
References: <CAJKmMz81zJeP3PHKCrRsG7iFc2AJ7fnbVvvrMH=xqE1CZXJxyw@mail.gmail.com>
 <87bjx77pna.fsf@smart-cactus.org>
 <CAJKmMz_jFq27uz6OTv-Wj_46WXrn5UfNUpNCEM7QXNr5jZKeyg@mail.gmail.com>
Message-ID: <871py37cxa.fsf@smart-cactus.org>

Simon Peyton Jones <simon.peytonjones at gmail.com> writes:

> Does /home/simonpj/code/HEAD-20/_build/stage1/lib/../bin/ghc-iserv
> exist?
>
>
> bash$   ls  /home/simonpj/code/HEAD-20/_build/stage1/lib/../bin
> check-exact  count-deps  ghc ghc-pkg   haddock  hpc     lint-codes unlit
> check-ppr    dump-decls  ghc-iserv-dyn ghc-toolchain-bin  hp2ps    hsc2hs
>  runghc
>
Which build flavour are you using?

Perhaps let's just chat if you are available.

https://meet.jit.si/AnnoyedCharitiesLendRight

Cheers,

- Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241219/9dd7fe7e/attachment.sig>

From matthewtpickering at gmail.com  Fri Dec 20 13:01:43 2024
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 20 Dec 2024 13:01:43 +0000
Subject: Using ghc-debug with ghc
Message-ID: <CALuQ0m--AWFJg1OPe1KLRZysj9vjRCiVrz1uE3FrOLFSKOgmSg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241220/53c29db7/attachment.html>

From ben at smart-cactus.org  Fri Dec 20 16:33:21 2024
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 20 Dec 2024 11:33:21 -0500
Subject: Lift instance cause GHC build error: unknown symbol with CFFI
In-Reply-To: <CAJpKSkXzccQQJECa6zfKr7GE=8iid3TE+GWXLTZPNttSJxnhyA@mail.gmail.com>
References: <CAJpKSkUNmNW-+dMpZuHxWqSc6ZRP32KJQkSg7v+V7Bcx422R6A@mail.gmail.com>
 <875xnf7dgw.fsf@smart-cactus.org>
 <CAJpKSkXzccQQJECa6zfKr7GE=8iid3TE+GWXLTZPNttSJxnhyA@mail.gmail.com>
Message-ID: <87ldwa5n7i.fsf@smart-cactus.org>

Minh Le <minhxecole at gmail.com> writes:

> Hi Ben,
> The missing module FPFloat is something related in the naming of the
> file. Currently, I am developing this library in Window and test it
> with both Window and Linux WSL. In Linux, it has stricter naming, so
> that you have to rename file fpfloat.hs and proto.hs into FPFloat.hs
> and Proto.hs. It is mentioned in the discussion in the Cabal issue,
> which I have included the link.

Hi Minh,

I have tried reproducing this under a Debian 11 VM yet strangely it
built without any trouble. I checked a few hypotheses yet nothing
obvious seems wrong. I have pushed my full reproducer here [1].

I will try again under Windows when I get a chance.

Cheers,

- Ben


[1] https://github.com/bgamari/FloPoCoFloat/tree/wip/repro
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241220/a54a3c1c/attachment.sig>

From ben at well-typed.com  Fri Dec 20 18:30:13 2024
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 20 Dec 2024 13:30:13 -0500
Subject: GHC 9.10.2 preparation
Message-ID: <87ed225hss.fsf@smart-cactus.org>


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241220/e0ad1589/attachment.sig>

From andrew.lelechenko at gmail.com  Sat Dec 21 14:02:34 2024
From: andrew.lelechenko at gmail.com (Andrew Lelechenko)
Date: Sat, 21 Dec 2024 14:02:34 +0000
Subject: Feedback on potential change in boot library
In-Reply-To: <mailman.3.1734523202.17680.ghc-devs@haskell.org>
References: <mailman.3.1734523202.17680.ghc-devs@haskell.org>
Message-ID: <58B9E7C8-C7EF-4396-82FD-99C4FAB4542F@gmail.com>

On Thu, 28 Nov 2024 at 14:51, Andreas Klebinger via ghc-devs <ghc-devs at 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

From moritz.angermann at gmail.com  Sat Dec 21 14:39:56 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Sat, 21 Dec 2024 23:39:56 +0900
Subject: Feedback on potential change in boot library
In-Reply-To: <58B9E7C8-C7EF-4396-82FD-99C4FAB4542F@gmail.com>
References: <mailman.3.1734523202.17680.ghc-devs@haskell.org>
 <58B9E7C8-C7EF-4396-82FD-99C4FAB4542F@gmail.com>
Message-ID: <CAKfdd-wguaASJqBhY93pJQYNsNJawYEjFUoe+9D6R_KW3+sJsg@mail.gmail.com>

I’m mildly concerned about the show export. However the real issue is that
we have no good way to measure the actual impact of this change. I believe
text to be reinstallable and as such unless GHC prohibits a downgrade of
text end users could still use an older non-breaking text. I’m much less
concerned about boot library bumps that do not force these version on an
end user without the ability to override and downgrade. The goal must
always be to be able to use a newer compiler with an existing codebase
outright. Anything else is just a recipe for QA disaster.

On Sat, Dec 21, 2024 at 11:02 PM Andrew Lelechenko <
andrew.lelechenko at gmail.com> wrote:

> On Thu, 28 Nov 2024 at 14:51, Andreas Klebinger via ghc-devs <
> ghc-devs at 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
> _______________________________________________
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20241221/4680ade0/attachment.html>