From matthewtpickering at gmail.com  Tue Jan  3 11:14:36 2023
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 3 Jan 2023 11:14:36 +0000
Subject: Will there be a GHC 9.2.6?
In-Reply-To: <CAFDVgwE+p4p_jNV3uLY+MTMVidHhyz2-2D92=_mVL_07DJFrUg@mail.gmail.com>
References: <CAFDVgwGn8kesp-5+Gy=NdkFFiyiBSOZBWPXQUs+yq4qot_FXHg@mail.gmail.com>
 <CAFDVgwE+p4p_jNV3uLY+MTMVidHhyz2-2D92=_mVL_07DJFrUg@mail.gmail.com>
Message-ID: <CALuQ0m_YHyB404N7J=Q=BCvkE9Vx+92CwU+PpgG6wDm8KtE22w@mail.gmail.com>

Hi Clinton,

It seems likely to me that there will be a 9.2.6 release but we need
to discuss it once everyone is back from holiday in order to determine
when to schedule it and which patches need to be included.

Cheers,

Matt

On Fri, Dec 30, 2022 at 12:07 PM Clinton Mead <clintonmead at gmail.com> wrote:
>
> Hi All
>
> I just noticed Haskell Language Server (HLS) 1.9 has been released, which supports GHC 9.2.5. My organisation is currently using GHC 9.2.2 and I don't see any immediate need to jump to GHC 9.4, it would be good to settle on the latest most stable version of the GHC 9.2 series as it includes all the features we need at the moment. Also I understand that HLS tends to have long term(ish) support for the latest GHC in a release series.
>
> I'd rather not do this upgrade twice so I was just wondering whether it has been decided or not whether there will be a 9.2.6 release (if this is still unknown that's okay).
>
> I did notice this page: https://gitlab.haskell.org/ghc/ghc/-/milestones/385 but was unsure whether this page was autogenerated or a deliberate indication that there will be a GHC 9.2.6 at some point.
>
> Thanks,
> Clinton
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From carter.schonwald at gmail.com  Fri Jan 13 17:06:54 2023
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 13 Jan 2023 12:06:54 -0500
Subject: Deprecating Safe Haskell, or heavily investing in it?
In-Reply-To: <CABFs2VgnYir07TPFJ9D5xzhKcMoLzY3eqJFPsyN7vBu6eQA0aA@mail.gmail.com>
References: <4b5304a6-f035-b72c-0816-d450d9347ea7@glitchbra.in>
 <CAPq5Pv+h0gtxTAXB4YERhCp0Hkx43xhJbqQJQi-f+b4m38w+zA@mail.gmail.com>
 <Y6wy/c/ET6iPeNr7@cloudinit-builder>
 <CABFs2VgnYir07TPFJ9D5xzhKcMoLzY3eqJFPsyN7vBu6eQA0aA@mail.gmail.com>
Message-ID: <CAHYVw0yCgSdd321bn_KAL+pt-Ge5NvegE4eYdzLCB2-3Ls4jcA@mail.gmail.com>

Indeed type safety is exactly what it’s for! The other notions of safety
were never part of the goals. And it was designed so that the end user
could decide which codes they deem trustworthy.

On Wed, Dec 28, 2022 at 6:04 PM davean <davean at xkcd.com> wrote:

> The only part of Safe Haskell I ever really cared about was type safety.
> That's what matters, I think.
>
> I've wanted to use it a number of times and played with it, but it's never
> actually managed to become an important part of anything for me.
> So take that as you will. I'd love it if it worked well, its issues have
> limited what I attempt, but at the end of the day it's never hurt me too
> bad to not have it.
>
>
> -davean
>
> On Wed, Dec 28, 2022 at 7:14 AM Tom Ellis <
> tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk> wrote:
>
>> On Tue, Dec 27, 2022 at 08:33:04PM -0700, Chris Smith wrote:
>> > This conversation reminds me of a parable I encountered somewhere, in
>> which
>> > someone declares "I don't understand why this decision was ever made,
>> and I
>> > we should change it", and someone responds, "No, if you don't understand
>> > the decision was made, then you don't know enough to change it.  If you
>> > learn why it was decided that way in the first place, then you will have
>> > the understanding to decide whether to change it."
>>
>> That parable is Chesterton's fence:
>>
>> https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence
>> _______________________________________________
>> 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/20230113/9e47a75a/attachment.html>

From jaro.reinders at gmail.com  Fri Jan 13 18:44:15 2023
From: jaro.reinders at gmail.com (Jaro Reinders)
Date: Fri, 13 Jan 2023 19:44:15 +0100
Subject: Deprecating Safe Haskell, or heavily investing in it?
In-Reply-To: <CAHYVw0yCgSdd321bn_KAL+pt-Ge5NvegE4eYdzLCB2-3Ls4jcA@mail.gmail.com>
References: <4b5304a6-f035-b72c-0816-d450d9347ea7@glitchbra.in>
 <CAPq5Pv+h0gtxTAXB4YERhCp0Hkx43xhJbqQJQi-f+b4m38w+zA@mail.gmail.com>
 <Y6wy/c/ET6iPeNr7@cloudinit-builder>
 <CABFs2VgnYir07TPFJ9D5xzhKcMoLzY3eqJFPsyN7vBu6eQA0aA@mail.gmail.com>
 <CAHYVw0yCgSdd321bn_KAL+pt-Ge5NvegE4eYdzLCB2-3Ls4jcA@mail.gmail.com>
Message-ID: <ea7ee017-5852-5bbe-1287-7c4bb717f77e@gmail.com>

I do agree that Safe Haskell would be useful even if it was only used for 
enforcing type safety and avoiding accidental use of unsafe features, but the 
paper [1] makes it quite clear that one of the main goals is to safely execute 
untrusted code:

"Safe Haskell makes it possible to confine and safely execute untrusted, 
possibly malicious code. By strictly enforcing types, Safe Haskell allows a 
variety of different policies from API sandboxing to information-flow control 
to be implemented easily as monads.
[..]
We use Safe Haskell to implement an online Haskell interpreter that can 
securely execute arbitrary untrusted code with no overhead."

Cheers, Jaro

[1] https://www.scs.stanford.edu/~dm/home/papers/terei:safe-haskell.pdf

On 13-01-2023 18:06, Carter Schonwald wrote:
> Indeed type safety is exactly what it’s for! The other notions of safety were 
> never part of the goals. And it was designed so that the end user could decide 
> which codes they deem trustworthy.
> 
> On Wed, Dec 28, 2022 at 6:04 PM davean <davean at xkcd.com 
> <mailto:davean at xkcd.com>> wrote:
> 
>     The only part of Safe Haskell I ever really cared about was type safety.
>     That's what matters, I think.
> 
>     I've wanted to use it a number of times and played with it, but it's never
>     actually managed to become an important part of anything for me.
>     So take that as you will. I'd love it if it worked well, its issues have
>     limited what I attempt, but at the end of the day it's never hurt me too
>     bad to not have it.
> 
> 
>     -davean
> 
>     On Wed, Dec 28, 2022 at 7:14 AM Tom Ellis
>     <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk
>     <mailto:tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>> wrote:
> 
>         On Tue, Dec 27, 2022 at 08:33:04PM -0700, Chris Smith wrote:
>          > This conversation reminds me of a parable I encountered somewhere,
>         in which
>          > someone declares "I don't understand why this decision was ever
>         made, and I
>          > we should change it", and someone responds, "No, if you don't understand
>          > the decision was made, then you don't know enough to change it.  If you
>          > learn why it was decided that way in the first place, then you will have
>          > the understanding to decide whether to change it."
> 
>         That parable is Chesterton's fence:
> 
>         https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence
>         <https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence>
>         _______________________________________________
>         ghc-devs mailing list
>         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>         <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
> 
>     _______________________________________________
>     ghc-devs mailing list
>     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
>     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>     <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

