From ben at smart-cactus.org  Wed Jun  4 01:27:19 2025
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 03 Jun 2025 21:27:19 -0400
Subject: Features for GHC 9.14?
Message-ID: <87zfeo8few.fsf@smart-cactus.org>

Hi all,

I am currently putting together the GHC status talk for this year's HIW.
Do let me know if you anticipate merging any features for the coming
9.14 release which you haven't yet put on GitLab.

Cheers,

- Ben

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

From matthewtpickering at gmail.com  Wed Jun  4 08:15:54 2025
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Wed, 4 Jun 2025 09:15:54 +0100
Subject: Features for GHC 9.14?
In-Reply-To: <87zfeo8few.fsf@smart-cactus.org>
References: <87zfeo8few.fsf@smart-cactus.org>
Message-ID: <CALuQ0m-B5BJCewtCMyHSF5euBeXs1XHZn2p=d04C94EvKzqBcQ@mail.gmail.com>

Hi Ben,

Can you clarify what date in July the release is scheduled for?

I think we have managed to merge the significant features which were
targeted for this release.

* Explicit Level Imports (Matt)
* Debugger Improvements (Rodrigo)
* MHU GHCi Support (Hannes)
* Improved Prinop Performance in the Interpreter (Andreas)

Cheers,

Matt

On Wed, Jun 4, 2025 at 2:27 AM Ben Gamari via ghc-devs <ghc-devs at haskell.org>
wrote:

> Hi all,
>
> I am currently putting together the GHC status talk for this year's HIW.
> Do let me know if you anticipate merging any features for the coming
> 9.14 release which you haven't yet put on GitLab.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> 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/20250604/8160b221/attachment.html>

From george.colpitts at gmail.com  Wed Jun  4 11:16:42 2025
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 4 Jun 2025 08:16:42 -0300
Subject: Features for GHC 9.14?
In-Reply-To: <CALuQ0m-B5BJCewtCMyHSF5euBeXs1XHZn2p=d04C94EvKzqBcQ@mail.gmail.com>
References: <87zfeo8few.fsf@smart-cactus.org>
 <CALuQ0m-B5BJCewtCMyHSF5euBeXs1XHZn2p=d04C94EvKzqBcQ@mail.gmail.com>
Message-ID: <CAB-d4A6jfLtZai4Du4c-qcDd+n-7XJ6ensALq-_pmP8-KpvMVQ@mail.gmail.com>

According to https://gitlab.haskell.org/ghc/ghc/-/milestones/400#tab-issues
the final release is scheduled for September.

Will we be supporting llvm 20?

On Wed, Jun 4, 2025 at 5:16 AM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> Hi Ben,
>
> Can you clarify what date in July the release is scheduled for?
>
> I think we have managed to merge the significant features which were
> targeted for this release.
>
> * Explicit Level Imports (Matt)
> * Debugger Improvements (Rodrigo)
> * MHU GHCi Support (Hannes)
> * Improved Prinop Performance in the Interpreter (Andreas)
>
> Cheers,
>
> Matt
>
> On Wed, Jun 4, 2025 at 2:27 AM Ben Gamari via ghc-devs <
> ghc-devs at haskell.org> wrote:
>
>> Hi all,
>>
>> I am currently putting together the GHC status talk for this year's HIW.
>> Do let me know if you anticipate merging any features for the coming
>> 9.14 release which you haven't yet put on GitLab.
>>
>> Cheers,
>>
>> - Ben
>>
>> _______________________________________________
>> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250604/e74da222/attachment.html>

From ben at smart-cactus.org  Wed Jun  4 16:17:33 2025
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 04 Jun 2025 12:17:33 -0400
Subject: Features for GHC 9.14?
In-Reply-To: <CAB-d4A6jfLtZai4Du4c-qcDd+n-7XJ6ensALq-_pmP8-KpvMVQ@mail.gmail.com>
References: <87zfeo8few.fsf@smart-cactus.org>
 <CALuQ0m-B5BJCewtCMyHSF5euBeXs1XHZn2p=d04C94EvKzqBcQ@mail.gmail.com>
 <CAB-d4A6jfLtZai4Du4c-qcDd+n-7XJ6ensALq-_pmP8-KpvMVQ@mail.gmail.com>
Message-ID: <87wm9r8orp.fsf@smart-cactus.org>

George Colpitts <george.colpitts at gmail.com> writes:

> According to https://gitlab.haskell.org/ghc/ghc/-/milestones/400#tab-issues
> the final release is scheduled for September.
>
> Will we be supporting llvm 20?
>
Yes, we will likely enable LLVM 20 support.

Cheers,

- Ben

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

From ben at smart-cactus.org  Wed Jun  4 16:18:55 2025
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 04 Jun 2025 12:18:55 -0400
Subject: Features for GHC 9.14?
In-Reply-To: <CALuQ0m-B5BJCewtCMyHSF5euBeXs1XHZn2p=d04C94EvKzqBcQ@mail.gmail.com>
References: <87zfeo8few.fsf@smart-cactus.org>
 <CALuQ0m-B5BJCewtCMyHSF5euBeXs1XHZn2p=d04C94EvKzqBcQ@mail.gmail.com>
Message-ID: <87tt4v8opc.fsf@smart-cactus.org>

Matthew Pickering <matthewtpickering at gmail.com> writes:

> Hi Ben,
>
> Can you clarify what date in July the release is scheduled for?
>
Indeed the preliminary schedule previously given in the milestone is not
realistic at this point. I have updated the schedule to a more realistic
September date as I hope to fork soon after we return from Zurihac.

Cheers,

- Ben

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

From ben at well-typed.com  Thu Jun 12 22:53:37 2025
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 12 Jun 2025 18:53:37 -0400
Subject: GHC 9.14 fork status
Message-ID: <877c1g8tch.fsf@smart-cactus.org>

Hi all,

As those of you at Zurihac may know, we are currently in the process of
preparing for the GHC 9.14 fork. This week I have been working through
the various necessary core library version bumps and submodule changes.
My hope is that we can land this work early next week and declare the
fork at some point in the days that follow.

I am aware of a few things that we want to land prior to forking:

 * @int-index's !14136 (Visible forall in GADTs)
 * testing and enabling of LLVM 20 support
 * an update of win32-tarballs
 * Cheng's libffi update (!14392)

If you have any further work that you would like to see in 9.14 please
do let me know by next Wednesday.

If all goes well, my hope is that we can have our first alpha out by the
end of this month, with an eye towards a final release in early
September.

Cheers,

- Ben

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

From ben at well-typed.com  Thu Jun 12 22:42:41 2025
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 12 Jun 2025 18:42:41 -0400
Subject: GHC 9.14 boot library status
Message-ID: <878qlw8tuq.fsf@smart-cactus.org>

Hi all,

This week I have been pushing through submodule updates and bounds
bumps in preparation for the fork of the GHC 9.14 release. Today I have
opened merge requests against those boot libraries which will require
changes to integrate into 9.14; thankfully, it appears that these
changes are all limited to bounds bumps this cycle.

In keeping with our release management policy [1], I have updated GHC's
submodules to reflect the current releases present on Hackage. I have
also updated the submodule tracking spreadsheet [2] to reflect the
expected boot library versions on release. Please have a look over the
spreadsheet and if you would like to see anything changed here, update
it accordingly at some point in the next few weeks.

As always, thanks for your efforts!

Cheers,

- Ben


[1] https://gitlab.haskell.org/ghc/ghc-hq/-/blob/main/release-management.mkd?ref_type=heads
[2] https://docs.google.com/spreadsheets/d/19WeWjXPh8Q64qoe3fjs8AswpTHk6uLBD8WG-7R97a1U/edit?gid=343507833#gid=343507833
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250612/86a3d942/attachment.sig>

From a.pelenitsyn at gmail.com  Thu Jun 12 23:16:26 2025
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Thu, 12 Jun 2025 19:16:26 -0400
Subject: GHC 9.14 boot library status
In-Reply-To: <878qlw8tuq.fsf@smart-cactus.org>
References: <878qlw8tuq.fsf@smart-cactus.org>
Message-ID: <CAPKAvQWr5aUOMQv_yS_7K4PPeHEFTNE7iPKSob+EV5qV==s1=g@mail.gmail.com>

Hi Ben,

In the spreadsheet, Cabal says desired version 3.15.0.0, while it should be
3.16.0.0 I believe: Cabal reserves odd numbers for development versions.

Thanks for all your hard work!

--
Best, Artem

On Thu, Jun 12, 2025, 7:00 PM Ben Gamari <ben at well-typed.com> wrote:

> Hi all,
>
> This week I have been pushing through submodule updates and bounds
> bumps in preparation for the fork of the GHC 9.14 release. Today I have
> opened merge requests against those boot libraries which will require
> changes to integrate into 9.14; thankfully, it appears that these
> changes are all limited to bounds bumps this cycle.
>
> In keeping with our release management policy [1], I have updated GHC's
> submodules to reflect the current releases present on Hackage. I have
> also updated the submodule tracking spreadsheet [2] to reflect the
> expected boot library versions on release. Please have a look over the
> spreadsheet and if you would like to see anything changed here, update
> it accordingly at some point in the next few weeks.
>
> As always, thanks for your efforts!
>
> Cheers,
>
> - Ben
>
>
> [1]
> https://gitlab.haskell.org/ghc/ghc-hq/-/blob/main/release-management.mkd?ref_type=heads
> [2]
> https://docs.google.com/spreadsheets/d/19WeWjXPh8Q64qoe3fjs8AswpTHk6uLBD8WG-7R97a1U/edit?gid=343507833#gid=343507833
> _______________________________________________
> 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/20250612/5ddae4ef/attachment.html>

From ben at well-typed.com  Thu Jun 12 23:48:11 2025
From: ben at well-typed.com (Ben Gamari)
Date: Thu, 12 Jun 2025 19:48:11 -0400
Subject: GHC 9.14 boot library status
In-Reply-To: <CAPKAvQWr5aUOMQv_yS_7K4PPeHEFTNE7iPKSob+EV5qV==s1=g@mail.gmail.com>
References: <878qlw8tuq.fsf@smart-cactus.org>
 <CAPKAvQWr5aUOMQv_yS_7K4PPeHEFTNE7iPKSob+EV5qV==s1=g@mail.gmail.com>
Message-ID: <871pro8qtk.fsf@smart-cactus.org>

Artem Pelenitsyn <a.pelenitsyn at gmail.com> writes:

> Hi Ben,
>
> In the spreadsheet, Cabal says desired version 3.15.0.0, while it should be
> 3.16.0.0 I believe: Cabal reserves odd numbers for development versions.
>
Sigh, yes, quite right. Thanks for noticing!

Fixed.

Cheers,

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

From matthewtpickering at gmail.com  Fri Jun 13 09:01:53 2025
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 13 Jun 2025 10:01:53 +0100
Subject: GHC 9.14 fork status
In-Reply-To: <877c1g8tch.fsf@smart-cactus.org>
References: <877c1g8tch.fsf@smart-cactus.org>
Message-ID: <CALuQ0m9bVtCdzSjBYFhb024VCjLzV6txRffpi8d9S5Bz3LiE2w@mail.gmail.com>

Hi Ben,

Can we land the following patches:

* https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14183
* https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14321
* https://gitlab.haskell.org/ghc/ghc/-/merge_requests/14377

If someone could help landing #14183, that would be good.

Matt

On Thu, Jun 12, 2025 at 11:53 PM Ben Gamari <ben at well-typed.com> wrote:

> Hi all,
>
> As those of you at Zurihac may know, we are currently in the process of
> preparing for the GHC 9.14 fork. This week I have been working through
> the various necessary core library version bumps and submodule changes.
> My hope is that we can land this work early next week and declare the
> fork at some point in the days that follow.
>
> I am aware of a few things that we want to land prior to forking:
>
>  * @int-index's !14136 (Visible forall in GADTs)
>  * testing and enabling of LLVM 20 support
>  * an update of win32-tarballs
>  * Cheng's libffi update (!14392)
>
> If you have any further work that you would like to see in 9.14 please
> do let me know by next Wednesday.
>
> If all goes well, my hope is that we can have our first alpha out by the
> end of this month, with an eye towards a final release in early
> September.
>
> Cheers,
>
> - Ben
>
> _______________________________________________
> 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/20250613/cde79c61/attachment.html>

From ben at well-typed.com  Mon Jun 16 21:04:00 2025
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 16 Jun 2025 17:04:00 -0400
Subject: Placing GitLab behind Anubis
Message-ID: <87frfz760y.fsf@smart-cactus.org>

Hi all,

As you may know, for the last few years we have used a variety of
strategies for dealing with the problem of abuse and spam on
gitlab.haskell.org. The currently-employed and seemingly most effective
technique has been to require manual approval of new account requests.

