From ben at well-typed.com  Sun May  1 23:17:01 2022
From: ben at well-typed.com (Ben Gamari)
Date: Sun, 01 May 2022 19:17:01 -0400
Subject: GHC 9.4.1-alpha1 now available
Message-ID: <87h768alnr.fsf@smart-cactus.org>


The GHC developers are happy to announce the availability of the first
alpha release of the GHC 9.4 series. Binary distributions, source
distributions, and documentation are available at downloads.haskell.org:

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

This major release will include:

 - A new profiling mode, `-fprof-late`, which adds automatic cost-center
   annotations to all top-level functions *after* Core optimisation has
   run. This incurs significantly less performance cost while still
   providing informative profiles.

 - A variety of plugin improvements including the introduction of a new
   plugin type, *defaulting plugins*, and the ability for typechecking
   plugins to rewrite type-families.

 - An improved constructed product result analysis, allowing unboxing of
   nested structures, and a new boxity analysis, leading to less reboxing.

 - Introduction of a tag-check elision optimisation, bringing
   significant performance improvements in strict programs.

 - Generalisation of a variety of primitive types to be levity
   polymorphic. Consequently, the `ArrayArray#` type can at long last be
   retired, replaced by standard `Array#`.

 - Introduction of the `\cases` syntax from [GHC proposal 0302]

 - A complete overhaul of GHC's Windows support. This includes a
   migration to a fully Clang-based C toolchain, a deep refactoring of
   the linker, and many fixes in WinIO.

 - Support for multiple home packages, significantly improving support
   in IDEs and other tools for multi-package projects.

 - A refactoring of GHC's error message infrastructure, allowing GHC to
   provide diagnostic information to downstream consumers as structured
   data, greatly easing IDE support.

 - Significant compile-time improvements to runtime and memory consumption.

 - ... and much more

We would like to thank Microsoft Azure, GitHub, IOHK, the Zw3rk
stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
contributors whose on-going financial and in-kind support has
facilitated GHC maintenance and release management over the years.
Finally, this release would not have been possible without the hundreds
of open-source contributors whose work comprise this release.

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

Happy testing,

- Ben


[GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst 
[ticket]: 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/20220501/aa59f390/attachment.sig>

From a.pelenitsyn at gmail.com  Mon May  2 01:31:01 2022
From: a.pelenitsyn at gmail.com (Artem Pelenitsyn)
Date: Sun, 1 May 2022 21:31:01 -0400
Subject: GHC 9.4.1-alpha1 now available
In-Reply-To: <87h768alnr.fsf@smart-cactus.org>
References: <87h768alnr.fsf@smart-cactus.org>
Message-ID: <CAPKAvQUQ9v_gmgSM6yHbxWG3kardK=Z0iK1hod7O_p2qxxM5Vg@mail.gmail.com>

Thanks a lot, devs!

A bug in the docs, it seems:

https://downloads.haskell.org/ghc/9.4.1-alpha1/docs/html/

references User Guide as

https://downloads.haskell.org/ghc/9.4.1-alpha1/docs/html/users_guide/index.html

but this url gives 404. Same with the GHC API link.

--
Best, Artem

On Sun, May 1, 2022, 7:18 PM Ben Gamari <ben at well-typed.com> wrote:

>
> The GHC developers are happy to announce the availability of the first
> alpha release of the GHC 9.4 series. Binary distributions, source
> distributions, and documentation are available at downloads.haskell.org:
>
>    https://downloads.haskell.org/ghc/9.4.1-alpha1
>
> This major release will include:
>
>  - A new profiling mode, `-fprof-late`, which adds automatic cost-center
>    annotations to all top-level functions *after* Core optimisation has
>    run. This incurs significantly less performance cost while still
>    providing informative profiles.
>
>  - A variety of plugin improvements including the introduction of a new
>    plugin type, *defaulting plugins*, and the ability for typechecking
>    plugins to rewrite type-families.
>
>  - An improved constructed product result analysis, allowing unboxing of
>    nested structures, and a new boxity analysis, leading to less reboxing.
>
>  - Introduction of a tag-check elision optimisation, bringing
>    significant performance improvements in strict programs.
>
>  - Generalisation of a variety of primitive types to be levity
>    polymorphic. Consequently, the `ArrayArray#` type can at long last be
>    retired, replaced by standard `Array#`.
>
>  - Introduction of the `\cases` syntax from [GHC proposal 0302]
>
>  - A complete overhaul of GHC's Windows support. This includes a
>    migration to a fully Clang-based C toolchain, a deep refactoring of
>    the linker, and many fixes in WinIO.
>
>  - Support for multiple home packages, significantly improving support
>    in IDEs and other tools for multi-package projects.
>
>  - A refactoring of GHC's error message infrastructure, allowing GHC to
>    provide diagnostic information to downstream consumers as structured
>    data, greatly easing IDE support.
>
>  - Significant compile-time improvements to runtime and memory consumption.
>
>  - ... and much more
>
> We would like to thank Microsoft Azure, GitHub, IOHK, the Zw3rk
> stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
> contributors whose on-going financial and in-kind support has
> facilitated GHC maintenance and release management over the years.
> Finally, this release would not have been possible without the hundreds
> of open-source contributors whose work comprise this release.
>
> As always, do give this release a try and open a [ticket] if you see
> anything amiss.
>
> Happy testing,
>
> - Ben
>
>
> [GHC proposal 0302]:
> https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst
> [ticket]: 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/20220501/abb12816/attachment.html>

From simon.peytonjones at gmail.com  Mon May  2 10:33:06 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 2 May 2022 11:33:06 +0100
Subject: Extending call_args when specialising DFuns
In-Reply-To: <alpine.DEB.2.22.394.2204301029540.3183073@galaxy>
References: <alpine.DEB.2.22.394.2204301029540.3183073@galaxy>
Message-ID: <CAJKmMz95DK8fEVqHWYtE5qUN3XQ-r9hpWMnEhKgKodd-9paA+A@mail.gmail.com>

Looking at the code in Specialise, there are only two differences in the
way that UnspecArg and UnspecType are treated differently:
* In specHeader, small differences
* In ppr_call_key_ty, when generating the name of the RULE

So we could collapse them into SpecArg, and fix the small differences some
other way.

But 'd have thought it was easier just to get the right SpecArg/SpecType
for the padding for DFuns.  That's not hard. Something like
```
        do { let all_call_args | is_dfun   = call_args ++ map
mk_extra_dfun_arg (dropList call_args rhs_bndrs)
                               | otherwise = call_args
                               -- See Note [Specialising DFuns]
                      mk_extra_dfun_arg bndr  | isTyVar bndrs = UnspecType
                                                               | otherwise
= UnspecArg
 ```
This is really a GHC bug already, albeit one that is hard to provoke.
Would you like to open a ticket and add the fix?

Simon

On Sat, 30 Apr 2022 at 10:27, ÉRDI Gergő <gergo at erdi.hu> wrote:

> Hi,
>
> In GHC.Core.Opt.Specialise.specCalls, when specialising a DFun call, GHC
> extends the call_args with dummy UnspecArg elements, to make it trivially
> fully saturated. There's a Note describing this behaviour:
>
> """
> Note [Specialising DFuns]
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> DFuns have a special sort of unfolding (DFunUnfolding), and these are
> hard to specialise a DFunUnfolding to give another DFunUnfolding
> unless the DFun is fully applied (#18120).  So, in the case of DFunIds
> we simply extend the CallKey with trailing UnspecArgs, so we'll
> generate a rule that completely saturates the DFun.
>
> There is an ASSERT that checks this, in the DFunUnfolding case of
> GHC.Core.Unfold.specUnfolding.
> """
>
> (note that the reference in the second paragraph is stale; it should point
> to GHC.Core.Unfold.Make.specUnfolding)
>
> So my question is, why UnspecArgs instead of UnspecTypes? Unless I'm
> missing something, a DFun can't have any term parameters, only type and
> dictionary ones. Changing the padding from UnspecArg to UnspecType doesn't
> break validate, which suggests that it is hard to even exercise this code
> path.
>
> I'm bringing this up because on the GHC fork that I'm working on, I have
> the specializer do more than vanilla GHC: on my fork, specialization of
> higher-kinded type variables is just as useful as specializing
> dictionaries. With that change, I can get GHC panics when padding DFun
> calls with UnspecArgs, but not when padding with UnspecTypes. Yes, this is
> a very weak argument for this change; what I'm looking for here is a
> discussion on what the padding should be, in vanilla GHC, from first
> principles.
>
> Thanks,
>         Gergo
> _______________________________________________
> 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/20220502/8733cd6c/attachment.html>

From gergo at erdi.hu  Mon May  2 10:39:27 2022
From: gergo at erdi.hu (=?ISO-8859-2?Q?=C9RDI_Gerg=F5?=)
Date: Mon, 2 May 2022 18:39:27 +0800 (+08)
Subject: Extending call_args when specialising DFuns
In-Reply-To: <CAJKmMz95DK8fEVqHWYtE5qUN3XQ-r9hpWMnEhKgKodd-9paA+A@mail.gmail.com>
References: <alpine.DEB.2.22.394.2204301029540.3183073@galaxy>
 <CAJKmMz95DK8fEVqHWYtE5qUN3XQ-r9hpWMnEhKgKodd-9paA+A@mail.gmail.com>
Message-ID: <alpine.DEB.2.22.394.2205021838340.3183073@galaxy>

On Mon, 2 May 2022, Simon Peyton Jones wrote:

> This is really a GHC bug already, albeit one that is hard to provoke.  Would you like
> to open a ticket and add the fix?

I'm happy to provide a patch (and also fix the comment referencing 
GHC.Core.Unfold.specUnfolding), but I don't think I'll be able to provide 
a test case for it, because, like you said, it's hard to provoke.

From george.colpitts at gmail.com  Mon May  2 10:59:00 2022
From: george.colpitts at gmail.com (George Colpitts)
Date: Mon, 2 May 2022 07:59:00 -0300
Subject: macos install issue: ghc-pkg-9.2.2 cannot be opened because the
 developer cannot be verified
In-Reply-To: <20220307.152740.1433207400109063719.kazu@iij.ad.jp>
References: <87r17ewuxe.fsf@smart-cactus.org>
 <CAB-d4A4yAiDzHLEkDA=AhNN-2=0YcKPR7Rk5fXxCOkrKMnxRQw@mail.gmail.com>
 <20220307.152740.1433207400109063719.kazu@iij.ad.jp>
Message-ID: <CAB-d4A4=L=gwbYc+=eN3UPaFzUScNuZhj2VhCAUGDavMGCfT0Q@mail.gmail.com>

Hi

Did this get fixed? Is it fixed in 9.4.1-alpha1?

Thanks
George

On Mon, Mar 7, 2022 at 2:27 AM Kazu Yamamoto <kazu at iij.ad.jp> wrote:

> Hi George,
>
> FYI:
>
> https://twitter.com/kazu_yamamoto/status/1500643489985761282
>
> --Kazu
>
> > Thanks Ben
> >
> > When I do an install on macos Monterey 12.2.1 (Intel) I get
> >
> > ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified
> >
> >
> > On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari <ben at well-typed.com> wrote:
> >
> >>
> >> The GHC developers are very happy to at announce the availability of GHC
> >>
> >> 9.2.2. Binary distributions, source distributions, and documentation are
> >>
> >> available at downloads.haskell.org:
> >>
> >>    https://downloads.haskell.org/ghc/9.2.2
> >>
> >> This release includes many bug-fixes and other improvements to 9.2.1
> >> including:
> >>
> >>  * A number of bug-fixes in the new AArch64 native code generator
> >>
> >>  * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is
> >> handled
> >>    correctly on platforms lacking support for unaligned memory accesses
> >>    (#21015, #20987).
> >>
> >>  * Improvements to the compatibility story in GHC's migration to the
> >>    XDG Base Directory Specification (#20684, #20669, #20660)
> >>
> >>  * Restored compatibility with Windows 7
> >>
> >>  * A new `-fcompact-unwind` flag, improving compatibility with C++
> >> libraries on
> >>    Apple Darwin (#11829)
> >>
> >>  * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime
> >> bounds
> >>    checking of array primops (#20769)
> >>
> >>  * Unboxing of unlifted types (#20663)
> >>
> >>  * Numerous improvements in compiler performance.
> >>
> >>  * Many, many others. See the [release notes] for a full list.
> >>
> >> As some of the fixed issues do affect correctness users are encouraged
> to
> >>
> >> upgrade promptly.
> >>
> >> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake
> >> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
> >> contributors whose on-going financial and in-kind support has
> >> facilitated GHC maintenance and release management over the years.
> >> Moreover, this release would not have been possible without the hundreds
> >>
> >> of open-source contributors whose work comprise this release.
> >>
> >> As always, do open a [ticket][] if you see anything amiss.
> >>
> >> Happy compiling,
> >>
> >> - Ben
> >>
> >>
> >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> >> [release notes]:
> >>
> https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.html
> >>
> >> _______________________________________________
> >> 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/20220502/386b895d/attachment.html>

From hecate at glitchbra.in  Tue May  3 14:56:11 2022
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Tue, 3 May 2022 16:56:11 +0200
Subject: Our ambitions for GHC 9.6
Message-ID: <1cad7c59-13cd-0ebd-1307-1dc7c5057afd@glitchbra.in>

Hi everyone,

With 9.4 just around the corner, I am gathering broad ambitions for 
user-facing improvements that we wish to ship for GHC 9.6.

At this moment, the new JavaScript and WebAssembly backends have been 
listed, but I'd be very interested to add more content.

This document is especially for public communication regarding our 
activities.
Since these are ambitions, it's not a hard deadline, nor does it imply 
dreadful consequences for the people who didn't manage to have their 
improvements shipped in time.

I'm really excited for 9.4 and all the good stuff we're going to have in 
the future of GHC!

Cheers,
Hécate.

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD


From hecate at glitchbra.in  Tue May  3 15:00:20 2022
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Tue, 3 May 2022 17:00:20 +0200
Subject: Our ambitions for GHC 9.6
In-Reply-To: <1cad7c59-13cd-0ebd-1307-1dc7c5057afd@glitchbra.in>
References: <1cad7c59-13cd-0ebd-1307-1dc7c5057afd@glitchbra.in>
Message-ID: <e2364747-0a80-eda4-7241-f399be072eaf@glitchbra.in>

Of course it wouldn't be funny if I didn't forget to add a link to the 
page that lists everything, so here it is: 
https://gitlab.haskell.org/ghc/ghc/-/wikis/status/ghc-9.6

Le 03/05/2022 à 16:56, Hécate a écrit :
> Hi everyone,
>
> With 9.4 just around the corner, I am gathering broad ambitions for 
> user-facing improvements that we wish to ship for GHC 9.6.
>
> At this moment, the new JavaScript and WebAssembly backends have been 
> listed, but I'd be very interested to add more content.
>
> This document is especially for public communication regarding our 
> activities.
> Since these are ambitions, it's not a hard deadline, nor does it imply 
> dreadful consequences for the people who didn't manage to have their 
> improvements shipped in time.
>
> I'm really excited for 9.4 and all the good stuff we're going to have 
> in the future of GHC!
>
> Cheers,
> Hécate.
>
-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD


From sylvain at haskus.fr  Wed May  4 10:42:40 2022
From: sylvain at haskus.fr (Sylvain Henry)
Date: Wed, 4 May 2022 12:42:40 +0200
Subject: "Modularizing GHC" paper
Message-ID: <5c78e6b1-3d6f-4f2e-9cd4-1f7a13ece095@haskus.fr>

Hi GHC devs,

With John Ericson and Jeffrey Young we wrote a paper about the 
modularization of GHC. It gives a global picture for the refactorings we 
have been performing (c.f. e.g. #17957) and some potential future ones.

Announce blog post: 
https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-paper.html
Paper: https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf
Discussion on Reddit: 
https://www.reddit.com/r/haskell/comments/uhdu4l/modularizing_ghc_paper/

We welcome any feedback, here or on reddit.

Cheers,
Sylvain


From ecrockett0 at gmail.com  Wed May  4 14:33:57 2022
From: ecrockett0 at gmail.com (Eric Crockett)
Date: Wed, 4 May 2022 07:33:57 -0700
Subject: "Modularizing GHC" paper
In-Reply-To: <5c78e6b1-3d6f-4f2e-9cd4-1f7a13ece095@haskus.fr>
References: <5c78e6b1-3d6f-4f2e-9cd4-1f7a13ece095@haskus.fr>
Message-ID: <CAApao_nXfX=DOHD2pCNbOAk0fsR5nOCy-oy5oObxBEMmoLCAQQ@mail.gmail.com>

I am very happy to see this paper. It was an enjoyable read, and accessible
to non-experts such as myself. I appreciated the effort spent on research,
and was even happier to see that you have started implementing these
suggestions and have a plan going forward. Technical debt is a hard thing
to overcome, especially in the face of a rapidly evolving language.

This paper resonates with me as both a user and one-time (as in a single
time🙂) developer of GHC. As a user, I’ve run into issues related to the
debts you discuss. I also tried to fix a GHC bug, and remember being
overwhelmed by DynFlags.

I applaud your efforts. Thank you for this service to the Haskell community.

Eric Crockett

On Wed, May 4, 2022 at 3:51 AM Sylvain Henry <sylvain at haskus.fr> wrote:

> Hi GHC devs,
>
> With John Ericson and Jeffrey Young we wrote a paper about the
> modularization of GHC. It gives a global picture for the refactorings we
> have been performing (c.f. e.g. #17957) and some potential future ones.
>
> Announce blog post:
> https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-paper.html
> Paper: https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf
> Discussion on Reddit:
> https://www.reddit.com/r/haskell/comments/uhdu4l/modularizing_ghc_paper/
>
> We welcome any feedback, here or on reddit.
>
> Cheers,
> Sylvain
>
> _______________________________________________
> 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/20220504/bd1692e0/attachment.html>

From benjamin.redelings at gmail.com  Wed May  4 18:12:39 2022
From: benjamin.redelings at gmail.com (Benjamin Redelings)
Date: Wed, 4 May 2022 14:12:39 -0400
Subject: "Modularizing GHC" paper
In-Reply-To: <5c78e6b1-3d6f-4f2e-9cd4-1f7a13ece095@haskus.fr>
References: <5c78e6b1-3d6f-4f2e-9cd4-1f7a13ece095@haskus.fr>
Message-ID: <7786e686-5c52-59ce-ae5f-6337765e09b4@gmail.com>

This is a great paper!  The explanation of how DynFlags has wormed its 
way into more and more functions is quite interesting. I wonder if, in 
general, some developers lean away from refactoring and more towards 
"getting things done", whereas other developers lean into code 
refactoring and decreasing technical debt.

A few comments:

On page 2, the first sentence about design patterns derived from OO 
literature seems a little awkward.

On page 7, the phrase "code smell" could maybe be replaced.  In my 
experience the phrase "code smell" is often used to avoid explaining why 
an anti-pattern is actually problematic.  It is also a neologism, and is 
only used once in the paper.

On page 30, the explanation of DDD talks about "business rules", 
"business knowledge", "business software", "business situation", 
"business code", etc. was unfamiliar to me.  It seems to use the word 
"business" to talk about the specific goal of the code.  This seems to 
be using language specific to corporations to talk about the .  The 
usage of "business" in this way is limited to pages 30, 31, and 34.

On page 34, I didn't find the relationship between Figure 1 and Figure 2 
entirely clear.  It sounds like Figure 1 is the way things are, and 
Figure 2 is the way that things should be?  Maybe that could be made 
clearer in the figure captions.  Also, it seems like the main difference 
in the figures is that Figure 2 replaces mutual dependency between the 
boxes on the right (i.e. "Type checker, renamer") and the output 
languages ("Haskell", "Core") with mutual dependencies between the 
output languages... is that good, and if so, why?

On page 37, its unclear to me what A and B are.

Other than that, I found the paper really easy to read!  I personally 
found the purpose of disentangling different parts of the compiler 
intuitively clear -- modularity and separation of concerns seem like an 
obvious goal.  The quoted text on the topic of "supple design" seems 
very motivating!

-BenRI

On 5/4/22 6:42 AM, Sylvain Henry wrote:
> Hi GHC devs,
>
> With John Ericson and Jeffrey Young we wrote a paper about the 
> modularization of GHC. It gives a global picture for the refactorings 
> we have been performing (c.f. e.g. #17957) and some potential future 
> ones.
>
> Announce blog post: 
> https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-paper.html
> Paper: https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf
> Discussion on Reddit: 
> https://www.reddit.com/r/haskell/comments/uhdu4l/modularizing_ghc_paper/
>
> We welcome any feedback, here or on reddit.
>
> Cheers,
> Sylvain
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From hecate at glitchbra.in  Wed May  4 21:36:42 2022
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Wed, 4 May 2022 23:36:42 +0200
Subject: "Modularizing GHC" paper
In-Reply-To: <7786e686-5c52-59ce-ae5f-6337765e09b4@gmail.com>
References: <5c78e6b1-3d6f-4f2e-9cd4-1f7a13ece095@haskus.fr>
 <7786e686-5c52-59ce-ae5f-6337765e09b4@gmail.com>
Message-ID: <713fa6ee-0758-6625-7eb8-cb62004146c9@glitchbra.in>

re: page 30, the term "business" should really be understood as the core 
thing that the code has to achieve. It's not the supporting 
infrastructure but rather the reason of being of the code. No actual 
relation with a company.
Even non-corporate codebases have business logic and supporting / 
infrastructural code.

And I'd like to join you in praising the paper, it is really a nice 
piece of literature that makes me want to support GHC development even more!

Le 04/05/2022 à 20:12, Benjamin Redelings a écrit :
> This is a great paper!  The explanation of how DynFlags has wormed its 
> way into more and more functions is quite interesting. I wonder if, in 
> general, some developers lean away from refactoring and more towards 
> "getting things done", whereas other developers lean into code 
> refactoring and decreasing technical debt.
>
> A few comments:
>
> On page 2, the first sentence about design patterns derived from OO 
> literature seems a little awkward.
>
> On page 7, the phrase "code smell" could maybe be replaced.  In my 
> experience the phrase "code smell" is often used to avoid explaining 
> why an anti-pattern is actually problematic.  It is also a neologism, 
> and is only used once in the paper.
>
> On page 30, the explanation of DDD talks about "business rules", 
> "business knowledge", "business software", "business situation", 
> "business code", etc. was unfamiliar to me.  It seems to use the word 
> "business" to talk about the specific goal of the code.  This seems to 
> be using language specific to corporations to talk about the .  The 
> usage of "business" in this way is limited to pages 30, 31, and 34.
>
> On page 34, I didn't find the relationship between Figure 1 and Figure 
> 2 entirely clear.  It sounds like Figure 1 is the way things are, and 
> Figure 2 is the way that things should be?  Maybe that could be made 
> clearer in the figure captions.  Also, it seems like the main 
> difference in the figures is that Figure 2 replaces mutual dependency 
> between the boxes on the right (i.e. "Type checker, renamer") and the 
> output languages ("Haskell", "Core") with mutual dependencies between 
> the output languages... is that good, and if so, why?
>
> On page 37, its unclear to me what A and B are.
>
> Other than that, I found the paper really easy to read!  I personally 
> found the purpose of disentangling different parts of the compiler 
> intuitively clear -- modularity and separation of concerns seem like 
> an obvious goal.  The quoted text on the topic of "supple design" 
> seems very motivating!
>
> -BenRI
>
> On 5/4/22 6:42 AM, Sylvain Henry wrote:
>> Hi GHC devs,
>>
>> With John Ericson and Jeffrey Young we wrote a paper about the 
>> modularization of GHC. It gives a global picture for the refactorings 
>> we have been performing (c.f. e.g. #17957) and some potential future 
>> ones.
>>
>> Announce blog post: 
>> https://hsyl20.fr/home/posts/2022-05-03-modularizing-ghc-paper.html
>> Paper: https://hsyl20.fr/home/files/papers/2022-ghc-modularity.pdf
>> Discussion on Reddit: 
>> https://www.reddit.com/r/haskell/comments/uhdu4l/modularizing_ghc_paper/
>>
>> We welcome any feedback, here or on reddit.
>>
>> Cheers,
>> Sylvain
>>
>> _______________________________________________
>> 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

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD


From shayne.fletcher.50 at gmail.com  Wed May  4 21:55:50 2022
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Wed, 4 May 2022 17:55:50 -0400
Subject: stack exec -- pacman broken
Message-ID: <CAMsAzy-pGFNiG78JZyz-8WUP_SGMafsSiDtC5ZVo7uQVypsJXw@mail.gmail.com>

this isn't exactly a GHC issue but perhaps someone knows how to get it
resolved? (suspecting commercial/stack i've raised [this issue](
https://github.com/commercialhaskell/stack/issues/5732) there).

tl;dr `stack exec -- pacman -S ...` like commands required for building GHC
on windows are broken and have been for sometime

ghc-lib CI runs this command on windows,
```
stack --resolver lts-18.23   exec -- pacman -S autoconf automake-wrapper
make patch python tar mintty --noconfirm
```
this normally works ok but as of today,
```
warning: database file for 'clang32' does not exist (use '-Sy' to download)
warning: mintty-1~3.6.0-1 is up to date -- reinstalling
error: failed to prepare transaction (could not find database)
```

in another project (ghc-lib-parser-ex), a similar command (different
compiler version/stack yaml) has been producing the following reliably long
enough that i'm sorry to say i just gave up testing it windows.
```
:: File /var/cache/pacman/pkg/automake1.9-1.9.6-3-any.pkg.tar.zst is
corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: automake1.10: signature from "David Macek <david.macek.0 at gmail.com>"
is unknown trust
error: automake1.11: signature from "David Macek <david.macek.0 at gmail.com>"
is unknown trust
error: automake1.12: signature from "David Macek <david.macek.0 at gmail.com>"
is unknown trust
error: automake1.13: signature from "David Macek <david.macek.0 at gmail.com>"
is unknown trust
error: automake1.14: signature from "David Macek <david.macek.0 at gmail.com>"
is unknown trust
error: automake1.15: signature from "David Macek <david.macek.0 at gmail.com>"
is unknown trust
:: File /var/cache/pacman/pkg/automake1.10-1.10.3-4-any.pkg.tar.zst is
corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
:: File /var/cache/pacman/pkg/automake1.11-1.11.6-4-any.pkg.tar.zst is
corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
:: File /var/cache/pacman/pkg/automake1.12-1.12.6-4-any.pkg.tar.zst is
corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
:: File /var/cache/pacman/pkg/automake1.13-1.13.4-5-any.pkg.tar.zst is
corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
:: File /var/cache/pacman/pkg/automake1.14-1.14.1-4-any.pkg.tar.zst is
corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
error: automake1.16: signature from "David Macek <david.macek.0 at gmail.com>"
is unknown trust
error: failed to commit transaction (invalid or corrupted package)
:: File /var/cache/pacman/pkg/automake1.15-1.15.1-2-any.pkg.tar.zst is
corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
:: File /var/cache/pacman/pkg/automake1.16-1.16.3-1-any.pkg.tar.zst is
corrupted (invalid or corrupted package (PGP signature)).
Do you want to delete it? [Y/n]
Errors occurred, no packages were upgraded.
```

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

From facundo.dominguez at tweag.io  Thu May  5 00:05:18 2022
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Dom=C3=ADnguez=2C_Facundo?=)
Date: Wed, 4 May 2022 21:05:18 -0300
Subject: Implementing a compilation server
Message-ID: <CAF7SUTSMPt5ozeqj5e_0JO6T1C9S2ycMN8JHVehGS2MGyg1R-w@mail.gmail.com>

Dear ghc devs,

I'm using the ghc API to write a compilation server (a.k.a. persistent
worker). The idea is to serve requests to compile individual modules. In
this fashion, we can compile modules with different compilation flags and
yet pay only once for the startup overheads of the compiler.

One challenge of this approach is to reuse as much as possible from the ghc
API session/environment from one compilation request to the next, so we
save the trouble of reconstructing it each time. This message is to ask for
advise on how to better accomplish this reuse.

I tried reusing the whole environment for multiple requests, but I'm
conjecturing that this might cause troubles when the requests require
building modules with different values of -this-unit-id. Another problem
that streams from this is that recompiling a module which defines a type
class instance fails because it encounters in the environment the type
class instance from the
previous compilation.

My work-in-progress implementation is here [1]. There appears to be
multiple ways to compile a module in the API, so far I have been trying
DriverPipeline.compileFile.

My best lead right now is to look for inspiration in how GHCi implements
the load command, but this does a sort of --make compilation while I'm
going here for the one-shot style.

Thanks in advance,
Facundo

[1]
https://github.com/tweag/rules_haskell/blob/16ba422457ea4daa5dbf40d46327ebcb20588e97/tools/haskell_module_worker/src/Compile.hs#L188
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220504/82e02e26/attachment.html>

From matthewtpickering at gmail.com  Thu May  5 08:13:32 2022
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Thu, 5 May 2022 09:13:32 +0100
Subject: Implementing a compilation server
In-Reply-To: <CAF7SUTSMPt5ozeqj5e_0JO6T1C9S2ycMN8JHVehGS2MGyg1R-w@mail.gmail.com>
References: <CAF7SUTSMPt5ozeqj5e_0JO6T1C9S2ycMN8JHVehGS2MGyg1R-w@mail.gmail.com>
Message-ID: <CALuQ0m-XEcJu=xS8jTuKNHGS-SQ_057VU_fzYCc92OPD7XDfeg@mail.gmail.com>

Hi Facundo

Some pointers...

1. Only put things in the EPS if they are not going to change
throughout the whole compilation
2. Treat everything which can change as a home package
2a. I suppose you have performed your own dependency analysis, so
build your own `ModGraph` and start looking from `load'`, you might
just want to call `upsweep_mod/compileOne'` directly yourself.
2b. I suppose you are NOT targeting 9.4.1 yet, but that will make
things easier as you can use support for multiple home packages,
otherwise you will get into severe difficulties if you load a package
you later want to compile into the EPS. The only thing you can do here
      is restart the compilation session I think.
3. To my knowledge, there is no issue using different -this-unit-id in
the same session. Not sure what errors you have seen.
4. You need to use --make mode rather than -c (oneshot) because
oneshot mode loads all interfaces into the EPS (see point 1)

ghcide is the closest program to this kind of compilation server you
imagine so you can look at how that uses the GHC API.

Cheers,

Matt


On Thu, May 5, 2022 at 1:06 AM Domínguez, Facundo
<facundo.dominguez at tweag.io> wrote:
>
> Dear ghc devs,
>
> I'm using the ghc API to write a compilation server (a.k.a. persistent worker). The idea is to serve requests to compile individual modules. In this fashion, we can compile modules with different compilation flags and yet pay only once for the startup overheads of the compiler.
>
> One challenge of this approach is to reuse as much as possible from the ghc API session/environment from one compilation request to the next, so we save the trouble of reconstructing it each time. This message is to ask for advise on how to better accomplish this reuse.
>
> I tried reusing the whole environment for multiple requests, but I'm conjecturing that this might cause troubles when the requests require building modules with different values of -this-unit-id. Another problem that streams from this is that recompiling a module which defines a type class instance fails because it encounters in the environment the type class instance from the
> previous compilation.
>
> My work-in-progress implementation is here [1]. There appears to be multiple ways to compile a module in the API, so far I have been trying DriverPipeline.compileFile.
>
> My best lead right now is to look for inspiration in how GHCi implements the load command, but this does a sort of --make compilation while I'm going here for the one-shot style.
>
> Thanks in advance,
> Facundo
>
> [1] https://github.com/tweag/rules_haskell/blob/16ba422457ea4daa5dbf40d46327ebcb20588e97/tools/haskell_module_worker/src/Compile.hs#L188
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From george.colpitts at gmail.com  Thu May  5 15:56:19 2022
From: george.colpitts at gmail.com (George Colpitts)
Date: Thu, 5 May 2022 12:56:19 -0300
Subject: macos install issue: ghc-pkg-9.2.2 cannot be opened because the
 developer cannot be verified
In-Reply-To: <CAB-d4A4=L=gwbYc+=eN3UPaFzUScNuZhj2VhCAUGDavMGCfT0Q@mail.gmail.com>
References: <87r17ewuxe.fsf@smart-cactus.org>
 <CAB-d4A4yAiDzHLEkDA=AhNN-2=0YcKPR7Rk5fXxCOkrKMnxRQw@mail.gmail.com>
 <20220307.152740.1433207400109063719.kazu@iij.ad.jp>
 <CAB-d4A4=L=gwbYc+=eN3UPaFzUScNuZhj2VhCAUGDavMGCfT0Q@mail.gmail.com>
Message-ID: <CAB-d4A5RVp-G_6Oq1OO7jvnYGR8VCVE_BQaVQwdH9hSNO1M5gw@mail.gmail.com>

It's not fixed for me so I filed
https://gitlab.haskell.org/ghc/ghc/-/issues/21506

On Mon, May 2, 2022 at 7:59 AM George Colpitts <george.colpitts at gmail.com>
wrote:

> Hi
>
> Did this get fixed? Is it fixed in 9.4.1-alpha1?
>
> Thanks
> George
>
> On Mon, Mar 7, 2022 at 2:27 AM Kazu Yamamoto <kazu at iij.ad.jp> wrote:
>
>> Hi George,
>>
>> FYI:
>>
>> https://twitter.com/kazu_yamamoto/status/1500643489985761282
>>
>> --Kazu
>>
>> > Thanks Ben
>> >
>> > When I do an install on macos Monterey 12.2.1 (Intel) I get
>> >
>> > ghc-pkg-9.2.2 cannot be opened because the developer cannot be verified
>> >
>> >
>> > On Sun, Mar 6, 2022 at 7:02 PM Ben Gamari <ben at well-typed.com> wrote:
>> >
>> >>
>> >> The GHC developers are very happy to at announce the availability of
>> GHC
>> >>
>> >> 9.2.2. Binary distributions, source distributions, and documentation
>> are
>> >>
>> >> available at downloads.haskell.org:
>> >>
>> >>    https://downloads.haskell.org/ghc/9.2.2
>> >>
>> >> This release includes many bug-fixes and other improvements to 9.2.1
>> >> including:
>> >>
>> >>  * A number of bug-fixes in the new AArch64 native code generator
>> >>
>> >>  * Fixes ensuring that the `indexWord8ArrayAs*#` family of primops is
>> >> handled
>> >>    correctly on platforms lacking support for unaligned memory accesses
>> >>    (#21015, #20987).
>> >>
>> >>  * Improvements to the compatibility story in GHC's migration to the
>> >>    XDG Base Directory Specification (#20684, #20669, #20660)
>> >>
>> >>  * Restored compatibility with Windows 7
>> >>
>> >>  * A new `-fcompact-unwind` flag, improving compatibility with C++
>> >> libraries on
>> >>    Apple Darwin (#11829)
>> >>
>> >>  * Introduction of a new flag, `-fcheck-prim-bounds`, enabling runtime
>> >> bounds
>> >>    checking of array primops (#20769)
>> >>
>> >>  * Unboxing of unlifted types (#20663)
>> >>
>> >>  * Numerous improvements in compiler performance.
>> >>
>> >>  * Many, many others. See the [release notes] for a full list.
>> >>
>> >> As some of the fixed issues do affect correctness users are encouraged
>> to
>> >>
>> >> upgrade promptly.
>> >>
>> >> Finally, thank you to Microsoft Research, GitHub, IOHK, the Zw3rk stake
>> >> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
>> >> contributors whose on-going financial and in-kind support has
>> >> facilitated GHC maintenance and release management over the years.
>> >> Moreover, this release would not have been possible without the
>> hundreds
>> >>
>> >> of open-source contributors whose work comprise this release.
>> >>
>> >> As always, do open a [ticket][] if you see anything amiss.
>> >>
>> >> Happy compiling,
>> >>
>> >> - Ben
>> >>
>> >>
>> >> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
>> >> [release notes]:
>> >>
>> https://downloads.haskell.org/ghc/9.2.2/docs/html/users_guide/9.2.2-notes.html
>> >>
>> >> _______________________________________________
>> >> 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/20220505/1fba2494/attachment.html>

From simon.peytonjones at gmail.com  Fri May  6 09:04:11 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 6 May 2022 10:04:11 +0100
Subject: Specialising NOINLINE functions
Message-ID: <CAJKmMz-ye9+qU2seqr5M+eKco73sW5n7FD5LCc0aD1=mm0AMSw@mail.gmail.com>

Dear devs

At the moment the INLINEABLE pragma means "capture my right-hand side,
regardless of how big it is, so that it can be type-class-specialised,
including in other modules".  But it *also *says "feel free to inline me".

Some users (eg Gergo) want to say NOINLINE on some functions. But for these
they'd still like to generate type-class-specialised versions.  After all,
if we aren't going to inline them, specialising is the next best thing.

But we have no way to say both "specialise me" and "don't inline me",
because you can't say both INLINEABLE and NOINLINE.  (That would look
silly.)

I think we should probably just bite the bullet and add a SPECIALISABLE
pragma, *orthogonal to INLINE/NOINLNE*, which say "capture my right-hand
side, regardless of how big it is, so that it can be
type-class-specialised, including in other modules".  It behaves exactly
like INLINEABLE except that  you can specify it along with INLINE/NOINLINE.

Any thoughts?  Do you think this needs a GHC proposal?

See #21036 <https://gitlab.haskell.org/ghc/ghc/-/issues/21036#note_407930>


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

From oleg.grenrus at iki.fi  Fri May  6 09:07:59 2022
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Fri, 6 May 2022 12:07:59 +0300
Subject: Specialising NOINLINE functions
In-Reply-To: <CAJKmMz-ye9+qU2seqr5M+eKco73sW5n7FD5LCc0aD1=mm0AMSw@mail.gmail.com>
References: <CAJKmMz-ye9+qU2seqr5M+eKco73sW5n7FD5LCc0aD1=mm0AMSw@mail.gmail.com>
Message-ID: <c24632bf-2f45-0ed2-22be-223291238d83@iki.fi>

There is a (stale) ghc-proposal for that,
https://github.com/ghc-proposals/ghc-proposals/pull/357

- Oleg

On 6.5.2022 12.04, Simon Peyton Jones wrote:
> Dear devs
>
> At the moment the INLINEABLE pragma means "capture my right-hand side,
> regardless of how big it is, so that it can be type-class-specialised,
> including in other modules".  But it /also /says "feel free to inline me".
>
> Some users (eg Gergo) want to say NOINLINE on some functions. But for
> these they'd still like to generate type-class-specialised versions. 
> After all, if we aren't going to inline them, specialising is the next
> best thing.
>
> But we have no way to say both "specialise me" and "don't inline me",
> because you can't say both INLINEABLE and NOINLINE.  (That would look
> silly.)
>
> I think we should probably just bite the bullet and add a
> SPECIALISABLE pragma, /orthogonal to INLINE/NOINLNE/, which say
> "capture my right-hand side, regardless of how big it is, so that it
> can be type-class-specialised, including in other modules".  It
> behaves exactly like INLINEABLE except that  you can specify it along
> with INLINE/NOINLINE.
>
> Any thoughts?  Do you think this needs a GHC proposal?
>
> See #21036 <https://gitlab.haskell.org/ghc/ghc/-/issues/21036#note_407930>
>
>
> Simon
>
> _______________________________________________
> 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  Fri May  6 09:25:59 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 6 May 2022 10:25:59 +0100
Subject: Specialising NOINLINE functions
In-Reply-To: <c24632bf-2f45-0ed2-22be-223291238d83@iki.fi>
References: <CAJKmMz-ye9+qU2seqr5M+eKco73sW5n7FD5LCc0aD1=mm0AMSw@mail.gmail.com>
 <c24632bf-2f45-0ed2-22be-223291238d83@iki.fi>
Message-ID: <CAJKmMz_Un1=thSFuYseugpcwhfFbCK1xHxm-WbcjnkWnBKOvDg@mail.gmail.com>

>
> There is a (stale) ghc-proposal for that,
> https://github.com/ghc-proposals/ghc-proposals/pull/357
>

So there is!  Thank you.

Gergo: would you like to take over this proposal, revise it if necessary in
the light of the comments, and submit it?

Simon

On Fri, 6 May 2022 at 10:08, Oleg Grenrus <oleg.grenrus at iki.fi> wrote:

> There is a (stale) ghc-proposal for that,
> https://github.com/ghc-proposals/ghc-proposals/pull/357
>
> - Oleg
>
> On 6.5.2022 12.04, Simon Peyton Jones wrote:
> > Dear devs
> >
> > At the moment the INLINEABLE pragma means "capture my right-hand side,
> > regardless of how big it is, so that it can be type-class-specialised,
> > including in other modules".  But it /also /says "feel free to inline
> me".
> >
> > Some users (eg Gergo) want to say NOINLINE on some functions. But for
> > these they'd still like to generate type-class-specialised versions.
> > After all, if we aren't going to inline them, specialising is the next
> > best thing.
> >
> > But we have no way to say both "specialise me" and "don't inline me",
> > because you can't say both INLINEABLE and NOINLINE.  (That would look
> > silly.)
> >
> > I think we should probably just bite the bullet and add a
> > SPECIALISABLE pragma, /orthogonal to INLINE/NOINLNE/, which say
> > "capture my right-hand side, regardless of how big it is, so that it
> > can be type-class-specialised, including in other modules".  It
> > behaves exactly like INLINEABLE except that  you can specify it along
> > with INLINE/NOINLINE.
> >
> > Any thoughts?  Do you think this needs a GHC proposal?
> >
> > See #21036 <
> https://gitlab.haskell.org/ghc/ghc/-/issues/21036#note_407930>
> >
> >
> > Simon
> >
> > _______________________________________________
> > 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/20220506/db8d51ce/attachment.html>

From carter.schonwald at gmail.com  Sat May  7 15:18:52 2022
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 7 May 2022 11:18:52 -0400
Subject: Specialising NOINLINE functions
In-Reply-To: <CAJKmMz_Un1=thSFuYseugpcwhfFbCK1xHxm-WbcjnkWnBKOvDg@mail.gmail.com>
References: <CAJKmMz-ye9+qU2seqr5M+eKco73sW5n7FD5LCc0aD1=mm0AMSw@mail.gmail.com>
 <c24632bf-2f45-0ed2-22be-223291238d83@iki.fi>
 <CAJKmMz_Un1=thSFuYseugpcwhfFbCK1xHxm-WbcjnkWnBKOvDg@mail.gmail.com>
Message-ID: <CAHYVw0yMk7iS5siGet8ERZuE12iji7qncrowBMLoc47xSksmvw@mail.gmail.com>

There even was a ghc branch with partial work towards implementing this as
part of fgaz’s gsoc.

I’m happy to help out if any spare cycles are needed to work through the
details

On Fri, May 6, 2022 at 5:26 AM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> There is a (stale) ghc-proposal for that,
>> https://github.com/ghc-proposals/ghc-proposals/pull/357
>>
>
> So there is!  Thank you.
>
> Gergo: would you like to take over this proposal, revise it if necessary
> in the light of the comments, and submit it?
>
> Simon
>
> On Fri, 6 May 2022 at 10:08, Oleg Grenrus <oleg.grenrus at iki.fi> wrote:
>
>> There is a (stale) ghc-proposal for that,
>> https://github.com/ghc-proposals/ghc-proposals/pull/357
>>
>> - Oleg
>>
>> On 6.5.2022 12.04, Simon Peyton Jones wrote:
>> > Dear devs
>> >
>> > At the moment the INLINEABLE pragma means "capture my right-hand side,
>> > regardless of how big it is, so that it can be type-class-specialised,
>> > including in other modules".  But it /also /says "feel free to inline
>> me".
>> >
>> > Some users (eg Gergo) want to say NOINLINE on some functions. But for
>> > these they'd still like to generate type-class-specialised versions.
>> > After all, if we aren't going to inline them, specialising is the next
>> > best thing.
>> >
>> > But we have no way to say both "specialise me" and "don't inline me",
>> > because you can't say both INLINEABLE and NOINLINE.  (That would look
>> > silly.)
>> >
>> > I think we should probably just bite the bullet and add a
>> > SPECIALISABLE pragma, /orthogonal to INLINE/NOINLNE/, which say
>> > "capture my right-hand side, regardless of how big it is, so that it
>> > can be type-class-specialised, including in other modules".  It
>> > behaves exactly like INLINEABLE except that  you can specify it along
>> > with INLINE/NOINLINE.
>> >
>> > Any thoughts?  Do you think this needs a GHC proposal?
>> >
>> > See #21036 <
>> https://gitlab.haskell.org/ghc/ghc/-/issues/21036#note_407930>
>> >
>> >
>> > Simon
>> >
>> > _______________________________________________
>> > 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
>>
> _______________________________________________
> 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/20220507/c35d56fb/attachment.html>

From Gergo.Erdi at sc.com  Mon May  9 01:38:21 2022
From: Gergo.Erdi at sc.com (Erdi, Gergo)
Date: Mon, 9 May 2022 01:38:21 +0000
Subject: [External] Re: Specialising NOINLINE functions
In-Reply-To: <CAJKmMz_Un1=thSFuYseugpcwhfFbCK1xHxm-WbcjnkWnBKOvDg@mail.gmail.com>
References: <CAJKmMz-ye9+qU2seqr5M+eKco73sW5n7FD5LCc0aD1=mm0AMSw@mail.gmail.com>
 <c24632bf-2f45-0ed2-22be-223291238d83@iki.fi>
 <CAJKmMz_Un1=thSFuYseugpcwhfFbCK1xHxm-WbcjnkWnBKOvDg@mail.gmail.com>
Message-ID: <HK0PR03MB48678AA99D8568965248DB6EE9C69@HK0PR03MB4867.apcprd03.prod.outlook.com>

PUBLIC

I can look into this, sure, but it wouldn't exactly solve my original problem, which is that I would like to turn this on wholesale, not definition by definition. It seems that all past discussion about this was in the context of a per-definition pragma (and sadly, a large part of that was bikeshedding over the name of the pragma...). But is the reason for that spelled out explicitly somewhere? In other words, what is the cost of specialisation, why would I ever not want to specialize a definition (inlinable or not)? I'd like to understand this first before reviving the proposal.

From: ghc-devs <ghc-devs-bounces at haskell.org> On Behalf Of Simon Peyton Jones
Sent: Friday, May 6, 2022 5:26 PM
To: Oleg Grenrus <oleg.grenrus at iki.fi>; ÉRDI Gergő <gergo at erdi.hu>
Cc: GHC developers <ghc-devs at haskell.org>
Subject: [External] Re: Specialising NOINLINE functions

There is a (stale) ghc-proposal for that,
https://github.com/ghc-proposals/ghc-proposals/pull/357<https://clicktime.symantec.com/3NuNFMzg65dA5k5kXHX5U196xU?u=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F357>

So there is!  Thank you.

Gergo: would you like to take over this proposal, revise it if necessary in the light of the comments, and submit it?

Simon

On Fri, 6 May 2022 at 10:08, Oleg Grenrus <oleg.grenrus at iki.fi<mailto:oleg.grenrus at iki.fi>> wrote:
There is a (stale) ghc-proposal for that,
https://github.com/ghc-proposals/ghc-proposals/pull/357<https://clicktime.symantec.com/3NuNFMzg65dA5k5kXHX5U196xU?u=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F357>

- Oleg

On 6.5.2022 12.04, Simon Peyton Jones wrote:
> Dear devs
>
> At the moment the INLINEABLE pragma means "capture my right-hand side,
> regardless of how big it is, so that it can be type-class-specialised,
> including in other modules".  But it /also /says "feel free to inline me".
>
> Some users (eg Gergo) want to say NOINLINE on some functions. But for
> these they'd still like to generate type-class-specialised versions.
> After all, if we aren't going to inline them, specialising is the next
> best thing.
>
> But we have no way to say both "specialise me" and "don't inline me",
> because you can't say both INLINEABLE and NOINLINE.  (That would look
> silly.)
>
> I think we should probably just bite the bullet and add a
> SPECIALISABLE pragma, /orthogonal to INLINE/NOINLNE/, which say
> "capture my right-hand side, regardless of how big it is, so that it
> can be type-class-specialised, including in other modules".  It
> behaves exactly like INLINEABLE except that  you can specify it along
> with INLINE/NOINLINE.
>
> Any thoughts?  Do you think this needs a GHC proposal?
>
> See #21036 <https://gitlab.haskell.org/ghc/ghc/-/issues/21036#note_407930<https://clicktime.symantec.com/3SB6vTf6r7gWFXH7FGMko9a6xU?u=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F21036%23note_407930>>
>
>
> Simon
>
> _______________________________________________
> 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<https://clicktime.symantec.com/37EyM1zQDopVjPevRNvP7f96xU?u=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-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<https://clicktime.symantec.com/37EyM1zQDopVjPevRNvP7f96xU?u=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs>

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at https: //www.sc.com/en/our-locations

Where you have a Financial Markets relationship with Standard Chartered PLC, Standard Chartered Bank and their subsidiaries (the "Group"), information on the regulatory standards we adhere to and how it may affect you can be found in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm

Insofar as this communication is not sent by the Global Research team and contains any market commentary, the market commentary has been prepared by the sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied on for any other purpose and is subject to the relevant disclaimers available at https: //www.sc.com/en/regulatory-disclosures/#market-disclaimer.

Insofar as this communication is sent by the Global Research team and contains any research materials prepared by members of the team, the research material is for information purpose only and shall not be relied on for any other purpose, and is subject to the relevant disclaimers available at https: //research.sc.com/research/api/application/static/terms-and-conditions. 

Insofar as this e-mail contains the term sheet for a proposed transaction, by responding affirmatively to this e-mail, you agree that you have understood the terms and conditions in the attached term sheet and evaluated the merits and risks of the transaction. We may at times also request you to sign the term sheet to acknowledge the same.

Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for important information with respect to derivative products.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220509/97f3da9f/attachment.html>

From simon.peytonjones at gmail.com  Mon May  9 08:12:57 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Mon, 9 May 2022 09:12:57 +0100
Subject: [External] Re: Specialising NOINLINE functions
In-Reply-To: <HK0PR03MB48678AA99D8568965248DB6EE9C69@HK0PR03MB4867.apcprd03.prod.outlook.com>
References: <CAJKmMz-ye9+qU2seqr5M+eKco73sW5n7FD5LCc0aD1=mm0AMSw@mail.gmail.com>
 <c24632bf-2f45-0ed2-22be-223291238d83@iki.fi>
 <CAJKmMz_Un1=thSFuYseugpcwhfFbCK1xHxm-WbcjnkWnBKOvDg@mail.gmail.com>
 <HK0PR03MB48678AA99D8568965248DB6EE9C69@HK0PR03MB4867.apcprd03.prod.outlook.com>
Message-ID: <CAJKmMz8CUr+DpU2G4N1_Xs2f=+pBsKiHeAU-8BjC=d1SfWVXiw@mail.gmail.com>

>
> I can look into this, sure, but it wouldn’t exactly solve my original
> problem, which is that I would like to turn this on wholesale, not
> definition by definition.
>

What is "this" that you want to turn on, precisely?

why would I ever not want to specialize a definition
>

I think the only downside is compilation time and code bloat.


I think you are concerned about cross-module specialisation.  There are two
things in play:

   1. Whether the defining module exposes the definition
   2. Whether the importing module specialises the thus-exposed definition

For (1) there are two choices:

   - (1a) Currently INLINEABLE captures the RHS of the function *exactly as
   the user wrote it*, and allows that to be specialised.
   - (1b) On the other hand, -fexpose-all-unfoldings does not attempt to
   capture the functions the user wrote; instead, it exposes the
*post-optimisation
   *RHSs of all functions, regardless of per-function pragmas.

I believe that (1b) is closer to what you want.

For (2) one might wonder whether to

   - (2a) specialise every imported (type-class-overloaded) function whose
   unfolding we can see
   - (2b) specialise only imported functions with a SPECIALISABLE pragma
   - (2c) specialise imported functions only with -fspecialise-aggressively

I think GHC currently does (2c).

Maybe this taxonomy helps you a bit?

Simon

On Mon, 9 May 2022 at 02:38, Erdi, Gergo <Gergo.Erdi at sc.com> wrote:

> PUBLIC
>
>
>
> I can look into this, sure, but it wouldn’t exactly solve my original
> problem, which is that I would like to turn this on wholesale, not
> definition by definition. It seems that all past discussion about this was
> in the context of a per-definition pragma (and sadly, a large part of that
> was bikeshedding over the name of the pragma…). But is the reason for that
> spelled out explicitly somewhere? In other words, what is the cost of
> specialisation, why would I ever not want to specialize a definition
> (inlinable or not)? I’d like to understand this first before reviving the
> proposal.
>
>
>
> *From:* ghc-devs <ghc-devs-bounces at haskell.org> *On Behalf Of *Simon
> Peyton Jones
> *Sent:* Friday, May 6, 2022 5:26 PM
> *To:* Oleg Grenrus <oleg.grenrus at iki.fi>; ÉRDI Gergő <gergo at erdi.hu>
> *Cc:* GHC developers <ghc-devs at haskell.org>
> *Subject:* [External] Re: Specialising NOINLINE functions
>
>
>
> There is a (stale) ghc-proposal for that,
> https://github.com/ghc-proposals/ghc-proposals/pull/357
> <https://clicktime.symantec.com/3NuNFMzg65dA5k5kXHX5U196xU?u=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F357>
>
>
>
> So there is!  Thank you.
>
>
>
> Gergo: would you like to take over this proposal, revise it if necessary
> in the light of the comments, and submit it?
>
>
>
> Simon
>
>
>
> On Fri, 6 May 2022 at 10:08, Oleg Grenrus <oleg.grenrus at iki.fi> wrote:
>
> There is a (stale) ghc-proposal for that,
> https://github.com/ghc-proposals/ghc-proposals/pull/357
> <https://clicktime.symantec.com/3NuNFMzg65dA5k5kXHX5U196xU?u=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F357>
>
> - Oleg
>
> On 6.5.2022 12.04, Simon Peyton Jones wrote:
> > Dear devs
> >
> > At the moment the INLINEABLE pragma means "capture my right-hand side,
> > regardless of how big it is, so that it can be type-class-specialised,
> > including in other modules".  But it /also /says "feel free to inline
> me".
> >
> > Some users (eg Gergo) want to say NOINLINE on some functions. But for
> > these they'd still like to generate type-class-specialised versions.
> > After all, if we aren't going to inline them, specialising is the next
> > best thing.
> >
> > But we have no way to say both "specialise me" and "don't inline me",
> > because you can't say both INLINEABLE and NOINLINE.  (That would look
> > silly.)
> >
> > I think we should probably just bite the bullet and add a
> > SPECIALISABLE pragma, /orthogonal to INLINE/NOINLNE/, which say
> > "capture my right-hand side, regardless of how big it is, so that it
> > can be type-class-specialised, including in other modules".  It
> > behaves exactly like INLINEABLE except that  you can specify it along
> > with INLINE/NOINLINE.
> >
> > Any thoughts?  Do you think this needs a GHC proposal?
> >
> > See #21036 <
> https://gitlab.haskell.org/ghc/ghc/-/issues/21036#note_407930
> <https://clicktime.symantec.com/3SB6vTf6r7gWFXH7FGMko9a6xU?u=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fissues%2F21036%23note_407930>
> >
> >
> >
> > Simon
> >
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> <https://clicktime.symantec.com/37EyM1zQDopVjPevRNvP7f96xU?u=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> <https://clicktime.symantec.com/37EyM1zQDopVjPevRNvP7f96xU?u=http%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs>
>
>
> This email and any attachments are confidential and may also be
> privileged. If you are not the intended recipient, please delete all copies
> and notify the sender immediately. You may wish to refer to the
> incorporation details of Standard Chartered PLC, Standard Chartered Bank
> and their subsidiaries at https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard Chartered
> PLC, Standard Chartered Bank and their subsidiaries (the "Group"),
> information on the regulatory standards we adhere to and how it may affect
> you can be found in our Regulatory Compliance Statement at https: //
> www.sc.com/rcs/ and Regulatory Compliance Disclosures at http: //
> www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and
> contains any market commentary, the market commentary has been prepared by
> the sales and/or trading desk of Standard Chartered Bank or its affiliate.
> It is not and does not constitute research material, independent research,
> recommendation or financial advice. Any market commentary is for
> information purpose only and shall not be relied on for any other purpose
> and is subject to the relevant disclaimers available at https: //
> www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and
> contains any research materials prepared by members of the team, the
> research material is for information purpose only and shall not be relied
> on for any other purpose, and is subject to the relevant disclaimers
> available at https: //
> research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction,
> by responding affirmatively to this e-mail, you agree that you have
> understood the terms and conditions in the attached term sheet and
> evaluated the merits and risks of the transaction. We may at times also
> request you to sign the term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/
> for important information with respect to derivative products.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220509/2a94a06c/attachment.html>

From klebinger.andreas at gmx.at  Mon May  9 11:14:24 2022
From: klebinger.andreas at gmx.at (Andreas Klebinger)
Date: Mon, 9 May 2022 13:14:24 +0200
Subject: [External] Re: Specialising NOINLINE functions
In-Reply-To: <CAJKmMz8CUr+DpU2G4N1_Xs2f=+pBsKiHeAU-8BjC=d1SfWVXiw@mail.gmail.com>
References: <CAJKmMz-ye9+qU2seqr5M+eKco73sW5n7FD5LCc0aD1=mm0AMSw@mail.gmail.com>
 <c24632bf-2f45-0ed2-22be-223291238d83@iki.fi>
 <CAJKmMz_Un1=thSFuYseugpcwhfFbCK1xHxm-WbcjnkWnBKOvDg@mail.gmail.com>
 <HK0PR03MB48678AA99D8568965248DB6EE9C69@HK0PR03MB4867.apcprd03.prod.outlook.com>
 <CAJKmMz8CUr+DpU2G4N1_Xs2f=+pBsKiHeAU-8BjC=d1SfWVXiw@mail.gmail.com>
Message-ID: <f553511e-def1-58bf-ce3e-32579b8e6c1c@gmx.at>


Am 09/05/2022 um 10:12 schrieb Simon Peyton Jones:
> I think the only downside is compilation time and code bloat.

It can cause some rules to stop firing in a similar fashion as
https://gitlab.haskell.org/ghc/ghc/-/issues/20364 discusses for W/W.

But that can be fixed by adding the appropriate INLINE[ABLE] pragmas.


From hecate at glitchbra.in  Mon May  9 22:00:14 2022
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Tue, 10 May 2022 00:00:14 +0200
Subject: Deprecation process for GHC.Pack
Message-ID: <2e9c6bb3-7161-859e-c078-c89650d3aeee@glitchbra.in>

Hello fellow devs,

Just an email to signal the start of the deprecation process of 
GHC.Pack, with the three-releases cycle:

 1. By prose (GHC 9.6) (#21541
    <https://gitlab.haskell.org/ghc/ghc/-/issues/21541>)
 2. By warning (GHC 9.8) (#21540
    <https://gitlab.haskell.org/ghc/ghc/-/issues/21540>)
 3. By error (GHC 9.10) (#21536
    <https://gitlab.haskell.org/ghc/ghc/-/issues/21536>)


You can read more about the whole thing here: 
https://gitlab.haskell.org/ghc/ghc/-/issues/21461

Cheers, have a nice week!

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW:https://glitchbra.in
RUN: BSD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220510/c5da01a7/attachment.html>

From simon.peytonjones at gmail.com  Tue May 10 15:31:42 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 10 May 2022 16:31:42 +0100
Subject: Gitlab problem
Message-ID: <CAJKmMz8JFLM=bs+zjVpAMG8cQR2yWa-MCn5OsCu3wfThh-HrEQ@mail.gmail.com>

Friends

I am abruptly unable to push or pull to the GHC repo.  E.g. 'git fetch'
just hangs.

Yet ssh git at gitlab.haskell.org seems to succeed with
PTY allocation request failed on channel 0
Welcome to GitLab, @simonpj!
Connection to gitlab.haskell.org closed.

How could I debug this?  I'm on WSL.  My network appears to be fine.

Thanks.  I'm totally stalled.

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

From matthewtpickering at gmail.com  Tue May 10 16:00:55 2022
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 10 May 2022 17:00:55 +0100
Subject: Gitlab problem
In-Reply-To: <CAJKmMz8JFLM=bs+zjVpAMG8cQR2yWa-MCn5OsCu3wfThh-HrEQ@mail.gmail.com>
References: <CAJKmMz8JFLM=bs+zjVpAMG8cQR2yWa-MCn5OsCu3wfThh-HrEQ@mail.gmail.com>
Message-ID: <CALuQ0m_uHZLoS1OmY448kNepDZ+enCU+qw2UgCs+wuMVmBycAA@mail.gmail.com>

Hi Simon,

I can't reproduce this locally.. still broken for you?

Matt

On Tue, May 10, 2022 at 4:32 PM Simon Peyton Jones
<simon.peytonjones at gmail.com> wrote:
>
> Friends
>
> I am abruptly unable to push or pull to the GHC repo.  E.g. 'git fetch' just hangs.
>
> Yet ssh git at gitlab.haskell.org seems to succeed with
> PTY allocation request failed on channel 0
> Welcome to GitLab, @simonpj!
> Connection to gitlab.haskell.org closed.
>
> How could I debug this?  I'm on WSL.  My network appears to be fine.
>
> Thanks.  I'm totally stalled.
>
> Simon
> _______________________________________________
> 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  Tue May 10 16:10:58 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 10 May 2022 17:10:58 +0100
Subject: Gitlab problem
In-Reply-To: <CALuQ0m_uHZLoS1OmY448kNepDZ+enCU+qw2UgCs+wuMVmBycAA@mail.gmail.com>
References: <CAJKmMz8JFLM=bs+zjVpAMG8cQR2yWa-MCn5OsCu3wfThh-HrEQ@mail.gmail.com>
 <CALuQ0m_uHZLoS1OmY448kNepDZ+enCU+qw2UgCs+wuMVmBycAA@mail.gmail.com>
Message-ID: <CAJKmMz9ic74Q3Ugoe6xtXRic2rzMtBJzHBAs3NYiZ6_4VcHrGw@mail.gmail.com>

Thanks.  It has mysteriously started working again now...   Sorry for the
noise.

Simon

On Tue, 10 May 2022 at 17:01, Matthew Pickering <matthewtpickering at gmail.com>
wrote:

> Hi Simon,
>
> I can't reproduce this locally.. still broken for you?
>
> Matt
>
> On Tue, May 10, 2022 at 4:32 PM Simon Peyton Jones
> <simon.peytonjones at gmail.com> wrote:
> >
> > Friends
> >
> > I am abruptly unable to push or pull to the GHC repo.  E.g. 'git fetch'
> just hangs.
> >
> > Yet ssh git at gitlab.haskell.org seems to succeed with
> > PTY allocation request failed on channel 0
> > Welcome to GitLab, @simonpj!
> > Connection to gitlab.haskell.org closed.
> >
> > How could I debug this?  I'm on WSL.  My network appears to be fine.
> >
> > Thanks.  I'm totally stalled.
> >
> > 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/20220510/3c559a2f/attachment.html>

From shayne.fletcher.50 at gmail.com  Wed May 11 12:45:35 2022
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Wed, 11 May 2022 08:45:35 -0400
Subject: stack exec -- pacman broken
In-Reply-To: <CAMsAzy-pGFNiG78JZyz-8WUP_SGMafsSiDtC5ZVo7uQVypsJXw@mail.gmail.com>
References: <CAMsAzy-pGFNiG78JZyz-8WUP_SGMafsSiDtC5ZVo7uQVypsJXw@mail.gmail.com>
Message-ID: <CAMsAzy_=hFwgdm1HSOJVXACxgwyrrZrgE9+OLk+L10Hh7FXp7Q@mail.gmail.com>

On Wed, May 4, 2022 at 5:55 PM Shayne Fletcher <shayne.fletcher.50 at gmail.com>
wrote:

> this isn't exactly a GHC issue but perhaps someone knows how to get it
> resolved? (suspecting commercial/stack i've raised [this issue](
> https://github.com/commercialhaskell/stack/issues/5732) there).
>
> tl;dr `stack exec -- pacman -S ...` like commands required for building
> GHC on windows are broken and have been for sometime
>

Thanks to commericalhaskell/stack maintainer Mike Pilgrem and Michael
Snoyman, the 64-bit MSYS2 that `stack` downloads has been bumped to version
20220503 and issue #5732 above is resolved!

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

From simon.peytonjones at gmail.com  Fri May 13 10:46:26 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 13 May 2022 11:46:26 +0100
Subject: Extra file in GHC repo
Message-ID: <CAJKmMz-kS_ZBZHbEK5DPKcZpv_++mH=fP8=8g_ziDpjYX2NVRQ@mail.gmail.com>

Hi devs

I've started to get this a lot

bash$ git rebase origin/master
First, rewinding head to replay your work on top of it...
error: The following untracked working tree files would be overwritten by
checkout:
docs/index.html
Please move or remove them before you switch branches.
Aborting
fatal: Could not detach HEAD

Removing docs/index.html makes things work again.  What am I doing wrong?

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

From matthewtpickering at gmail.com  Fri May 13 12:37:38 2022
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 13 May 2022 13:37:38 +0100
Subject: Extra file in GHC repo
In-Reply-To: <CAJKmMz-kS_ZBZHbEK5DPKcZpv_++mH=fP8=8g_ziDpjYX2NVRQ@mail.gmail.com>
References: <CAJKmMz-kS_ZBZHbEK5DPKcZpv_++mH=fP8=8g_ziDpjYX2NVRQ@mail.gmail.com>
Message-ID: <CALuQ0m_oBuAE7PSFGL4WS4zmV95MHM+6__SB5Wg5OAvA7YJQWw@mail.gmail.com>

The docs/index.html used to be generated by configure (and now it's
not). So you get this error when you have a dirty tree and try to
checkout a newer commit where the generated version will get
overwritten by the new non-generated version.

Matt

On Fri, May 13, 2022 at 11:46 AM Simon Peyton Jones
<simon.peytonjones at gmail.com> wrote:
>
> Hi devs
>
> I've started to get this a lot
>
> bash$ git rebase origin/master
> First, rewinding head to replay your work on top of it...
> error: The following untracked working tree files would be overwritten by checkout:
> docs/index.html
> Please move or remove them before you switch branches.
> Aborting
> fatal: Could not detach HEAD
>
> Removing docs/index.html makes things work again.  What am I doing wrong?
>
> Simon
> _______________________________________________
> 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  Fri May 13 13:14:55 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 13 May 2022 14:14:55 +0100
Subject: Extra file in GHC repo
In-Reply-To: <CALuQ0m_oBuAE7PSFGL4WS4zmV95MHM+6__SB5Wg5OAvA7YJQWw@mail.gmail.com>
References: <CAJKmMz-kS_ZBZHbEK5DPKcZpv_++mH=fP8=8g_ziDpjYX2NVRQ@mail.gmail.com>
 <CALuQ0m_oBuAE7PSFGL4WS4zmV95MHM+6__SB5Wg5OAvA7YJQWw@mail.gmail.com>
Message-ID: <CAJKmMz8Rg54YNyj9q2eCL4sp3rTMZEgsGge6D_c44ypoDiD-Ag@mail.gmail.com>

OK so I should delete the file -- and then the error should not re-occur,
correct?

thanks

Simon

On Fri, 13 May 2022 at 13:37, Matthew Pickering <matthewtpickering at gmail.com>
wrote:

> The docs/index.html used to be generated by configure (and now it's
> not). So you get this error when you have a dirty tree and try to
> checkout a newer commit where the generated version will get
> overwritten by the new non-generated version.
>
> Matt
>
> On Fri, May 13, 2022 at 11:46 AM Simon Peyton Jones
> <simon.peytonjones at gmail.com> wrote:
> >
> > Hi devs
> >
> > I've started to get this a lot
> >
> > bash$ git rebase origin/master
> > First, rewinding head to replay your work on top of it...
> > error: The following untracked working tree files would be overwritten
> by checkout:
> > docs/index.html
> > Please move or remove them before you switch branches.
> > Aborting
> > fatal: Could not detach HEAD
> >
> > Removing docs/index.html makes things work again.  What am I doing wrong?
> >
> > 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/20220513/b925fcbe/attachment.html>

From matthewtpickering at gmail.com  Fri May 13 13:48:45 2022
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 13 May 2022 14:48:45 +0100
Subject: Extra file in GHC repo
In-Reply-To: <CAJKmMz8Rg54YNyj9q2eCL4sp3rTMZEgsGge6D_c44ypoDiD-Ag@mail.gmail.com>
References: <CAJKmMz-kS_ZBZHbEK5DPKcZpv_++mH=fP8=8g_ziDpjYX2NVRQ@mail.gmail.com>
 <CALuQ0m_oBuAE7PSFGL4WS4zmV95MHM+6__SB5Wg5OAvA7YJQWw@mail.gmail.com>
 <CAJKmMz8Rg54YNyj9q2eCL4sp3rTMZEgsGge6D_c44ypoDiD-Ag@mail.gmail.com>
Message-ID: <CALuQ0m9PoF8qbb1KfGaOh6x6iZiy5rGPfOLn2QnfYKZYEdyb1g@mail.gmail.com>

Yes, that is correct.

On Fri, May 13, 2022 at 2:14 PM Simon Peyton Jones
<simon.peytonjones at gmail.com> wrote:
>
> OK so I should delete the file -- and then the error should not re-occur, correct?
>
> thanks
>
> Simon
>
> On Fri, 13 May 2022 at 13:37, Matthew Pickering <matthewtpickering at gmail.com> wrote:
>>
>> The docs/index.html used to be generated by configure (and now it's
>> not). So you get this error when you have a dirty tree and try to
>> checkout a newer commit where the generated version will get
>> overwritten by the new non-generated version.
>>
>> Matt
>>
>> On Fri, May 13, 2022 at 11:46 AM Simon Peyton Jones
>> <simon.peytonjones at gmail.com> wrote:
>> >
>> > Hi devs
>> >
>> > I've started to get this a lot
>> >
>> > bash$ git rebase origin/master
>> > First, rewinding head to replay your work on top of it...
>> > error: The following untracked working tree files would be overwritten by checkout:
>> > docs/index.html
>> > Please move or remove them before you switch branches.
>> > Aborting
>> > fatal: Could not detach HEAD
>> >
>> > Removing docs/index.html makes things work again.  What am I doing wrong?
>> >
>> > Simon
>> > _______________________________________________
>> > ghc-devs mailing list
>> > ghc-devs at haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From hecate at glitchbra.in  Sun May 15 20:58:53 2022
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Sun, 15 May 2022 22:58:53 +0200
Subject: Deprecation of GHCi's tag generation feature, starting with GHC 9.4
Message-ID: <303f6c48-9180-07a9-7c23-afc7bbc9cb52@glitchbra.in>

Hello devs,

Last year was discussed the deprecation of GHCi's tag generation 
feature, as it had become a liability with recent additions to the 
language, like Unboxed Sums¹.

The deprecation process starts with GHC 9.4, and merge request !6325².

TL;DR: The ghc-tags tool has been elected to replace the tags feature. 
This is being documented in the "Tags" wiki page³.

You are invited to help with broadcasting this announcement to your 
fellow Haskell users.
I will post on Reddit and the Haskell Discourse but increasing the 
coverage of this will be important.

Cheers,
Hécate


¹ https://gitlab.haskell.org/ghc/ghc/-/issues/19884
² https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6325
³ https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/GHCi/Tags

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD


From matthewtpickering at gmail.com  Mon May 16 09:57:19 2022
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Mon, 16 May 2022 10:57:19 +0100
Subject: Welcome to Bryan (Devops Engineer)
Message-ID: <CALuQ0m-BXP_Nv2oH-gG+ZjYC3u4qWv1B_Yorozd3-+=+Hv-Hdg@mail.gmail.com>

Hi all,

Bryan has been hired by the Haskell foundation to work on devops
problems in the Haskell ecosystem. His first day is today! At least
initially he will be working closely with the GHC team to shore up CI
infrastructure and other devops tasks. If you see him around make sure
to say hello, especially if you've got a complaint about CI ;)

His username is chreekat.

Cheers,

Matt

From hecate at glitchbra.in  Mon May 16 09:58:25 2022
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Mon, 16 May 2022 11:58:25 +0200
Subject: Welcome to Bryan (Devops Engineer)
In-Reply-To: <CALuQ0m-BXP_Nv2oH-gG+ZjYC3u4qWv1B_Yorozd3-+=+Hv-Hdg@mail.gmail.com>
References: <CALuQ0m-BXP_Nv2oH-gG+ZjYC3u4qWv1B_Yorozd3-+=+Hv-Hdg@mail.gmail.com>
Message-ID: <5b9f55c8-f5c1-f77c-93f6-ffe08ef2d2cb@glitchbra.in>

Hi Bryan, welcome aboard!

Le 16/05/2022 à 11:57, Matthew Pickering a écrit :
> Hi all,
>
> Bryan has been hired by the Haskell foundation to work on devops
> problems in the Haskell ecosystem. His first day is today! At least
> initially he will be working closely with the GHC team to shore up CI
> infrastructure and other devops tasks. If you see him around make sure
> to say hello, especially if you've got a complaint about CI ;)
>
> His username is chreekat.
>
> Cheers,
>
> Matt
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD


From b at chreekat.net  Mon May 16 10:32:35 2022
From: b at chreekat.net (Bryan)
Date: Mon, 16 May 2022 10:32:35 +0000
Subject: Welcome to Bryan (Devops Engineer)
In-Reply-To: <5b9f55c8-f5c1-f77c-93f6-ffe08ef2d2cb@glitchbra.in>
References: <CALuQ0m-BXP_Nv2oH-gG+ZjYC3u4qWv1B_Yorozd3-+=+Hv-Hdg@mail.gmail.com>
 <5b9f55c8-f5c1-f77c-93f6-ffe08ef2d2cb@glitchbra.in>
Message-ID: <b0FnIcTR4NxMnz2MyqOUSFt_knHpFJH2TYvWuZOSkVrwslSgYm-Cdi6iwDmmswgzxpS8SmbMEyS_X9k9QWNRi7_g7vrKXiv-ZwyUEMESzmc=@chreekat.net>

Hello, glad to be here with the new role! I've transitioned from lurker to active participant. :) I'm looking forward to stabilizing CI and making it more useful to you all.

My HF address is bryan at haskell.foundation, although in the blurry space of open source development I'll probably keep using this email address (and chreekat / @b:chreekat.net on IRC, Slack, and Matrix) for contact points. Feel free to reach out to say hi or complain about failed CI jobs. :)

See ya,

-Bryan

------- Original Message -------
On Monday, May 16th, 2022 at 12:58, Hécate <hecate at glitchbra.in> wrote:


>
>
> Hi Bryan, welcome aboard!
>
> Le 16/05/2022 à 11:57, Matthew Pickering a écrit :
>
> > Hi all,
> >
> > Bryan has been hired by the Haskell foundation to work on devops
> > problems in the Haskell ecosystem. His first day is today! At least
> > initially he will be working closely with the GHC team to shore up CI
> > infrastructure and other devops tasks. If you see him around make sure
> > to say hello, especially if you've got a complaint about CI ;)
> >
> > His username is chreekat.
> >
> > Cheers,
> >
> > Matt
> > _______________________________________________
> > ghc-devs mailing list
> > ghc-devs at haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
> --
> Hécate ✨
> 🐦: @TechnoEmpress
> IRC: Hecate
> WWW: https://glitchbra.in
> RUN: BSD
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From b at chreekat.net  Mon May 16 13:52:23 2022
From: b at chreekat.net (Bryan)
Date: Mon, 16 May 2022 13:52:23 +0000
Subject: gitlab spam
Message-ID: <I2z5d4VRZntKqJPcx_2168QkKnGSjpyojctV0lQD7SQJOm17-0balvn8JyLOq2uF3lPWFtXqj-GQz8A2L1HbTUUvW6ZW1QDl6YaC0BwyxUg=@chreekat.net>

While familiarizing myself with gitlab.haskell.org, I noticed there's a ton of spam users and projects.

Does this have any practical effect on any of you?

Who (if anyone) is the moderation team that handles abuse reports?

While I don't think it's a high-priority concern for myself and I don't intend to address it right now, I'd like to at least know what kind of effect this is having on GHC devs.

There have already been 50+ users added today, and a random sample was 100% spam.

There are 84,000 users and 1700 projects in the system in total. I assume 90-99% of them are spam. Not really conducive to a balanced diet.

-Bryan "eat more veggies" Richter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220516/4c93ddbe/attachment.html>

From hecate at glitchbra.in  Mon May 16 16:10:07 2022
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Mon, 16 May 2022 18:10:07 +0200
Subject: gitlab spam
In-Reply-To: <I2z5d4VRZntKqJPcx_2168QkKnGSjpyojctV0lQD7SQJOm17-0balvn8JyLOq2uF3lPWFtXqj-GQz8A2L1HbTUUvW6ZW1QDl6YaC0BwyxUg=@chreekat.net>
References: <I2z5d4VRZntKqJPcx_2168QkKnGSjpyojctV0lQD7SQJOm17-0balvn8JyLOq2uF3lPWFtXqj-GQz8A2L1HbTUUvW6ZW1QDl6YaC0BwyxUg=@chreekat.net>
Message-ID: <52720a86-16f1-b6b8-6557-225e94cbf860@glitchbra.in>

No visible effect on my part, but I would agree that it's not something 
we should keep. :)

Le 16/05/2022 à 15:52, Bryan a écrit :
> While familiarizing myself with gitlab.haskell.org, I noticed there's 
> a ton of spam users and projects.
>
> Does this have any practical effect on any of you?
>
> Who (if anyone) is the moderation team that handles abuse reports?
>
> While I don't think it's a high-priority concern for myself and I 
> don't intend to address it right now, I'd like to at least know what 
> kind of effect this is having on GHC devs.
>
> There have already been 50+ users added today, and a random sample was 
> 100% spam.
>
> There are 84,000 users and 1700 projects in the system in total. I 
> assume 90-99% of them are spam. Not really conducive to a balanced diet.
>
> -Bryan "eat more veggies" Richter
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW:https://glitchbra.in
RUN: BSD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220516/4cab3188/attachment.html>

From ben at well-typed.com  Mon May 16 17:25:42 2022
From: ben at well-typed.com (Ben Gamari)
Date: Mon, 16 May 2022 13:25:42 -0400
Subject: gitlab spam
In-Reply-To: <I2z5d4VRZntKqJPcx_2168QkKnGSjpyojctV0lQD7SQJOm17-0balvn8JyLOq2uF3lPWFtXqj-GQz8A2L1HbTUUvW6ZW1QDl6YaC0BwyxUg=@chreekat.net>
References: <I2z5d4VRZntKqJPcx_2168QkKnGSjpyojctV0lQD7SQJOm17-0balvn8JyLOq2uF3lPWFtXqj-GQz8A2L1HbTUUvW6ZW1QDl6YaC0BwyxUg=@chreekat.net>
Message-ID: <87v8u58k59.fsf@smart-cactus.org>

Bryan and I discussed this in person but I'll repeat what I said there
here:

In short, there are two kinds of spam:

 * user creation without the creation of any other content
 * spam content (primarily projects and snippets)

My sense is that the former has thusfar been harmless and consequently
we shouldn't worry lose any sleep over it. On the other hand, spam
content is quite problematic and we should strive to eliminate it.
Once every few months I take a bit of time and do some cleaning (with
some mechanical help [1]). It's also helpful when users use GitLab's
"Report Abuse" feature to flag spam accounts as these cases are very
easy to handle.

Cheers,

- Ben


[1] https://gitlab.haskell.org/bgamari/ghc-utils/-/blob/master/gitlab-utils/gitlab_utils/spam_util.py

-------------- 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/20220516/fc164ce4/attachment.sig>

From lists at richarde.dev  Mon May 16 19:09:33 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 16 May 2022 19:09:33 +0000
Subject: ambiguous record field (but not *that* kind of ambiguous record field)
Message-ID: <010f0180ce4693b6-e3d38276-57f1-4fe4-a753-4b3ccd9da3b9-000000@us-east-2.amazonses.com>

Hi all,

On a project I'm working on, I wish to declare something like

data Rec = MkRec { field :: forall a. SomeConstraint a => ... }

where the ... contains no mention of `a`.

Even with https://github.com/ghc-proposals/ghc-proposals/pull/448 <https://github.com/ghc-proposals/ghc-proposals/pull/448>, I think there is no way to avoid the ambiguity when setting `field`. Is that correct? If so, what shall we do about it? The natural answer is somehow to write ... MkRec { field @a = ... } ... but that would break significant new syntactic ground. (Maybe it's good new syntactic ground, but it would still be very new.)

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220516/de4808aa/attachment.html>

From sgraf1337 at gmail.com  Mon May 16 19:45:20 2022
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Mon, 16 May 2022 19:45:20 +0000
Subject: ambiguous record field (but not *that* kind of ambiguous record
 field)
In-Reply-To: <010f0180ce4693b6-e3d38276-57f1-4fe4-a753-4b3ccd9da3b9-000000@us-east-2.amazonses.com>
References: <010f0180ce4693b6-e3d38276-57f1-4fe4-a753-4b3ccd9da3b9-000000@us-east-2.amazonses.com>
Message-ID: <em2e1e0f57-77ad-44e0-9687-212e364660be@sebastian-pc>

Hi Richard,

I'm not sure if I'm missing something, but my adolescent naivety in 
frontend matters would try to reach for
https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0155-type-lambda.rst#motivation 
and write

   MkRec { field = \@a -> ... }

and I hope that will do the right thing. Indeed, I interpret your 
proposed `field @a = ...` as much the same.

Sebastian


------ Originalnachricht ------
Von: "Richard Eisenberg" <lists at richarde.dev>
An: "Erdi, Gergo via ghc-devs" <ghc-devs at haskell.org>
Gesendet: 16.05.2022 21:09:33
Betreff: ambiguous record field (but not *that* kind of ambiguous record 
field)

>Hi all,
>
>On a project I'm working on, I wish to declare something like
>
>data Rec = MkRec { field :: forall a. SomeConstraint a => ... }
>
>where the ... contains no mention of `a`.
>
>Even with https://github.com/ghc-proposals/ghc-proposals/pull/448, I 
>think there is no way to avoid the ambiguity when setting `field`. Is 
>that correct? If so, what shall we do about it? The natural answer is 
>somehow to write ... MkRec { field @a = ... } ... but that would break 
>significant new syntactic ground. (Maybe it's good new syntactic 
>ground, but it would still be very new.)
>
>Thanks,
>Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220516/61952013/attachment.html>

From lists at richarde.dev  Mon May 16 20:07:34 2022
From: lists at richarde.dev (Richard Eisenberg)
Date: Mon, 16 May 2022 20:07:34 +0000
Subject: ambiguous record field (but not *that* kind of ambiguous record
 field)
In-Reply-To: <em2e1e0f57-77ad-44e0-9687-212e364660be@sebastian-pc>
References: <010f0180ce4693b6-e3d38276-57f1-4fe4-a753-4b3ccd9da3b9-000000@us-east-2.amazonses.com>
 <em2e1e0f57-77ad-44e0-9687-212e364660be@sebastian-pc>
Message-ID: <010f0180ce7baf90-99a2fbd0-c55a-4125-84c4-5d38970fb15e-000000@us-east-2.amazonses.com>



> On May 16, 2022, at 3:45 PM, Sebastian Graf <sgraf1337 at gmail.com> wrote:
> 
> MkRec { field = \@a -> ... }

Hm -- perhaps you're right. I may have gotten myself all worked up over nothing. I was worried that unification would get confused, not sure that the `a`s match up. But I now think I was wrong -- it should be OK.

Thanks,
Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220516/6ecce3b9/attachment.html>

From mail at joachim-breitner.de  Mon May 16 20:22:07 2022
From: mail at joachim-breitner.de (Joachim Breitner)
Date: Mon, 16 May 2022 22:22:07 +0200
Subject: ambiguous record field (but not *that* kind of ambiguous record
 field)
In-Reply-To: <010f0180ce4693b6-e3d38276-57f1-4fe4-a753-4b3ccd9da3b9-000000@us-east-2.amazonses.com>
References: <010f0180ce4693b6-e3d38276-57f1-4fe4-a753-4b3ccd9da3b9-000000@us-east-2.amazonses.com>
Message-ID: <393ea087fd027c3eb5d2e270efceeb916cab7eee.camel@joachim-breitner.de>

Hi,

Am Montag, dem 16.05.2022 um 19:09 +0000 schrieb Richard Eisenberg:
> Hi all,
> 
> On a project I'm working on, I wish to declare something like
> 
> data Rec = MkRec { field :: forall a. SomeConstraint a => ... }
> 
> where the ... contains no mention of `a`.
> 
> Even with https://github.com/ghc-proposals/ghc-proposals/pull/448, I
> think there is no way to avoid the ambiguity when setting `field`. Is
> that correct? If so, what shall we do about it? The natural answer is
> somehow to write ... MkRec { field @a = ... } ... but that would
> break significant new syntactic ground. (Maybe it's good new
> syntactic ground, but it would still be very new.)

I’m probably revealing ignorance of #448 this way, but why would

   MkRec { field = \@a -> ...}
   
not work with -XTypeAbstractions

Cheers,
Joachim

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


From moritz.angermann at gmail.com  Mon May 16 23:23:37 2022
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Tue, 17 May 2022 07:23:37 +0800
Subject: gitlab spam
In-Reply-To: <87v8u58k59.fsf@smart-cactus.org>
References: <I2z5d4VRZntKqJPcx_2168QkKnGSjpyojctV0lQD7SQJOm17-0balvn8JyLOq2uF3lPWFtXqj-GQz8A2L1HbTUUvW6ZW1QDl6YaC0BwyxUg=@chreekat.net>
 <87v8u58k59.fsf@smart-cactus.org>
Message-ID: <CAKfdd-w1f31OLDD2FoDi+m+ygsT=tmNc=-t_Qh30OF8S-eNBzg@mail.gmail.com>

The second one is an issue if it consumes CI Ressource. Ideally we’d have
only “blessed” repos allowed to consume CI. The issue with this is that
(random) new users can’t fork GHC and have CI run against their change.

I’d still very much like to see a solution to this; it is a security
concern.

Moritz

On Tue, 17 May 2022 at 1:27 AM, Ben Gamari <ben at well-typed.com> wrote:

> Bryan and I discussed this in person but I'll repeat what I said there
> here:
>
> In short, there are two kinds of spam:
>
>  * user creation without the creation of any other content
>  * spam content (primarily projects and snippets)
>
> My sense is that the former has thusfar been harmless and consequently
> we shouldn't worry lose any sleep over it. On the other hand, spam
> content is quite problematic and we should strive to eliminate it.
> Once every few months I take a bit of time and do some cleaning (with
> some mechanical help [1]). It's also helpful when users use GitLab's
> "Report Abuse" feature to flag spam accounts as these cases are very
> easy to handle.
>
> Cheers,
>
> - Ben
>
>
> [1]
> https://gitlab.haskell.org/bgamari/ghc-utils/-/blob/master/gitlab-utils/gitlab_utils/spam_util.py
>
> _______________________________________________
> 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/20220517/3067d6d3/attachment.html>

From ben at well-typed.com  Tue May 17 16:08:09 2022
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 17 May 2022 12:08:09 -0400
Subject: gitlab spam
In-Reply-To: <CAKfdd-w1f31OLDD2FoDi+m+ygsT=tmNc=-t_Qh30OF8S-eNBzg@mail.gmail.com>
References: <I2z5d4VRZntKqJPcx_2168QkKnGSjpyojctV0lQD7SQJOm17-0balvn8JyLOq2uF3lPWFtXqj-GQz8A2L1HbTUUvW6ZW1QDl6YaC0BwyxUg=@chreekat.net>
 <87v8u58k59.fsf@smart-cactus.org>
 <CAKfdd-w1f31OLDD2FoDi+m+ygsT=tmNc=-t_Qh30OF8S-eNBzg@mail.gmail.com>
Message-ID: <87sfp887n1.fsf@smart-cactus.org>

Moritz Angermann <moritz.angermann at gmail.com> writes:

> The second one is an issue if it consumes CI Ressource. Ideally we’d have
> only “blessed” repos allowed to consume CI. The issue with this is that
> (random) new users can’t fork GHC and have CI run against their change.
>
> I’d still very much like to see a solution to this; it is a security
> concern.
>
I have never seen a spam user attempt to use our CI infrastructure.
While I believe we could in principle disable CI for new users now since
this feature request has (AFAICT) been implemented [1], I am a bit
reluctant to do so unless there is actual evidence of abuse.

Cheers,

- Ben


[1] https://gitlab.com/groups/gitlab-org/-/epics/3278
-------------- 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/20220517/2542c2ff/attachment.sig>

From b at chreekat.net  Wed May 18 10:25:57 2022
From: b at chreekat.net (Bryan)
Date: Wed, 18 May 2022 10:25:57 +0000
Subject: Tracking intermittently failing CI jobs
Message-ID: <czzKVKXJAL4F1htJPSgwSH5ISqY8AtP8bFDHwoyYEwJx5k5AYviwVUE7uzymbikuf4w03da1wAHG6O0MS6EXqCt9GQtWeKR4If4hD8WhmxY=@chreekat.net>

Hi all,

I'd like to get some data on weird CI failures. Before clicking "retry" on a spurious failure, please paste the url for your job into the spreadsheet you'll find linked at https://gitlab.haskell.org/ghc/ghc/-/issues/21591.

Sorry for the slight misdirection. I wanted the spreadsheet to be world-writable, which means I don't want its url floating around in too many places. Maybe you can bookmark it if CI is causing you too much trouble. :)

-Bryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220518/4b341ff4/attachment.html>

From cheng.shao at tweag.io  Fri May 20 11:43:24 2022
From: cheng.shao at tweag.io (Cheng Shao)
Date: Fri, 20 May 2022 13:43:24 +0200
Subject: What to do with gmp wasm fixes
Message-ID: <CALHrtFk84w2nxu=MHoK42oZKxK-29aug2hVQxevox4kzR0eZxg@mail.gmail.com>

Hi all,

The ghc wasm32-wasi build needs to patch gmp. Currently, our working
branch uses a fork of gmp-tarballs that includes the patch into the
tarball, but at some point we need to upstream it. What's the best way
to add these fixes?

- Send a PR to gmp-tarballs, including our patch (doesn't alter
behavior on native archs) and the updated tarball build script
- Don't touch gmp-tarballs, use "system" gmp, so the wasm32-wasi gmp
build process is decoupled from ghc build
- Give up gmp completely, only support native bignum for wasm32.

Cheers.
Cheng

From matthewtpickering at gmail.com  Mon May 23 09:33:21 2022
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Mon, 23 May 2022 10:33:21 +0100
Subject: Release Status - 9.4.1-alpha2/9.2.3/9.0.* series
Message-ID: <CALuQ0m-9JfY87RPnka+rNC27xZ1Xj6hs=y5LEGoD4Lmmd9yt3g@mail.gmail.com>

Hi all,

I will shortly prepare a blog post which describes the situation in
more detail for a general audience but for the subscribers here is a
summary of the release status.

9.4.1-alpha2: The release is imminent, and fixes a number of packaging
issues identified with alpha1. Slightly delayed due to regression
involving deb9 toolchains. (Ben)

9.2.3: The release will follow shortly (within 1 week) after the
9.4.1-alpha2 release. Slightly delayed due to 9.4.1-alpha2 delay. (Zubin)

9.4.1: The target for the final release is end of July.

9.0.* series: We do not intend to do any more releases in the 9.0.* series.
 - The 9.2 series is more stable
 - The 9.2 series does not contain significant breakage (when
upgrading from 9.0)
 - Anecdotal evidence suggests users are upgrading straight from 8.10.7 to 9.2.2
 - We do not have capacity to manage 4 active branches.

Any thoughts, please reply promptly before I communicate these facts
with the community.

Best Wishes,

Matt

From sylvain at haskus.fr  Mon May 23 09:34:07 2022
From: sylvain at haskus.fr (Sylvain Henry)
Date: Mon, 23 May 2022 11:34:07 +0200
Subject: What to do with gmp wasm fixes
In-Reply-To: <CALHrtFk84w2nxu=MHoK42oZKxK-29aug2hVQxevox4kzR0eZxg@mail.gmail.com>
References: <CALHrtFk84w2nxu=MHoK42oZKxK-29aug2hVQxevox4kzR0eZxg@mail.gmail.com>
Message-ID: <9fa19ff4-12eb-fcd6-d474-4cdf4460482c@haskus.fr>

Hi Cheng,

Couldn't the changes be upstreamed into libgmp directly? Other projects 
may benefit from being able to compile libgmp into wasm. Or are the 
changes specific to GHC?

 > - Send a PR to gmp-tarballs, including our patch (doesn't alter 
behavior on native archs) and the updated tarball build script

I'm not sure if it's still the case, but in the past we applied some 
patches to gmp before building it (to use fPIC and to remove the docs). 
So it should be possible to do it for wasm.

 > - Give up gmp completely, only support native bignum for wasm32.

That's the solution we will use for the JS backend. For wasm, it would 
be great to compare performance between both native and gmp ghc-bignum 
backends. libgmp uses some asm code when it is directly compiled to 
x86-64 asm for example and afaict passing through wasm will make it use 
less optimized codes. It may make the gmp backend less relevant: only 
benchmarks will tell. I would ensure that everything works with 
ghc-bignum's native backend before worrying about using gmp.

Cheers,
Sylvain


On 20/05/2022 13:43, Cheng Shao wrote:
> Hi all,
>
> The ghc wasm32-wasi build needs to patch gmp. Currently, our working
> branch uses a fork of gmp-tarballs that includes the patch into the
> tarball, but at some point we need to upstream it. What's the best way
> to add these fixes?
>
> - Send a PR to gmp-tarballs, including our patch (doesn't alter
> behavior on native archs) and the updated tarball build script
> - Don't touch gmp-tarballs, use "system" gmp, so the wasm32-wasi gmp
> build process is decoupled from ghc build
> - Give up gmp completely, only support native bignum for wasm32.
>
> Cheers.
> Cheng
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From cheng.shao at tweag.io  Mon May 23 11:31:04 2022
From: cheng.shao at tweag.io (Cheng Shao)
Date: Mon, 23 May 2022 13:31:04 +0200
Subject: What to do with gmp wasm fixes
In-Reply-To: <9fa19ff4-12eb-fcd6-d474-4cdf4460482c@haskus.fr>
References: <CALHrtFk84w2nxu=MHoK42oZKxK-29aug2hVQxevox4kzR0eZxg@mail.gmail.com>
 <9fa19ff4-12eb-fcd6-d474-4cdf4460482c@haskus.fr>
Message-ID: <CALHrtFmXxRqz=5yTF5aVRwmYqMP0i2P7D-xObL2PY3YKHYZzcw@mail.gmail.com>

Hi Sylvain,

> Couldn't the changes be upstreamed into libgmp directly?

GMP is a very old project with long release cycles, last release dates
back to 2020. So there's no guarantee a GMP release will be ready by
the time 9.6 branch is cut. Even if the patch is upstreamed, there's
no proper CI to avoid wasm breakage.

> Or are the changes specific to GHC?

Not really. It's due to the timing & future-proof issue above, so even
if we do send patch to gmp, we need to prepare for situation as if we
still need to do patching in our build.

> I'm not sure if it's still the case, but in the past we applied some
> patches to gmp before building it (to use fPIC and to remove the docs).
> So it should be possible to do it for wasm.

We still patch gmp tarball to remove the docs. Yes, as long as GHC HQ
doesn't push back the idea of including a patch for wasm, I'll send a
PR to gmp-tarballs.

> I would ensure that everything works with
> ghc-bignum's native backend before worrying about using gmp.

Both gmp/native already works for wasm32. As long as we figure out the
plan to include gmp patches, we intend to provide both gmp/native
bindists. As for benchmarking, may be worthwhile at some point, but we
got tons of other stuff on our plate right now.

On Mon, May 23, 2022 at 11:36 AM Sylvain Henry <sylvain at haskus.fr> wrote:
>
> Hi Cheng,
>
> Couldn't the changes be upstreamed into libgmp directly? Other projects
> may benefit from being able to compile libgmp into wasm. Or are the
> changes specific to GHC?
>
>  > - Send a PR to gmp-tarballs, including our patch (doesn't alter
> behavior on native archs) and the updated tarball build script
>
> I'm not sure if it's still the case, but in the past we applied some
> patches to gmp before building it (to use fPIC and to remove the docs).
> So it should be possible to do it for wasm.
>
>  > - Give up gmp completely, only support native bignum for wasm32.
>
> That's the solution we will use for the JS backend. For wasm, it would
> be great to compare performance between both native and gmp ghc-bignum
> backends. libgmp uses some asm code when it is directly compiled to
> x86-64 asm for example and afaict passing through wasm will make it use
> less optimized codes. It may make the gmp backend less relevant: only
> benchmarks will tell. I would ensure that everything works with
> ghc-bignum's native backend before worrying about using gmp.
>
> Cheers,
> Sylvain
>
>
> On 20/05/2022 13:43, Cheng Shao wrote:
> > Hi all,
> >
> > The ghc wasm32-wasi build needs to patch gmp. Currently, our working
> > branch uses a fork of gmp-tarballs that includes the patch into the
> > tarball, but at some point we need to upstream it. What's the best way
> > to add these fixes?
> >
> > - Send a PR to gmp-tarballs, including our patch (doesn't alter
> > behavior on native archs) and the updated tarball build script
> > - Don't touch gmp-tarballs, use "system" gmp, so the wasm32-wasi gmp
> > build process is decoupled from ghc build
> > - Give up gmp completely, only support native bignum for wasm32.
> >
> > Cheers.
> > Cheng
> > _______________________________________________
> > 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

From nr at cs.tufts.edu  Mon May 23 16:45:51 2022
From: nr at cs.tufts.edu (Norman Ramsey)
Date: Mon, 23 May 2022 12:45:51 -0400
Subject: best way to detect invalid Haddock early?
Message-ID: <20220523164551.54E722C270B@homedog.cs.tufts.edu>

I've had some CI failures because of invalid Haddock comments.  What
is the best way to detect such issues locally, early?  I tried setting
environment variable GHC_FLAGS to "-Winvalid-haddock", which should
have told `./hadrian/ghci` to issue a warning.  But for some reason,
no warning was issued.

What's a good way to detect invalid Haddock before it hits CI?


Norman


From matthewtpickering at gmail.com  Mon May 23 18:13:09 2022
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Mon, 23 May 2022 19:13:09 +0100
Subject: Release Status - 9.4.1-alpha2/9.2.3/9.0.* series
In-Reply-To: <CALuQ0m-9JfY87RPnka+rNC27xZ1Xj6hs=y5LEGoD4Lmmd9yt3g@mail.gmail.com>
References: <CALuQ0m-9JfY87RPnka+rNC27xZ1Xj6hs=y5LEGoD4Lmmd9yt3g@mail.gmail.com>
Message-ID: <CALuQ0m85zvyxjVDoJ88rSHo2do0F3o6PRGhT2o8u+YG+Kafa+g@mail.gmail.com>

Blog post: https://www.haskell.org/ghc/blog/20220523-release-status.html

On Mon, May 23, 2022 at 10:33 AM Matthew Pickering
<matthewtpickering at gmail.com> wrote:
>
> Hi all,
>
> I will shortly prepare a blog post which describes the situation in
> more detail for a general audience but for the subscribers here is a
> summary of the release status.
>
> 9.4.1-alpha2: The release is imminent, and fixes a number of packaging
> issues identified with alpha1. Slightly delayed due to regression
> involving deb9 toolchains. (Ben)
>
> 9.2.3: The release will follow shortly (within 1 week) after the
> 9.4.1-alpha2 release. Slightly delayed due to 9.4.1-alpha2 delay. (Zubin)
>
> 9.4.1: The target for the final release is end of July.
>
> 9.0.* series: We do not intend to do any more releases in the 9.0.* series.
>  - The 9.2 series is more stable
>  - The 9.2 series does not contain significant breakage (when
> upgrading from 9.0)
>  - Anecdotal evidence suggests users are upgrading straight from 8.10.7 to 9.2.2
>  - We do not have capacity to manage 4 active branches.
>
> Any thoughts, please reply promptly before I communicate these facts
> with the community.
>
> Best Wishes,
>
> Matt

From alan.zimm at gmail.com  Mon May 23 19:05:05 2022
From: alan.zimm at gmail.com (Alan & Kim Zimmerman)
Date: Mon, 23 May 2022 20:05:05 +0100
Subject: Release Status - 9.4.1-alpha2/9.2.3/9.0.* series
In-Reply-To: <CALuQ0m85zvyxjVDoJ88rSHo2do0F3o6PRGhT2o8u+YG+Kafa+g@mail.gmail.com>
References: <CALuQ0m-9JfY87RPnka+rNC27xZ1Xj6hs=y5LEGoD4Lmmd9yt3g@mail.gmail.com>
 <CALuQ0m85zvyxjVDoJ88rSHo2do0F3o6PRGhT2o8u+YG+Kafa+g@mail.gmail.com>
Message-ID: <CANma=H_TEqAQO26uVoXcegjef0qkKHy7+DgQxeAnfXpKfrUZLg@mail.gmail.com>

For the record, I have three exact print annotations commits that I would
like to backport to 9.4.  I am doing my final checks at the moment, will
make an official request for them soon.

On Mon, 23 May 2022 at 19:13, Matthew Pickering <matthewtpickering at gmail.com>
wrote:

> Blog post: https://www.haskell.org/ghc/blog/20220523-release-status.html
>
> On Mon, May 23, 2022 at 10:33 AM Matthew Pickering
> <matthewtpickering at gmail.com> wrote:
> >
> > Hi all,
> >
> > I will shortly prepare a blog post which describes the situation in
> > more detail for a general audience but for the subscribers here is a
> > summary of the release status.
> >
> > 9.4.1-alpha2: The release is imminent, and fixes a number of packaging
> > issues identified with alpha1. Slightly delayed due to regression
> > involving deb9 toolchains. (Ben)
> >
> > 9.2.3: The release will follow shortly (within 1 week) after the
> > 9.4.1-alpha2 release. Slightly delayed due to 9.4.1-alpha2 delay. (Zubin)
> >
> > 9.4.1: The target for the final release is end of July.
> >
> > 9.0.* series: We do not intend to do any more releases in the 9.0.*
> series.
> >  - The 9.2 series is more stable
> >  - The 9.2 series does not contain significant breakage (when
> > upgrading from 9.0)
> >  - Anecdotal evidence suggests users are upgrading straight from 8.10.7
> to 9.2.2
> >  - We do not have capacity to manage 4 active branches.
> >
> > Any thoughts, please reply promptly before I communicate these facts
> > with the community.
> >
> > Best Wishes,
> >
> > Matt
> _______________________________________________
> 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/20220523/6e1ecd74/attachment.html>

From hecate at glitchbra.in  Tue May 24 07:02:26 2022
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Tue, 24 May 2022 09:02:26 +0200
Subject: Release Status - 9.4.1-alpha2/9.2.3/9.0.* series
In-Reply-To: <CALuQ0m85zvyxjVDoJ88rSHo2do0F3o6PRGhT2o8u+YG+Kafa+g@mail.gmail.com>
References: <CALuQ0m-9JfY87RPnka+rNC27xZ1Xj6hs=y5LEGoD4Lmmd9yt3g@mail.gmail.com>
 <CALuQ0m85zvyxjVDoJ88rSHo2do0F3o6PRGhT2o8u+YG+Kafa+g@mail.gmail.com>
Message-ID: <6116e946-4f27-e60a-5cf9-40198abbd9ac@glitchbra.in>

Awesome, thank you very much Matthew. :)

Le 23/05/2022 à 20:13, Matthew Pickering a écrit :
> Blog post: https://www.haskell.org/ghc/blog/20220523-release-status.html
>
> On Mon, May 23, 2022 at 10:33 AM Matthew Pickering
> <matthewtpickering at gmail.com> wrote:
>> Hi all,
>>
>> I will shortly prepare a blog post which describes the situation in
>> more detail for a general audience but for the subscribers here is a
>> summary of the release status.
>>
>> 9.4.1-alpha2: The release is imminent, and fixes a number of packaging
>> issues identified with alpha1. Slightly delayed due to regression
>> involving deb9 toolchains. (Ben)
>>
>> 9.2.3: The release will follow shortly (within 1 week) after the
>> 9.4.1-alpha2 release. Slightly delayed due to 9.4.1-alpha2 delay. (Zubin)
>>
>> 9.4.1: The target for the final release is end of July.
>>
>> 9.0.* series: We do not intend to do any more releases in the 9.0.* series.
>>   - The 9.2 series is more stable
>>   - The 9.2 series does not contain significant breakage (when
>> upgrading from 9.0)
>>   - Anecdotal evidence suggests users are upgrading straight from 8.10.7 to 9.2.2
>>   - We do not have capacity to manage 4 active branches.
>>
>> Any thoughts, please reply promptly before I communicate these facts
>> with the community.
>>
>> Best Wishes,
>>
>> Matt
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD


From ben at well-typed.com  Tue May 24 13:22:16 2022
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 24 May 2022 09:22:16 -0400
Subject: What to do with gmp wasm fixes
In-Reply-To: <CALHrtFk84w2nxu=MHoK42oZKxK-29aug2hVQxevox4kzR0eZxg@mail.gmail.com>
References: <CALHrtFk84w2nxu=MHoK42oZKxK-29aug2hVQxevox4kzR0eZxg@mail.gmail.com>
Message-ID: <874k1f83rm.fsf@smart-cactus.org>

Cheng Shao <cheng.shao at tweag.io> writes:

> Hi all,
>
> The ghc wasm32-wasi build needs to patch gmp. Currently, our working
> branch uses a fork of gmp-tarballs that includes the patch into the
> tarball, but at some point we need to upstream it. What's the best way
> to add these fixes?
>
> - Send a PR to gmp-tarballs, including our patch (doesn't alter
> behavior on native archs) and the updated tarball build script
> - Don't touch gmp-tarballs, use "system" gmp, so the wasm32-wasi gmp
> build process is decoupled from ghc build
> - Give up gmp completely, only support native bignum for wasm32.
>
I think it would be reasonable to include your patch in `gmp-tarballs`;
please do open an MR. However I do also think we should make an attempt
to upstream it so that eventually we can drop the patch locally.

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/20220524/843e1560/attachment.sig>

From ben at well-typed.com  Tue May 24 16:44:53 2022
From: ben at well-typed.com (Ben Gamari)
Date: Tue, 24 May 2022 12:44:53 -0400
Subject: GHC 9.4.1-alpha2 now available
Message-ID: <8735gy98yb.fsf@smart-cactus.org>

The GHC developers are happy to announce the availability of the second
alpha release of the GHC 9.4 series. Binary distributions, source
distributions, and documentation are available at downloads.haskell.org:

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

This major release will include:

 - A new profiling mode, `-fprof-late`, which adds automatic cost-center
   annotations to all top-level functions *after* Core optimisation has
   run. This incurs significantly less performance cost while still
   providing informative profiles.

 - A variety of plugin improvements including the introduction of a new
   plugin type, *defaulting plugins*, and the ability for typechecking
   plugins to rewrite type-families.

 - An improved constructed product result analysis, allowing unboxing of
   nested structures, and a new boxity analysis, leading to less reboxing.

 - Introduction of a tag-check elision optimisation, bringing
   significant performance improvements in strict programs.

 - Generalisation of a variety of primitive types to be levity
   polymorphic. Consequently, the `ArrayArray#` type can at long last be
   retired, replaced by standard `Array#`.

 - Introduction of the `\cases` syntax from [GHC proposal 0302]

 - A complete overhaul of GHC's Windows support. This includes a
   migration to a fully Clang-based C toolchain, a deep refactoring of
   the linker, and many fixes in WinIO.

 - Support for multiple home packages, significantly improving support
   in IDEs and other tools for multi-package projects.

 - A refactoring of GHC's error message infrastructure, allowing GHC to
   provide diagnostic information to downstream consumers as structured
   data, greatly easing IDE support.

 - Significant compile-time improvements to runtime and memory consumption.

 - On overhaul of our packaging infrastructure, allowing full
   traceability of release artifacts and more reliable binary
   distributions.

 - ... and much more. See the [release notes] for a full accounting.

Note that, as 9.4.1 is the first release for which the released
artifacts will all be generated by Hadrian, it's possible that there
will be packaging issues. If you enounter trouble while using a binary
distribution, please open a [ticket]. Likewise, if you are a downstream
packager, do consider migrating to [Hadrian] to run your build; the
Hadrian build system can be built using `cabal-install`, `stack`, or the
in-tree [bootstrap script].

We would like to thank Microsoft Azure, GitHub, IOHK, the Zw3rk
stake pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
contributors whose on-going financial and in-kind support has
facilitated GHC maintenance and release management over the years.
Finally, this release would not have been possible without the hundreds
of open-source contributors whose work comprise this release.

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

Happy testing,

- Ben


[GHC proposal 0302]: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0302-cases.rst 
[ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
[bootstrap script]: https://gitlab.haskell.org/ghc/ghc/-/blob/e2520df3fffa0cf22fb19c5fb872832d11c07d35/hadrian/bootstrap/README.md
[release notes]: https://downloads.haskell.org/~ghc/9.4.1-alpha2/docs/users_guide/9.4.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/20220524/03a9e235/attachment.sig>

From shayne.fletcher.50 at gmail.com  Tue May 24 21:34:09 2022
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Tue, 24 May 2022 17:34:09 -0400
Subject: 9.4 branch build failure on ByteString/Internal.hs
Message-ID: <CAMsAzy8nvx=yFggqfDhHd_Xz6dfkD2qwErXCWZF03D2+CrnZWw@mail.gmail.com>

i've found for the last couple of weeks, the 9.4 branch fails to build with
the following error. is this known? a fix in the works?
```
libraries/bytestring/Data/ByteString/Internal.hs:292:23: error:
    • Couldn't match type ‘m’ with ‘TH.Q’
      ‘m’ is a rigid type variable bound by
        the type signature for:
          TH.lift :: forall (m :: * -> *).
                     TH.Quote m =>
                     ByteString -> m TH.Exp
        at libraries/bytestring/Data/ByteString/Internal.hs:292:3-6
      Expected type: m TH.Exp
        Actual type: TH.Q TH.Exp
    • In the expression:
        [| unsafePackLenLiteral |]
          `TH.appE` TH.litE (TH.integerL (fromIntegral len))
          `TH.appE`
            TH.litE (TH.BytesPrimL $ TH.Bytes ptr 0 (fromIntegral len))
      In an equation for ‘TH.lift’:
          TH.lift (BS ptr len)
            = [| unsafePackLenLiteral |]
                `TH.appE` TH.litE (TH.integerL (fromIntegral len))
                `TH.appE`
                  TH.litE (TH.BytesPrimL $ TH.Bytes ptr 0 (fromIntegral
len))
      In the instance declaration for ‘TH.Lift ByteString’
    • Relevant bindings include
        lift :: ByteString -> m TH.Exp
          (bound at libraries/bytestring/Data/ByteString/Internal.hs:292:3)
    |
292 |   lift (BS ptr len) = [| unsafePackLenLiteral |]
    |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^...
```

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

From shayne.fletcher.50 at gmail.com  Tue May 24 21:49:41 2022
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Tue, 24 May 2022 17:49:41 -0400
Subject: 9.4 branch build failure on ByteString/Internal.hs
In-Reply-To: <CAMsAzy8nvx=yFggqfDhHd_Xz6dfkD2qwErXCWZF03D2+CrnZWw@mail.gmail.com>
References: <CAMsAzy8nvx=yFggqfDhHd_Xz6dfkD2qwErXCWZF03D2+CrnZWw@mail.gmail.com>
Message-ID: <CAMsAzy9J+oMaPiM+VRwBEOEdtKbRyAWpnKOvcaaKFb4NXr7MKQ@mail.gmail.com>

never mind. i see that's it's been discussed and there's a ticket
https://gitlab.haskell.org/ghc/ghc/-/issues/21633 and a related MR
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8332.

On Tue, May 24, 2022 at 5:34 PM Shayne Fletcher <
shayne.fletcher.50 at gmail.com> wrote:

> i've found for the last couple of weeks, the 9.4 branch fails to build
> with the following error. is this known? a fix in the works?
> ```
> libraries/bytestring/Data/ByteString/Internal.hs:292:23: error:
>     • Couldn't match type ‘m’ with ‘TH.Q’
>       ‘m’ is a rigid type variable bound by
>         the type signature for:
>           TH.lift :: forall (m :: * -> *).
>                      TH.Quote m =>
>                      ByteString -> m TH.Exp
>         at libraries/bytestring/Data/ByteString/Internal.hs:292:3-6
>       Expected type: m TH.Exp
>         Actual type: TH.Q TH.Exp
>     • In the expression:
>         [| unsafePackLenLiteral |]
>           `TH.appE` TH.litE (TH.integerL (fromIntegral len))
>           `TH.appE`
>             TH.litE (TH.BytesPrimL $ TH.Bytes ptr 0 (fromIntegral len))
>       In an equation for ‘TH.lift’:
>           TH.lift (BS ptr len)
>             = [| unsafePackLenLiteral |]
>                 `TH.appE` TH.litE (TH.integerL (fromIntegral len))
>                 `TH.appE`
>                   TH.litE (TH.BytesPrimL $ TH.Bytes ptr 0 (fromIntegral
> len))
>       In the instance declaration for ‘TH.Lift ByteString’
>     • Relevant bindings include
>         lift :: ByteString -> m TH.Exp
>           (bound at libraries/bytestring/Data/ByteString/Internal.hs:292:3)
>     |
> 292 |   lift (BS ptr len) = [| unsafePackLenLiteral |]
>     |                       ^^^^^^^^^^^^^^^^^^^^^^^^^^...
> ```
>
> --
> Shayne Fletcher
>


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

From simon.peytonjones at gmail.com  Thu May 26 08:39:09 2022
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 26 May 2022 09:39:09 +0100
Subject: Type vs Constraint
Message-ID: <CAJKmMz-CpkrRCfU81rXwXnsC8juxMB7F7Xu-wRTjx4Yb4YEZhQ@mail.gmail.com>

Dear GHC devs and core libraries committee

Can I draw your attention to

https://gitlab.haskell.org/ghc/ghc/-/issues/21623

This ticket makes specific proposals for how to move forward on the
long-standing, and increasingly painful issue of *whether or not Constraint
and Type are equal in GHC's type system*.

We'd love to know what you think.  Please respond on the ticket.  The
changes affect only GHC internals, so we aren't planning a GHC proposal,
but the ticket is essentially a full proposal anyway.  It affects only GHC
internals, but there are some users who rely on GHC internals, which is why
we are seeking your opinions.

Thanks

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

From hecate at glitchbra.in  Thu May 26 14:39:18 2022
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Thu, 26 May 2022 16:39:18 +0200
Subject: Haddock needs help
Message-ID: <c0a4cd28-3f4f-c7c1-af95-9ad7d35e2f23@glitchbra.in>

Hi everyone,

Haddock needs help.

Since I joined the Haddock team to help triage the tickets and interact 
with the community, we lost all of our experts, and I didn't have time 
to level up quickly enough to handle the mass of incoming tickets, let 
alone actually reduce the number of tickets to number below two hundred.

As things stand now, the Haddock code base is in a disastrous state, 
largely not understood and its CI is in shambles.
There are things that we can improve on the short and longer term – see 
https://github.com/haskell/haddock/issues/1465 – but the greater lack of 
expertise means that any project involving some core business logic is 
bound to be utterly and unnecessarily painful. The Hi Haddock GSOC 
proposal, whilst fully implemented in GHC, cannot be brought in Haddock 
at this moment in a reasonable timeline without any help.

At present time, I need:

* People who can refactor the code base, following modern software 
engineering practices, like domain-driven design and test-driven 
development.
* UI developers, proficient in CSS and web accessibility.

If you feel like you fit some of these criteria, please do contact me at 
this address. If your company can spare some engineering hours for you 
to give a hand, you're most welcome to do so.

Just so we are clear, I am immensely grateful to the people who have 
submitted fixes and patches these past months, but this situation is 
untenable.

Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD


From mikolaj at well-typed.com  Thu May 26 15:12:45 2022
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Thu, 26 May 2022 17:12:45 +0200
Subject: Haddock needs help
In-Reply-To: <c0a4cd28-3f4f-c7c1-af95-9ad7d35e2f23@glitchbra.in>
References: <c0a4cd28-3f4f-c7c1-af95-9ad7d35e2f23@glitchbra.in>
Message-ID: <CAHFo2upUUXEaWffGxZsL5=2FE6YtvsrQo9fhMYesRbLxjAKjXg@mail.gmail.com>

Talking as a Haskell user, but also a cabal maintainer:
the Haddock work Hécate describes is crucial for the health
and efficiency of the whole ecosystem and the sooner
we can start it, the less drag it's going to have on the rest.

Given that GHC expertise is not necessary for many
of the tasks involved, could we forward this message
to other media? I don't think there is shame in disclosing
technical debt (as opposed to hiding it) and I think the way
it's worded, it may be viewed as a challenge, not a turn-off.
Still, are there any suggestions on how to tweak the text
before an announcement on discourse, reddit, etc.?
Would, e.g., HF, like to chime in early in each of the ensuing
discussions? If so, how would we know where it gets posted to?

Cheers,
Mikolaj

On Thu, May 26, 2022 at 4:39 PM Hécate <hecate at glitchbra.in> wrote:
>
> Hi everyone,
>
> Haddock needs help.
>
> Since I joined the Haddock team to help triage the tickets and interact
> with the community, we lost all of our experts, and I didn't have time
> to level up quickly enough to handle the mass of incoming tickets, let
> alone actually reduce the number of tickets to number below two hundred.
>
> As things stand now, the Haddock code base is in a disastrous state,
> largely not understood and its CI is in shambles.
> There are things that we can improve on the short and longer term – see
> https://github.com/haskell/haddock/issues/1465 – but the greater lack of
> expertise means that any project involving some core business logic is
> bound to be utterly and unnecessarily painful. The Hi Haddock GSOC
> proposal, whilst fully implemented in GHC, cannot be brought in Haddock
> at this moment in a reasonable timeline without any help.
>
> At present time, I need:
>
> * People who can refactor the code base, following modern software
> engineering practices, like domain-driven design and test-driven
> development.
> * UI developers, proficient in CSS and web accessibility.
>
> If you feel like you fit some of these criteria, please do contact me at
> this address. If your company can spare some engineering hours for you
> to give a hand, you're most welcome to do so.
>
> Just so we are clear, I am immensely grateful to the people who have
> submitted fixes and patches these past months, but this situation is
> untenable.
>
> Hécate ✨
> 🐦: @TechnoEmpress
> IRC: Hecate
> WWW: https://glitchbra.in
> RUN: BSD
>
> _______________________________________________
> 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  Fri May 27 17:01:16 2022
From: ben at well-typed.com (Ben Gamari)
Date: Fri, 27 May 2022 13:01:16 -0400
Subject: GHC.X.Hackage and GHC's release cycle
Message-ID: <87v8tq7vwz.fsf@smart-cactus.org>


Hello all,

Recently in the Haskell Foundation's stability working group we have been
discussing various practical issues that Haskell users and prospective adopters
encounter around the ecosystem. During these discussions the topic of GHC's
release schedule and the ecosystem's process migration to new GHC releases has
come up repeatedly.

To address some of these issues, I have opened a pair of somewhat-related HF
Tech Proposals:

 * the GHC.X.Hackage proposal ([ghc.x.hackage]) seeks to extend the
   [head.hackage] infrastructure used to test GHC to enable use by
   library maintainers in porting and testing their libraries on new GHC
   releases.

 * the [tick-tock] release proposal seeks to provide better guidance to users
   needing long release lifecycles by designating every other release as a
   "long-term support" release, with 18-month backport window.

Given the wide applicability of these proposals we hope to gather feedback from
a broad swath of the community. If you have questions, opinions, or concerns on
either, please leave your feedback on the respective proposal. We look
forward to hearing from you.

Thanks!

 - Ben


[ghc.x.hackage]: https://github.com/haskellfoundation/tech-proposals/pull/27
[head.hackage]: https://ghc.gitlab.haskell.org/head.hackage/
[tick-tock]: https://github.com/haskellfoundation/tech-proposals/pull/34

-------------- 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/20220527/c7e39123/attachment.sig>

From zubin at well-typed.com  Fri May 27 19:31:48 2022
From: zubin at well-typed.com (Zubin Duggal)
Date: Sat, 28 May 2022 01:01:48 +0530
Subject: [Haskell] [ANNOUNCE] GHC 9.2.3 released
Message-ID: <20220527193148.xaj72eelctawugcm@zubin-msi>


The GHC developers are very happy to at announce the availability of GHC
9.2.3. Binary distributions, source distributions, and documentation are
available at [`downloads.haskell.org`](https://downloads.haskell.org/ghc/9.2.3).

Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html
Blog Post: https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html

This release includes many bug-fixes and other improvements to 9.2.2 including:

  * A fix to a critical linking bug on Windows causing the 9.2.2 release
  to be unusable (#21196).

  * Numerous bug fixes for regressions and other issues in the
  typechecker (#2147, #21515, #20582, #20820, #21130, #21479).

  * Correctness bugs in the code generator and compiler backends (#21396,
  #20959, #21465).

  * Packaging fixes on many platforms (#20760, #21487, #21402).

  * Many others. See the [release notes][] for a full list.

As some of the fixed issues do affect correctness users are encouraged
to upgrade promptly.

We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake
pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
contributors whose on-going financial and in-kind support has
facilitated GHC maintenance and release management over the years.
Finally, this release would not have been possible without the hundreds
of open-source contributors whose work comprise this release.

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

Happy compiling,

- Zubin


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

From shayne.fletcher.50 at gmail.com  Fri May 27 20:25:14 2022
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Fri, 27 May 2022 16:25:14 -0400
Subject: [Haskell] [ANNOUNCE] GHC 9.2.3 released
In-Reply-To: <20220527193148.xaj72eelctawugcm@zubin-msi>
References: <20220527193148.xaj72eelctawugcm@zubin-msi>
Message-ID: <CAMsAzy-OHivbsfMX0xD3U7wbg2NQ4omLAXsUK_iAs7OD8hHQsg@mail.gmail.com>

There is no ghc-9.2.3-release tag. Can it be created and pushed please?

On Fri, May 27, 2022 at 3:39 PM Zubin Duggal <zubin at well-typed.com> wrote:

>
> The GHC developers are very happy to at announce the availability of GHC
> 9.2.3. Binary distributions, source distributions, and documentation are
> available at [`downloads.haskell.org`](
> https://downloads.haskell.org/ghc/9.2.3).
>
> Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html
> Blog Post:
> https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html
>
> This release includes many bug-fixes and other improvements to 9.2.2
> including:
>
>   * A fix to a critical linking bug on Windows causing the 9.2.2 release
>   to be unusable (#21196).
>
>   * Numerous bug fixes for regressions and other issues in the
>   typechecker (#2147, #21515, #20582, #20820, #21130, #21479).
>
>   * Correctness bugs in the code generator and compiler backends (#21396,
>   #20959, #21465).
>
>   * Packaging fixes on many platforms (#20760, #21487, #21402).
>
>   * Many others. See the [release notes][] for a full list.
>
> As some of the fixed issues do affect correctness users are encouraged
> to upgrade promptly.
>
> We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake
> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
> contributors whose on-going financial and in-kind support has
> facilitated GHC maintenance and release management over the years.
> Finally, this release would not have been possible without the hundreds
> of open-source contributors whose work comprise this release.
>
> As always, do give this release a try and open a [ticket] if you see
> anything amiss.
>
> Happy compiling,
>
> - Zubin
>
>
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> [release notes]:
> https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.html
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


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

From george.colpitts at gmail.com  Fri May 27 23:07:10 2022
From: george.colpitts at gmail.com (George Colpitts)
Date: Fri, 27 May 2022 20:07:10 -0300
Subject: [Haskell] [ANNOUNCE] GHC 9.2.3 released
In-Reply-To: <20220527193148.xaj72eelctawugcm@zubin-msi>
References: <20220527193148.xaj72eelctawugcm@zubin-msi>
Message-ID: <CAB-d4A5QYcOJVeXKmj0EczzPYGz1-m3yokcxUmwCF9Y2+TS3yg@mail.gmail.com>

Hi

https://gitlab.haskell.org/ghc/ghc/-/issues/21506, ghc-9.4.1-alpha1 does
not install on macos, exists on 9.2.3 also. The workaround given in 21506
works. Do you want a ticket for this?

Thanks
George


On Fri, May 27, 2022 at 4:41 PM Zubin Duggal <zubin at well-typed.com> wrote:

>
> The GHC developers are very happy to at announce the availability of GHC
> 9.2.3. Binary distributions, source distributions, and documentation are
> available at [`downloads.haskell.org`](
> https://downloads.haskell.org/ghc/9.2.3).
>
> Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html
> Blog Post:
> https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html
>
> This release includes many bug-fixes and other improvements to 9.2.2
> including:
>
>   * A fix to a critical linking bug on Windows causing the 9.2.2 release
>   to be unusable (#21196).
>
>   * Numerous bug fixes for regressions and other issues in the
>   typechecker (#2147, #21515, #20582, #20820, #21130, #21479).
>
>   * Correctness bugs in the code generator and compiler backends (#21396,
>   #20959, #21465).
>
>   * Packaging fixes on many platforms (#20760, #21487, #21402).
>
>   * Many others. See the [release notes][] for a full list.
>
> As some of the fixed issues do affect correctness users are encouraged
> to upgrade promptly.
>
> We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake
> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
> contributors whose on-going financial and in-kind support has
> facilitated GHC maintenance and release management over the years.
> Finally, this release would not have been possible without the hundreds
> of open-source contributors whose work comprise this release.
>
> As always, do give this release a try and open a [ticket] if you see
> anything amiss.
>
> Happy compiling,
>
> - Zubin
>
>
> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
> [release notes]:
> https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.html
> _______________________________________________
> 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/20220527/cf84ef08/attachment.html>

From shayne.fletcher.50 at gmail.com  Fri May 27 23:24:32 2022
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Fri, 27 May 2022 19:24:32 -0400
Subject: [Haskell] [ANNOUNCE] GHC 9.2.3 released
In-Reply-To: <CAB-d4A5QYcOJVeXKmj0EczzPYGz1-m3yokcxUmwCF9Y2+TS3yg@mail.gmail.com>
References: <20220527193148.xaj72eelctawugcm@zubin-msi>
 <CAB-d4A5QYcOJVeXKmj0EczzPYGz1-m3yokcxUmwCF9Y2+TS3yg@mail.gmail.com>
Message-ID: <CAMsAzy_hw1pTQmtd6KzTPE+HbUDV=zVZ3++_X8OBXd3oXOUKtQ@mail.gmail.com>

there are already tickets covering this see
https://gitlab.haskell.org/ghc/ghc/-/issues/21633 &
    -- https://gitlab.haskell.org/ghc/ghc/-/issues/21634. i have found that
`allow-newer:true` and `resolver: nightly-2022-05-27` in
`hadrian/stack.yaml` provides a workaround for the moment.

On Fri, May 27, 2022 at 7:08 PM George Colpitts <george.colpitts at gmail.com>
wrote:

> Hi
>
> https://gitlab.haskell.org/ghc/ghc/-/issues/21506, ghc-9.4.1-alpha1 does
> not install on macos, exists on 9.2.3 also. The workaround given in 21506
> works. Do you want a ticket for this?
>
> Thanks
> George
>
>
> On Fri, May 27, 2022 at 4:41 PM Zubin Duggal <zubin at well-typed.com> wrote:
>
>>
>> The GHC developers are very happy to at announce the availability of GHC
>> 9.2.3. Binary distributions, source distributions, and documentation are
>> available at [`downloads.haskell.org`](
>> https://downloads.haskell.org/ghc/9.2.3).
>>
>> Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html
>> Blog Post:
>> https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html
>>
>> This release includes many bug-fixes and other improvements to 9.2.2
>> including:
>>
>>   * A fix to a critical linking bug on Windows causing the 9.2.2 release
>>   to be unusable (#21196).
>>
>>   * Numerous bug fixes for regressions and other issues in the
>>   typechecker (#2147, #21515, #20582, #20820, #21130, #21479).
>>
>>   * Correctness bugs in the code generator and compiler backends (#21396,
>>   #20959, #21465).
>>
>>   * Packaging fixes on many platforms (#20760, #21487, #21402).
>>
>>   * Many others. See the [release notes][] for a full list.
>>
>> As some of the fixed issues do affect correctness users are encouraged
>> to upgrade promptly.
>>
>> We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake
>> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
>> contributors whose on-going financial and in-kind support has
>> facilitated GHC maintenance and release management over the years.
>> Finally, this release would not have been possible without the hundreds
>> of open-source contributors whose work comprise this release.
>>
>> As always, do give this release a try and open a [ticket] if you see
>> anything amiss.
>>
>> Happy compiling,
>>
>> - Zubin
>>
>>
>> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
>> [release notes]:
>> https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.html
>> _______________________________________________
>> 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
>


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

From shayne.fletcher.50 at gmail.com  Fri May 27 23:25:11 2022
From: shayne.fletcher.50 at gmail.com (Shayne Fletcher)
Date: Fri, 27 May 2022 19:25:11 -0400
Subject: [Haskell] [ANNOUNCE] GHC 9.2.3 released
In-Reply-To: <CAMsAzy_hw1pTQmtd6KzTPE+HbUDV=zVZ3++_X8OBXd3oXOUKtQ@mail.gmail.com>
References: <20220527193148.xaj72eelctawugcm@zubin-msi>
 <CAB-d4A5QYcOJVeXKmj0EczzPYGz1-m3yokcxUmwCF9Y2+TS3yg@mail.gmail.com>
 <CAMsAzy_hw1pTQmtd6KzTPE+HbUDV=zVZ3++_X8OBXd3oXOUKtQ@mail.gmail.com>
Message-ID: <CAMsAzy_Xrm_enqv2iyLtAJky4J8Y+RBF_q4Y1RU0YHbSAbCL5g@mail.gmail.com>

oops, sorry, no my mistake. please disregard.

On Fri, May 27, 2022 at 7:24 PM Shayne Fletcher <
shayne.fletcher.50 at gmail.com> wrote:

> there are already tickets covering this see
> https://gitlab.haskell.org/ghc/ghc/-/issues/21633 &
>     -- https://gitlab.haskell.org/ghc/ghc/-/issues/21634. i have found
> that `allow-newer:true` and `resolver: nightly-2022-05-27` in
> `hadrian/stack.yaml` provides a workaround for the moment.
>
> On Fri, May 27, 2022 at 7:08 PM George Colpitts <george.colpitts at gmail.com>
> wrote:
>
>> Hi
>>
>> https://gitlab.haskell.org/ghc/ghc/-/issues/21506, ghc-9.4.1-alpha1 does
>> not install on macos, exists on 9.2.3 also. The workaround given in 21506
>> works. Do you want a ticket for this?
>>
>> Thanks
>> George
>>
>>
>> On Fri, May 27, 2022 at 4:41 PM Zubin Duggal <zubin at well-typed.com>
>> wrote:
>>
>>>
>>> The GHC developers are very happy to at announce the availability of GHC
>>> 9.2.3. Binary distributions, source distributions, and documentation are
>>> available at [`downloads.haskell.org`](
>>> https://downloads.haskell.org/ghc/9.2.3).
>>>
>>> Download Page: https://www.haskell.org/ghc/download_ghc_9_2_3.html
>>> Blog Post:
>>> https://www.haskell.org/ghc/blog/20220527-ghc-9.2.3-released.html
>>>
>>> This release includes many bug-fixes and other improvements to 9.2.2
>>> including:
>>>
>>>   * A fix to a critical linking bug on Windows causing the 9.2.2 release
>>>   to be unusable (#21196).
>>>
>>>   * Numerous bug fixes for regressions and other issues in the
>>>   typechecker (#2147, #21515, #20582, #20820, #21130, #21479).
>>>
>>>   * Correctness bugs in the code generator and compiler backends (#21396,
>>>   #20959, #21465).
>>>
>>>   * Packaging fixes on many platforms (#20760, #21487, #21402).
>>>
>>>   * Many others. See the [release notes][] for a full list.
>>>
>>> As some of the fixed issues do affect correctness users are encouraged
>>> to upgrade promptly.
>>>
>>> We would like to thank Microsoft Azure, GitHub, IOG, the Zw3rk stake
>>> pool, Tweag I/O, Serokell, Equinix, SimSpace, and other anonymous
>>> contributors whose on-going financial and in-kind support has
>>> facilitated GHC maintenance and release management over the years.
>>> Finally, this release would not have been possible without the hundreds
>>> of open-source contributors whose work comprise this release.
>>>
>>> As always, do give this release a try and open a [ticket] if you see
>>> anything amiss.
>>>
>>> Happy compiling,
>>>
>>> - Zubin
>>>
>>>
>>> [ticket]: https://gitlab.haskell.org/ghc/ghc/-/issues/new
>>> [release notes]:
>>> https://downloads.haskell.org/ghc/9.2.3/docs/html/users_guide/9.2.3-notes.html
>>> _______________________________________________
>>> 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
>>
>
>
> --
> Shayne Fletcher
>


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

From facundo.dominguez at tweag.io  Mon May 30 02:36:06 2022
From: facundo.dominguez at tweag.io (=?UTF-8?Q?Dom=C3=ADnguez=2C_Facundo?=)
Date: Sun, 29 May 2022 23:36:06 -0300
Subject: Implementing a compilation server
In-Reply-To: <CALuQ0m-XEcJu=xS8jTuKNHGS-SQ_057VU_fzYCc92OPD7XDfeg@mail.gmail.com>
References: <CAF7SUTSMPt5ozeqj5e_0JO6T1C9S2ycMN8JHVehGS2MGyg1R-w@mail.gmail.com>
 <CALuQ0m-XEcJu=xS8jTuKNHGS-SQ_057VU_fzYCc92OPD7XDfeg@mail.gmail.com>
Message-ID: <CAF7SUTQp=aapyw=W+MZH3-AQrvYT0Jb0431=seSM_DAFhrq6Kg@mail.gmail.com>

Thanks Matthew for your pointers.

Since originally posting, I managed to simplify the problem by terminating
the compilation server at the end of a build, which allows to introduce the
assumption that the code doesn't change during the lifetime of the server.

Now, I'm observing that sometimes different compilation requests place the
same package databases at different paths using the -package-db flags. From
the point of view of GHC, it is as if the package databases had been moved
from one location to another. In newer requests, GHC still looks for the
interface files at the old locations, and fails when it doesn't find them.

Another difference between requests is that, even for a same package
database, different interface files are present, depending on what the
module under compilation imports transitively. This is causing failures
sometimes but not always, I still need to pin exactly the circumstances.
The error manifests as an attempt to load a missing interface file that is
apparently not transitively needed.

If I understand correctly, all the packages pointed with -package-id and
-package-db end up in the EPS. And this means that we can't expect to
update the locations of the interface files without discarding and
repopulating the EPS, correct? I'm thinking of this as approximately as
costly as restarting the compilation server.

I can reasonably ensure that package databases aren't moved around between
compilation requests. But from the standpoint of the build system, it would
require some compromises to demand that all of the interface files of a
package be available even when not all of them are transitively imported.
Can we hope to have GHC cope with this dynamic membership of modules to
Haskell packages during the build? Is this an ability that 8.10.7 already
has?

Thanks,
Facundo

On Thu, May 5, 2022 at 5:13 AM Matthew Pickering <
matthewtpickering at gmail.com> wrote:

> Hi Facundo
>
> Some pointers...
>
> 1. Only put things in the EPS if they are not going to change
> throughout the whole compilation
> 2. Treat everything which can change as a home package
> 2a. I suppose you have performed your own dependency analysis, so
> build your own `ModGraph` and start looking from `load'`, you might
> just want to call `upsweep_mod/compileOne'` directly yourself.
> 2b. I suppose you are NOT targeting 9.4.1 yet, but that will make
> things easier as you can use support for multiple home packages,
> otherwise you will get into severe difficulties if you load a package
> you later want to compile into the EPS. The only thing you can do here
>       is restart the compilation session I think.
> 3. To my knowledge, there is no issue using different -this-unit-id in
> the same session. Not sure what errors you have seen.
> 4. You need to use --make mode rather than -c (oneshot) because
> oneshot mode loads all interfaces into the EPS (see point 1)
>
> ghcide is the closest program to this kind of compilation server you
> imagine so you can look at how that uses the GHC API.
>
> Cheers,
>
> Matt
>
>
> On Thu, May 5, 2022 at 1:06 AM Domínguez, Facundo
> <facundo.dominguez at tweag.io> wrote:
> >
> > Dear ghc devs,
> >
> > I'm using the ghc API to write a compilation server (a.k.a. persistent
> worker). The idea is to serve requests to compile individual modules. In
> this fashion, we can compile modules with different compilation flags and
> yet pay only once for the startup overheads of the compiler.
> >
> > One challenge of this approach is to reuse as much as possible from the
> ghc API session/environment from one compilation request to the next, so we
> save the trouble of reconstructing it each time. This message is to ask for
> advise on how to better accomplish this reuse.
> >
> > I tried reusing the whole environment for multiple requests, but I'm
> conjecturing that this might cause troubles when the requests require
> building modules with different values of -this-unit-id. Another problem
> that streams from this is that recompiling a module which defines a type
> class instance fails because it encounters in the environment the type
> class instance from the
> > previous compilation.
> >
> > My work-in-progress implementation is here [1]. There appears to be
> multiple ways to compile a module in the API, so far I have been trying
> DriverPipeline.compileFile.
> >
> > My best lead right now is to look for inspiration in how GHCi implements
> the load command, but this does a sort of --make compilation while I'm
> going here for the one-shot style.
> >
> > Thanks in advance,
> > Facundo
> >
> > [1]
> https://github.com/tweag/rules_haskell/blob/16ba422457ea4daa5dbf40d46327ebcb20588e97/tools/haskell_module_worker/src/Compile.hs#L188
> > _______________________________________________
> > 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/20220529/4c148dc9/attachment.html>

From matthewtpickering at gmail.com  Tue May 31 16:24:15 2022
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 31 May 2022 17:24:15 +0100
Subject: Deep Subsumption Proposal
Message-ID: <CALuQ0m_eqp4h0B0Yw5SEhsHFXJ5Gom-f-QgyVciGN0nnaEW-eg@mail.gmail.com>

Hi all,

I draw everyone's attention to the Deep Subsumption Proposal. The
proposal invites the community to comment on a technical solution to
the issues introduced by the simplified subsumption proposal.

https://github.com/ghc-proposals/ghc-proposals/pull/511

Cheers,

Matt