From carter.schonwald at gmail.com  Fri Jan 13 19:53:34 2023
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Fri, 13 Jan 2023 14:53:34 -0500
Subject: Deprecating Safe Haskell, or heavily investing in it?
In-Reply-To: <ea7ee017-5852-5bbe-1287-7c4bb717f77e@gmail.com>
References: <4b5304a6-f035-b72c-0816-d450d9347ea7@glitchbra.in>
 <CAPq5Pv+h0gtxTAXB4YERhCp0Hkx43xhJbqQJQi-f+b4m38w+zA@mail.gmail.com>
 <Y6wy/c/ET6iPeNr7@cloudinit-builder>
 <CABFs2VgnYir07TPFJ9D5xzhKcMoLzY3eqJFPsyN7vBu6eQA0aA@mail.gmail.com>
 <CAHYVw0yCgSdd321bn_KAL+pt-Ge5NvegE4eYdzLCB2-3Ls4jcA@mail.gmail.com>
 <ea7ee017-5852-5bbe-1287-7c4bb717f77e@gmail.com>
Message-ID: <CAHYVw0y9YJjz+pF0GRwGR=VYE9BsU0ZHYyeZCVFLZ1OYgyxRNw@mail.gmail.com>

I think some flavor / iterations of lambda bot has used it for example.

On Fri, Jan 13, 2023 at 1:44 PM Jaro Reinders <jaro.reinders at gmail.com>
wrote:

> I do agree that Safe Haskell would be useful even if it was only used for
> enforcing type safety and avoiding accidental use of unsafe features, but
> the
> paper [1] makes it quite clear that one of the main goals is to safely
> execute
> untrusted code:
>
> "Safe Haskell makes it possible to confine and safely execute untrusted,
> possibly malicious code. By strictly enforcing types, Safe Haskell allows
> a
> variety of different policies from API sandboxing to information-flow
> control
> to be implemented easily as monads.
> [..]
> We use Safe Haskell to implement an online Haskell interpreter that can
> securely execute arbitrary untrusted code with no overhead."
>
> Cheers, Jaro
>
> [1] https://www.scs.stanford.edu/~dm/home/papers/terei:safe-haskell.pdf
>
> On 13-01-2023 18:06, Carter Schonwald wrote:
> > Indeed type safety is exactly what it’s for! The other notions of safety
> were
> > never part of the goals. And it was designed so that the end user could
> decide
> > which codes they deem trustworthy.
> >
> > On Wed, Dec 28, 2022 at 6:04 PM davean <davean at xkcd.com
> > <mailto:davean at xkcd.com>> wrote:
> >
> >     The only part of Safe Haskell I ever really cared about was type
> safety.
> >     That's what matters, I think.
> >
> >     I've wanted to use it a number of times and played with it, but it's
> never
> >     actually managed to become an important part of anything for me.
> >     So take that as you will. I'd love it if it worked well, its issues
> have
> >     limited what I attempt, but at the end of the day it's never hurt me
> too
> >     bad to not have it.
> >
> >
> >     -davean
> >
> >     On Wed, Dec 28, 2022 at 7:14 AM Tom Ellis
> >     <tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk
> >     <mailto:tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk>> wrote:
> >
> >         On Tue, Dec 27, 2022 at 08:33:04PM -0700, Chris Smith wrote:
> >          > This conversation reminds me of a parable I encountered
> somewhere,
> >         in which
> >          > someone declares "I don't understand why this decision was
> ever
> >         made, and I
> >          > we should change it", and someone responds, "No, if you don't
> understand
> >          > the decision was made, then you don't know enough to change
> it.  If you
> >          > learn why it was decided that way in the first place, then
> you will have
> >          > the understanding to decide whether to change it."
> >
> >         That parable is Chesterton's fence:
> >
> >
> https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence
> >         <
> https://en.wikipedia.org/wiki/G._K._Chesterton#Chesterton's_fence>
> >         _______________________________________________
> >         ghc-devs mailing list
> >         ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> >         http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >         <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
> >
> >     _______________________________________________
> >     ghc-devs mailing list
> >     ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> >     http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >     <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
> _______________________________________________
> 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/20230113/d7fe422b/attachment.html>

From ben at well-typed.com  Fri Jan 13 23:01:19 2023
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 13 Jan 2023 18:01:19 -0500
Subject: [ANNOUNCE] GHC 9.6.1-alpha1 is now available
Message-ID: <87r0vyt4yd.fsf@smart-cactus.org>


The GHC team is very pleased to announce the availability of GHC
9.6.1-alpha1. As usual, binaries and source distributions are available
at downloads.haskell.org:

    https://downloads.haskell.org/ghc/9.6.1-alpha1/

This is the first alpha release in the 9.6 series which will bring a
number of exciting features:

* A new Javascript code generation backend

* A new WebAssembly code generation backend,

* Significant latency improvements in the non-moving garbage collector

* Support for loading of multiple components in GHCi

* Efficient support for delimited continuations

* Improvements in error messages

* Numerous improvements in compiler-residency

Note that both the Javascript and WebAssembly backends are still in a
state of infancy and are present in this release as a technology
preview; we hope that they will mature considerably before the final
9.6.1 release.

Please give this release a try and open a [ticket] if you see anything
amiss.

Cheers,

- Ben


[ticket]: https://gitlab.haskell.org/ghc/ghc/issues/

-------------- 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/20230113/b416a2a0/attachment.sig>

From george.colpitts at gmail.com  Sat Jan 14 12:51:54 2023
From: george.colpitts at gmail.com (George Colpitts)
Date: Sat, 14 Jan 2023 08:51:54 -0400
Subject: [ANNOUNCE] GHC 9.6.1-alpha1 is now available
In-Reply-To: <87r0vyt4yd.fsf@smart-cactus.org>
References: <87r0vyt4yd.fsf@smart-cactus.org>
Message-ID: <CAB-d4A5CUYpTWCz9aMu=Hct1Nn4M_terz=c58wypmpVDC1fhhA@mail.gmail.com>

Hi

I believe llvm does not work in this alpha as 21936 is still open. Is that
correct?

I also believe that when it does work it will require llvm 15 which will be
incompatible with earlier versions of ghc. Is that correct?

Thanks
George




On Fri, Jan 13, 2023 at 7:02 PM Ben Gamari <ben at well-typed.com> wrote:

>
> The GHC team is very pleased to announce the availability of GHC
> 9.6.1-alpha1. As usual, binaries and source distributions are available
> at downloads.haskell.org:
>
>     https://downloads.haskell.org/ghc/9.6.1-alpha1/
>
> This is the first alpha release in the 9.6 series which will bring a
> number of exciting features:
>
> * A new Javascript code generation backend
>
> * A new WebAssembly code generation backend,
>
> * Significant latency improvements in the non-moving garbage collector
>
> * Support for loading of multiple components in GHCi
>
> * Efficient support for delimited continuations
>
> * Improvements in error messages
>
> * Numerous improvements in compiler-residency
>
> Note that both the Javascript and WebAssembly backends are still in a
> state of infancy and are present in this release as a technology
> preview; we hope that they will mature considerably before the final
> 9.6.1 release.
>
> Please give this release a try and open a [ticket] if you see anything
> amiss.
>
> Cheers,
>
> - Ben
>
>
> [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/
>
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230114/c78e16a1/attachment.html>

From george.colpitts at gmail.com  Sun Jan 15 17:01:49 2023
From: george.colpitts at gmail.com (George Colpitts)
Date: Sun, 15 Jan 2023 13:01:49 -0400
Subject: [ANNOUNCE] GHC 9.6.1-alpha1 is now available
In-Reply-To: <CAB-d4A5CUYpTWCz9aMu=Hct1Nn4M_terz=c58wypmpVDC1fhhA@mail.gmail.com>
References: <87r0vyt4yd.fsf@smart-cactus.org>
 <CAB-d4A5CUYpTWCz9aMu=Hct1Nn4M_terz=c58wypmpVDC1fhhA@mail.gmail.com>
Message-ID: <CAB-d4A6=9+AASao44-+Kcx6cp8osXYSLooJf6oKuhxdum65RaQ@mail.gmail.com>

my original email corrected below

On Sat, Jan 14, 2023 at 8:51 AM George Colpitts <george.colpitts at gmail.com>
wrote:

> Hi
>
> I believe llvm 15 does not work in this alpha as 21936 is still open. Is
> that correct?
>
> I also believe that when it does work ghc 9.6 will not be compatible with
> earlier versions of llvm 15. Is that correct?
>
> Thanks
> George
>
>
>
>
> On Fri, Jan 13, 2023 at 7:02 PM Ben Gamari <ben at well-typed.com> wrote:
>
>>
>> The GHC team is very pleased to announce the availability of GHC
>> 9.6.1-alpha1. As usual, binaries and source distributions are available
>> at downloads.haskell.org:
>>
>>     https://downloads.haskell.org/ghc/9.6.1-alpha1/
>>
>> This is the first alpha release in the 9.6 series which will bring a
>> number of exciting features:
>>
>> * A new Javascript code generation backend
>>
>> * A new WebAssembly code generation backend,
>>
>> * Significant latency improvements in the non-moving garbage collector
>>
>> * Support for loading of multiple components in GHCi
>>
>> * Efficient support for delimited continuations
>>
>> * Improvements in error messages
>>
>> * Numerous improvements in compiler-residency
>>
>> Note that both the Javascript and WebAssembly backends are still in a
>> state of infancy and are present in this release as a technology
>> preview; we hope that they will mature considerably before the final
>> 9.6.1 release.
>>
>> Please give this release a try and open a [ticket] if you see anything
>> amiss.
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/
>>
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230115/eb63907c/attachment.html>

From george.colpitts at gmail.com  Sun Jan 15 17:02:31 2023
From: george.colpitts at gmail.com (George Colpitts)
Date: Sun, 15 Jan 2023 13:02:31 -0400
Subject: [ANNOUNCE] GHC 9.6.1-alpha1 is now available
In-Reply-To: <CAB-d4A6=9+AASao44-+Kcx6cp8osXYSLooJf6oKuhxdum65RaQ@mail.gmail.com>
References: <87r0vyt4yd.fsf@smart-cactus.org>
 <CAB-d4A5CUYpTWCz9aMu=Hct1Nn4M_terz=c58wypmpVDC1fhhA@mail.gmail.com>
 <CAB-d4A6=9+AASao44-+Kcx6cp8osXYSLooJf6oKuhxdum65RaQ@mail.gmail.com>
Message-ID: <CAB-d4A52SS=8O1pNcMGmttD7XMjr9-uHj9Jsq4wiipR2J8nXhg@mail.gmail.com>

On Sun, Jan 15, 2023 at 1:01 PM George Colpitts <george.colpitts at gmail.com>
wrote:

> my original email corrected below
>
> On Sat, Jan 14, 2023 at 8:51 AM George Colpitts <george.colpitts at gmail.com>
> wrote:
>
>> Hi
>>
>> I believe llvm 15 does not work in this alpha as 21936 is still open. Is
>> that correct?
>>
>> I also believe that when it does work ghc 9.6 will not be compatible
>> with earlier versions of llvm. Is that correct?
>>
>> Thanks
>> George
>>
>>
>>
>>
>> On Fri, Jan 13, 2023 at 7:02 PM Ben Gamari <ben at well-typed.com> wrote:
>>
>>>
>>> The GHC team is very pleased to announce the availability of GHC
>>> 9.6.1-alpha1. As usual, binaries and source distributions are available
>>> at downloads.haskell.org:
>>>
>>>     https://downloads.haskell.org/ghc/9.6.1-alpha1/
>>>
>>> This is the first alpha release in the 9.6 series which will bring a
>>> number of exciting features:
>>>
>>> * A new Javascript code generation backend
>>>
>>> * A new WebAssembly code generation backend,
>>>
>>> * Significant latency improvements in the non-moving garbage collector
>>>
>>> * Support for loading of multiple components in GHCi
>>>
>>> * Efficient support for delimited continuations
>>>
>>> * Improvements in error messages
>>>
>>> * Numerous improvements in compiler-residency
>>>
>>> Note that both the Javascript and WebAssembly backends are still in a
>>> state of infancy and are present in this release as a technology
>>> preview; we hope that they will mature considerably before the final
>>> 9.6.1 release.
>>>
>>> Please give this release a try and open a [ticket] if you see anything
>>> amiss.
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>>> [ticket]: https://gitlab.haskell.org/ghc/ghc/issues/
>>>
>>> _______________________________________________
>>> Glasgow-haskell-users mailing list
>>> Glasgow-haskell-users at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230115/c906786a/attachment.html>

From ben at well-typed.com  Mon Jan 16 14:02:21 2023
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 16 Jan 2023 09:02:21 -0500
Subject: [ANNOUNCE] GHC 9.6.1-alpha1 is now available
In-Reply-To: <CAB-d4A5CUYpTWCz9aMu=Hct1Nn4M_terz=c58wypmpVDC1fhhA@mail.gmail.com>
References: <87r0vyt4yd.fsf@smart-cactus.org>
 <CAB-d4A5CUYpTWCz9aMu=Hct1Nn4M_terz=c58wypmpVDC1fhhA@mail.gmail.com>
Message-ID: <87lem2tw6g.fsf@smart-cactus.org>

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

> Hi
>
> I believe llvm does not work in this alpha as 21936 is still open. Is that
> correct?
>
Indeed we do not yet support LLVM 15 but all previous LLVM versions
continue to work. We can try to fix this for the final release.


> I also believe that when it does work it will require llvm 15 which will be
> incompatible with earlier versions of ghc. Is that correct?
>
Early indications suggest that supporting LLVM 15 will require that we
raise the minimum supported version to LLVM 13.

Cheers,

- Ben
-------------- 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/20230116/a9907d26/attachment.sig>

From bryan at haskell.foundation  Mon Jan 23 07:13:29 2023
From: bryan at haskell.foundation (Bryan Richter)
Date: Mon, 23 Jan 2023 09:13:29 +0200
Subject: Marge-bot outage over the weekend
Message-ID: <CACUTo6zAnDy+=3vCDNJMV80wQGqJ5JCO2eDcEJtQ8=zNHhhOSA@mail.gmail.com>

Hi folks,

Just writing to let you know that Marge experienced an error condition
on Friday (unable to reach GitLab) and shut down. I noticed it this
morning and restarted the service. A new batch merge
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9774 is now
active.

-Bryan

From matthewtpickering at gmail.com  Mon Jan 23 11:45:43 2023
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Mon, 23 Jan 2023 11:45:43 +0000
Subject: Marge-bot outage over the weekend
In-Reply-To: <CACUTo6zAnDy+=3vCDNJMV80wQGqJ5JCO2eDcEJtQ8=zNHhhOSA@mail.gmail.com>
References: <CACUTo6zAnDy+=3vCDNJMV80wQGqJ5JCO2eDcEJtQ8=zNHhhOSA@mail.gmail.com>
Message-ID: <CALuQ0m8BmnSDa=Mv46aTYe=5L+koDK9CM4j_7Gh7roqR-3DGAA@mail.gmail.com>

Thanks Bryan for unsticking things.

On Mon, Jan 23, 2023 at 7:13 AM Bryan Richter via ghc-devs
<ghc-devs at haskell.org> wrote:
>
> Hi folks,
>
> Just writing to let you know that Marge experienced an error condition
> on Friday (unable to reach GitLab) and shut down. I noticed it this
> morning and restarted the service. A new batch merge
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9774 is now
> active.
>
> -Bryan
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From mail at joachim-breitner.de  Mon Jan 23 14:41:21 2023
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 23 Jan 2023 15:41:21 +0100
Subject: DKIM failures for gitlab mail
In-Reply-To: <CACUTo6zOxmy4T4p7fUpSXJTQLNKnA8TbHpaZRUHre284njkD_w@mail.gmail.com>
References: <15a1738d1daedaad7a7f7b8a3b2db9944dd3ed7b.camel@joachim-breitner.de>
 <Y4eO1OQ/ZekwFLre@straasha.imrryr.org>
 <CACUTo6zOxmy4T4p7fUpSXJTQLNKnA8TbHpaZRUHre284njkD_w@mail.gmail.com>
Message-ID: <52e4723d1fcea5f0ea644415e465351d1dfea6f8.camel@joachim-breitner.de>

Hi Ben,

gentle reminder about this issue? I’m worried I (and maybe others) are
going to miss gitlab notifications.

Cheers,
Joachim

Am Donnerstag, dem 01.12.2022 um 10:21 +0200 schrieb Bryan Richter via
ghc-devs:
> Thanks for noticing, Joachim!
> 
> Ben Gamari is still the primary contact for GitLab configuration...
> Ben, maybe you know something about this?
> 
> On Wed, Nov 30, 2022 at 7:12 PM Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> > 
> > On Wed, Nov 30, 2022 at 05:33:44PM +0100, Joachim Breitner wrote:
> > 
> > > I noticed that a small number of Gitlab notification emails end up in
> > > my spamfilter. While there is not much you can do about triggering some
> > > bayesian style spam filter at my email provider (mailbox.org), I did
> > > notice this in the headers:
> > > 
> > > X-Spam-Status: No, score=2.704 tagged_above=2 required=6
> > >         tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HS_RSPAMD_10_11=2.5,
> > >         HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001,
> > >         URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
> > > Authentication-Results: spamfilter01.heinlein-hosting.de (amavisd-new);
> > >         dkim=fail (1024-bit key) reason="fail (bad RSA signature)"
> > >         header.d=gitlab.haskell.org
> > > DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
> > > d=gitlab.haskell.org;
> > >         s=mail; t=1669733134;
> > >         bh=D0NUcHiskEnwSP99umP3zo8Fz8fl74OgAJ8NRDKCsp4=;
> > >         h=Date:From:Reply-To:To:In-Reply-To:References:Subject:List-Id:
> > >          List-Unsubscribe;
> > >         b=R+WMLfhRZZdYxMd6K6w+iodDe8EHzwONNArNyboqsU5NnafPRhKZ1UeGxO/BCMvEK
> > >          M7XHRRrBsPfRYpTph7xSGY427KGXieASVg1GDhAiwKSLBCiqDdkBaoJLLUIfUD02NS
> > >          ouI3tvQ9mddNdaEK7retq8N+29hzs/ezf9cpgy+Q=
> > 
> > Indeed the signature in "b=" was not made by the key at
> > mail._domainkey.gitlab.haskell.org.  Running the below:
> > 
> >     sig=$(
> >         printf "%s\n%s\n%s\n" \
> >             R+WMLfhRZZdYxMd6K6w+iodDe8EHzwONNArNyboqsU5NnafPRhKZ1UeGxO/BCMvE \
> >             KM7XHRRrBsPfRYpTph7xSGY427KGXieASVg1GDhAiwKSLBCiqDdkBaoJLLUIfUD0 \
> >             2NSouI3tvQ9mddNdaEK7retq8N+29hzs/ezf9cpgy+Q=
> >         )
> > 
> >     pkey=$(
> >         dig +short -t txt mail._domainkey.gitlab.haskell.org |
> >         perl -MMIME::Base64 -ne '
> >             /^"v=DKIM1;/ or next;
> >             print decode_base64($1) if m{;\s*p=(\S+?)(?:;|$)}
> >             ' |
> >         openssl pkey -pubin -inform DER
> >         )
> > 
> >     openssl rsautl -raw -encrypt -pubin \
> >         -inkey <( printf "%s\n" "$pkey" ) \
> >         -in <(printf "%s\n" "$sig" | openssl base64 -d) |
> >         xxd -p
> > 
> > the output is:
> > 
> >     509bfc93a492f1b5328308e51624d9a7ed1378861f577b11413c5034bc0c
> >     673d61660434d4bc30844e7648da0f9605923805973a313a8c3bc82215cc
> >     ac447e47551087c544a0592ac3ae48474584bad7d9ca5b850a67493a7977
> >     d28aaa3a9a7580d165dc4f31ff484bdbc40e94a2be1750e71c51c555b5c1
> >     6bc051947bb07ae4
> > 
> > Which is not a PKCS#1.5 padded signature block.  So either the
> > "b=" value was corrupted in transit, or it was signed by a key
> > that is different from what is published in DNS.
> > 
> > > but maybe Postfix  is not using the right key?
> > 
> > Strictly speaking that's not Postfix itself, but some DKIM milter, but
> > nits aside, more likely a stale public key is published in DNS.
> > 
> > --
> >     Viktor.
> > _______________________________________________
> > 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

-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/


From ietf-dane at dukhovni.org  Mon Jan 23 17:23:41 2023
From: ietf-dane at dukhovni.org (Viktor Dukhovni)
Date: Mon, 23 Jan 2023 12:23:41 -0500
Subject: DKIM failures for gitlab mail
In-Reply-To: <52e4723d1fcea5f0ea644415e465351d1dfea6f8.camel@joachim-breitner.de>
References: <15a1738d1daedaad7a7f7b8a3b2db9944dd3ed7b.camel@joachim-breitner.de>
 <Y4eO1OQ/ZekwFLre@straasha.imrryr.org>
 <CACUTo6zOxmy4T4p7fUpSXJTQLNKnA8TbHpaZRUHre284njkD_w@mail.gmail.com>
 <52e4723d1fcea5f0ea644415e465351d1dfea6f8.camel@joachim-breitner.de>
Message-ID: <Y87CnSzIlHBH/sVS@straasha.imrryr.org>

On Mon, Jan 23, 2023 at 03:41:21PM +0100, Joachim Breitner wrote:
> Hi Ben,
> 
> gentle reminder about this issue? I’m worried I (and maybe others) are
> going to miss gitlab notifications.

A recent gitlab notice has:

    Received: by gitlab.haskell.org (Postfix, from userid 165)
            id AF9E627CA9; Mon, 16 Jan 2023 20:50:59 -0500 (EST)
    DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gitlab.haskell.org;
            s=mail; t=1673920259;
            bh=bezCH96kI1N9pklJv6GEpVDADij1+8Q/zwCT65Djz/4=;
            h=Date:From:Reply-To:To:Subject:List-Id;
            b=L7ikqNV+Hn0OZzM9AH+rLIvP5P9COe8/zuP7bmSsMJ50kFJ2a7gJy4cbxoX83bNqU
            oBQV78j6nIFV/SRgbaF9vQciNBzWu1GNACMGaqVMVjTBki93xw/hvMv8JDIhAdAYaV
            da96BBtxrTDoDUtFBtYlb5n361TqIDHXHkCqE5Dc=

The DKIM data in DNS is:

    $ dig +short +nosplit -t txt mail._domainkey.gitlab.haskell.org
    "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDiTJ9J8+wWWFRzHjjr5CCbOx33rZaDH2PQsQtTLwOPVZDTSjz8pwUuyQ4s+Xxq6f6UEEAIo/8ZHySJqXG6HN3b6/Gq2SwnE2xLk307gcWzZgyF/9UM5SpcJ46VxYPu2spBQSWhDnRbp849ZouuY/orKT/HMb/9xow25KwWbAyh8wIDAQAB"

Putting it together:

    $ echo MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDiTJ9J8+wWWFRzHjjr5CCbOx33rZaDH2PQsQtTLwOPVZDTSjz8pwUuyQ4s+Xxq6f6UEEAIo/8ZHySJqXG6HN3b6/Gq2SwnE2xLk307gcWzZgyF/9UM5SpcJ46VxYPu2spBQSWhDnRbp849ZouuY/orKT/HMb/9xow25KwWbAyh8wIDAQAB |
	openssl base64 -A -d |
	openssl pkey -pubin -inform DER -out /tmp/pkey.pem

    $ openssl base64 -d <<-\EOF > /tmp/sig.dat
	L7ikqNV+Hn0OZzM9AH+rLIvP5P9COe8/zuP7bmSsMJ50kFJ2a7gJy4cbxoX83bNq
	UoBQV78j6nIFV/SRgbaF9vQciNBzWu1GNACMGaqVMVjTBki93xw/hvMv8JDIhAdA
	YaVda96BBtxrTDoDUtFBtYlb5n361TqIDHXHkCqE5Dc=
	EOF

    $ openssl pkeyutl -pubin -inkey /tmp/pkey.pem \
	-encrypt -pkeyopt rsa_padding_mode:none \
	-in /tmp/sig.dat -hexdump

    0000 - 52 90 e5 01 80 fa 77 53-b3 19 97 16 33 70 1e 29   R.....wS....3p.)
    0010 - 7e 7b cf 5c a4 51 b2 eb-7c fa 88 dc ce 92 b2 ac   ~{.\.Q..|.......
    0020 - 4f 86 d4 f1 32 83 55 0a-0b c0 49 92 a3 4a 54 47   O...2.U...I..JTG
    0030 - dc 6b 5d bd 2c 1e 5d 85-cf f4 4f c8 3c c5 3f bd   .k].,.]...O.<.?.
    0040 - 9d 56 29 a2 b5 dc 94 13-50 c3 28 23 0c a0 64 0b   .V).....P.(#..d.
    0050 - 0e 99 96 4a 0f b4 36 1a-3a d6 ff 6f 50 00 1a 38   ...J..6.:..oP..8
    0060 - 09 34 75 a6 d5 29 da 80-7c c1 bd 77 c4 a3 01 32   .4u..)..|..w...2
    0070 - d1 16 b4 8f 6c 3d fd a4-25 8d 53 2b 64 9c d8 ed   ....l=..%.S+d...