This has always been an uneasy compromise. Not only does this approval
process add considerable friction to the contribution process, the
increasing prevalence of ill-behaved web crawlers has rendered the
approach less and less effective at prevent that form of abuse.

For this reason we now exploring alternative approaches. One promising
strategy employed by other FOSS GitLab deployments (e.g.
gitlab.freedesktop.org) is the Anubis proof-of-work system. Anubis works
by forcing the client to perform a small (but non-negligible) amount of
work before requests are serviced. This will mean that GitLab users'
clients will periodically be asked to perform small amounts of work.
While Anubis primarily targets crawlers, it may be that the slight
increase in per-request cost might also allow us to lift our manual
account approval requirement.

Ultimately, the only way to find out is to try. If there are no
objections, I will place Anubis in front of GitLab starting next week.
During this process we will assess the effectiveness of Anubis at
prevent both spam and over-zealous crawlers. This may require a bit of
iterative parameter tuning but I am hopeful that the end result might be
a more accessible and faster GitLab instance for us all.

Let me know what you think.

Cheers,

- Ben


[1] https://github.com/TecharoHQ/anubis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 255 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250616/93bc3917/attachment.sig>

From mark at ploeh.dk  Tue Jun 17 05:27:41 2025
From: mark at ploeh.dk (Mark Seemann)
Date: Tue, 17 Jun 2025 05:27:41 +0000
Subject: Placing GitLab behind Anubis
In-Reply-To: <87frfz760y.fsf@smart-cactus.org>
References: <87frfz760y.fsf@smart-cactus.org>
Message-ID: <DBBPR04MB79647219026FACA0B2C4E78DB073A@DBBPR04MB7964.eurprd04.prod.outlook.com>

Hi

I'm currently just a lurker here, so my opinion may not count as much as those who actually contribute, but perhaps other readers have the same questions as I do.

- What does 'small' mean? Are we talking about a second of work, minutes, hours?
- Do clients need to install custom software to interact, or is that work done via existing protocols?

TIA

Mark Seemann

-----Original Message-----
From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ben Gamari
Sent: 16. juni 2025 23:04
To: GHC developers <ghc-devs at haskell.org>
Subject: Placing GitLab behind Anubis

Hi all,

As you may know, for the last few years we have used a variety of strategies for dealing with the problem of abuse and spam on gitlab.haskell.org. The currently-employed and seemingly most effective technique has been to require manual approval of new account requests.

This has always been an uneasy compromise. Not only does this approval process add considerable friction to the contribution process, the increasing prevalence of ill-behaved web crawlers has rendered the approach less and less effective at prevent that form of abuse.

For this reason we now exploring alternative approaches. One promising strategy employed by other FOSS GitLab deployments (e.g.
gitlab.freedesktop.org) is the Anubis proof-of-work system. Anubis works by forcing the client to perform a small (but non-negligible) amount of work before requests are serviced. This will mean that GitLab users'
clients will periodically be asked to perform small amounts of work.
While Anubis primarily targets crawlers, it may be that the slight increase in per-request cost might also allow us to lift our manual account approval requirement.

Ultimately, the only way to find out is to try. If there are no objections, I will place Anubis in front of GitLab starting next week.
During this process we will assess the effectiveness of Anubis at prevent both spam and over-zealous crawlers. This may require a bit of iterative parameter tuning but I am hopeful that the end result might be a more accessible and faster GitLab instance for us all.

Let me know what you think.

Cheers,

- Ben


[1] https://github.com/TecharoHQ/anubis

From hecate at glitchbra.in  Tue Jun 17 05:50:53 2025
From: hecate at glitchbra.in (=?ISO-8859-1?Q?H=E9cate?=)
Date: Tue, 17 Jun 2025 07:50:53 +0200
Subject: Placing GitLab behind Anubis
In-Reply-To: <DBBPR04MB79647219026FACA0B2C4E78DB073A@DBBPR04MB7964.eurprd04.prod.outlook.com>
References: <87frfz760y.fsf@smart-cactus.org>
 <DBBPR04MB79647219026FACA0B2C4E78DB073A@DBBPR04MB7964.eurprd04.prod.outlook.com>
Message-ID: <0455998C-2CDC-4C88-BC81-B8413AB656D7@glitchbra.in>

From experience it takes a couple of seconds and it's just client JS.