We see that the RSA public key operation does not produce a valid PKCS#1
padded block, so most likely an outdated key is published in DNS, or the
wrong "selector" ("s=" value, currently "mail") was added to the DKIM
signature header (if the correct key is published under some other
selector).

-- 
    Viktor.

From simon.peytonjones at gmail.com  Tue Jan 24 15:47:16 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 24 Jan 2023 15:47:16 +0000
Subject: Searching tickets
Message-ID: <CAJKmMz8TC7jiX2u+pE8jmVEpOX2ZLTa=0wszgkt5QQBT2GfQgg@mail.gmail.com>

I keep finding that 'search' in Gitlab misses things.

Example
https://gitlab.haskell.org/ghc/ghc/-/issues/22715 mentions "Haskeline"
(just look on that page)

Yet when I go to
https://gitlab.haskell.org/ghc/ghc/-/issues/
and search for "Haskeline", this ticket isn't reported.

What am I doing wrong?

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

From ben at smart-cactus.org  Tue Jan 24 18:21:43 2023
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 24 Jan 2023 13:21:43 -0500
Subject: Searching tickets
In-Reply-To: <CAJKmMz8TC7jiX2u+pE8jmVEpOX2ZLTa=0wszgkt5QQBT2GfQgg@mail.gmail.com>
References: <CAJKmMz8TC7jiX2u+pE8jmVEpOX2ZLTa=0wszgkt5QQBT2GfQgg@mail.gmail.com>
Message-ID: <87357zssiu.fsf@smart-cactus.org>

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

> I keep finding that 'search' in Gitlab misses things.
>
> Example
> https://gitlab.haskell.org/ghc/ghc/-/issues/22715 mentions "Haskeline"
> (just look on that page)
>
> Yet when I go to
> https://gitlab.haskell.org/ghc/ghc/-/issues/
> and search for "Haskeline", this ticket isn't reported.
>
> What am I doing wrong?
>
I belive that the search bar at the top of
https://gitlab.haskell.org/ghc/ghc/-/issues/ only searches the issues'
title and description. However, in this particular ticket Haskeline is
only mentioned in a comment.

It is possible to search in comments via
https://gitlab.haskell.org/search?group_id=2&project_id=1&scope=notes.
Sadly, searching for "Haskeline" here turns up over 300 results and none
of which are the ticket you are looking for; I'm sure that the ticket is
in the returned results somewhere, but I don't think this would be an
efficient way to find it (although being able to sort the result set by
date would make this much easier).

For this reason I routinely edit issue labels and descriptions to ensure
that they mention useful keywords. However, even then locating tickets
can be challenging.

Cheers,

- Ben
-------------- 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/20230124/8e5192be/attachment.sig>

From terrorjack at type.dance  Tue Jan 24 18:25:07 2023
From: terrorjack at type.dance (Cheng Shao)
Date: Tue, 24 Jan 2023 19:25:07 +0100
Subject: Searching tickets
In-Reply-To: <87357zssiu.fsf@smart-cactus.org>
References: <CAJKmMz8TC7jiX2u+pE8jmVEpOX2ZLTa=0wszgkt5QQBT2GfQgg@mail.gmail.com>
 <87357zssiu.fsf@smart-cactus.org>
Message-ID: <CAGegzND+SRyRkrcsmosH_0QgsOJ+8ik8UTsTwysFKBn8ARTpfw@mail.gmail.com>

I tend to use google with the extra keyword site:
gitlab.haskell.org/ghc/ghc/-/issues, as it often has better search results
than gitlab itself. It doesn't work too well for very recent tickets though
(e.g. haskeline one as you mentioned), but otherwise it works for me.

Cheers,
Cheng