Le 17 juin 2025 07:27:41 GMT+02:00, Mark Seemann <mark at ploeh.dk> a écrit :
>Hi
>
>I'm currently just a lurker here, so my opinion may not count as much as those who actually contribute, but perhaps other readers have the same questions as I do.
>
>- What does 'small' mean? Are we talking about a second of work, minutes, hours?
>- Do clients need to install custom software to interact, or is that work done via existing protocols?
>
>TIA
>
>Mark Seemann
>
>-----Original Message-----
>From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Ben Gamari
>Sent: 16. juni 2025 23:04
>To: GHC developers <ghc-devs at haskell.org>
>Subject: Placing GitLab behind Anubis
>
>Hi all,
>
>As you may know, for the last few years we have used a variety of strategies for dealing with the problem of abuse and spam on gitlab.haskell.org. The currently-employed and seemingly most effective technique has been to require manual approval of new account requests.
>
>This has always been an uneasy compromise. Not only does this approval process add considerable friction to the contribution process, the increasing prevalence of ill-behaved web crawlers has rendered the approach less and less effective at prevent that form of abuse.
>
>For this reason we now exploring alternative approaches. One promising strategy employed by other FOSS GitLab deployments (e.g.
>gitlab.freedesktop.org) is the Anubis proof-of-work system. Anubis works by forcing the client to perform a small (but non-negligible) amount of work before requests are serviced. This will mean that GitLab users'
>clients will periodically be asked to perform small amounts of work.
>While Anubis primarily targets crawlers, it may be that the slight increase in per-request cost might also allow us to lift our manual account approval requirement.
>
>Ultimately, the only way to find out is to try. If there are no objections, I will place Anubis in front of GitLab starting next week.
>During this process we will assess the effectiveness of Anubis at prevent both spam and over-zealous crawlers. This may require a bit of iterative parameter tuning but I am hopeful that the end result might be a more accessible and faster GitLab instance for us all.
>
>Let me know what you think.
>
>Cheers,
>
>- Ben
>
>
>[1] https://github.com/TecharoHQ/anubis
>_______________________________________________
>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/20250617/d23ce386/attachment.html>

From ben at smart-cactus.org  Tue Jun 17 12:51:58 2025
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 17 Jun 2025 08:51:58 -0400
Subject: Placing GitLab behind Anubis
In-Reply-To: <0455998C-2CDC-4C88-BC81-B8413AB656D7@glitchbra.in>
References: <87frfz760y.fsf@smart-cactus.org>
 <DBBPR04MB79647219026FACA0B2C4E78DB073A@DBBPR04MB7964.eurprd04.prod.outlook.com>
 <0455998C-2CDC-4C88-BC81-B8413AB656D7@glitchbra.in>
Message-ID: <87bjqm7cph.fsf@smart-cactus.org>

Hécate via ghc-devs <ghc-devs at haskell.org> writes:

> From experience it takes a couple of seconds and it's just client JS.
>

Right, I believe the amount of work is configurable. This is a knob that
we will may need to twiddle. freedesktop.org's challenge takes less than
a second on my laptop.

Cheers,

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

From klebinger.andreas at gmx.at  Wed Jun 18 14:34:09 2025
From: klebinger.andreas at gmx.at (Andreas Klebinger)
Date: Wed, 18 Jun 2025 16:34:09 +0200
Subject: RTS: mmap fails on RISC-V with Linux 6.8
In-Reply-To: <3595c1c3-8509-41de-936e-00843acdb645@gmx.de>
References: <3595c1c3-8509-41de-936e-00843acdb645@gmx.de>
Message-ID: <683eb016-1da0-4865-b9f8-6ce63380c288@gmx.at>

There have been changes to upstream that likely fixes this.

See https://gitlab.haskell.org/ghc/ghc/-/issues/25492

If you can reproduce this issue using a ghc build base of a recent ghc 
master version please let us know!

Cheers

On 27/05/2025 20:35, Heinrich Schuchardt via ghc-devs wrote:

> The following bug related to the Haskell runtime was reported in 
> Launchpad:
>
> Haskell's default behaviour of using large-address-space is causing 
> pandoc to stuck in an infinite loop on QEMU 10 Edit
> https://bugs.launchpad.net/ubuntu/+source/ghc/+bug/2111581
>
> The problem seems to relate to the following loop in 
> osReserveHeapMemory():
>
> https://gitlab.haskell.org/ghc/ghc/-/blob/master/rts/posix/OSMem.c?ref_type=heads#L589 
>
>
> According to the mmap() manpage the address passed to the kernel in 
> only a hint there is no guarantee that the same address will be used 
> for allocation.
>
> As shown in the strace logs attached in Launchpad this code can lead 
> to an endless loop when the kernel decides always to return an address 
> below 8 GiB.
>
> It might make sense to round up the address to 8 GiB if the returned 
> address is below 8 GiB and reduce *len accordingly instead of retrying.
>
> Best regards
>
> Heinrich
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From xypron.glpk at gmx.de  Fri Jun 20 05:11:00 2025
From: xypron.glpk at gmx.de (Heinrich Schuchardt)
Date: Fri, 20 Jun 2025 07:11:00 +0200
Subject: RTS: mmap fails on RISC-V with Linux 6.8
In-Reply-To: <683eb016-1da0-4865-b9f8-6ce63380c288@gmx.at>
References: <3595c1c3-8509-41de-936e-00843acdb645@gmx.de>
 <683eb016-1da0-4865-b9f8-6ce63380c288@gmx.at>
Message-ID: <2FDA0A34-40A8-4287-9975-8887B74E4992@gmx.de>

Am 18. Juni 2025 16:34:09 MESZ schrieb Andreas Klebinger <klebinger.andreas at gmx.at>:
>There have been changes to upstream that likely fixes this.
>
>See https://gitlab.haskell.org/ghc/ghc/-/issues/25492
>
>If you can reproduce this issue using a ghc build base of a recent ghc master version please let us know!
>
>Cheers

The loop in <https://gitlab.haskell.org/ghc/ghc/-/blob/master/rts/posix/OSMem.c?ref_type=heads#L589> is still the same as what failed  when I reported the issue. The loop has not changed within the last 4 years.

If mmap() consistently returns an address below 8GiB, the code loops forever.

Best regards 

Heinrich 


>
>On 27/05/2025 20:35, Heinrich Schuchardt via ghc-devs wrote:
>
>> The following bug related to the Haskell runtime was reported in Launchpad:
>> 
>> Haskell's default behaviour of using large-address-space is causing pandoc to stuck in an infinite loop on QEMU 10 Edit
>> https://bugs.launchpad.net/ubuntu/+source/ghc/+bug/2111581
>> 
>> The problem seems to relate to the following loop in osReserveHeapMemory():
>> 
>> https://gitlab.haskell.org/ghc/ghc/-/blob/master/rts/posix/OSMem.c?ref_type=heads#L589 
>> 
>> According to the mmap() manpage the address passed to the kernel in only a hint there is no guarantee that the same address will be used for allocation.
>> 
>> As shown in the strace logs attached in Launchpad this code can lead to an endless loop when the kernel decides always to return an address below 8 GiB.
>> 
>> It might make sense to round up the address to 8 GiB if the returned address is below 8 GiB and reduce *len accordingly instead of retrying.
>> 
>> Best regards
>> 
>> Heinrich
>> 
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


From ben at well-typed.com  Sat Jun 21 17:12:43 2025
From: ben at well-typed.com (Ben Gamari)
Date: Sat, 21 Jun 2025 13:12:43 -0400
Subject: GHC 9.14 status
Message-ID: <87wm953to7.fsf@smart-cactus.org>

Hi all,

We are coming up on the final fork for the ghc-9.14 branch. I expect
that Vlad's !14136 will land in the next day. The submodule bumps will
likely land shortly after. At this rate I expect the fork to be cut on
Tuesday, with the first alphas coming around a week after.

Naturally, if I have missed anything let me know ASAP.

Cheers,

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

From write2mark1 at gmail.com  Tue Jun 24 16:11:28 2025
From: write2mark1 at gmail.com (mark M)
Date: Tue, 24 Jun 2025 16:11:28 +0000
Subject: Request for approval of account
In-Reply-To: <DBBPR04MB79646C87161F4D1D95A63214B038A@DBBPR04MB7964.eurprd04.prod.outlook.com>
References: <DBBPR04MB79646C87161F4D1D95A63214B038A@DBBPR04MB7964.eurprd04.prod.outlook.com>
Message-ID: <PH7PR19MB7310B6ED440AD22A2AAD586AF338A@PH7PR19MB7310.namprd19.prod.outlook.com>

Can I request for account approval as well  username bitcoin