On Tue, Jan 24, 2023 at 7:22 PM Ben Gamari <ben at smart-cactus.org> wrote:

> Simon Peyton Jones <simon.peytonjones at gmail.com> writes:
>
> > I keep finding that 'search' in Gitlab misses things.
> >
> > Example
> > https://gitlab.haskell.org/ghc/ghc/-/issues/22715 mentions "Haskeline"
> > (just look on that page)
> >
> > Yet when I go to
> > https://gitlab.haskell.org/ghc/ghc/-/issues/
> > and search for "Haskeline", this ticket isn't reported.
> >
> > What am I doing wrong?
> >
> I belive that the search bar at the top of
> https://gitlab.haskell.org/ghc/ghc/-/issues/ only searches the issues'
> title and description. However, in this particular ticket Haskeline is
> only mentioned in a comment.
>
> It is possible to search in comments via
> https://gitlab.haskell.org/search?group_id=2&project_id=1&scope=notes.
> Sadly, searching for "Haskeline" here turns up over 300 results and none
> of which are the ticket you are looking for; I'm sure that the ticket is
> in the returned results somewhere, but I don't think this would be an
> efficient way to find it (although being able to sort the result set by
> date would make this much easier).
>
> For this reason I routinely edit issue labels and descriptions to ensure
> that they mention useful keywords. However, even then locating tickets
> can be challenging.
>
> 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/20230124/e534cc81/attachment.html>

From simon.peytonjones at gmail.com  Tue Jan 24 19:37:28 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 24 Jan 2023 19:37:28 +0000
Subject: Searching tickets
In-Reply-To: <87357zssiu.fsf@smart-cactus.org>
References: <CAJKmMz8TC7jiX2u+pE8jmVEpOX2ZLTa=0wszgkt5QQBT2GfQgg@mail.gmail.com>
 <87357zssiu.fsf@smart-cactus.org>
Message-ID: <CAJKmMz_5HiUT0Ehsf0zMZaUUdPAUhsa4c=7tmA4xggE7fH9Y3A@mail.gmail.com>

>
> I belive that the search bar at the top of
> https://gitlab.haskell.org/ghc/ghc/-/issues/ only searches the issues'
> title and description.
>

That is ... disappointing to say the least.

It is possible to search in comments via
> https://gitlab.haskell.org/search?group_id=2&project_id=1&scope=notes.
>

Alas that interface has no way to sort by date or anything else -- as you
say, not very useful.

Sadly, searching for "Haskeline" here turns up over 300 results and none
> of which are the ticket you are looking for
>

very very sadly

These days, search is basically a solved problem.  I wonder if Gitlab have
any interest in picking up a solution and deploying it?  It seems deeply
sad that Gitlab should be so deficient here.  When you have 20,000 tickets,
search isn't optional  any more .. it's a key tool.

I tend to use google with the extra keyword site:
> gitlab.haskell.org/ghc/ghc/-/issues, as it often has better search
> results than gitlab itself. It doesn't work too well for very recent
> tickets though
>

Yes: site:gitlab.haskell.org/ghc/ghc/-/issues haskeline
-fspecialize-aggressively doesn't find it.  Not working well for recent
tickets (this one is 2 weeks old) is a huge drawback.

Boo.  Thanks for responses though

Simon

On Tue, 24 Jan 2023 at 18:21, Ben Gamari <ben at smart-cactus.org> wrote:

> Simon Peyton Jones <simon.peytonjones at gmail.com> writes:
>
> > I keep finding that 'search' in Gitlab misses things.
> >
> > Example
> > https://gitlab.haskell.org/ghc/ghc/-/issues/22715 mentions "Haskeline"
> > (just look on that page)
> >
> > Yet when I go to
> > https://gitlab.haskell.org/ghc/ghc/-/issues/
> > and search for "Haskeline", this ticket isn't reported.
> >
> > What am I doing wrong?
> >
> I belive that the search bar at the top of
> https://gitlab.haskell.org/ghc/ghc/-/issues/ only searches the issues'
> title and description. However, in this particular ticket Haskeline is
> only mentioned in a comment.
>
> It is possible to search in comments via
> https://gitlab.haskell.org/search?group_id=2&project_id=1&scope=notes.
> Sadly, searching for "Haskeline" here turns up over 300 results and none
> of which are the ticket you are looking for; I'm sure that the ticket is
> in the returned results somewhere, but I don't think this would be an
> efficient way to find it (although being able to sort the result set by
> date would make this much easier).
>
> For this reason I routinely edit issue labels and descriptions to ensure
> that they mention useful keywords. However, even then locating tickets
> can be challenging.
>
> Cheers,
>
> - Ben
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230124/d5d16624/attachment.html>

From ben at smart-cactus.org  Wed Jan 25 01:30:19 2023
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 24 Jan 2023 20:30:19 -0500
Subject: Searching tickets
In-Reply-To: <CAJKmMz_5HiUT0Ehsf0zMZaUUdPAUhsa4c=7tmA4xggE7fH9Y3A@mail.gmail.com>
References: <CAJKmMz8TC7jiX2u+pE8jmVEpOX2ZLTa=0wszgkt5QQBT2GfQgg@mail.gmail.com>
 <87357zssiu.fsf@smart-cactus.org>
 <CAJKmMz_5HiUT0Ehsf0zMZaUUdPAUhsa4c=7tmA4xggE7fH9Y3A@mail.gmail.com>
Message-ID: <87y1prqu43.fsf@smart-cactus.org>

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

>>
>> I belive that the search bar at the top of
>> https://gitlab.haskell.org/ghc/ghc/-/issues/ only searches the issues'
>> title and description.
>>
>
> That is ... disappointing to say the least.
>
>> It is possible to search in comments via
>> https://gitlab.haskell.org/search?group_id=2&project_id=1&scope=notes.
>>
>
> Alas that interface has no way to sort by date or anything else -- as you
> say, not very useful.
>
Agreed, this is a pretty serious deficiency which I have run into quite
a bit. It's also quite perplexing as (at least on paper) sorting the
result set should be straightforward.

>> Sadly, searching for "Haskeline" here turns up over 300 results and none
>> of which are the ticket you are looking for
>>
>
> very very sadly
>
> These days, search is basically a solved problem.

As someone married to a professor of information retrieval, I can attest that
there remains no shortage of open questions. Broadly speaking, web
search today works in no small part by learning from users' responses to
rankings (e.g. so-called "click data"). This works remarkably well if
you have plenty of user data (e.g. Google). However, it is quite hard to
match the quality of click-driven rankings on small-scale,
domain-specific corpora where click data is generally not available in
sufficient quantity.

Regardless, GitLab is very much lacking in its search functionality, in
many ways falling short of even Trac. This is something that I wish they
would focus on; one would think there would be no shortage of
incentive given that the GitLab repository has over 300k tickets.

>> I tend to use google with the extra keyword site:
>> gitlab.haskell.org/ghc/ghc/-/issues, as it often has better search
>> results than gitlab itself. It doesn't work too well for very recent
>> tickets though
>>
>
> Yes: site:gitlab.haskell.org/ghc/ghc/-/issues haskeline
> -fspecialize-aggressively doesn't find it.  Not working well for recent
> tickets (this one is 2 weeks old) is a huge drawback.
>
> Boo.  Thanks for responses though
>
Yes, I wish I had a more helpful response.

Cheers,

- Ben
-------------- 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/20230124/51ae5221/attachment.sig>