________________________________
From: ghc-devs <ghc-devs-bounces at haskell.org> on behalf of Mark Seemann <mark at ploeh.dk>
Sent: Tuesday, July 18, 2023 10:44:46 AM
To: ghc-devs at haskell.org <ghc-devs at haskell.org>
Subject: Request for approval of account


Hello



I’d like to report a bug in GHC because an error message tells me to do so. In order to do that, I’m trying to follow the guidelines in https://gitlab.haskell.org/ghc/ghc/-/wikis/report-a-bug, so I’ve created an account.



The next step, as I understand it, is to use this mailing list to request approval for he account.



I’m hereby doing that.



TIA



Mark Seemann
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250624/b5b71af5/attachment.html>

From harendra.kumar at gmail.com  Sat Jun 28 12:26:03 2025
From: harendra.kumar at gmail.com (Harendra Kumar)
Date: Sat, 28 Jun 2025 17:56:03 +0530
Subject: openFile gives "file is locked" error on Linux when creating a
 non-existing file
In-Reply-To: <ZzhKd5ccnk5lP-pn@chardros.imrryr.org>
References: <ZwTPFOdJ9kFCInfr@chardros.imrryr.org>
 <CAPW+kkbcSFzYcQv-FwHDQww8P9CgWWLyDKp10_JcBoEZG4uV4w@mail.gmail.com>
 <ZwUI-EInD3b-569V@chardros.imrryr.org>
 <CAPW+kkZyActMm_C9VphFD-k6ezhLY7MwTRzvTvpO6GCED01KXg@mail.gmail.com>
 <ZwXyp29LdyxQlIqt@chardros.imrryr.org>
 <CAPW+kkYR2pdLUsrc1p5rSouBiMtOqUxtHbBPOyy7X2kH+nCGhQ@mail.gmail.com>
 <ZwYOOwnirs0lqI0-@chardros.imrryr.org>
 <CAPW+kkaspne_dqHTxQTcuvN1sFRYJh+V-P9swaw0vtaDmz7g9Q@mail.gmail.com>
 <ZwcLiPPnsM8OfTyh@chardros.imrryr.org>
 <CAPW+kkayL0U4fo3r2HUTipKfBvEcyGJ5KQfxwKbF12aPXUQmxg@mail.gmail.com>
 <ZzhKd5ccnk5lP-pn@chardros.imrryr.org>
Message-ID: <CAPW+kkapxCyxy_ZSO5L+11EXCrP7ZJT=+yjQnM-j_jE6XhAqnQ@mail.gmail.com>

We instrumented the GHC locking mechanism as suggested by Viktor and
deployed the instrumented GHC in CI. We got our first crash after 4 months!

Summary from the preliminary investigation of the crash:

* The problem is not filesystem dependent or inode reuse related.
* After understanding it better, now I am able to reproduce it on the
local machine.
* The problem may be related to hClose getting interrupted by an async
exception.

The GHC panic message from the instrumented code is as follows:

2025-06-27T09:11:41.8177372Z lockFile: first lock: pid 21804, tid
21806, id 17 dev 2065 ino 262152 write 1
  2025-06-27T09:11:41.8178053Z FileSystem.Event: internal error:
close: lock exists: pid 21804, tid 21806, fd 17
2025-06-27T09:11:41.8178492Z
2025-06-27T09:11:41.8178604Z     (GHC version 9.2.8 for x86_64_unknown_linux)
2025-06-27T09:11:41.8179160Z     Please report this as a GHC bug:
https://www.haskell.org/ghc/reportabug

The message is coming from the "close" system call wrapper that I
created. It means we are closing the fd without releasing the lock first.

Based on the test logs I figured that the "close" call in the panic message is
happening from this code:

createFile :: FilePath -> FilePath -> IO ()
createFile file parent = openFile (parent </> file) WriteMode >>= hClose

Now the interesting thing is that in this particular test, we are
running two threads. In one thread, we are watching for file system
events related to this file, and in the other thread we are running
the createFile code snippet given above. As soon as the file gets
created we receive a file CREATED event in the first thread and we use
throwTo to send a ThreadAbort async exception to the createFile thread to
kill it.

My theory is that if the exception is delivered at a certain point
during hClose it returns without releasing the lock but closes the
file. To test that theory I wrote the createFile thread code as shown
below, so that I keep doing open and close in a loop, to make it more
likely to interrupt hClose by the exception:

createFile :: FilePath -> FilePath -> IO ()
createFile file parent = go
    where
    go =
        do
            h <- openFile (parent </> file) WriteMode
            hClose h
            go

Voila! With this code I am able to reproduce it locally now, though it
takes many runs (in a loop) and more than a few minutes to reproduce.

Any ideas, whether the problem is in hClose or it may be something else?
Next, I will try a code review of hClose and instrumenting further to narrow
down the problem.

Thanks,
Harendra

On Sat, 16 Nov 2024 at 13:02, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>
> On Fri, Nov 15, 2024 at 06:45:40PM +0530, Harendra Kumar wrote:
>
> > Coming back to this issue after a break. I reviewed the code carefully
> > and I cannot find anything where we are doing something in the
> > application code that affects the RTS locking mechanism. Let me walk
> > through the steps of the test up to failure and what we are doing in
> > the code. The test output is like this:
>
> It is indeed not immediately clear where in your code or in some
> dependency (including base, GHC, ...) a descriptor that contributes to
> the RTS file reader/writer count (indexed by (dev, ino)) might be closed
> without adjusting the count by calling the RTS `unlockFile()` function
> (via GHC.IO.FD.release).
>
> It may be worth noting that GHC does not *reliably* prevent simultaneous
> open handles for the same underlying file, because handles returned by
> hDuplicate do not contribute to the count:
>
>     demo.hs:
>         import GHC.IO.Handle (hDuplicate)
>         import System.IO
>
>         main :: IO ()
>         main = do
>             fh1 <- dupOpen "/tmp/foo"
>             fh2 <- dupOpen "/tmp/foo"
>             writeNow fh1 "abc\n"
>             writeNow fh2 "def\n"
>             readFile "/tmp/foo" >>= putStr
>             hClose fh1
>             hClose fh2
>          where
>             -- Look Mom, no lock!
>             dupOpen path = do
>                 fh <- openFile path WriteMode
>                 hDuplicate fh <* hClose fh
>
>             writeNow fh s = hPutStr fh s >> hFlush fh
>
>     $ ghc -O demo.hs
>     [1 of 2] Compiling Main             ( demo.hs, demo.o )
>     [2 of 2] Linking demo
>     $ ./demo
>     def
>
> I am not sure that Haskell really should be holding the application's
> hand in this area, corrupting output files by concurrent writers can
> just as easily happen by running two independent processes.  But letting
> go of this guardrail would IIRC be a deviation from the Haskell report,
> and there are likely applications that depend on this (and don't use
> hDupicate or equivalent to break the reader/writer tracking).
>
> --
>     Viktor.
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From simon.peytonjones at gmail.com  Mon Jun 30 16:47:23 2025
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 30 Jun 2025 17:47:23 +0100
Subject: Build failure
Message-ID: <CAJKmMz_12OSnGPYjpg+4FvSiG7Y7wqK7iJF_RRJq2+tOw0afkw@mail.gmail.com>

Friends

My build !14410 has started consistently failing to show me testsuite
output etc.  The tail of the log is s very long sequence of Haddock
warnings.

Something has changed and I don't think it's my MR!

Does anyone have any idea what is happening?

Thanks
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20250630/e271b856/attachment.html>

From apoorv-ingle at uiowa.edu  Mon Jun 30 17:07:32 2025
From: apoorv-ingle at uiowa.edu (Ingle, Apoorv N)
Date: Mon, 30 Jun 2025 17:07:32 +0000
Subject: [External] Build failure
In-Reply-To: <CAJKmMz_12OSnGPYjpg+4FvSiG7Y7wqK7iJF_RRJq2+tOw0afkw@mail.gmail.com>
References: <CAJKmMz_12OSnGPYjpg+4FvSiG7Y7wqK7iJF_RRJq2+tOw0afkw@mail.gmail.com>
Message-ID: <47260096-8BDB-42FA-9055-374490DBCCEF@uiowa.edu>

Hi Simon,

I suspect you need to click on the arrow right next to the line numbers in the log to unfold the complete log starting “Test via Hadrian"

— Apoorv


On Jun 30, 2025, at 11:47 AM, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:

Friends

My build !14410 has started consistently failing to show me testsuite output etc.  The tail of the log is s very long sequence of Haddock warnings.

Something has changed and I don't think it's my MR!

Does anyone have any idea what is happening?

Thanks
Simon

_______________________________________________
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/20250630/004e3c22/attachment.html>