From djsamperi at gmail.com  Thu Jan 26 21:07:27 2023
From: djsamperi at gmail.com (Dominick Samperi)
Date: Thu, 26 Jan 2023 16:07:27 -0500
Subject: FFI changes?
Message-ID: <CADUbQ5j+Gxqqna9vWLzh8dhLdmRr8tLejMpDZwu4N_aZBjELVQ@mail.gmail.com>

Hello,

I have been working with a program that uses FFI to communicate with R for
several
years, but today there is a segmentation fault while importing functions or
data from R.
Before giving up on this project, I'm posting a few detail here, in case
anybody has
ideas...perhaps something changed with FFI?

I tried going back to the version of R and ghc where it worked using stack,
but no luck.
The Haskell code is a modification of the code in the package hR (by Dylan
Simon),
and here is a function that fails that worked before. It fails with a seg
fault
on the call to r_install. (s = "parse" when it fails)...

foreign import ccall safe "Rf_install" r_Install :: CString -> IO R_EXP
rInstall :: String -> IO REXP
rInstall s = withCString s r_Install >>= extREXP

The types are defined as follows...

extREXP :: R_EXP -> IO REXP
extREXP = newForeignPtr_

data REXPREC

type R_EXP = Ptr REXPREC

type REXP = ForeignPtr REXPREC

newtype SEXP a = SEXP { unSEXP :: REXP } deriving (Eq, Show)

Please let me know if you see anything obviously wrong and in need
of improvement, perhaps because of changes to the FFI.

Thanks,
Dominick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230126/8c238cb7/attachment.html>

From ben at smart-cactus.org  Thu Jan 26 22:00:02 2023
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 26 Jan 2023 17:00:02 -0500
Subject: FFI changes?
In-Reply-To: <CADUbQ5j+Gxqqna9vWLzh8dhLdmRr8tLejMpDZwu4N_aZBjELVQ@mail.gmail.com>
References: <CADUbQ5j+Gxqqna9vWLzh8dhLdmRr8tLejMpDZwu4N_aZBjELVQ@mail.gmail.com>
Message-ID: <87ilgtq7pg.fsf@smart-cactus.org>

Dominick Samperi <djsamperi at gmail.com> writes:

> Hello,
>
> I have been working with a program that uses FFI to communicate with R
> for several years, but today there is a segmentation fault while
> importing functions or data from R. Before giving up on this project,
> I'm posting a few detail here, in case anybody has ideas...perhaps
> something changed with FFI?
>
Hi Dominick,

As far as I know nothing should have changed that would break
previously-correct FFI programs.

More information would be helpful: Which GHC version are you using?
Which platform are you running on? Can you provide a reproducer?
If so, please open a ticket [1].

Cheers,

- Ben


[1] https://gitlab.haskell.org/ghc/ghc/-/issues/new
-------------- 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/20230126/d5318647/attachment.sig>

From facundo.dominguez at tweag.io  Fri Jan 27 20:22:39 2023
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Fri, 27 Jan 2023 17:22:39 -0300
Subject: Extracting comments from the source code
Message-ID: <CADvOm+rJQRYs=3Py-m4a3RPZQRHaqOPJvZ+zFMGNYHfE=7kR4A@mail.gmail.com>

Dear GHC devs,

I'm trying to port Liquid Haskell to ghc 9.2.5. And having much difficulty
using the GHC API for a specific task, so I come here to ask about it.

As you may know already, Liquid Haskell needs to read special comments from
Haskell source code which have the form {-@ ... @-}.

For example

> module Demo.Lib where
>
> {-@ type Pos = {v:Int | 0 < v} @-}
>
> {-@ incr :: Pos -> Pos @-}
> incr :: Int -> Int
> incr x = h x
>   where
>      {-@ h :: Pos -> Pos @-}
>      h x = x - 1

Since Liquid Haskell runs as a GHC plugin, it has access to the GHC API. It
used to be the case that one could find all of the comments together with
their source spans in a field

pm_annotations :: ParsedModule -> ApiAnns -- [1]

However this field has been removed in ghc-9.2, and now the comments are
all spread through the AST after parsing.

I managed to collect them all again with a generic traversal:

> go :: forall a. Data a => a -> [LEpaComment]
> go = gmapQr (++) [] go `extQ` (id @[LEpaComment])

but I'd expect this to be rather slow. So I'd like to ask here, is there a
better way to collect all of the comments?

The other obvious way would be to write the traversal manually, but it
would be some code to write, and it would likely need attention when
porting to newer GHCs onwards.

Thanks!
Facundo

[1]:
https://hackage.haskell.org/package/ghc-9.0.2/docs/GHC.html#t:ParsedModule
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230127/64cecb42/attachment.html>

From santiago.weight at gmail.com  Fri Jan 27 22:47:47 2023
From: santiago.weight at gmail.com (Santiago Weight)
Date: Fri, 27 Jan 2023 14:47:47 -0800
Subject: Extracting comments from the source code
In-Reply-To: <CADvOm+rJQRYs=3Py-m4a3RPZQRHaqOPJvZ+zFMGNYHfE=7kR4A@mail.gmail.com>
References: <CADvOm+rJQRYs=3Py-m4a3RPZQRHaqOPJvZ+zFMGNYHfE=7kR4A@mail.gmail.com>
Message-ID: <CABXRwaJwUY9LiKmzyEKW+NT6-e-mqZMJnORz4i0y0e1env3+yA@mail.gmail.com>

I’m not sure why you expect it to be so slow? When developing refactoring
tasks for HLS I have never noticed big latencies, even when performing
multiple generic traversals over a full module.

You might have some success by specializing or inking the definition, so
that GHC can optimize the traversal generated.

Best

Santi

On Friday, 27 January 2023, Facundo Domínguez <facundo.dominguez at tweag.io>
wrote:

> Dear GHC devs,
>
> I'm trying to port Liquid Haskell to ghc 9.2.5. And having much difficulty
> using the GHC API for a specific task, so I come here to ask about it.
>
> As you may know already, Liquid Haskell needs to read special comments
> from Haskell source code which have the form {-@ ... @-}.
>
> For example
>
> > module Demo.Lib where
> >
> > {-@ type Pos = {v:Int | 0 < v} @-}
> >
> > {-@ incr :: Pos -> Pos @-}
> > incr :: Int -> Int
> > incr x = h x
> >   where
> >      {-@ h :: Pos -> Pos @-}
> >      h x = x - 1
>
> Since Liquid Haskell runs as a GHC plugin, it has access to the GHC API.
> It used to be the case that one could find all of the comments together
> with their source spans in a field
>
> pm_annotations :: ParsedModule -> ApiAnns -- [1]
>
> However this field has been removed in ghc-9.2, and now the comments are
> all spread through the AST after parsing.
>
> I managed to collect them all again with a generic traversal:
>
> > go :: forall a. Data a => a -> [LEpaComment]
> > go = gmapQr (++) [] go `extQ` (id @[LEpaComment])
>
> but I'd expect this to be rather slow. So I'd like to ask here, is there a
> better way to collect all of the comments?
>
> The other obvious way would be to write the traversal manually, but it
> would be some code to write, and it would likely need attention when
> porting to newer GHCs onwards.
>
> Thanks!
> Facundo
>
> [1]: https://hackage.haskell.org/package/ghc-9.0.2/docs/GHC.
> html#t:ParsedModule
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230127/212dbeb3/attachment.html>

From ben at smart-cactus.org  Sat Jan 28 01:15:02 2023
From: ben at smart-cactus.org (Ben Gamari)
Date: Fri, 27 Jan 2023 20:15:02 -0500
Subject: Extracting comments from the source code
In-Reply-To: <CADvOm+rJQRYs=3Py-m4a3RPZQRHaqOPJvZ+zFMGNYHfE=7kR4A@mail.gmail.com>
References: <CADvOm+rJQRYs=3Py-m4a3RPZQRHaqOPJvZ+zFMGNYHfE=7kR4A@mail.gmail.com>
Message-ID: <87edrfqx3d.fsf@smart-cactus.org>

Facundo Domínguez <facundo.dominguez at tweag.io> writes:

> Dear GHC devs,
>
> I'm trying to port Liquid Haskell to ghc 9.2.5. And having much difficulty
> using the GHC API for a specific task, so I come here to ask about it.
>
> As you may know already, Liquid Haskell needs to read special comments from
> Haskell source code which have the form {-@ ... @-}.
>
I agree with Santiago here: Data doesn't produce fantiastic code but I
would guess that the cost of the traversal to collect your signatures
will be negligible relative to the cost of the work you will later do
later in your pipeline. I would leave optimising this until you know
that it is a significant problem.

Cheers,

 - Ben

-------------- 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/20230127/31f89541/attachment.sig>

From simon.peytonjones at gmail.com  Sun Jan 29 17:50:11 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Sun, 29 Jan 2023 17:50:11 +0000
Subject: Slow downloads
Message-ID: <CAJKmMz-Hk70YpVk0jwp10gryjKXu1E9CDfsJ5JRcn-EQF5fn_g@mail.gmail.com>

I'm getting very low transfer rates on Git operations.  Like 16 kb/s.
Things that usually take a second or two are still going 10 minutes later.
See below

My internet connection appears to be solid at 100Mb/s upload and download.

Any ideas?

Simon


[image: image.png]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230129/eeefde3f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 90114 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230129/eeefde3f/attachment-0001.png>

From facundo.dominguez at tweag.io  Mon Jan 30 12:37:57 2023
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Facundo_Dom=C3=ADnguez?=)
Date: Mon, 30 Jan 2023 09:37:57 -0300
Subject: Extracting comments from the source code
In-Reply-To: <87edrfqx3d.fsf@smart-cactus.org>
References: <CADvOm+rJQRYs=3Py-m4a3RPZQRHaqOPJvZ+zFMGNYHfE=7kR4A@mail.gmail.com>
 <87edrfqx3d.fsf@smart-cactus.org>
Message-ID: <CADvOm+rPz_6+nvSbBrNfaYDRR+goyqQgTLNbuvRiL-Z7QaLcxQ@mail.gmail.com>

Thanks folks. I was concerned I might be missing some dedicated way to
achieve the same with the GHC API. I agree there's a fair chance this won't
be noticeable in benchmarks.

Cheers!
Facundo


On Fri, Jan 27, 2023 at 10:15 PM Ben Gamari <ben at smart-cactus.org> wrote:

> Facundo Domínguez <facundo.dominguez at tweag.io> writes:
>
> > Dear GHC devs,
> >
> > I'm trying to port Liquid Haskell to ghc 9.2.5. And having much
> difficulty
> > using the GHC API for a specific task, so I come here to ask about it.
> >
> > As you may know already, Liquid Haskell needs to read special comments
> from
> > Haskell source code which have the form {-@ ... @-}.
> >
> I agree with Santiago here: Data doesn't produce fantiastic code but I
> would guess that the cost of the traversal to collect your signatures
> will be negligible relative to the cost of the work you will later do
> later in your pipeline. I would leave optimising this until you know
> that it is a significant problem.
>
> Cheers,
>
>  - Ben
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230130/a8bafd1d/attachment.html>

From ben at well-typed.com  Mon Jan 30 18:21:32 2023
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 30 Jan 2023 13:21:32 -0500
Subject: [ANNOUNCE] GHC 9.6.1-alpha2 is now available
Message-ID: <87a61zriif.fsf@smart-cactus.org>


The GHC team is very pleased to announce the availability of GHC
9.6.1-alpha2. As usual, binaries and source distributions are available
at downloads.haskell.org:

  https://downloads.haskell.org/ghc/9.6.1-alpha2/

Beginning with GHC 9.6.1, GHC can be built as a cross-compiler to
WebAssembly and JavaScript. This is an important step towards robust
support for compiling Haskell to the Web, but there are a few caveats to
be aware of in the 9.6 series:

 - Both the Javascript and WebAssembly backends are still at an early
   stage of development and are present in this release as a technology
   preview

 - Using GHC as a cross-compiler is not as easy as we would like it to
   be; in particular, there are challenges related to Template Haskell.

 - GHC is not yet run-time retargetable; a given GHC binary targets
   exactly one platform, and both WebAssembly and JavaScript are
   considered platforms for this purpose. Cross-compilers must be built
   from source by their users

We hope to lift all of these limitations in future releases.

Additionally, 9.6.1 will include:

 - Significant latency improvements in the non-moving garbage collector

 - Efficient runtime support for delimited continuations

 - Improvements in compiler error messages

 - Numerous improvements in the compiler's memory usage

See the [release notes] for a comprehensive accounting of changes in
this release.

As always, one can find a [migration guide] to aid in transitioning from
older releases on the GHC Wiki. We have also recently started extending
our release process to cover a wider set of Linux distributions. In
particular, we now offer Rocky 8 and Ubuntu 20.04 binary distributions
which cover RedHat-derivative and distributions using older `glibc`
releases (namely 2.27), respectively.

Please do give this release a try and open a [ticket] if you see
anything amiss.

Cheers,

- Ben


[ticket]: https://gitlab.haskell.org/ghc/ghc/issues/
[migration-guide]: https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.6
[release notes]: https://downloads.haskell.org/ghc/9.6.1-alpha2/docs/users_guide/9.6.1-notes.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230130/699cd985/attachment.sig>

From carter.schonwald at gmail.com  Mon Jan 30 22:05:17 2023
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Mon, 30 Jan 2023 17:05:17 -0500
Subject: FFI changes?
In-Reply-To: <87ilgtq7pg.fsf@smart-cactus.org>
References: <CADUbQ5j+Gxqqna9vWLzh8dhLdmRr8tLejMpDZwu4N_aZBjELVQ@mail.gmail.com>
 <87ilgtq7pg.fsf@smart-cactus.org>
Message-ID: <CAHYVw0wW3=Dykshw0F4PPac2+KGnFYFw6XnNiveEB7MWT4-MLQ@mail.gmail.com>

Hey domninick: what platform are you using?

Is this on an arm flavor mac?

On Thu, Jan 26, 2023 at 5:00 PM Ben Gamari <ben at smart-cactus.org> wrote:

> Dominick Samperi <djsamperi at gmail.com> writes:
>
> > Hello,
> >
> > I have been working with a program that uses FFI to communicate with R
> > for several years, but today there is a segmentation fault while
> > importing functions or data from R. Before giving up on this project,
> > I'm posting a few detail here, in case anybody has ideas...perhaps
> > something changed with FFI?
> >
> Hi Dominick,
>
> As far as I know nothing should have changed that would break
> previously-correct FFI programs.
>
> More information would be helpful: Which GHC version are you using?
> Which platform are you running on? Can you provide a reproducer?
> If so, please open a ticket [1].
>
> Cheers,
>
> - Ben
>
>
> [1] https://gitlab.haskell.org/ghc/ghc/-/issues/new
> _______________________________________________
> 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/20230130/78ba7209/attachment.html>