From krz.gogolewski at gmail.com  Thu Jun  1 09:28:03 2023
From: krz.gogolewski at gmail.com (Krzysztof Gogolewski)
Date: Thu, 1 Jun 2023 11:28:03 +0200
Subject: Trouble building GHC
In-Reply-To: <CAH3XM1mGN5cyBTPQmLh=R_2KeALhyb+9rgpjgADdPzd94sRPeg@mail.gmail.com>
References: <CAH3XM1mFDhGreqSbJhy+_3McjGeGC2u7crbZGYULoHMx1gvWsw@mail.gmail.com>
 <CAAS+=P8vjEgwjuBfQWmdSz-dC-5JL19xWudBfZ6_OktRqCbrZg@mail.gmail.com>
 <5b99bed9-7c03-f547-b941-abd308990ea8@gmail.com>
 <CAAS+=P8d4FFr-OLVjjD8xTuFJRcw9eCNaqxYY-rcBXSxvYMHrg@mail.gmail.com>
 <CAH3XM1mGN5cyBTPQmLh=R_2KeALhyb+9rgpjgADdPzd94sRPeg@mail.gmail.com>
Message-ID: <CA+h2LznsyL=eiXu9mr3idfsEUkOTcu_zX-yFu7wyNbXxecWkZw@mail.gmail.com>

Hi Lyle,

There was a temporary build issue, fetching newest master should fix it.

Krzysztof

On Thu, Jun 1, 2023 at 12:03 AM Lyle Kopnicky <lists at qseep.net> wrote:
>>
>> Thanks, Georgi and Sebastian.
>
>
> The instructions at https://github.com/alpmestan/ghc.nix and https://ghc.dev/ seem a bit outdated, then. I’m not sure who maintains those.
>
> In the README.md for ghc.nix, it says to run:
>
> nix-shell https://github.com/alpmestan/ghc.nix/archive/master.tar.gz --attr devShells.<your-system>.default
>
> That failed didn’t work for me and I was told I needed to use nix-develop, which worked.
>
> Then later, it says to run:
>
> $ ./boot && ./configure $CONFIGURE_ARGS # In zsh, use ${=CONFIGURE_ARGS}
>
> …which as you pointed out should be updated to configure_ghc.
>
> Anyway, that got me further, but I still get several fatal errors of this sort:
>
> compiler/GHC/Tc/Zonk/Type.hs:1277:13: error:
>     • Illegal equational constraint Anno
>                                       (StmtLR GhcTc GhcTc (LocatedA (body GhcTc)))
>                                     ~ SrcSpanAnnA
>       (Use GADTs or TypeFamilies to permit this)
>     • In the type signature:
>         zonkStmt :: Anno (StmtLR GhcTc GhcTc (LocatedA (body GhcTc)))
>                     ~ SrcSpanAnnA =>
>                     (LocatedA (body GhcTc) -> ZonkTcM (LocatedA (body GhcTc)))
>                     -> Stmt GhcTc (LocatedA (body GhcTc))
>                        -> ZonkBndrTcM (Stmt GhcTc (LocatedA (body GhcTc)))
>      |
> 1277 | zonkStmt :: Anno (StmtLR GhcTc GhcTc (LocatedA (body GhcTc))) ~ SrcSpanAnnA
>      |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
> Command failed
> Build failed.
>
>
> Georgi, I might just ping you on Slack about it. (We’re coworkers.)
>
> Thanks,
> Lyle
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From bryan at haskell.foundation  Thu Jun  1 15:11:38 2023
From: bryan at haskell.foundation (Bryan Richter)
Date: Thu, 1 Jun 2023 18:11:38 +0300
Subject: help migrating a tool that uses the ghc api
In-Reply-To: <874jo4kr18.fsf@gmail.com>
References: <87v8gpl59d.fsf@gmail.com>
 <CACK-K+2jW=4tx9BMDpZOD-CLmcUrDPh_yETy7nv1e4vfdFs+Fw@mail.gmail.com>
 <CAJKmMz-jo1mH+OtjwreFR4h2XEbxO8yWY+HVDn2JqK75W8bpiQ@mail.gmail.com>
 <87ilcoll5e.fsf@gmail.com> <874jo4kr18.fsf@gmail.com>
Message-ID: <CACUTo6wtYEYoEydzAxaEJXD4b9H9s_n3g3-gGGipfy=ixGX+cA@mail.gmail.com>

Hi Sam,

https://gitlab.haskell.org/ghc/ghc/-/wikis/building/running-tests/adding is
a well-written and well-hidden page that explains quite a lot about writing
a test. I'm not sure it's a good idea, though, to add a test to the GHC
test suite that enforces some guarantee that nobody signed up for in the
first place. To put it another way, the CLC proposal process should already
be providing the guarantees you're looking for, and figuring out how to
make that process meaningful and practical regarding GHC's internals is
already stressing the community's limits. I'd suggest to you that you make
a list of the functionality you actually consider "core" and get it into
the hands of the people working on that problem, and I'd suggest to *them*
that they put out a call for other such lists from users of the API.



On Tue, 23 May 2023 at 00:13, Sam Halliday <sam.halliday at gmail.com> wrote:

>
> Thanks to everybody who chimed in on this thread.
>
> I have now updated ghcflags / hsinspect to work with all versions of ghc
> from 8.8.3 through to 9.6.1. You can see the churn in various parts of
> the ghc api in the commit history
> https://gitlab.com/tseenshe/hsinspect/-/commits/develop ... if the
> authors of some refactors inside ghc were aware that some of these
> functions and data types were being used externally then perhaps they
> could have left functions in place that would have continued to work as
> before.
>
> I'd like to extract this one part from the thread, and ask if there
> would be any objections to me submitting a standalone test file to the
> ghc codebase:
>
> > tooling authors can submit test code (in the sense that it is compiled
> > as part of the ghc build) to ghc as documentation of their most
> > sensitive uses of the ghc APIs. It wouldn't be distributed and
> > therefore there is no risk to pollution of the ghc api.
>
> It will take me some time to do this so I don't want to do it without
> understanding if it would be accepted. I think it will pay for itself
> after about 2 or 3 major releases of ghc, but it mitigates against
> anybody removing core functionality that I'm making use of which is the
> most important thing.
>
> If that is ok, where should I start? I don't know how to add (or run) a
> test file to ghc that would simply test that the file compiles.
>
>
> Sam Halliday wrote:
> > Thanks Simon,
> >
> > Simon Peyton Jones wrote:
> >> What we need is
> >>    - An API for GHC that is *designed *and *actively curated*.
> >>    ...
> >
> > Some may believe that the API would need to be some huge reflection of
> > the internal API, with maximal reuse in mind. That is a mammoth task,
> > but an API could also end up being a lot of the code from tools pushed
> > further into the ghc codebase (although perhaps a very inefficient way
> > of doing it for everybody if it's going through committees).
> >
> > I propose an alternative: that tooling authors can submit test code (in
> > the sense that it is compiled as part of the ghc build) to ghc as
> > documentation of their most sensitive uses of the ghc APIs. It wouldn't
> > be distributed and therefore there is no risk to pollution of the ghc
> > api.
> >
> > Breaking changes would require fixing inside the ghc test codebase at
> > the point of the breaking change by the author of the change (who
> > presumably understands it the most!) and then when ghc is released, the
> > tooling author knows exactly what to do to fix their code without having
> > to involve the ghc developers any further, except to extend their
> > thanks.
> >
> > One of my biggest fears is that somebody just *removes* something from
> > the api entirely and I can't do what I need at all anymore. I don't
> > think that kind of problem can be addressed retrospectively.
> >
> >
> >> I know this isn't helping Sam much in the short term -- apologies for
> that.
> >
> > Bringing attention to it is helping, so thank you for that. My immediate
> > problem can probably be solved by some kind soul dedicating 30 mins of
> > their time to help push my code over the line. I'm more than happy to
> > barter my own time for something they'd like in return, or send a small
> > gift! :-)
> >
> >
> > --
> > Best regards,
> > Sam
>
> --
> Best regards,
> Sam
> _______________________________________________
> 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/20230601/e194d6be/attachment.html>

From lists at qseep.net  Sat Jun  3 17:17:46 2023
From: lists at qseep.net (Lyle Kopnicky)
Date: Sat, 3 Jun 2023 10:17:46 -0700
Subject: Trouble building GHC
In-Reply-To: <CA+h2LznsyL=eiXu9mr3idfsEUkOTcu_zX-yFu7wyNbXxecWkZw@mail.gmail.com>
References: <CAH3XM1mFDhGreqSbJhy+_3McjGeGC2u7crbZGYULoHMx1gvWsw@mail.gmail.com>
 <CAAS+=P8vjEgwjuBfQWmdSz-dC-5JL19xWudBfZ6_OktRqCbrZg@mail.gmail.com>
 <5b99bed9-7c03-f547-b941-abd308990ea8@gmail.com>
 <CAAS+=P8d4FFr-OLVjjD8xTuFJRcw9eCNaqxYY-rcBXSxvYMHrg@mail.gmail.com>
 <CAH3XM1mGN5cyBTPQmLh=R_2KeALhyb+9rgpjgADdPzd94sRPeg@mail.gmail.com>
 <CA+h2LznsyL=eiXu9mr3idfsEUkOTcu_zX-yFu7wyNbXxecWkZw@mail.gmail.com>
Message-ID: <CAH3XM1m9ZqiACuACP2V+mqqHt_Ku__e9p0aOB5+ZBe3m0-FJug@mail.gmail.com>

 Yes, that fixed it, thank you!

On Jun 1, 2023 at 2:28:03 AM, Krzysztof Gogolewski <krz.gogolewski at gmail.com>
wrote:

> Hi Lyle,
>
> There was a temporary build issue, fetching newest master should fix it.
>
> Krzysztof
>
> On Thu, Jun 1, 2023 at 12:03 AM Lyle Kopnicky <lists at qseep.net> wrote:
>
> >
>
> > Thanks, Georgi and Sebastian.
>
>
>
> The instructions at https://github.com/alpmestan/ghc.nix and
> https://ghc.dev/ seem a bit outdated, then. I’m not sure who maintains
> those.
>
>
> In the README.md for ghc.nix, it says to run:
>
>
> nix-shell https://github.com/alpmestan/ghc.nix/archive/master.tar.gz
> --attr devShells.<your-system>.default
>
>
> That failed didn’t work for me and I was told I needed to use nix-develop,
> which worked.
>
>
> Then later, it says to run:
>
>
> $ ./boot && ./configure $CONFIGURE_ARGS # In zsh, use ${=CONFIGURE_ARGS}
>
>
> …which as you pointed out should be updated to configure_ghc.
>
>
> Anyway, that got me further, but I still get several fatal errors of this
> sort:
>
>
> compiler/GHC/Tc/Zonk/Type.hs:1277:13: error:
>
>     • Illegal equational constraint Anno
>
>                                       (StmtLR GhcTc GhcTc (LocatedA (body
> GhcTc)))
>
>                                     ~ SrcSpanAnnA
>
>       (Use GADTs or TypeFamilies to permit this)
>
>     • In the type signature:
>
>         zonkStmt :: Anno (StmtLR GhcTc GhcTc (LocatedA (body GhcTc)))
>
>                     ~ SrcSpanAnnA =>
>
>                     (LocatedA (body GhcTc) -> ZonkTcM (LocatedA (body
> GhcTc)))
>
>                     -> Stmt GhcTc (LocatedA (body GhcTc))
>
>                        -> ZonkBndrTcM (Stmt GhcTc (LocatedA (body GhcTc)))
>
>      |
>
> 1277 | zonkStmt :: Anno (StmtLR GhcTc GhcTc (LocatedA (body GhcTc))) ~
> SrcSpanAnnA
>
>      |
>             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
>
> Command failed
>
> Build failed.
>
>
>
> Georgi, I might just ping you on Slack about it. (We’re coworkers.)
>
>
> Thanks,
>
> Lyle
>
> _______________________________________________
>
> 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/20230603/6d5727f8/attachment.html>

From lists at qseep.net  Sat Jun  3 20:17:19 2023
From: lists at qseep.net (Lyle Kopnicky)
Date: Sat, 3 Jun 2023 13:17:19 -0700
Subject: Trouble building GHC
In-Reply-To: <CAAS+=P8d4FFr-OLVjjD8xTuFJRcw9eCNaqxYY-rcBXSxvYMHrg@mail.gmail.com>
References: <CAH3XM1mFDhGreqSbJhy+_3McjGeGC2u7crbZGYULoHMx1gvWsw@mail.gmail.com>
 <CAAS+=P8vjEgwjuBfQWmdSz-dC-5JL19xWudBfZ6_OktRqCbrZg@mail.gmail.com>
 <5b99bed9-7c03-f547-b941-abd308990ea8@gmail.com>
 <CAAS+=P8d4FFr-OLVjjD8xTuFJRcw9eCNaqxYY-rcBXSxvYMHrg@mail.gmail.com>
Message-ID: <CAH3XM1=5zsrimhAC47+ndzc06ZGe+vBE1WbzgNYohVS7g40XPg@mail.gmail.com>

 Thanks for the explanation. I’m just hoping that someone can update the
README at https://github.com/alpmestan/ghc.nix. It still says to run

nix-shell ~/ghc.nix/shell.nix --run './boot && ./configure
$CONFIGURE_ARGS && make -j4'


Thanks for your help!
Lyle

On May 31, 2023 at 2:41:28 AM, Sebastian Graf <sgraf1337 at gmail.com> wrote:

> > I've had no issues with the configure step by running the configure_ghc
> shell function that the flake provides.
>
> For reference, this is the relevant ghc.nix issue:
> https://github.com/alpmestan/ghc.nix/issues/111
> It seems that the `configure_ghc` used to be a shell function in
> https://github.com/alpmestan/ghc.nix/blob/b200a76a4f28d6434e4678827a0373002e641b12/default.nix#L156
> .
> Nowadays, it became a standalone bash script (great work, Magnus!), which
> explains why it works for you:
> https://github.com/alpmestan/ghc.nix/blob/f34c21877257fc37bbcf8962dc006024bfd0f946/ghc.nix#L138
>
> You can't do `./configure $CONFIGURE_ARGS` in zsh directly, though.
>
> Am Mi., 31. Mai 2023 um 09:49 Uhr schrieb Georgi Lyubenov <
> godzbanebane at gmail.com>:
>
>> Just chiming in to mention that I'm on zsh, and I've had no issues with
>> the configure step by running the configure_ghc shell function that the
>> flake provides.
>> On 5/31/23 10:13, Sebastian Graf wrote:
>>
>> Hi Lyle,
>>
>> I'm sorry that you have so much trouble in getting your first build done.
>> The Classes.hi issue sounds like something I had experienced in the past,
>> but I'm not having it at the moment.
>> Are you also using symlinks by any chance? Then it is very likely that
>> you have been bitten by https://gitlab.haskell.org/ghc/ghc/-/issues/22451,
>> the workaround to which would be to do something like `cd "$(readlink -f
>> .)"` before you start your build.
>>
>> Regarding your second issue using ghc.nix, a quick google turned up
>> https://gitlab.haskell.org/ghc/ghc/-/issues/20429#note_379762.
>> Is it possible that you didn't start from a clean build?
>> E.g., at the least you should `rm -rf _build` (note that `hadrian/cabal
>> clean` sadly is insufficient IIRC for reasons I don't recall).
>> I often simply do `git clean -fxd` to be extra sure.
>> After that, you'll have to boot, configure (including passing
>> $CONFIGURE_ARGS) and build again.
>> By the way, are you using ZSH? I'm using it and I have to pass the
>> CONFIGURE_ARGS in a slightly different way
>> <https://github.com/alpmestan/ghc.nix#building-ghc>: `./configure
>> ${=CONFIGURE_ARGS}`.
>>
>> I also updated
>> https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/linux#nixnixos
>> to account for new-style flakified builds+direnv, if that's a workflow that
>> you are familiar with.
>>
>> Hope that helps,
>> Sebastian
>>
>> Am Mi., 31. Mai 2023 um 05:14 Uhr schrieb Lyle Kopnicky <lists at qseep.net
>> >:
>>
>>> Hi folks, I’m new here. I’ll be attending the GHC Contributors’ Workshop
>>> next week, and in preparation, I’m trying to build GHC, both the native
>>> code backend and the JS backend. So far, I’ve only tried to build it with
>>> the native code backend, but I haven’t been able to get it to work. I’ve
>>> gotten help from some friendly folks on the #ghc channel on Matrix, and
>>> made some progress, but I’m still stuck.
>>>
>>> Is there anyone here who could be a point person for helping me get it
>>> to build? BTW I’m located on the west coast of the US (until next week when
>>> I’ll be in Switzerland), so time lag may be a factor.
>>>
>>> I’m using a Mac with aarch64 and macOS 13.3. Here are some of the things
>>> I’ve tried, and issues I’ve run into:
>>>
>>>
>>>    - Started with the advice from this wiki:
>>>    https://gitlab.haskell.org/ghc/ghc/-/wikis/building
>>>    - Checked out the ghc source, on HEAD.
>>>    - The rest of the steps were at
>>>    https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/mac-osx
>>>    - Already had Apple’s command line tools, but when I tried to do
>>>    operations using them, I got an error saying I needed the full Xcode, so I
>>>    installed that.
>>>    - brew install autoconf automake python sphinx-doc
>>>       - Worked fine, also added sphinx-build to the path
>>>    - Initially tried using ghc 9.2.7 to build - later tried switching
>>>    to 9.4.4 and eventually 9.4.5
>>>    - cabal update; cabal install alex happy haddock
>>>    - This is where I ran into trouble - couldn’t build haddock. Cabal
>>>       said it couldn’t resolve the dependencies.
>>>       - I tried switching to ghc 9.4.4 and cabal 3.10.1.0 - same problem
>>>       - User romes (Rodrigo) on #ghc helped with this - was able to
>>>       reproduce it and filed a ticket:
>>>       https://github.com/haskell/haddock/issues/1596
>>>       - However he pointed out that haddock was already supplied
>>>       through ghcup so I don’t need to build it.
>>>    - Already had MacTex installed and I installed the DejaVu font
>>>    family.
>>>    - ./boot && ./configure
>>>       - Worked fine, although ./boot gave me lots of autoconf warnings
>>>       like:
>>>       configure.ac:9: warning: The macro `AC_HELP_STRING' is obsolete.
>>>       configure.ac:9: You should run autoupdate.
>>>       - Apparently autoconf has renamed these macros to pluralize them,
>>>       and also encloses the arguments in square brackets.
>>>    - hadrian/build
>>>       - Ran into another problem: The build failed with:
>>>       Error, file does not exist and no rule available:
>>>
>>>       /Users/lyle/devel/haskell/ghc/_build/stage1/libraries/ghc-prim/build/GHC/Classes.hi
>>>       - Rodrigo helped me out with this. Introduced me to other build
>>>       flags like -j —flavour-quick.
>>>       - The issue proved quite persistent, but it might fail on
>>>       different .hi files.
>>>       - It turns out if you ask Hadrian to build that specific file, it
>>>       works. So somehow it can find a rule! Then you can proceed to rebuild and
>>>       it will fail on a different .hi file. Obviously it would be
>>>       tedious to do this for all the possible files it can fail on.
>>>       - I also tried not building profiled libraries.
>>>       - I tried, instead of using the Apple toolchain, using llvm 12,
>>>       then llvm 16. But I got different errors from that.
>>>       - Rodrigo was unable to reproduce the issue.
>>>    - So, I thought I’d try the Nix approach.
>>>    - First I had to repair my nix installation, because apparently
>>>    updating macOS overwrites /etc/zshrc, overwriting the bit that sources
>>>    '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh’
>>>    - Nix reminded me when I ran commands that I needed to add the
>>>    flag '--extra-experimental-features nix-command’ and
>>>    sometimes '--extra-experimental-features flakes’
>>>    - The instructions from the wiki
>>>    <https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/mac-osx>
>>>    didn’t work, got an error:
>>>       -
>>>       - nix build -f .gitlab/darwin/toolchain.nix -o toolchain.sh
>>>       --extra-experimental-features nix-command
>>>       - error: cannot evaluate a function that has an argument without
>>>       a value ('system’)
>>>    - But folks on #ghc recommended I use ghc.nix instead
>>>       - Pointed me to https://ghc.dev/
>>>       - That linked to these instructions:
>>>       https://github.com/alpmestan/ghc.nix#building-ghc
>>>       - But those instructions failed with:
>>>          - error: nix-shell requires a single derivation
>>>          - User Artem said my command was wrong, instead recommended:
>>>          - nix develop
>>>          https://github.com/alpmestan/ghc.nix/archive/master.tar.gz
>>>       - Once I added the magic experimental flags…
>>>       - It failed, with:
>>>          - error: NAR hash mismatch in input
>>>          'github:commercialhaskell/all-cabal-hashes/02bb1361217e690d83af9cc132b1d2bf2096763c'
>>>          (/nix/store/zbav3qqbyz7mn7rh4iwybs0ni01ppdbj-source), expected
>>>          'sha256-HdAnlSc4U8ftnZrBZr2CewsPQs03V9K2gkTVHKG8IfA=', got
>>>          'sha256-86BgvJ+ebMxTp+nPxo659hsNJbhE6CYJWiIbQXX+sBM=
>>>          - User MangoIV helped me out with this.
>>>       - First I tried regenerating the lock file, with nix flake update.
>>>          - Didn’t fix the problem.
>>>       - Then, I checked out the branch update_flake_lock_action
>>>          - This is apparently a branch designed to fix the problem
>>>          - Didn’t fix the problem
>>>       - Then I regenerated the lock file again, with nix flake update
>>>          - That worked! Well, at least that got me to a ghc.nix prompt
>>>       - So, I did:
>>>          - ./boot
>>>          - ./configure
>>>          - cabal v2-update
>>>          - hadrian/build -j --flavour=quick
>>>          - It chugged along for quite a while. Sadly, it ended with
>>>       this error:
>>>          -
>>>          - Linking
>>>          /Users/lyle/Sync/devel/haskell/ghc/hadrian/dist-newstyle/build/aarch64-osx/ghc-9.2.4/hadrian-0.1.0.0/x/hadrian/build/hadrian/hadrian
>>>          ...
>>>          Data.Binary.Get.runGet at position 1181: Unknown encoding for
>>>          constructor
>>>       - What also worries me is that I thought I read somewhere that
>>>       ghc.nix doesn’t work for cross-compilers, so even if it works for
>>>       the native backend, it may not work for the JS backend.
>>>
>>>
>>> Any help would be much appreciated!
>>> — Lyle
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
>> _______________________________________________
>> ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> 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/20230603/2aad9e18/attachment.html>

From lists at qseep.net  Sat Jun  3 21:47:59 2023
From: lists at qseep.net (Lyle Kopnicky)
Date: Sat, 3 Jun 2023 14:47:59 -0700
Subject: Trouble building GHC
In-Reply-To: <CAAS+=P8d4FFr-OLVjjD8xTuFJRcw9eCNaqxYY-rcBXSxvYMHrg@mail.gmail.com>
References: <CAH3XM1mFDhGreqSbJhy+_3McjGeGC2u7crbZGYULoHMx1gvWsw@mail.gmail.com>
 <CAAS+=P8vjEgwjuBfQWmdSz-dC-5JL19xWudBfZ6_OktRqCbrZg@mail.gmail.com>
 <5b99bed9-7c03-f547-b941-abd308990ea8@gmail.com>
 <CAAS+=P8d4FFr-OLVjjD8xTuFJRcw9eCNaqxYY-rcBXSxvYMHrg@mail.gmail.com>
Message-ID: <CAH3XM1mcQwDH7Fk-t8uFESZUsfbtU9BN_SvC=KH6f5XTb5u=LQ@mail.gmail.com>

How do you build the JavaScript backend then?

Without nix, I used:

emconfigure ./configure --target=javascript-unknown-ghcjs


But with ghc.nix, if I use configure_ghc, can I pass that to emconfigure?
Would it be like this?

emconfigure configure_ghc --target=javascript-unknown-ghcjs


Well, never mind - I tried that, and it worked!

Thanks,
Lyle

On May 31, 2023 at 2:41:28 AM, Sebastian Graf <sgraf1337 at gmail.com> wrote:

> > I've had no issues with the configure step by running the configure_ghc
> shell function that the flake provides.
>
> For reference, this is the relevant ghc.nix issue:
> https://github.com/alpmestan/ghc.nix/issues/111
> It seems that the `configure_ghc` used to be a shell function in
> https://github.com/alpmestan/ghc.nix/blob/b200a76a4f28d6434e4678827a0373002e641b12/default.nix#L156
> .
> Nowadays, it became a standalone bash script (great work, Magnus!), which
> explains why it works for you:
> https://github.com/alpmestan/ghc.nix/blob/f34c21877257fc37bbcf8962dc006024bfd0f946/ghc.nix#L138
>
> You can't do `./configure $CONFIGURE_ARGS` in zsh directly, though.
>
> Am Mi., 31. Mai 2023 um 09:49 Uhr schrieb Georgi Lyubenov <
> godzbanebane at gmail.com>:
>
>> Just chiming in to mention that I'm on zsh, and I've had no issues with
>> the configure step by running the configure_ghc shell function that the
>> flake provides.
>> On 5/31/23 10:13, Sebastian Graf wrote:
>>
>> Hi Lyle,
>>
>> I'm sorry that you have so much trouble in getting your first build done.
>> The Classes.hi issue sounds like something I had experienced in the past,
>> but I'm not having it at the moment.
>> Are you also using symlinks by any chance? Then it is very likely that
>> you have been bitten by https://gitlab.haskell.org/ghc/ghc/-/issues/22451,
>> the workaround to which would be to do something like `cd "$(readlink -f
>> .)"` before you start your build.
>>
>> Regarding your second issue using ghc.nix, a quick google turned up
>> https://gitlab.haskell.org/ghc/ghc/-/issues/20429#note_379762.
>> Is it possible that you didn't start from a clean build?
>> E.g., at the least you should `rm -rf _build` (note that `hadrian/cabal
>> clean` sadly is insufficient IIRC for reasons I don't recall).
>> I often simply do `git clean -fxd` to be extra sure.
>> After that, you'll have to boot, configure (including passing
>> $CONFIGURE_ARGS) and build again.
>> By the way, are you using ZSH? I'm using it and I have to pass the
>> CONFIGURE_ARGS in a slightly different way
>> <https://github.com/alpmestan/ghc.nix#building-ghc>: `./configure
>> ${=CONFIGURE_ARGS}`.
>>
>> I also updated
>> https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/linux#nixnixos
>> to account for new-style flakified builds+direnv, if that's a workflow that
>> you are familiar with.
>>
>> Hope that helps,
>> Sebastian
>>
>> Am Mi., 31. Mai 2023 um 05:14 Uhr schrieb Lyle Kopnicky <lists at qseep.net
>> >:
>>
>>> Hi folks, I’m new here. I’ll be attending the GHC Contributors’ Workshop
>>> next week, and in preparation, I’m trying to build GHC, both the native
>>> code backend and the JS backend. So far, I’ve only tried to build it with
>>> the native code backend, but I haven’t been able to get it to work. I’ve
>>> gotten help from some friendly folks on the #ghc channel on Matrix, and
>>> made some progress, but I’m still stuck.
>>>
>>> Is there anyone here who could be a point person for helping me get it
>>> to build? BTW I’m located on the west coast of the US (until next week when
>>> I’ll be in Switzerland), so time lag may be a factor.
>>>
>>> I’m using a Mac with aarch64 and macOS 13.3. Here are some of the things
>>> I’ve tried, and issues I’ve run into:
>>>
>>>
>>>    - Started with the advice from this wiki:
>>>    https://gitlab.haskell.org/ghc/ghc/-/wikis/building
>>>    - Checked out the ghc source, on HEAD.
>>>    - The rest of the steps were at
>>>    https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/mac-osx
>>>    - Already had Apple’s command line tools, but when I tried to do
>>>    operations using them, I got an error saying I needed the full Xcode, so I
>>>    installed that.
>>>    - brew install autoconf automake python sphinx-doc
>>>       - Worked fine, also added sphinx-build to the path
>>>    - Initially tried using ghc 9.2.7 to build - later tried switching
>>>    to 9.4.4 and eventually 9.4.5
>>>    - cabal update; cabal install alex happy haddock
>>>    - This is where I ran into trouble - couldn’t build haddock. Cabal
>>>       said it couldn’t resolve the dependencies.
>>>       - I tried switching to ghc 9.4.4 and cabal 3.10.1.0 - same problem
>>>       - User romes (Rodrigo) on #ghc helped with this - was able to
>>>       reproduce it and filed a ticket:
>>>       https://github.com/haskell/haddock/issues/1596
>>>       - However he pointed out that haddock was already supplied
>>>       through ghcup so I don’t need to build it.
>>>    - Already had MacTex installed and I installed the DejaVu font
>>>    family.
>>>    - ./boot && ./configure
>>>       - Worked fine, although ./boot gave me lots of autoconf warnings
>>>       like:
>>>       configure.ac:9: warning: The macro `AC_HELP_STRING' is obsolete.
>>>       configure.ac:9: You should run autoupdate.
>>>       - Apparently autoconf has renamed these macros to pluralize them,
>>>       and also encloses the arguments in square brackets.
>>>    - hadrian/build
>>>       - Ran into another problem: The build failed with:
>>>       Error, file does not exist and no rule available:
>>>
>>>       /Users/lyle/devel/haskell/ghc/_build/stage1/libraries/ghc-prim/build/GHC/Classes.hi
>>>       - Rodrigo helped me out with this. Introduced me to other build
>>>       flags like -j —flavour-quick.
>>>       - The issue proved quite persistent, but it might fail on
>>>       different .hi files.
>>>       - It turns out if you ask Hadrian to build that specific file, it
>>>       works. So somehow it can find a rule! Then you can proceed to rebuild and
>>>       it will fail on a different .hi file. Obviously it would be
>>>       tedious to do this for all the possible files it can fail on.
>>>       - I also tried not building profiled libraries.
>>>       - I tried, instead of using the Apple toolchain, using llvm 12,
>>>       then llvm 16. But I got different errors from that.
>>>       - Rodrigo was unable to reproduce the issue.
>>>    - So, I thought I’d try the Nix approach.
>>>    - First I had to repair my nix installation, because apparently
>>>    updating macOS overwrites /etc/zshrc, overwriting the bit that sources
>>>    '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh’
>>>    - Nix reminded me when I ran commands that I needed to add the
>>>    flag '--extra-experimental-features nix-command’ and
>>>    sometimes '--extra-experimental-features flakes’
>>>    - The instructions from the wiki
>>>    <https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/mac-osx>
>>>    didn’t work, got an error:
>>>       -
>>>       - nix build -f .gitlab/darwin/toolchain.nix -o toolchain.sh
>>>       --extra-experimental-features nix-command
>>>       - error: cannot evaluate a function that has an argument without
>>>       a value ('system’)
>>>    - But folks on #ghc recommended I use ghc.nix instead
>>>       - Pointed me to https://ghc.dev/
>>>       - That linked to these instructions:
>>>       https://github.com/alpmestan/ghc.nix#building-ghc
>>>       - But those instructions failed with:
>>>          - error: nix-shell requires a single derivation
>>>          - User Artem said my command was wrong, instead recommended:
>>>          - nix develop
>>>          https://github.com/alpmestan/ghc.nix/archive/master.tar.gz
>>>       - Once I added the magic experimental flags…
>>>       - It failed, with:
>>>          - error: NAR hash mismatch in input
>>>          'github:commercialhaskell/all-cabal-hashes/02bb1361217e690d83af9cc132b1d2bf2096763c'
>>>          (/nix/store/zbav3qqbyz7mn7rh4iwybs0ni01ppdbj-source), expected
>>>          'sha256-HdAnlSc4U8ftnZrBZr2CewsPQs03V9K2gkTVHKG8IfA=', got
>>>          'sha256-86BgvJ+ebMxTp+nPxo659hsNJbhE6CYJWiIbQXX+sBM=
>>>          - User MangoIV helped me out with this.
>>>       - First I tried regenerating the lock file, with nix flake update.
>>>          - Didn’t fix the problem.
>>>       - Then, I checked out the branch update_flake_lock_action
>>>          - This is apparently a branch designed to fix the problem
>>>          - Didn’t fix the problem
>>>       - Then I regenerated the lock file again, with nix flake update
>>>          - That worked! Well, at least that got me to a ghc.nix prompt
>>>       - So, I did:
>>>          - ./boot
>>>          - ./configure
>>>          - cabal v2-update
>>>          - hadrian/build -j --flavour=quick
>>>          - It chugged along for quite a while. Sadly, it ended with
>>>       this error:
>>>          -
>>>          - Linking
>>>          /Users/lyle/Sync/devel/haskell/ghc/hadrian/dist-newstyle/build/aarch64-osx/ghc-9.2.4/hadrian-0.1.0.0/x/hadrian/build/hadrian/hadrian
>>>          ...
>>>          Data.Binary.Get.runGet at position 1181: Unknown encoding for
>>>          constructor
>>>       - What also worries me is that I thought I read somewhere that
>>>       ghc.nix doesn’t work for cross-compilers, so even if it works for
>>>       the native backend, it may not work for the JS backend.
>>>
>>>
>>> Any help would be much appreciated!
>>> — Lyle
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
>> _______________________________________________
>> ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
> _______________________________________________
> 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/20230603/a793afc3/attachment.html>

From lists at qseep.net  Sat Jun  3 22:40:30 2023
From: lists at qseep.net (Lyle Kopnicky)
Date: Sat, 3 Jun 2023 15:40:30 -0700
Subject: Trouble building GHC
In-Reply-To: <CAH3XM1mcQwDH7Fk-t8uFESZUsfbtU9BN_SvC=KH6f5XTb5u=LQ@mail.gmail.com>
References: <CAH3XM1mFDhGreqSbJhy+_3McjGeGC2u7crbZGYULoHMx1gvWsw@mail.gmail.com>
 <CAAS+=P8vjEgwjuBfQWmdSz-dC-5JL19xWudBfZ6_OktRqCbrZg@mail.gmail.com>
 <5b99bed9-7c03-f547-b941-abd308990ea8@gmail.com>
 <CAAS+=P8d4FFr-OLVjjD8xTuFJRcw9eCNaqxYY-rcBXSxvYMHrg@mail.gmail.com>
 <CAH3XM1mcQwDH7Fk-t8uFESZUsfbtU9BN_SvC=KH6f5XTb5u=LQ@mail.gmail.com>
Message-ID: <CAH3XM1mQwhxUKNwkk7qU_1wH4YjPDy-W6zbDakBP9RRecgGUcg@mail.gmail.com>

 It does look like emconfigure came from homebrew though, not nix.

On Jun 3, 2023 at 2:47:59 PM, Lyle Kopnicky <lists at qseep.net> wrote:

> How do you build the JavaScript backend then?
>
> Without nix, I used:
>
> emconfigure ./configure --target=javascript-unknown-ghcjs
>
>
> But with ghc.nix, if I use configure_ghc, can I pass that to emconfigure?
> Would it be like this?
>
> emconfigure configure_ghc --target=javascript-unknown-ghcjs
>
>
> Well, never mind - I tried that, and it worked!
>
> Thanks,
> Lyle
>
> On May 31, 2023 at 2:41:28 AM, Sebastian Graf <sgraf1337 at gmail.com> wrote:
>
>> > I've had no issues with the configure step by running the configure_ghc
>> shell function that the flake provides.
>>
>> For reference, this is the relevant ghc.nix issue:
>> https://github.com/alpmestan/ghc.nix/issues/111
>> It seems that the `configure_ghc` used to be a shell function in
>> https://github.com/alpmestan/ghc.nix/blob/b200a76a4f28d6434e4678827a0373002e641b12/default.nix#L156
>> .
>> Nowadays, it became a standalone bash script (great work, Magnus!), which
>> explains why it works for you:
>> https://github.com/alpmestan/ghc.nix/blob/f34c21877257fc37bbcf8962dc006024bfd0f946/ghc.nix#L138
>>
>> You can't do `./configure $CONFIGURE_ARGS` in zsh directly, though.
>>
>> Am Mi., 31. Mai 2023 um 09:49 Uhr schrieb Georgi Lyubenov <
>> godzbanebane at gmail.com>:
>>
>>> Just chiming in to mention that I'm on zsh, and I've had no issues with
>>> the configure step by running the configure_ghc shell function that the
>>> flake provides.
>>> On 5/31/23 10:13, Sebastian Graf wrote:
>>>
>>> Hi Lyle,
>>>
>>> I'm sorry that you have so much trouble in getting your first build done.
>>> The Classes.hi issue sounds like something I had experienced in the
>>> past, but I'm not having it at the moment.
>>> Are you also using symlinks by any chance? Then it is very likely that
>>> you have been bitten by
>>> https://gitlab.haskell.org/ghc/ghc/-/issues/22451, the workaround to
>>> which would be to do something like `cd "$(readlink -f .)"` before you
>>> start your build.
>>>
>>> Regarding your second issue using ghc.nix, a quick google turned up
>>> https://gitlab.haskell.org/ghc/ghc/-/issues/20429#note_379762.
>>> Is it possible that you didn't start from a clean build?
>>> E.g., at the least you should `rm -rf _build` (note that `hadrian/cabal
>>> clean` sadly is insufficient IIRC for reasons I don't recall).
>>> I often simply do `git clean -fxd` to be extra sure.
>>> After that, you'll have to boot, configure (including passing
>>> $CONFIGURE_ARGS) and build again.
>>> By the way, are you using ZSH? I'm using it and I have to pass the
>>> CONFIGURE_ARGS in a slightly different way
>>> <https://github.com/alpmestan/ghc.nix#building-ghc>: `./configure
>>> ${=CONFIGURE_ARGS}`.
>>>
>>> I also updated
>>> https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/linux#nixnixos
>>> to account for new-style flakified builds+direnv, if that's a workflow that
>>> you are familiar with.
>>>
>>> Hope that helps,
>>> Sebastian
>>>
>>> Am Mi., 31. Mai 2023 um 05:14 Uhr schrieb Lyle Kopnicky <lists at qseep.net
>>> >:
>>>
>>>> Hi folks, I’m new here. I’ll be attending the GHC Contributors’
>>>> Workshop next week, and in preparation, I’m trying to build GHC, both the
>>>> native code backend and the JS backend. So far, I’ve only tried to build it
>>>> with the native code backend, but I haven’t been able to get it to work.
>>>> I’ve gotten help from some friendly folks on the #ghc channel on Matrix,
>>>> and made some progress, but I’m still stuck.
>>>>
>>>> Is there anyone here who could be a point person for helping me get it
>>>> to build? BTW I’m located on the west coast of the US (until next week when
>>>> I’ll be in Switzerland), so time lag may be a factor.
>>>>
>>>> I’m using a Mac with aarch64 and macOS 13.3. Here are some of the
>>>> things I’ve tried, and issues I’ve run into:
>>>>
>>>>
>>>>    - Started with the advice from this wiki:
>>>>    https://gitlab.haskell.org/ghc/ghc/-/wikis/building
>>>>    - Checked out the ghc source, on HEAD.
>>>>    - The rest of the steps were at
>>>>    https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/mac-osx
>>>>    - Already had Apple’s command line tools, but when I tried to do
>>>>    operations using them, I got an error saying I needed the full Xcode, so I
>>>>    installed that.
>>>>    - brew install autoconf automake python sphinx-doc
>>>>       - Worked fine, also added sphinx-build to the path
>>>>    - Initially tried using ghc 9.2.7 to build - later tried switching
>>>>    to 9.4.4 and eventually 9.4.5
>>>>    - cabal update; cabal install alex happy haddock
>>>>    - This is where I ran into trouble - couldn’t build haddock. Cabal
>>>>       said it couldn’t resolve the dependencies.
>>>>       - I tried switching to ghc 9.4.4 and cabal 3.10.1.0 - same
>>>>       problem
>>>>       - User romes (Rodrigo) on #ghc helped with this - was able to
>>>>       reproduce it and filed a ticket:
>>>>       https://github.com/haskell/haddock/issues/1596
>>>>       - However he pointed out that haddock was already supplied
>>>>       through ghcup so I don’t need to build it.
>>>>    - Already had MacTex installed and I installed the DejaVu font
>>>>    family.
>>>>    - ./boot && ./configure
>>>>       - Worked fine, although ./boot gave me lots of autoconf warnings
>>>>       like:
>>>>       configure.ac:9: warning: The macro `AC_HELP_STRING' is obsolete.
>>>>       configure.ac:9: You should run autoupdate.
>>>>       - Apparently autoconf has renamed these macros to pluralize
>>>>       them, and also encloses the arguments in square brackets.
>>>>    - hadrian/build
>>>>       - Ran into another problem: The build failed with:
>>>>       Error, file does not exist and no rule available:
>>>>
>>>>       /Users/lyle/devel/haskell/ghc/_build/stage1/libraries/ghc-prim/build/GHC/Classes.hi
>>>>       - Rodrigo helped me out with this. Introduced me to other build
>>>>       flags like -j —flavour-quick.
>>>>       - The issue proved quite persistent, but it might fail on
>>>>       different .hi files.
>>>>       - It turns out if you ask Hadrian to build that specific file,
>>>>       it works. So somehow it can find a rule! Then you can proceed to rebuild
>>>>       and it will fail on a different .hi file. Obviously it would be
>>>>       tedious to do this for all the possible files it can fail on.
>>>>       - I also tried not building profiled libraries.
>>>>       - I tried, instead of using the Apple toolchain, using llvm 12,
>>>>       then llvm 16. But I got different errors from that.
>>>>       - Rodrigo was unable to reproduce the issue.
>>>>    - So, I thought I’d try the Nix approach.
>>>>    - First I had to repair my nix installation, because apparently
>>>>    updating macOS overwrites /etc/zshrc, overwriting the bit that sources
>>>>    '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh’
>>>>    - Nix reminded me when I ran commands that I needed to add the
>>>>    flag '--extra-experimental-features nix-command’ and
>>>>    sometimes '--extra-experimental-features flakes’
>>>>    - The instructions from the wiki
>>>>    <https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/mac-osx>
>>>>    didn’t work, got an error:
>>>>       -
>>>>       - nix build -f .gitlab/darwin/toolchain.nix -o toolchain.sh
>>>>       --extra-experimental-features nix-command
>>>>       - error: cannot evaluate a function that has an argument without
>>>>       a value ('system’)
>>>>    - But folks on #ghc recommended I use ghc.nix instead
>>>>       - Pointed me to https://ghc.dev/
>>>>       - That linked to these instructions:
>>>>       https://github.com/alpmestan/ghc.nix#building-ghc
>>>>       - But those instructions failed with:
>>>>          - error: nix-shell requires a single derivation
>>>>          - User Artem said my command was wrong, instead recommended:
>>>>          - nix develop
>>>>          https://github.com/alpmestan/ghc.nix/archive/master.tar.gz
>>>>       - Once I added the magic experimental flags…
>>>>       - It failed, with:
>>>>          - error: NAR hash mismatch in input
>>>>          'github:commercialhaskell/all-cabal-hashes/02bb1361217e690d83af9cc132b1d2bf2096763c'
>>>>          (/nix/store/zbav3qqbyz7mn7rh4iwybs0ni01ppdbj-source), expected
>>>>          'sha256-HdAnlSc4U8ftnZrBZr2CewsPQs03V9K2gkTVHKG8IfA=', got
>>>>          'sha256-86BgvJ+ebMxTp+nPxo659hsNJbhE6CYJWiIbQXX+sBM=
>>>>          - User MangoIV helped me out with this.
>>>>       - First I tried regenerating the lock file, with nix flake update
>>>>       .
>>>>          - Didn’t fix the problem.
>>>>       - Then, I checked out the branch update_flake_lock_action
>>>>          - This is apparently a branch designed to fix the problem
>>>>          - Didn’t fix the problem
>>>>       - Then I regenerated the lock file again, with nix flake update
>>>>          - That worked! Well, at least that got me to a ghc.nix prompt
>>>>       - So, I did:
>>>>          - ./boot
>>>>          - ./configure
>>>>          - cabal v2-update
>>>>          - hadrian/build -j --flavour=quick
>>>>          - It chugged along for quite a while. Sadly, it ended with
>>>>       this error:
>>>>          -
>>>>          - Linking
>>>>          /Users/lyle/Sync/devel/haskell/ghc/hadrian/dist-newstyle/build/aarch64-osx/ghc-9.2.4/hadrian-0.1.0.0/x/hadrian/build/hadrian/hadrian
>>>>          ...
>>>>          Data.Binary.Get.runGet at position 1181: Unknown encoding for
>>>>          constructor
>>>>       - What also worries me is that I thought I read somewhere that
>>>>       ghc.nix doesn’t work for cross-compilers, so even if it works
>>>>       for the native backend, it may not work for the JS backend.
>>>>
>>>>
>>>> Any help would be much appreciated!
>>>> — Lyle
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> _______________________________________________
>> 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/20230603/8c6186a7/attachment-0001.html>

From bryan at haskell.foundation  Sun Jun  4 07:10:11 2023
From: bryan at haskell.foundation (Bryan Richter)
Date: Sun, 4 Jun 2023 09:10:11 +0200
Subject: Trouble building GHC
In-Reply-To: <CAH3XM1=5zsrimhAC47+ndzc06ZGe+vBE1WbzgNYohVS7g40XPg@mail.gmail.com>
References: <CAH3XM1mFDhGreqSbJhy+_3McjGeGC2u7crbZGYULoHMx1gvWsw@mail.gmail.com>
 <CAAS+=P8vjEgwjuBfQWmdSz-dC-5JL19xWudBfZ6_OktRqCbrZg@mail.gmail.com>
 <5b99bed9-7c03-f547-b941-abd308990ea8@gmail.com>
 <CAAS+=P8d4FFr-OLVjjD8xTuFJRcw9eCNaqxYY-rcBXSxvYMHrg@mail.gmail.com>
 <CAH3XM1=5zsrimhAC47+ndzc06ZGe+vBE1WbzgNYohVS7g40XPg@mail.gmail.com>
Message-ID: <CACUTo6wyZtXqjY49JCmnxYLcb_wzJdGJ1z3Yb48tMskhkO75TQ@mail.gmail.com>

> I’m just hoping that someone can update the README at
https://github.com/alpmestan/ghc.nix.

That "someone" could be you! :O In fact, you are probably the most
qualified to do so!

On Sat, 3 Jun 2023, 22.17 Lyle Kopnicky, <lists at qseep.net> wrote:

> Thanks for the explanation. I’m just hoping that someone can update the
> README at https://github.com/alpmestan/ghc.nix. It still says to run
>
> nix-shell ~/ghc.nix/shell.nix --run './boot && ./configure $CONFIGURE_ARGS && make -j4'
>
>
> Thanks for your help!
> Lyle
>
> On May 31, 2023 at 2:41:28 AM, Sebastian Graf <sgraf1337 at gmail.com> wrote:
>
>> > I've had no issues with the configure step by running the configure_ghc
>> shell function that the flake provides.
>>
>> For reference, this is the relevant ghc.nix issue:
>> https://github.com/alpmestan/ghc.nix/issues/111
>> It seems that the `configure_ghc` used to be a shell function in
>> https://github.com/alpmestan/ghc.nix/blob/b200a76a4f28d6434e4678827a0373002e641b12/default.nix#L156
>> .
>> Nowadays, it became a standalone bash script (great work, Magnus!), which
>> explains why it works for you:
>> https://github.com/alpmestan/ghc.nix/blob/f34c21877257fc37bbcf8962dc006024bfd0f946/ghc.nix#L138
>>
>> You can't do `./configure $CONFIGURE_ARGS` in zsh directly, though.
>>
>> Am Mi., 31. Mai 2023 um 09:49 Uhr schrieb Georgi Lyubenov <
>> godzbanebane at gmail.com>:
>>
>>> Just chiming in to mention that I'm on zsh, and I've had no issues with
>>> the configure step by running the configure_ghc shell function that the
>>> flake provides.
>>> On 5/31/23 10:13, Sebastian Graf wrote:
>>>
>>> Hi Lyle,
>>>
>>> I'm sorry that you have so much trouble in getting your first build done.
>>> The Classes.hi issue sounds like something I had experienced in the
>>> past, but I'm not having it at the moment.
>>> Are you also using symlinks by any chance? Then it is very likely that
>>> you have been bitten by
>>> https://gitlab.haskell.org/ghc/ghc/-/issues/22451, the workaround to
>>> which would be to do something like `cd "$(readlink -f .)"` before you
>>> start your build.
>>>
>>> Regarding your second issue using ghc.nix, a quick google turned up
>>> https://gitlab.haskell.org/ghc/ghc/-/issues/20429#note_379762.
>>> Is it possible that you didn't start from a clean build?
>>> E.g., at the least you should `rm -rf _build` (note that `hadrian/cabal
>>> clean` sadly is insufficient IIRC for reasons I don't recall).
>>> I often simply do `git clean -fxd` to be extra sure.
>>> After that, you'll have to boot, configure (including passing
>>> $CONFIGURE_ARGS) and build again.
>>> By the way, are you using ZSH? I'm using it and I have to pass the
>>> CONFIGURE_ARGS in a slightly different way
>>> <https://github.com/alpmestan/ghc.nix#building-ghc>: `./configure
>>> ${=CONFIGURE_ARGS}`.
>>>
>>> I also updated
>>> https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/linux#nixnixos
>>> to account for new-style flakified builds+direnv, if that's a workflow that
>>> you are familiar with.
>>>
>>> Hope that helps,
>>> Sebastian
>>>
>>> Am Mi., 31. Mai 2023 um 05:14 Uhr schrieb Lyle Kopnicky <lists at qseep.net
>>> >:
>>>
>>>> Hi folks, I’m new here. I’ll be attending the GHC Contributors’
>>>> Workshop next week, and in preparation, I’m trying to build GHC, both the
>>>> native code backend and the JS backend. So far, I’ve only tried to build it
>>>> with the native code backend, but I haven’t been able to get it to work.
>>>> I’ve gotten help from some friendly folks on the #ghc channel on Matrix,
>>>> and made some progress, but I’m still stuck.
>>>>
>>>> Is there anyone here who could be a point person for helping me get it
>>>> to build? BTW I’m located on the west coast of the US (until next week when
>>>> I’ll be in Switzerland), so time lag may be a factor.
>>>>
>>>> I’m using a Mac with aarch64 and macOS 13.3. Here are some of the
>>>> things I’ve tried, and issues I’ve run into:
>>>>
>>>>
>>>>    - Started with the advice from this wiki:
>>>>    https://gitlab.haskell.org/ghc/ghc/-/wikis/building
>>>>    - Checked out the ghc source, on HEAD.
>>>>    - The rest of the steps were at
>>>>    https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/mac-osx
>>>>    - Already had Apple’s command line tools, but when I tried to do
>>>>    operations using them, I got an error saying I needed the full Xcode, so I
>>>>    installed that.
>>>>    - brew install autoconf automake python sphinx-doc
>>>>       - Worked fine, also added sphinx-build to the path
>>>>    - Initially tried using ghc 9.2.7 to build - later tried switching
>>>>    to 9.4.4 and eventually 9.4.5
>>>>    - cabal update; cabal install alex happy haddock
>>>>    - This is where I ran into trouble - couldn’t build haddock. Cabal
>>>>       said it couldn’t resolve the dependencies.
>>>>       - I tried switching to ghc 9.4.4 and cabal 3.10.1.0 - same
>>>>       problem
>>>>       - User romes (Rodrigo) on #ghc helped with this - was able to
>>>>       reproduce it and filed a ticket:
>>>>       https://github.com/haskell/haddock/issues/1596
>>>>       - However he pointed out that haddock was already supplied
>>>>       through ghcup so I don’t need to build it.
>>>>    - Already had MacTex installed and I installed the DejaVu font
>>>>    family.
>>>>    - ./boot && ./configure
>>>>       - Worked fine, although ./boot gave me lots of autoconf warnings
>>>>       like:
>>>>       configure.ac:9: warning: The macro `AC_HELP_STRING' is obsolete.
>>>>       configure.ac:9: You should run autoupdate.
>>>>       - Apparently autoconf has renamed these macros to pluralize
>>>>       them, and also encloses the arguments in square brackets.
>>>>    - hadrian/build
>>>>       - Ran into another problem: The build failed with:
>>>>       Error, file does not exist and no rule available:
>>>>
>>>>       /Users/lyle/devel/haskell/ghc/_build/stage1/libraries/ghc-prim/build/GHC/Classes.hi
>>>>       - Rodrigo helped me out with this. Introduced me to other build
>>>>       flags like -j —flavour-quick.
>>>>       - The issue proved quite persistent, but it might fail on
>>>>       different .hi files.
>>>>       - It turns out if you ask Hadrian to build that specific file,
>>>>       it works. So somehow it can find a rule! Then you can proceed to rebuild
>>>>       and it will fail on a different .hi file. Obviously it would be
>>>>       tedious to do this for all the possible files it can fail on.
>>>>       - I also tried not building profiled libraries.
>>>>       - I tried, instead of using the Apple toolchain, using llvm 12,
>>>>       then llvm 16. But I got different errors from that.
>>>>       - Rodrigo was unable to reproduce the issue.
>>>>    - So, I thought I’d try the Nix approach.
>>>>    - First I had to repair my nix installation, because apparently
>>>>    updating macOS overwrites /etc/zshrc, overwriting the bit that sources
>>>>    '/nix/var/nix/profiles/default/etc/profile.d/nix-daemon.sh’
>>>>    - Nix reminded me when I ran commands that I needed to add the
>>>>    flag '--extra-experimental-features nix-command’ and
>>>>    sometimes '--extra-experimental-features flakes’
>>>>    - The instructions from the wiki
>>>>    <https://gitlab.haskell.org/ghc/ghc/-/wikis/building/preparation/mac-osx>
>>>>    didn’t work, got an error:
>>>>       -
>>>>       - nix build -f .gitlab/darwin/toolchain.nix -o toolchain.sh
>>>>       --extra-experimental-features nix-command
>>>>       - error: cannot evaluate a function that has an argument without
>>>>       a value ('system’)
>>>>    - But folks on #ghc recommended I use ghc.nix instead
>>>>       - Pointed me to https://ghc.dev/
>>>>       - That linked to these instructions:
>>>>       https://github.com/alpmestan/ghc.nix#building-ghc
>>>>       - But those instructions failed with:
>>>>          - error: nix-shell requires a single derivation
>>>>          - User Artem said my command was wrong, instead recommended:
>>>>          - nix develop
>>>>          https://github.com/alpmestan/ghc.nix/archive/master.tar.gz
>>>>       - Once I added the magic experimental flags…
>>>>       - It failed, with:
>>>>          - error: NAR hash mismatch in input
>>>>          'github:commercialhaskell/all-cabal-hashes/02bb1361217e690d83af9cc132b1d2bf2096763c'
>>>>          (/nix/store/zbav3qqbyz7mn7rh4iwybs0ni01ppdbj-source), expected
>>>>          'sha256-HdAnlSc4U8ftnZrBZr2CewsPQs03V9K2gkTVHKG8IfA=', got
>>>>          'sha256-86BgvJ+ebMxTp+nPxo659hsNJbhE6CYJWiIbQXX+sBM=
>>>>          - User MangoIV helped me out with this.
>>>>       - First I tried regenerating the lock file, with nix flake update
>>>>       .
>>>>          - Didn’t fix the problem.
>>>>       - Then, I checked out the branch update_flake_lock_action
>>>>          - This is apparently a branch designed to fix the problem
>>>>          - Didn’t fix the problem
>>>>       - Then I regenerated the lock file again, with nix flake update
>>>>          - That worked! Well, at least that got me to a ghc.nix prompt
>>>>       - So, I did:
>>>>          - ./boot
>>>>          - ./configure
>>>>          - cabal v2-update
>>>>          - hadrian/build -j --flavour=quick
>>>>          - It chugged along for quite a while. Sadly, it ended with
>>>>       this error:
>>>>          -
>>>>          - Linking
>>>>          /Users/lyle/Sync/devel/haskell/ghc/hadrian/dist-newstyle/build/aarch64-osx/ghc-9.2.4/hadrian-0.1.0.0/x/hadrian/build/hadrian/hadrian
>>>>          ...
>>>>          Data.Binary.Get.runGet at position 1181: Unknown encoding for
>>>>          constructor
>>>>       - What also worries me is that I thought I read somewhere that
>>>>       ghc.nix doesn’t work for cross-compilers, so even if it works
>>>>       for the native backend, it may not work for the JS backend.
>>>>
>>>>
>>>> Any help would be much appreciated!
>>>> — Lyle
>>>> _______________________________________________
>>>> ghc-devs mailing list
>>>> ghc-devs at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing listghc-devs at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>> _______________________________________________
>> 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/20230604/a79adc9d/attachment.html>

From ryan.gl.scott at gmail.com  Mon Jun  5 11:47:24 2023
From: ryan.gl.scott at gmail.com (Ryan Scott)
Date: Mon, 5 Jun 2023 07:47:24 -0400
Subject: Final Call for Talks: Haskell Implementors' Workshop 2023
Message-ID: <CADdQpRBnj37Q1DfdUqMm8mixKFae0=H6q0YdeVwR3gjYf1RZFA@mail.gmail.com>

The 2023 Haskell Implementors' Workshop deadline is just under one month
away. We are looking forward to your talk submissions.

Best,

Ryan

==================================

ACM SIGPLAN Haskell Implementors' Workshop
https://icfp23.sigplan.org/home/hiw-2023
Seattle, Washington, United States, September 4, 2023

Co-located with ICFP 2023
https://icfp23.sigplan.org/

Important dates
---------------

Deadline: July 4, 2023 (AoE)
Notification: August 4, 2023
Workshop: September 4, 2023

The 15th Haskell Implementors' Workshop is to be held alongside ICFP
2023 this year in Seattle. It is a forum for people involved in the
design and development of Haskell implementations, tools, libraries,
and supporting infrastructure to share their work and to discuss future
directions and collaborations with others.

Talks and/or demos are proposed by submitting an abstract, and
selected by a small program committee. There will be no published
proceedings. The workshop will be informal and interactive, with
open spaces in the timetable and room for ad-hoc discussion, demos,
and short lightning talks.

Scope and target audience
-------------------------

It is important to distinguish the Haskell Implementors' Workshop from
the Haskell Symposium which is also co-located with ICFP 2023. The
Haskell Symposium is for the publication of Haskell-related research. In
contrast, the Haskell Implementors' Workshop will have no proceedings --
although we will aim to make talk videos, slides, and presented data
available with the consent of the speakers.

The Implementors' Workshop is an ideal place to describe a Haskell
extension, describe works-in-progress, demo a new Haskell-related tool,
or even propose future lines of Haskell development. Members of the
wider Haskell community are encouraged to attend the workshop -- we need
your feedback to keep the Haskell ecosystem thriving. Students working
with Haskell are especially encouraged to share their work.

The scope covers any of the following topics. There may be some topics
that people feel we've missed, so by all means submit a proposal even if
it doesn't fit exactly into one of these buckets:

* Compilation techniques
* Language features and extensions
* Type system implementation
* Concurrency and parallelism: language design and implementation
* Performance, optimisation and benchmarking
* Virtual machines and run-time systems
* Libraries and tools for development or deployment

Talks
-----

We invite proposals from potential speakers for talks and
demonstrations. We are aiming for 20-minute talks with 5 minutes for
questions and changeovers. We want to hear from people writing
compilers, tools, or libraries, people with cool ideas for directions in
which we should take the platform, proposals for new features to be
implemented, and half-baked crazy ideas. Please submit a talk title and
abstract of no more than 300 words.

Submissions can be made via HotCRP at https://icfphiw23.hotcrp.com
until July 4 (anywhere on earth).

We will also have a lightning talks session. These have been very well
received in recent years, and we aim to increase the time available to
them. Lightning talks should be ~7mins and are scheduled on the day of the
workshop. Suggested topics for lightning talks are to present a single
idea, a work-in-progress project, a problem to intrigue and perplex
Haskell implementors, or simply to ask for feedback and collaborators.

Program Committee
-----------------

* Gergő Érdi (Standard Chartered Bank)
* Sebastian Graf (Karlsruhe Institute of Technology)
* Wen Kokke (University of Strathclyde)
* Ryan Scott (Galois, Inc.)
* Rebecca Skinner (Mercury)
* Li-yao Xia (University of Edinburgh)

Contact
-------

* Ryan Scott <ryan.gl.scott at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230605/3d5df434/attachment.html>

From matthewtpickering at gmail.com  Tue Jun  6 12:56:49 2023
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 6 Jun 2023 13:56:49 +0100
Subject: End of 9.2.* release series
Message-ID: <CALuQ0m_wBRKAPChj-SBcFb+1puD0pACGKxH+rwO19+pDALs65A@mail.gmail.com>

Hi all,

Just a quick message to say that we don't intend to produce any more
releases in the 9.2.* release series.

The forthcoming 9.8 release will be branched on June 16th.

Cheers,

Matt

From moritz.angermann at gmail.com  Thu Jun  8 11:42:03 2023
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 8 Jun 2023 19:42:03 +0800
Subject: Inquiry about Supporting RISC-V 32 in Haskell
In-Reply-To: <APYAmAA5F2sSJemAmeKFbarL.2.1686206637608.Hmail.shiwei.lu@compiler-dev.com>
References: <CAKfdd-w7jeXRYJ2pCC2WpzVyyRinSFvWrxOyTotMjgnEsHLpQQ@mail.gmail.com>
 <APYAmAA5F2sSJemAmeKFbarL.2.1686206637608.Hmail.shiwei.lu@compiler-dev.com>
Message-ID: <CAKfdd-yRBGswp=kAnVeJo90s-8AauBexY0_TTG1S+mJkEKZcNQ@mail.gmail.com>

Hi Shiwei,

Let me try to draw up a more visual representation do the current pipelines
over the weekend. That might also explain why I think the subset might work
as the intermediate steps *do* carry register width.

Cheers,
 Moritz

On Thu, 8 Jun 2023 at 2:44 PM, 卢诗炜 <shiwei.lu at compiler-dev.com> wrote:

> Moritz,
>
> Thank you for your detailed response. However, we think that RV32 is not a
> subset of RV64, and that the instruction selection logic for RV32 and RV64
> may differ. Because RV32 and RV64 have different register widths, it is
> sometimes necessary to use different instructions than RV64 to ensure
> correct results.
>
> We plan to support RV32 in Native Code Generation. And we may draw
> inspiration from your support for RV64.  We do want to be able to support RV32I+MAF,
> also include C extensions.
>
> Do you have any comments or suggestions?
>
> Thank you so much for your answer and help!
>
> Best regards，
>   Shiwei
>
>
>
>
> 卢诗炜
> shiwei.lu at compiler-dev.com
>
> <https://lingxi.office.163.com/static_html/signature.html?id=69484630301586661&show=>
> 签名由 网易灵犀办公 <https://hubble.netease.com/sl/aaagLd> 定制
>
>
>
> Original:
>
>    - From：moritz.angermann<moritz.angermann at gmail.com>
>    - Date：2023-06-08 09:59:38(中国(GMT+08:00))
>
>
>    - To：卢诗炜<shiwei.lu at compiler-dev.com>
>    - Cc：
>    - Subject：Re: Inquiry about Supporting RISC-V 32 in Haskell
>
>
>
> 诗炜,
>
> This is a bit hard to answer. As GHC is a fairly distributed open source
> project, everyone can effectively just contribute (by opening a Merge
> Request on gitlab.haskell.org/ghc), and then the discussion around it
> will start. There is no fixed plan as to what ends up in e.g. GHC 9.8
> (merge window will close June 16th), or even what GHC 9.10 will look like
> or when it will be release (likely the merge window will close mid
> December).
>
> GHC has various ways to generate code:
> - Via a C backend (compile Haskell to C, use a C compiler to compile to
> machine code). This backend is quite slow (compile time, and runtime)
> - Via LLVM (comile Haskell to LLVM textual IR, then use LLVM's `opt` and
> `llc` to compile it to machine code). This backend produces good performing
> code, but is very slow to compile.
> - Via Native Code Generation (this turns Haskell into assembly, and then
> uses usually the CC compiler to just turn .S into .o). This has good
> compile time performance, and often competitive runtime performance.
> However this lacks for all supposed architectures proper SIMD support.
>
> The LLVM backend can _in theory_ compile to any LLVM supported target.
> (The LLVM RV64 backend in GHC is that effectively). The Native Code
> Generator (NCG), support x86_64, i686, aarch64, and soon rv64. There are
> also powerpc, sparc and mips NCG backends, however the state of most cross
> compilation targets are only on a best effort basis and are not tested in
> CI. Since GHC 9.2 there are also JavaScript and WASM backends in GHC.
>
> If you just want to cross compile for RV32, going down the LLVM route
> might be the easiest.
>
> _my_ current plans are to work on
> - The RV64 NCG
> - The linker/loader for ELF/RV64
> - aarch32 NCG
>
> For RV32, we are in the lucky position that the instruction set is
> effectively just a subset of the RV64 instruction set. So we might be able
> to request some of the RV64 backend, or even better make the RV64 backend a
> superset of the RV32 backend.
>
> I assume you are looking to support RV32I+MAF?
>
> Happy to help with any follow up questions.
>
> Cheers,
>  Moritz
>
> On Thu, 8 Jun 2023 at 08:38, 卢诗炜 <shiwei.lu at compiler-dev.com> wrote:
>
>> Thank you for your prompt reply. We have seen the support for your team
>> working for RV64 in the GHC. You've done a great job.
>>
>>
>>
>> We'd like to do what your team does for GHC by supporting new compile
>> backends, like RV32, to contribute to the community. We are more focused
>> on  _cross compilation_  from x86_64 to RV32 on Linux. But we dont know
>> much about GHC's current dynamics and plans, whether there is a need for
>> this or whether support is being provided.
>>
>> Do we need to support RV32 for GHC? Or is there anything else you think
>> we can contribute to?
>>
>> Looking forward to your reply, Thanks!
>>
>> Best regards，
>>   Shiwei
>>
>>
>> 卢诗炜
>> shiwei.lu at compiler-dev.com
>>
>> <https://lingxi.office.163.com/static_html/signature.html?id=69484630301586661&show=>
>> 签名由 网易灵犀办公 <https://hubble.netease.com/sl/aaagLd> 定制
>>
>>
>>
>> Original:
>>
>>    - From：moritz.angermann<moritz.angermann at gmail.com>
>>    - Date：2023-06-07 19:45:32
>>    - To：卢诗炜<shiwei.lu at compiler-dev.com>
>>    - Cc：
>>    - Subject：Re: Inquiry about Supporting RISC-V 32 in Haskell
>>
>> 您好诗炜！
>> 对不起，我的中文不很好。写英语。
>> I assume you've found my email from the ghc source repo? Yes, I have
>> extensive experience adding compiler backends to GHC, including GHC's
>> internal static linker.
>> Recently a friend and I have started working on RV64 support in GHC (See
>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10367). So we have
>> some prior experience
>> with RISC-V.
>>
>> I understand you want to have support for RV32 in ghc? Are you looking
>> for _native_ RV32 support GHC the compiler running natively on RISC-V 32
>> hardware? Or are you
>> primarily interested in _cross compilation_ to RV32 from e.g. RV64,
>> x86_64, aarch64?
>>
>> Also which platform are you interested in? Linux?
>>
>> Happy to provide more concrete feedback based on your exact requirements
>> and vision. Ultimately GHC is a community project and everyone can
>> contribute. I can certainly
>> provide guidance and assistance here.
>>
>> Cheers,
>>  Moritz
>>
>> On Wed, 7 Jun 2023 at 18:16, 卢诗炜 <shiwei.lu at compiler-dev.com> wrote:
>>
>>> Dear Moritz Angermann，
>>>
>>> Hello! I am writing on behalf of Hunan Compiler Technology Co., Ltd. to
>>> inquire about the possibility of supporting RISC-V 32 in Haskell o
>>>
>>> r if you're supporting it
>>> . We are a technology company based in China and we would like to
>>> contribute to the Haskell community by providing support for this
>>> architecture.
>>>
>>> As you may know, RISC-V is an open-source instruction set architecture
>>> that is gaining popularity in the industry. It is important for us to
>>> ensure that our products are compatible with this architecture, and we
>>> believe that supporting RISC-V in Haskell would be a valuable contribution
>>> to the community.
>>>
>>>
>>> We are willing to work closely with the community to understand the
>>> requirements and challenges of supporting RISC-V in Haskell. We have a team
>>> of experienced engineers who are familiar with both Haskell and RISC-V, and
>>> we are confident that we can provide high-quality support for this
>>> architecture.
>>>
>>>
>>> We would appreciate any guidance or feedback from the community on this
>>> matter. Please let us know if there are any specific requirements or
>>> challenges that we should be aware of. We look forward to working with the
>>> Haskell community to support RISC-V.
>>>
>>>
>>> Thank you for your time and consideration.
>>>
>>>
>>> Sincerely, Shiwei LU, Hunan Compiler Technology Co., Ltd.
>>>
>>>
>>>
>>> <https://lingxi.office.163.com/static_html/signature.html?id=69484630301586661&show=>
>>>
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230608/7572b881/attachment.html>

From hecate at glitchbra.in  Tue Jun 13 13:55:58 2023
From: hecate at glitchbra.in (=?UTF-8?Q?H=c3=a9cate?=)
Date: Tue, 13 Jun 2023 15:55:58 +0200
Subject: GHCi tags generation: the end
Message-ID: <e2570196-d629-c072-81bb-ecdebf2fe87d@glitchbra.in>

Hello everyone,

As the three-releases deprecation cycle has come to an end, GHC 9.8 
marks the end of the integrated tags generation feature that used to 
live in GHCi. Started in 2020, the deprecation proposal showed that many 
people didn't know about its existence, and favoured external tools.

It is also a burden that is removed from the shoulders of GHC 
developers, as it used to create friction with other features like 
UnboxedSums.

You can find the proposal here: 
https://gitlab.haskell.org/ghc/ghc/-/issues/19884
and the migration wiki page here: 
https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/GHCi/Tags

Thanks to everyone who was involved in this, especially Emily Martins.

Cheers,
Hécate

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


From sgraf1337 at gmail.com  Tue Jun 13 18:26:38 2023
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Tue, 13 Jun 2023 18:26:38 +0000
Subject: Minutes of Sunday's meeting of the "Staged Working Group"
Message-ID: <em12136097-4674-440d-8e45-54c2a7a620d0@sebastian-pc>

Hi GHC devs,

On Sunday I realised that there were many different people around at 
ZuriHac that are very knowledgeable about staged metaprogramming and 
macro systems (outside GHC, even).
I really want a good staged metaprogramming story in Haskell (but don't 
know much about it or what I could contribute), and so I called everyone 
into a very spontaneous meeting, dubbed the "Staged Working Group".
The purpose of the whole meeting was rather nebulous (staged, even); the 
only goal for me was to throw involved people in one room to have a 
focussed discussion (rather than lumping together with a subset of the 
people and then dissolving in the hall way) and to talk about different 
efforts in the community.
In the end, I think we got a lot clearer picture about the challenges 
involved.

We are very fortunate that Ben has kept minutes with useful pointers: 
https://edit.smart-cactus.org/u__IGA1bTd2DpulYmlnxaw

Note that I don't intend to hold regular meetings or something of the 
sort; it was essentially a one time thing (but perhaps we'll have a 2.0 
meeting at next year's ZuriHac).
We loosely agreed to keep everyone posted on ongoing efforts in the 
direction of staged metaprogramming (and macros) by writing short status 
reports to this mailing list.

Thanks to everyone who is involved in improving (Typed) Template Haskell 
and who was there on Sunday!
Sebastian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230613/8ed04ba0/attachment.html>

From bryan at haskell.foundation  Wed Jun 14 12:58:45 2023
From: bryan at haskell.foundation (Bryan Richter)
Date: Wed, 14 Jun 2023 15:58:45 +0300
Subject: Inquiry about Supporting RISC-V 32 in Haskell
In-Reply-To: <CAKfdd-yRBGswp=kAnVeJo90s-8AauBexY0_TTG1S+mJkEKZcNQ@mail.gmail.com>
References: <CAKfdd-w7jeXRYJ2pCC2WpzVyyRinSFvWrxOyTotMjgnEsHLpQQ@mail.gmail.com>
 <APYAmAA5F2sSJemAmeKFbarL.2.1686206637608.Hmail.shiwei.lu@compiler-dev.com>
 <CAKfdd-yRBGswp=kAnVeJo90s-8AauBexY0_TTG1S+mJkEKZcNQ@mail.gmail.com>
Message-ID: <CACUTo6wqW2_Sjgdmm8T2eu+TO9f_CaEPMDNH8PbTiY4dbcZ8PA@mail.gmail.com>

Hello!

I can't assist with RISC-V, but let me know if you have any trouble with
https://gitlab.haskell.org. In particular, approving accounts is currently
a manual process. When you create an account, let me know the username, and
I will approve it.

Best wishes,

-Bryan

On Thu, 8 Jun 2023 at 14:42, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Hi Shiwei,
>
> Let me try to draw up a more visual representation do the current
> pipelines over the weekend. That might also explain why I think the subset
> might work as the intermediate steps *do* carry register width.
>
> Cheers,
>  Moritz
>
> On Thu, 8 Jun 2023 at 2:44 PM, 卢诗炜 <shiwei.lu at compiler-dev.com> wrote:
>
>> Moritz,
>>
>> Thank you for your detailed response. However, we think that RV32 is not
>> a subset of RV64, and that the instruction selection logic for RV32 and
>> RV64 may differ. Because RV32 and RV64 have different register widths, it
>> is sometimes necessary to use different instructions than RV64 to ensure
>> correct results.
>>
>> We plan to support RV32 in Native Code Generation. And we may draw
>> inspiration from your support for RV64.  We do want to be able to support RV32I+MAF,
>> also include C extensions.
>>
>> Do you have any comments or suggestions?
>>
>> Thank you so much for your answer and help!
>>
>> Best regards，
>>   Shiwei
>>
>>
>>
>>
>> 卢诗炜
>> shiwei.lu at compiler-dev.com
>>
>> <https://lingxi.office.163.com/static_html/signature.html?id=69484630301586661&show=>
>> 签名由 网易灵犀办公 <https://hubble.netease.com/sl/aaagLd> 定制
>>
>>
>>
>> Original:
>>
>>    - From：moritz.angermann<moritz.angermann at gmail.com>
>>    - Date：2023-06-08 09:59:38(中国(GMT+08:00))
>>
>>
>>    - To：卢诗炜<shiwei.lu at compiler-dev.com>
>>    - Cc：
>>    - Subject：Re: Inquiry about Supporting RISC-V 32 in Haskell
>>
>>
>>
>> 诗炜,
>>
>> This is a bit hard to answer. As GHC is a fairly distributed open source
>> project, everyone can effectively just contribute (by opening a Merge
>> Request on gitlab.haskell.org/ghc), and then the discussion around it
>> will start. There is no fixed plan as to what ends up in e.g. GHC 9.8
>> (merge window will close June 16th), or even what GHC 9.10 will look like
>> or when it will be release (likely the merge window will close mid
>> December).
>>
>> GHC has various ways to generate code:
>> - Via a C backend (compile Haskell to C, use a C compiler to compile to
>> machine code). This backend is quite slow (compile time, and runtime)
>> - Via LLVM (comile Haskell to LLVM textual IR, then use LLVM's `opt` and
>> `llc` to compile it to machine code). This backend produces good performing
>> code, but is very slow to compile.
>> - Via Native Code Generation (this turns Haskell into assembly, and then
>> uses usually the CC compiler to just turn .S into .o). This has good
>> compile time performance, and often competitive runtime performance.
>> However this lacks for all supposed architectures proper SIMD support.
>>
>> The LLVM backend can _in theory_ compile to any LLVM supported target.
>> (The LLVM RV64 backend in GHC is that effectively). The Native Code
>> Generator (NCG), support x86_64, i686, aarch64, and soon rv64. There are
>> also powerpc, sparc and mips NCG backends, however the state of most cross
>> compilation targets are only on a best effort basis and are not tested in
>> CI. Since GHC 9.2 there are also JavaScript and WASM backends in GHC.
>>
>> If you just want to cross compile for RV32, going down the LLVM route
>> might be the easiest.
>>
>> _my_ current plans are to work on
>> - The RV64 NCG
>> - The linker/loader for ELF/RV64
>> - aarch32 NCG
>>
>> For RV32, we are in the lucky position that the instruction set is
>> effectively just a subset of the RV64 instruction set. So we might be able
>> to request some of the RV64 backend, or even better make the RV64 backend a
>> superset of the RV32 backend.
>>
>> I assume you are looking to support RV32I+MAF?
>>
>> Happy to help with any follow up questions.
>>
>> Cheers,
>>  Moritz
>>
>> On Thu, 8 Jun 2023 at 08:38, 卢诗炜 <shiwei.lu at compiler-dev.com> wrote:
>>
>>> Thank you for your prompt reply. We have seen the support for your team
>>> working for RV64 in the GHC. You've done a great job.
>>>
>>>
>>>
>>> We'd like to do what your team does for GHC by supporting new compile
>>> backends, like RV32, to contribute to the community. We are more
>>> focused on  _cross compilation_  from x86_64 to RV32 on Linux. But we dont
>>> know much about GHC's current dynamics and plans, whether there is a need
>>> for this or whether support is being provided.
>>>
>>> Do we need to support RV32 for GHC? Or is there anything else you think
>>> we can contribute to?
>>>
>>> Looking forward to your reply, Thanks!
>>>
>>> Best regards，
>>>   Shiwei
>>>
>>>
>>> 卢诗炜
>>> shiwei.lu at compiler-dev.com
>>>
>>> <https://lingxi.office.163.com/static_html/signature.html?id=69484630301586661&show=>
>>> 签名由 网易灵犀办公 <https://hubble.netease.com/sl/aaagLd> 定制
>>>
>>>
>>>
>>> Original:
>>>
>>>    - From：moritz.angermann<moritz.angermann at gmail.com>
>>>    - Date：2023-06-07 19:45:32
>>>    - To：卢诗炜<shiwei.lu at compiler-dev.com>
>>>    - Cc：
>>>    - Subject：Re: Inquiry about Supporting RISC-V 32 in Haskell
>>>
>>> 您好诗炜！
>>> 对不起，我的中文不很好。写英语。
>>> I assume you've found my email from the ghc source repo? Yes, I have
>>> extensive experience adding compiler backends to GHC, including GHC's
>>> internal static linker.
>>> Recently a friend and I have started working on RV64 support in GHC (See
>>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10367). So we have
>>> some prior experience
>>> with RISC-V.
>>>
>>> I understand you want to have support for RV32 in ghc? Are you looking
>>> for _native_ RV32 support GHC the compiler running natively on RISC-V 32
>>> hardware? Or are you
>>> primarily interested in _cross compilation_ to RV32 from e.g. RV64,
>>> x86_64, aarch64?
>>>
>>> Also which platform are you interested in? Linux?
>>>
>>> Happy to provide more concrete feedback based on your exact requirements
>>> and vision. Ultimately GHC is a community project and everyone can
>>> contribute. I can certainly
>>> provide guidance and assistance here.
>>>
>>> Cheers,
>>>  Moritz
>>>
>>> On Wed, 7 Jun 2023 at 18:16, 卢诗炜 <shiwei.lu at compiler-dev.com> wrote:
>>>
>>>> Dear Moritz Angermann，
>>>>
>>>> Hello! I am writing on behalf of Hunan Compiler Technology Co., Ltd.
>>>> to inquire about the possibility of supporting RISC-V 32 in Haskell o
>>>>
>>>> r if you're supporting it
>>>> . We are a technology company based in China and we would like to
>>>> contribute to the Haskell community by providing support for this
>>>> architecture.
>>>>
>>>> As you may know, RISC-V is an open-source instruction set architecture
>>>> that is gaining popularity in the industry. It is important for us to
>>>> ensure that our products are compatible with this architecture, and we
>>>> believe that supporting RISC-V in Haskell would be a valuable contribution
>>>> to the community.
>>>>
>>>>
>>>> We are willing to work closely with the community to understand the
>>>> requirements and challenges of supporting RISC-V in Haskell. We have a team
>>>> of experienced engineers who are familiar with both Haskell and RISC-V, and
>>>> we are confident that we can provide high-quality support for this
>>>> architecture.
>>>>
>>>>
>>>> We would appreciate any guidance or feedback from the community on this
>>>> matter. Please let us know if there are any specific requirements or
>>>> challenges that we should be aware of. We look forward to working with the
>>>> Haskell community to support RISC-V.
>>>>
>>>>
>>>> Thank you for your time and consideration.
>>>>
>>>>
>>>> Sincerely, Shiwei LU, Hunan Compiler Technology Co., Ltd.
>>>>
>>>>
>>>>
>>>> <https://lingxi.office.163.com/static_html/signature.html?id=69484630301586661&show=>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>> _______________________________________________
> 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/20230614/0f0fb220/attachment.html>

From matthewtpickering at gmail.com  Mon Jun 19 21:03:11 2023
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Mon, 19 Jun 2023 22:03:11 +0100
Subject: Improving Merge Request review processes
Message-ID: <CALuQ0m-Mdi02WTvBydvGhZvmqN+xhVvpaVXTUE1m=WEwgV-vzA@mail.gmail.com>

Hi all,

Recently there has been some discussion about better systems and
processes for keeping the flow of merge requests going smoothly
through the review process. It has become clear that we need to be a
bit more deliberate in handling merge requests in order to make sure
we can correctly triage, review and merge the many fantastic
contributions we get to GHC on a daily basis.

Therefore we are proposing to introduce a "GHC Reviewer Group" whose
members will share collective responsibility for ensuring that MRs
make their way smoothly from creation to merge.

The description of the role and responsibility for this group can be
read and commented on here:

https://docs.google.com/document/d/1FK9mryjC82DM6e5yxP7BOgu94As2bXccb55L8OrjPf4/edit?usp=sharing

The motivation for this proposal is two-fold.

* Ensuring that MRs are reviewed and triaged in a timely manner.
* Documenting where the responsibility for MR reviewing

We welcome any discussion about this document and other ideas about
how to improve the systems in this regard.

Cheers,

Matt

From simon.peytonjones at gmail.com  Thu Jun 22 10:15:28 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Thu, 22 Jun 2023 11:15:28 +0100
Subject: SSH on Gitlab
Message-ID: <CAJKmMz-=1w9_rt1_iXD7h4RS=0-QY7hNT2TkDj=5LavL+=AWiQ@mail.gmail.com>

Is SSH working on gitlab.haskell.org?  I'm getting this

simonpj at CDW-8FABODHF0V5:~$ ssh -v git at gitlab.haskell.org
OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /home/simonpj/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf
matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to gitlab.haskell.org [145.40.64.137] port 22.
debug1: Connection established.
debug1: identity file /home/simonpj/.ssh/id_rsa type 0
debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1
debug1: identity file /home/simonpj/.ssh/id_dsa type 1
debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1
debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1
debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/simonpj/.ssh/id_ed25519 type 3
debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1
debug1: identity file /home/simonpj/.ssh/id_ed25519_sk type -1
debug1: identity file /home/simonpj/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/simonpj/.ssh/id_xmss type -1
debug1: identity file /home/simonpj/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4

At this point it hangs.  Stackoverflow suggests
<https://superuser.com/questions/1374076/what-does-it-mean-if-ssh-hangs-after-connection-established>a
server fault.  But I'm on a new WLAN so I suppose there could be some
bizarre filtering?

Thanks

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

From tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk  Thu Jun 22 10:38:03 2023
From: tom-lists-haskell-cafe-2017 at jaguarpaw.co.uk (Tom Ellis)
Date: Thu, 22 Jun 2023 11:38:03 +0100
Subject: SSH on Gitlab
In-Reply-To: <CAJKmMz-=1w9_rt1_iXD7h4RS=0-QY7hNT2TkDj=5LavL+=AWiQ@mail.gmail.com>
References: <CAJKmMz-=1w9_rt1_iXD7h4RS=0-QY7hNT2TkDj=5LavL+=AWiQ@mail.gmail.com>
Message-ID: <ZJQki1PU9wFfH5+A@cloudinit-builder>

FWIW if I try the same command I get all the way through to a normal
exit (which I guess is expected since you're not supposed to be able
to actually obtain a shell via ssh!) so I guess the problem is
specific to you, Simon.

Tom



OpenSSH_8.4p1 Debian-5+deb11u1, OpenSSL 1.1.1n  15 Mar 2022
debug1: Reading configuration data /home/tom/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to gitlab.haskell.org [2604:1380:61:2300::1] port 22.
debug1: Connection established.
debug1: identity file <redacted>
debug1: Local version string SSH-2.0-OpenSSH_8.4p1 Debian-5+deb11u1
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.1
debug1: match: OpenSSH_9.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to gitlab.haskell.org:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-ed25519 SHA256:/dI7zsBRZNPB+0TqskF7rSaZ/LhQw0cF4c5W+4uMlRo
debug1: Host 'gitlab.haskell.org' is known and matches the ED25519 host key.
debug1: Found key in <redacted>
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: <redacted>
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519 at openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256 at openssh.com,webauthn-sk-ecdsa-sha2-nistp256 at openssh.com>
debug1: kex_input_ext_info: publickey-hostbound at openssh.com (unrecognised)
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: <redacted>
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Offering public key: <redacted>
debug1: Server accepts key: <redacted>
debug1: Authentication succeeded (publickey).
Authenticated to gitlab.haskell.org ([2604:1380:61:2300::1]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions at openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00 at openssh.com want_reply 0
debug1: Remote: /var/gitlab/state/home/.ssh/authorized_keys:857: key options: command user-rc
debug1: Remote: /var/gitlab/state/home/.ssh/authorized_keys:857: key options: command user-rc
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
PTY allocation request failed on channel 0
Welcome to GitLab, @tomjaguarpaw1!
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow at openssh.com reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to gitlab.haskell.org closed.
Transferred: sent 3296, received 2832 bytes, in 0.4 seconds
Bytes per second: sent 9134.7, received 7848.7
debug1: Exit status 0



On Thu, Jun 22, 2023 at 11:15:28AM +0100, Simon Peyton Jones wrote:
> Is SSH working on gitlab.haskell.org?  I'm getting this
> 
> simonpj at CDW-8FABODHF0V5:~$ ssh -v git at gitlab.haskell.org
> OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f  31 Mar 2020
> debug1: Reading configuration data /home/simonpj/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf
> matched no files
> debug1: /etc/ssh/ssh_config line 21: Applying options for *
> debug1: Connecting to gitlab.haskell.org [145.40.64.137] port 22.
> debug1: Connection established.
> debug1: identity file /home/simonpj/.ssh/id_rsa type 0
> debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_dsa type 1
> debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ed25519 type 3
> debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ed25519_sk type -1
> debug1: identity file /home/simonpj/.ssh/id_ed25519_sk-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_xmss type -1
> debug1: identity file /home/simonpj/.ssh/id_xmss-cert type -1
> debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4
> 
> At this point it hangs.  Stackoverflow suggests
> <https://superuser.com/questions/1374076/what-does-it-mean-if-ssh-hangs-after-connection-established>a
> server fault.  But I'm on a new WLAN so I suppose there could be some
> bizarre filtering?

From bryan at haskell.foundation  Thu Jun 22 15:15:13 2023
From: bryan at haskell.foundation (Bryan Richter)
Date: Thu, 22 Jun 2023 18:15:13 +0300
Subject: SSH on Gitlab
In-Reply-To: <CAJKmMz-=1w9_rt1_iXD7h4RS=0-QY7hNT2TkDj=5LavL+=AWiQ@mail.gmail.com>
References: <CAJKmMz-=1w9_rt1_iXD7h4RS=0-QY7hNT2TkDj=5LavL+=AWiQ@mail.gmail.com>
Message-ID: <CACUTo6zVgkOH0YD-5rNZGWUfmgtJjQjnUb_-UQwPuK3voZnB+g@mail.gmail.com>

Hi Simon,

I'm on vacation this week and can't help or attempt to reproduce. I
suspect, however, this is going to get better on its own. Any evidence for
or against intermittent network issues that anyone can provide, now or any
other time, would help me look into this later. For example, are there
correlations between ssh and website issues? Does CI have network issues at
the same time? Etc.

Good luck.

On Thu, 22 Jun 2023, 13.15 Simon Peyton Jones, <simon.peytonjones at gmail.com>
wrote:

> Is SSH working on gitlab.haskell.org?  I'm getting this
>
> simonpj at CDW-8FABODHF0V5:~$ ssh -v git at gitlab.haskell.org
> OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f  31 Mar 2020
> debug1: Reading configuration data /home/simonpj/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf
> matched no files
> debug1: /etc/ssh/ssh_config line 21: Applying options for *
> debug1: Connecting to gitlab.haskell.org [145.40.64.137] port 22.
> debug1: Connection established.
> debug1: identity file /home/simonpj/.ssh/id_rsa type 0
> debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_dsa type 1
> debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ed25519 type 3
> debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ed25519_sk type -1
> debug1: identity file /home/simonpj/.ssh/id_ed25519_sk-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_xmss type -1
> debug1: identity file /home/simonpj/.ssh/id_xmss-cert type -1
> debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4
>
> At this point it hangs.  Stackoverflow suggests
> <https://superuser.com/questions/1374076/what-does-it-mean-if-ssh-hangs-after-connection-established>a
> server fault.  But I'm on a new WLAN so I suppose there could be some
> bizarre filtering?
>
> Thanks
>
> Simon
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230622/f68c5f7e/attachment.html>

From ben at smart-cactus.org  Thu Jun 22 15:42:20 2023
From: ben at smart-cactus.org (Ben Gamari)
Date: Thu, 22 Jun 2023 11:42:20 -0400
Subject: SSH on Gitlab
In-Reply-To: <CAJKmMz-=1w9_rt1_iXD7h4RS=0-QY7hNT2TkDj=5LavL+=AWiQ@mail.gmail.com>
References: <CAJKmMz-=1w9_rt1_iXD7h4RS=0-QY7hNT2TkDj=5LavL+=AWiQ@mail.gmail.com>
Message-ID: <87v8ffqzbe.fsf@smart-cactus.org>

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

> Is SSH working on gitlab.haskell.org?  I'm getting this
>
> simonpj at CDW-8FABODHF0V5:~$ ssh -v git at gitlab.haskell.org
> OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f  31 Mar 2020
> debug1: Reading configuration data /home/simonpj/.ssh/config
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf
> matched no files
> debug1: /etc/ssh/ssh_config line 21: Applying options for *
> debug1: Connecting to gitlab.haskell.org [145.40.64.137] port 22.
> debug1: Connection established.
> debug1: identity file /home/simonpj/.ssh/id_rsa type 0
> debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_dsa type 1
> debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk type -1
> debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ed25519 type 3
> debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_ed25519_sk type -1
> debug1: identity file /home/simonpj/.ssh/id_ed25519_sk-cert type -1
> debug1: identity file /home/simonpj/.ssh/id_xmss type -1
> debug1: identity file /home/simonpj/.ssh/id_xmss-cert type -1
> debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4
>
> At this point it hangs.  Stackoverflow suggests
> <https://superuser.com/questions/1374076/what-does-it-mean-if-ssh-hangs-after-connection-established>a
> server fault.  But I'm on a new WLAN so I suppose there could be some
> bizarre filtering?
>
I suspect this may be a filtering issue. Like Tom, I am able to connect
without issue. A Wireshark trace [1] may help shed light on the
situation. Happy to have a call to debug if this would be helpful.

Cheers,

- Ben


[1] https://www.wireshark.org/
-------------- 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/20230622/c01b3d87/attachment.sig>

From matthewtpickering at gmail.com  Fri Jun 23 10:14:03 2023
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 23 Jun 2023 11:14:03 +0100
Subject: Improving Merge Request review processes
In-Reply-To: <CALuQ0m-Mdi02WTvBydvGhZvmqN+xhVvpaVXTUE1m=WEwgV-vzA@mail.gmail.com>
References: <CALuQ0m-Mdi02WTvBydvGhZvmqN+xhVvpaVXTUE1m=WEwgV-vzA@mail.gmail.com>
Message-ID: <CALuQ0m-0wcQSHSA3myqOvQs=FHbTRmi3eDxcSzwqAnb31YXJWA@mail.gmail.com>

We discussed this in the meeting on Tuesday.

The conclusion was that

* We now have a new label "Blocked on Review", which people can add to
merge requests if they are blocked waiting for a review.
* The "Reviewer Group" is taken to be the same as the "GHC Team" (see
https://gitlab.haskell.org/ghc/ghc-hq/-/tree/main), hence people
trusted to be part of the GHC team are expected to perform review as
well.
* We will take up some of the time on the Tuesday meeting by talking
about merge requests which are blocked and assigning them to people
for review.

Cheers,

Matt

On Mon, Jun 19, 2023 at 10:03 PM Matthew Pickering
<matthewtpickering at gmail.com> wrote:
>
> Hi all,
>
> Recently there has been some discussion about better systems and
> processes for keeping the flow of merge requests going smoothly
> through the review process. It has become clear that we need to be a
> bit more deliberate in handling merge requests in order to make sure
> we can correctly triage, review and merge the many fantastic
> contributions we get to GHC on a daily basis.
>
> Therefore we are proposing to introduce a "GHC Reviewer Group" whose
> members will share collective responsibility for ensuring that MRs
> make their way smoothly from creation to merge.
>
> The description of the role and responsibility for this group can be
> read and commented on here:
>
> https://docs.google.com/document/d/1FK9mryjC82DM6e5yxP7BOgu94As2bXccb55L8OrjPf4/edit?usp=sharing
>
> The motivation for this proposal is two-fold.
>
> * Ensuring that MRs are reviewed and triaged in a timely manner.
> * Documenting where the responsibility for MR reviewing
>
> We welcome any discussion about this document and other ideas about
> how to improve the systems in this regard.
>
> Cheers,
>
> Matt

From simon.peytonjones at gmail.com  Fri Jun 23 10:25:41 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 23 Jun 2023 11:25:41 +0100
Subject: Improving Merge Request review processes
In-Reply-To: <CALuQ0m-0wcQSHSA3myqOvQs=FHbTRmi3eDxcSzwqAnb31YXJWA@mail.gmail.com>
References: <CALuQ0m-Mdi02WTvBydvGhZvmqN+xhVvpaVXTUE1m=WEwgV-vzA@mail.gmail.com>
 <CALuQ0m-0wcQSHSA3myqOvQs=FHbTRmi3eDxcSzwqAnb31YXJWA@mail.gmail.com>
Message-ID: <CAJKmMz_uN-JNcSiofZwMDxYMYQLvZQuP1iuvLcjJOODKUOcG5g@mail.gmail.com>

Terrific.

We just need to add some guidance for contributors about when and how to
use the new tag.

Where should that guidance live?  We have the Contributing to GHC wiki page
<https://gitlab.haskell.org/ghc/ghc/-/wikis/contributing>.  It in turn (not
very prominently) points to Contributing a patch
<https://gitlab.haskell.org/ghc/ghc/-/wikis/Contributing-a-Patch>.  Are
these our primary pages?  If so, perhaps the latter is the one to edit?

Simon



On Fri, 23 Jun 2023 at 11:14, Matthew Pickering <matthewtpickering at gmail.com>
wrote:

> We discussed this in the meeting on Tuesday.
>
> The conclusion was that
>
> * We now have a new label "Blocked on Review", which people can add to
> merge requests if they are blocked waiting for a review.
> * The "Reviewer Group" is taken to be the same as the "GHC Team" (see
> https://gitlab.haskell.org/ghc/ghc-hq/-/tree/main), hence people
> trusted to be part of the GHC team are expected to perform review as
> well.
> * We will take up some of the time on the Tuesday meeting by talking
> about merge requests which are blocked and assigning them to people
> for review.
>
> Cheers,
>
> Matt
>
> On Mon, Jun 19, 2023 at 10:03 PM Matthew Pickering
> <matthewtpickering at gmail.com> wrote:
> >
> > Hi all,
> >
> > Recently there has been some discussion about better systems and
> > processes for keeping the flow of merge requests going smoothly
> > through the review process. It has become clear that we need to be a
> > bit more deliberate in handling merge requests in order to make sure
> > we can correctly triage, review and merge the many fantastic
> > contributions we get to GHC on a daily basis.
> >
> > Therefore we are proposing to introduce a "GHC Reviewer Group" whose
> > members will share collective responsibility for ensuring that MRs
> > make their way smoothly from creation to merge.
> >
> > The description of the role and responsibility for this group can be
> > read and commented on here:
> >
> >
> https://docs.google.com/document/d/1FK9mryjC82DM6e5yxP7BOgu94As2bXccb55L8OrjPf4/edit?usp=sharing
> >
> > The motivation for this proposal is two-fold.
> >
> > * Ensuring that MRs are reviewed and triaged in a timely manner.
> > * Documenting where the responsibility for MR reviewing
> >
> > We welcome any discussion about this document and other ideas about
> > how to improve the systems in this regard.
> >
> > Cheers,
> >
> > 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/20230623/24cfac72/attachment.html>

From matthewtpickering at gmail.com  Fri Jun 23 15:40:19 2023
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 23 Jun 2023 16:40:19 +0100
Subject: Improving Merge Request review processes
In-Reply-To: <CAJKmMz_uN-JNcSiofZwMDxYMYQLvZQuP1iuvLcjJOODKUOcG5g@mail.gmail.com>
References: <CALuQ0m-Mdi02WTvBydvGhZvmqN+xhVvpaVXTUE1m=WEwgV-vzA@mail.gmail.com>
 <CALuQ0m-0wcQSHSA3myqOvQs=FHbTRmi3eDxcSzwqAnb31YXJWA@mail.gmail.com>
 <CAJKmMz_uN-JNcSiofZwMDxYMYQLvZQuP1iuvLcjJOODKUOcG5g@mail.gmail.com>
Message-ID: <CALuQ0m9f6tnR6mT_q5-gnZmQXM3hG21MANgo5D+bq2HLdsB_uQ@mail.gmail.com>

I have modified the MR template -
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10709

and updated the wiki page that simon points out.

Matt

On Fri, Jun 23, 2023 at 11:25 AM Simon Peyton Jones
<simon.peytonjones at gmail.com> wrote:
>
> Terrific.
>
> We just need to add some guidance for contributors about when and how to use the new tag.
>
> Where should that guidance live?  We have the Contributing to GHC wiki page.  It in turn (not very prominently) points to Contributing a patch.  Are these our primary pages?  If so, perhaps the latter is the one to edit?
>
> Simon
>
>
>
> On Fri, 23 Jun 2023 at 11:14, Matthew Pickering <matthewtpickering at gmail.com> wrote:
>>
>> We discussed this in the meeting on Tuesday.
>>
>> The conclusion was that
>>
>> * We now have a new label "Blocked on Review", which people can add to
>> merge requests if they are blocked waiting for a review.
>> * The "Reviewer Group" is taken to be the same as the "GHC Team" (see
>> https://gitlab.haskell.org/ghc/ghc-hq/-/tree/main), hence people
>> trusted to be part of the GHC team are expected to perform review as
>> well.
>> * We will take up some of the time on the Tuesday meeting by talking
>> about merge requests which are blocked and assigning them to people
>> for review.
>>
>> Cheers,
>>
>> Matt
>>
>> On Mon, Jun 19, 2023 at 10:03 PM Matthew Pickering
>> <matthewtpickering at gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > Recently there has been some discussion about better systems and
>> > processes for keeping the flow of merge requests going smoothly
>> > through the review process. It has become clear that we need to be a
>> > bit more deliberate in handling merge requests in order to make sure
>> > we can correctly triage, review and merge the many fantastic
>> > contributions we get to GHC on a daily basis.
>> >
>> > Therefore we are proposing to introduce a "GHC Reviewer Group" whose
>> > members will share collective responsibility for ensuring that MRs
>> > make their way smoothly from creation to merge.
>> >
>> > The description of the role and responsibility for this group can be
>> > read and commented on here:
>> >
>> > https://docs.google.com/document/d/1FK9mryjC82DM6e5yxP7BOgu94As2bXccb55L8OrjPf4/edit?usp=sharing
>> >
>> > The motivation for this proposal is two-fold.
>> >
>> > * Ensuring that MRs are reviewed and triaged in a timely manner.
>> > * Documenting where the responsibility for MR reviewing
>> >
>> > We welcome any discussion about this document and other ideas about
>> > how to improve the systems in this regard.
>> >
>> > Cheers,
>> >
>> > Matt
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

From nicolas.frisby at gmail.com  Fri Jun 23 16:17:22 2023
From: nicolas.frisby at gmail.com (Nicolas Frisby)
Date: Fri, 23 Jun 2023 12:17:22 -0400
Subject: Minutes of Sunday's meeting of the "Staged Working Group"
In-Reply-To: <em12136097-4674-440d-8e45-54c2a7a620d0@sebastian-pc>
References: <em12136097-4674-440d-8e45-54c2a7a620d0@sebastian-pc>
Message-ID: <CADfHYo5wixSUPr6NuGayLMifUtjGZiq1BeM-PidXRJ9r+tq90g@mail.gmail.com>

I enjoyed reading the notes; thanks for sharing.

One thing that would help me: Can we get last names in the notes in
addition to first names? Or even just add a list of the (mentioned)
attendees?

Thanks!

On Tue, Jun 13, 2023, 14:26 Sebastian Graf <sgraf1337 at gmail.com> wrote:

> Hi GHC devs,
>
> On Sunday I realised that there were many different people around at
> ZuriHac that are very knowledgeable about staged metaprogramming and macro
> systems (outside GHC, even).
> I really want a good staged metaprogramming story in Haskell (but don't
> know much about it or what I could contribute), and so I called everyone
> into a very spontaneous meeting, dubbed the "Staged Working Group".
> The purpose of the whole meeting was rather nebulous (staged, even); the
> only goal for me was to throw involved people in one room to have a
> focussed discussion (rather than lumping together with a subset of the
> people and then dissolving in the hall way) and to talk about different
> efforts in the community.
> In the end, I think we got a lot clearer picture about the challenges
> involved.
>
> We are very fortunate that Ben has kept minutes with useful pointers:
> https://edit.smart-cactus.org/u__IGA1bTd2DpulYmlnxaw
>
> Note that I don't intend to hold regular meetings or something of the
> sort; it was essentially a one time thing (but perhaps we'll have a 2.0
> meeting at next year's ZuriHac).
> We loosely agreed to keep everyone posted on ongoing efforts in the
> direction of staged metaprogramming (and macros) by writing short status
> reports to this mailing list.
>
> Thanks to everyone who is involved in improving (Typed) Template Haskell
> and who was there on Sunday!
> Sebastian
> _______________________________________________
> 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/20230623/2f72daf2/attachment.html>

From lexi.lambda at gmail.com  Mon Jun 26 20:20:49 2023
From: lexi.lambda at gmail.com (Alexis King)
Date: Mon, 26 Jun 2023 15:20:49 -0500
Subject: Distinct closure types vs. known infotables for stack frames
Message-ID: <CAA8dsadwcgmg6+GKR+kV7myNxvaYZ_+Vwir+dndNKx59AteZhA@mail.gmail.com>

Hello all,

I am tinkering with the RTS again while trying to fix #23513
<https://gitlab.haskell.org/ghc/ghc/-/issues/23513>, and every time I touch
the exceptions/continuations code, I find myself waffling about whether to
introduce more closure types. I’d like to get a second opinion so I can
stop changing my mind!

Currently, we have distinct closure types for certain special stack frames,
like CATCH_FRAME, ATOMICALLY_FRAME, and UNDERFLOW_FRAME. However, there are
other special stack frames that *don’t* get their own closure types: there
is no MASK_ASYNC_EXCEPTIONS_FRAME or PROMPT_FRAME. Instead, when code needs
to recognize these frames on the stack, it just looks for a known infotable
pointer. That is, instead of writing

if (frame->header.info->i.type == PROMPT_FRAME) { ... }

we write

if (*frame == &stg_prompt_frame_info) { ... }

which works out because there’s only one info table that’s used for all
prompt frames.

There are a handful of stack frames that are recognized in this way by some
part of the RTS, but the criteria used to determine which frames get their
own types and which don’t is not particularly clear. For some frames, like
UPDATE_FRAME, the closure type is necessary because it is shared between
several infotables. But other types, like CATCH_FRAME and UNDERFLOW_FRAME,
are only ever used by precisely one infotable.

I think one can make the following arguments for/against using separate
closure types for these stack frames:

   -

   Pro: It’s helpful to have separate types for particularly special frames
   like UNDERFLOW_FRAME because it makes it easier to remember which
   special cases to handle when walking the stack.
   -

   Pro: Branching on stack frame closure types using switch is easier to
   read than comparing infotable pointers.
   -

   Con: Adding more closure types unnecessarily pollutes code that branches
   on closure types, like the garbage collector.
   -

   Con: Using special closure types for these frames might make it seem
   like they have some special layout when in fact they are just ordinary
   stack frames.

Does anyone have any opinions about this? I’m personally okay with the
status quo, but the inconsistency makes me constantly second-guess whether
someone else might feel strongly that I ought to be doing things the other
way!

Thanks,
Alexis
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230626/8564dc9f/attachment.html>

From bryan at haskell.foundation  Tue Jun 27 05:53:37 2023
From: bryan at haskell.foundation (Bryan Richter)
Date: Tue, 27 Jun 2023 08:53:37 +0300
Subject: Improving Merge Request review processes
In-Reply-To: <CALuQ0m9f6tnR6mT_q5-gnZmQXM3hG21MANgo5D+bq2HLdsB_uQ@mail.gmail.com>
References: <CALuQ0m-Mdi02WTvBydvGhZvmqN+xhVvpaVXTUE1m=WEwgV-vzA@mail.gmail.com>
 <CALuQ0m-0wcQSHSA3myqOvQs=FHbTRmi3eDxcSzwqAnb31YXJWA@mail.gmail.com>
 <CAJKmMz_uN-JNcSiofZwMDxYMYQLvZQuP1iuvLcjJOODKUOcG5g@mail.gmail.com>
 <CALuQ0m9f6tnR6mT_q5-gnZmQXM3hG21MANgo5D+bq2HLdsB_uQ@mail.gmail.com>
Message-ID: <CACUTo6zU=3nijeCap=wxrwCywMGRsmObZH-S3W8p7Pt6DZF9=Q@mail.gmail.com>

The majority of contributors don't have the rights to modify labels on
merge requests. It might be good to add a few words of advice for that
group: What should *they* do if their MR needs attention?

Thanks for this effort! The vast, vast majority of GHC contributors are the
ones who haven't even heard of it yet, or aren't even born yet. High
quality information on how things work and how to get started will be the
key to growing the ranks of GHC experts over time.

On Fri, 23 Jun 2023 at 18:40, Matthew Pickering <matthewtpickering at gmail.com>
wrote:

> I have modified the MR template -
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10709
>
> and updated the wiki page that simon points out.
>
> Matt
>
> On Fri, Jun 23, 2023 at 11:25 AM Simon Peyton Jones
> <simon.peytonjones at gmail.com> wrote:
> >
> > Terrific.
> >
> > We just need to add some guidance for contributors about when and how to
> use the new tag.
> >
> > Where should that guidance live?  We have the Contributing to GHC wiki
> page.  It in turn (not very prominently) points to Contributing a patch.
> Are these our primary pages?  If so, perhaps the latter is the one to edit?
> >
> > Simon
> >
> >
> >
> > On Fri, 23 Jun 2023 at 11:14, Matthew Pickering <
> matthewtpickering at gmail.com> wrote:
> >>
> >> We discussed this in the meeting on Tuesday.
> >>
> >> The conclusion was that
> >>
> >> * We now have a new label "Blocked on Review", which people can add to
> >> merge requests if they are blocked waiting for a review.
> >> * The "Reviewer Group" is taken to be the same as the "GHC Team" (see
> >> https://gitlab.haskell.org/ghc/ghc-hq/-/tree/main), hence people
> >> trusted to be part of the GHC team are expected to perform review as
> >> well.
> >> * We will take up some of the time on the Tuesday meeting by talking
> >> about merge requests which are blocked and assigning them to people
> >> for review.
> >>
> >> Cheers,
> >>
> >> Matt
> >>
> >> On Mon, Jun 19, 2023 at 10:03 PM Matthew Pickering
> >> <matthewtpickering at gmail.com> wrote:
> >> >
> >> > Hi all,
> >> >
> >> > Recently there has been some discussion about better systems and
> >> > processes for keeping the flow of merge requests going smoothly
> >> > through the review process. It has become clear that we need to be a
> >> > bit more deliberate in handling merge requests in order to make sure
> >> > we can correctly triage, review and merge the many fantastic
> >> > contributions we get to GHC on a daily basis.
> >> >
> >> > Therefore we are proposing to introduce a "GHC Reviewer Group" whose
> >> > members will share collective responsibility for ensuring that MRs
> >> > make their way smoothly from creation to merge.
> >> >
> >> > The description of the role and responsibility for this group can be
> >> > read and commented on here:
> >> >
> >> >
> https://docs.google.com/document/d/1FK9mryjC82DM6e5yxP7BOgu94As2bXccb55L8OrjPf4/edit?usp=sharing
> >> >
> >> > The motivation for this proposal is two-fold.
> >> >
> >> > * Ensuring that MRs are reviewed and triaged in a timely manner.
> >> > * Documenting where the responsibility for MR reviewing
> >> >
> >> > We welcome any discussion about this document and other ideas about
> >> > how to improve the systems in this regard.
> >> >
> >> > Cheers,
> >> >
> >> > Matt
> >> _______________________________________________
> >> 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/20230627/d287eecf/attachment.html>

From bryan at haskell.foundation  Tue Jun 27 06:29:04 2023
From: bryan at haskell.foundation (Bryan Richter)
Date: Tue, 27 Jun 2023 09:29:04 +0300
Subject: SSH on Gitlab
In-Reply-To: <87v8ffqzbe.fsf@smart-cactus.org>
References: <CAJKmMz-=1w9_rt1_iXD7h4RS=0-QY7hNT2TkDj=5LavL+=AWiQ@mail.gmail.com>
 <87v8ffqzbe.fsf@smart-cactus.org>
Message-ID: <CACUTo6wyvyevJ+0vLRSWL_1aYzCcVxKQCxw2F84xHkZsrdMjew@mail.gmail.com>

Hi Simon,

Did this, in fact, work itself out?

On Thu, 22 Jun 2023 at 18:43, Ben Gamari <ben at smart-cactus.org> wrote:

> Simon Peyton Jones <simon.peytonjones at gmail.com> writes:
>
> > Is SSH working on gitlab.haskell.org?  I'm getting this
> >
> > simonpj at CDW-8FABODHF0V5:~$ ssh -v git at gitlab.haskell.org
> > OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f  31 Mar 2020
> > debug1: Reading configuration data /home/simonpj/.ssh/config
> > debug1: Reading configuration data /etc/ssh/ssh_config
> > debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf
> > matched no files
> > debug1: /etc/ssh/ssh_config line 21: Applying options for *
> > debug1: Connecting to gitlab.haskell.org [145.40.64.137] port 22.
> > debug1: Connection established.
> > debug1: identity file /home/simonpj/.ssh/id_rsa type 0
> > debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1
> > debug1: identity file /home/simonpj/.ssh/id_dsa type 1
> > debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1
> > debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1
> > debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1
> > debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk type -1
> > debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk-cert type -1
> > debug1: identity file /home/simonpj/.ssh/id_ed25519 type 3
> > debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1
> > debug1: identity file /home/simonpj/.ssh/id_ed25519_sk type -1
> > debug1: identity file /home/simonpj/.ssh/id_ed25519_sk-cert type -1
> > debug1: identity file /home/simonpj/.ssh/id_xmss type -1
> > debug1: identity file /home/simonpj/.ssh/id_xmss-cert type -1
> > debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4
> >
> > At this point it hangs.  Stackoverflow suggests
> > <
> https://superuser.com/questions/1374076/what-does-it-mean-if-ssh-hangs-after-connection-established
> >a
> > server fault.  But I'm on a new WLAN so I suppose there could be some
> > bizarre filtering?
> >
> I suspect this may be a filtering issue. Like Tom, I am able to connect
> without issue. A Wireshark trace [1] may help shed light on the
> situation. Happy to have a call to debug if this would be helpful.
>
> Cheers,
>
> - Ben
>
>
> [1] https://www.wireshark.org/
> _______________________________________________
> 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/20230627/d2f24d96/attachment.html>

From simon.peytonjones at gmail.com  Tue Jun 27 09:13:12 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 27 Jun 2023 10:13:12 +0100
Subject: Distinct closure types vs. known infotables for stack frames
In-Reply-To: <CAA8dsadwcgmg6+GKR+kV7myNxvaYZ_+Vwir+dndNKx59AteZhA@mail.gmail.com>
References: <CAA8dsadwcgmg6+GKR+kV7myNxvaYZ_+Vwir+dndNKx59AteZhA@mail.gmail.com>
Message-ID: <CAJKmMz-5uuF9V6gNYoQUsQ=t6Z_XEVPgBO09tkhXYBQKCR0Ttw@mail.gmail.com>

Thanks for a clear writeup, Alexis.

My instinct is to do it all with closure types, not pointer comparison.
-
>
> Con: Adding more closure types unnecessarily pollutes code that branches
> on closure types, like the garbage collector.
>
-
>
> Con: Adding more closure types unnecessarily pollutes code that branches
> on closure types, like the garbage collector.
>
- I don't get this.  Different stack frames might have different layouts
(e.g a catch frame has a fixed size with with exactly two (or whatever)
pointers, etc).   This isn't pollution.  Just as every heap closure has a
closure type that describes its layout, so does every stack frame.

Perhaps you mean that in fact all stack frames share a single layout, with
a bitmap to describe it?  That seems sub-optimal for these special frames
where we statically know the entire shape!

Perhaps you mean that many stack frames share a common layout, so that the
case analysis on closure type might have many cases all pointing to the
same GC code.  But if so, isn't that true for heap closures too? If we are
concerned about that, we could have two "type" fields in the info table,
one exclusively concerned with layout, so that the GC could just branch on
that and only have a few cases to consider, and one with a finer
granularity.

In short, why are the design considerations for stack frames different to
heap objects?  I think of a stack frame simply as a heap object that
happens to be allocated on the stack

Simon


On Mon, 26 Jun 2023 at 21:21, Alexis King <lexi.lambda at gmail.com> wrote:

> Hello all,
>
> I am tinkering with the RTS again while trying to fix #23513
> <https://gitlab.haskell.org/ghc/ghc/-/issues/23513>, and every time I
> touch the exceptions/continuations code, I find myself waffling about
> whether to introduce more closure types. I’d like to get a second opinion
> so I can stop changing my mind!
>
> Currently, we have distinct closure types for certain special stack
> frames, like CATCH_FRAME, ATOMICALLY_FRAME, and UNDERFLOW_FRAME. However,
> there are other special stack frames that *don’t* get their own closure
> types: there is no MASK_ASYNC_EXCEPTIONS_FRAME or PROMPT_FRAME. Instead,
> when code needs to recognize these frames on the stack, it just looks for a
> known infotable pointer. That is, instead of writing
>
> if (frame->header.info->i.type == PROMPT_FRAME) { ... }
>
> we write
>
> if (*frame == &stg_prompt_frame_info) { ... }
>
> which works out because there’s only one info table that’s used for all
> prompt frames.
>
> There are a handful of stack frames that are recognized in this way by
> some part of the RTS, but the criteria used to determine which frames get
> their own types and which don’t is not particularly clear. For some frames,
> like UPDATE_FRAME, the closure type is necessary because it is shared
> between several infotables. But other types, like CATCH_FRAME and
> UNDERFLOW_FRAME, are only ever used by precisely one infotable.
>
> I think one can make the following arguments for/against using separate
> closure types for these stack frames:
>
>    -
>
>    Pro: It’s helpful to have separate types for particularly special
>    frames like UNDERFLOW_FRAME because it makes it easier to remember
>    which special cases to handle when walking the stack.
>    -
>
>    Pro: Branching on stack frame closure types using switch is easier to
>    read than comparing infotable pointers.
>    -
>
>    Con: Adding more closure types unnecessarily pollutes code that
>    branches on closure types, like the garbage collector.
>    -
>
>    Con: Using special closure types for these frames might make it seem
>    like they have some special layout when in fact they are just ordinary
>    stack frames.
>
> Does anyone have any opinions about this? I’m personally okay with the
> status quo, but the inconsistency makes me constantly second-guess whether
> someone else might feel strongly that I ought to be doing things the other
> way!
>
> Thanks,
> Alexis
> _______________________________________________
> 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/20230627/2ee2d16c/attachment.html>

From simon.peytonjones at gmail.com  Tue Jun 27 09:34:55 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 27 Jun 2023 10:34:55 +0100
Subject: Improving Merge Request review processes
In-Reply-To: <CACUTo6zU=3nijeCap=wxrwCywMGRsmObZH-S3W8p7Pt6DZF9=Q@mail.gmail.com>
References: <CALuQ0m-Mdi02WTvBydvGhZvmqN+xhVvpaVXTUE1m=WEwgV-vzA@mail.gmail.com>
 <CALuQ0m-0wcQSHSA3myqOvQs=FHbTRmi3eDxcSzwqAnb31YXJWA@mail.gmail.com>
 <CAJKmMz_uN-JNcSiofZwMDxYMYQLvZQuP1iuvLcjJOODKUOcG5g@mail.gmail.com>
 <CALuQ0m9f6tnR6mT_q5-gnZmQXM3hG21MANgo5D+bq2HLdsB_uQ@mail.gmail.com>
 <CACUTo6zU=3nijeCap=wxrwCywMGRsmObZH-S3W8p7Pt6DZF9=Q@mail.gmail.com>
Message-ID: <CAJKmMz9mNKGLT0S0oX5X+sgkZCwdSDhYpraasT7bwybCJ0frPg@mail.gmail.com>

>
> The majority of contributors don't have the rights to modify labels on
> merge requests. It might be good to add a few words of advice for that
> group: What should *they* do if their MR needs attention?
>

Oh!  That is bad.  It's no good us saying "add label X" if they can't add a
label.  Can we give everyone rights to modify labels?

Also: I have noticed that many MRs (hilariously including !10709) start
with "Thank you for your contribution to GHC".  That always irritates me:
it suggests that the author has not really bothered to write a proper MR
description.   The template isn't really a template: it's more *guidance *about
how to submit a MR, which we also supply at
https://gitlab.haskell.org/ghc/ghc/-/wikis/Contributing-a-Patch.    (And if
the template is widely used, as it seems to be though I don't know how
people find it initially, it should point to that wiki page.)

I'm not quite sure how to resolve this.  Maybe make the template be truly a
template, and point to the wiki page for all content?

Simon

On Tue, 27 Jun 2023 at 06:53, Bryan Richter <bryan at haskell.foundation>
wrote:

> The majority of contributors don't have the rights to modify labels on
> merge requests. It might be good to add a few words of advice for that
> group: What should *they* do if their MR needs attention?
>
> Thanks for this effort! The vast, vast majority of GHC contributors are
> the ones who haven't even heard of it yet, or aren't even born yet. High
> quality information on how things work and how to get started will be the
> key to growing the ranks of GHC experts over time.
>
> On Fri, 23 Jun 2023 at 18:40, Matthew Pickering <
> matthewtpickering at gmail.com> wrote:
>
>> I have modified the MR template -
>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10709
>>
>> and updated the wiki page that simon points out.
>>
>> Matt
>>
>> On Fri, Jun 23, 2023 at 11:25 AM Simon Peyton Jones
>> <simon.peytonjones at gmail.com> wrote:
>> >
>> > Terrific.
>> >
>> > We just need to add some guidance for contributors about when and how
>> to use the new tag.
>> >
>> > Where should that guidance live?  We have the Contributing to GHC wiki
>> page.  It in turn (not very prominently) points to Contributing a patch.
>> Are these our primary pages?  If so, perhaps the latter is the one to edit?
>> >
>> > Simon
>> >
>> >
>> >
>> > On Fri, 23 Jun 2023 at 11:14, Matthew Pickering <
>> matthewtpickering at gmail.com> wrote:
>> >>
>> >> We discussed this in the meeting on Tuesday.
>> >>
>> >> The conclusion was that
>> >>
>> >> * We now have a new label "Blocked on Review", which people can add to
>> >> merge requests if they are blocked waiting for a review.
>> >> * The "Reviewer Group" is taken to be the same as the "GHC Team" (see
>> >> https://gitlab.haskell.org/ghc/ghc-hq/-/tree/main), hence people
>> >> trusted to be part of the GHC team are expected to perform review as
>> >> well.
>> >> * We will take up some of the time on the Tuesday meeting by talking
>> >> about merge requests which are blocked and assigning them to people
>> >> for review.
>> >>
>> >> Cheers,
>> >>
>> >> Matt
>> >>
>> >> On Mon, Jun 19, 2023 at 10:03 PM Matthew Pickering
>> >> <matthewtpickering at gmail.com> wrote:
>> >> >
>> >> > Hi all,
>> >> >
>> >> > Recently there has been some discussion about better systems and
>> >> > processes for keeping the flow of merge requests going smoothly
>> >> > through the review process. It has become clear that we need to be a
>> >> > bit more deliberate in handling merge requests in order to make sure
>> >> > we can correctly triage, review and merge the many fantastic
>> >> > contributions we get to GHC on a daily basis.
>> >> >
>> >> > Therefore we are proposing to introduce a "GHC Reviewer Group" whose
>> >> > members will share collective responsibility for ensuring that MRs
>> >> > make their way smoothly from creation to merge.
>> >> >
>> >> > The description of the role and responsibility for this group can be
>> >> > read and commented on here:
>> >> >
>> >> >
>> https://docs.google.com/document/d/1FK9mryjC82DM6e5yxP7BOgu94As2bXccb55L8OrjPf4/edit?usp=sharing
>> >> >
>> >> > The motivation for this proposal is two-fold.
>> >> >
>> >> > * Ensuring that MRs are reviewed and triaged in a timely manner.
>> >> > * Documenting where the responsibility for MR reviewing
>> >> >
>> >> > We welcome any discussion about this document and other ideas about
>> >> > how to improve the systems in this regard.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Matt
>> >> _______________________________________________
>> >> 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/20230627/d51018fe/attachment.html>

From simon.peytonjones at gmail.com  Tue Jun 27 09:37:02 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Tue, 27 Jun 2023 10:37:02 +0100
Subject: SSH on Gitlab
In-Reply-To: <CACUTo6wyvyevJ+0vLRSWL_1aYzCcVxKQCxw2F84xHkZsrdMjew@mail.gmail.com>
References: <CAJKmMz-=1w9_rt1_iXD7h4RS=0-QY7hNT2TkDj=5LavL+=AWiQ@mail.gmail.com>
 <87v8ffqzbe.fsf@smart-cactus.org>
 <CACUTo6wyvyevJ+0vLRSWL_1aYzCcVxKQCxw2F84xHkZsrdMjew@mail.gmail.com>
Message-ID: <CAJKmMz8x75VAYQ-5MbyZMD7SemJw7C_czm-b0ARjMXL2f9Qjow@mail.gmail.com>

Thanks for following up.

I came home from hospital, and it was fine at home.  Maybe there was
something strange in their Wifi.   If I was there for longer I'd have had
to investigate more (somehow) but it was a thankfully brief stay.

Simon

On Tue, 27 Jun 2023 at 07:29, Bryan Richter <bryan at haskell.foundation>
wrote:

> Hi Simon,
>
> Did this, in fact, work itself out?
>
> On Thu, 22 Jun 2023 at 18:43, Ben Gamari <ben at smart-cactus.org> wrote:
>
>> Simon Peyton Jones <simon.peytonjones at gmail.com> writes:
>>
>> > Is SSH working on gitlab.haskell.org?  I'm getting this
>> >
>> > simonpj at CDW-8FABODHF0V5:~$ ssh -v git at gitlab.haskell.org
>> > OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f  31 Mar 2020
>> > debug1: Reading configuration data /home/simonpj/.ssh/config
>> > debug1: Reading configuration data /etc/ssh/ssh_config
>> > debug1: /etc/ssh/ssh_config line 19: include
>> /etc/ssh/ssh_config.d/*.conf
>> > matched no files
>> > debug1: /etc/ssh/ssh_config line 21: Applying options for *
>> > debug1: Connecting to gitlab.haskell.org [145.40.64.137] port 22.
>> > debug1: Connection established.
>> > debug1: identity file /home/simonpj/.ssh/id_rsa type 0
>> > debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1
>> > debug1: identity file /home/simonpj/.ssh/id_dsa type 1
>> > debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk-cert type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ed25519 type 3
>> > debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ed25519_sk type -1
>> > debug1: identity file /home/simonpj/.ssh/id_ed25519_sk-cert type -1
>> > debug1: identity file /home/simonpj/.ssh/id_xmss type -1
>> > debug1: identity file /home/simonpj/.ssh/id_xmss-cert type -1
>> > debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4
>> >
>> > At this point it hangs.  Stackoverflow suggests
>> > <
>> https://superuser.com/questions/1374076/what-does-it-mean-if-ssh-hangs-after-connection-established
>> >a
>> > server fault.  But I'm on a new WLAN so I suppose there could be some
>> > bizarre filtering?
>> >
>> I suspect this may be a filtering issue. Like Tom, I am able to connect
>> without issue. A Wireshark trace [1] may help shed light on the
>> situation. Happy to have a call to debug if this would be helpful.
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [1] https://www.wireshark.org/
>> _______________________________________________
>> 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/20230627/90c02faa/attachment.html>

From bryan at haskell.foundation  Tue Jun 27 12:01:26 2023
From: bryan at haskell.foundation (Bryan Richter)
Date: Tue, 27 Jun 2023 15:01:26 +0300
Subject: Improving Merge Request review processes
In-Reply-To: <CAJKmMz9mNKGLT0S0oX5X+sgkZCwdSDhYpraasT7bwybCJ0frPg@mail.gmail.com>
References: <CALuQ0m-Mdi02WTvBydvGhZvmqN+xhVvpaVXTUE1m=WEwgV-vzA@mail.gmail.com>
 <CALuQ0m-0wcQSHSA3myqOvQs=FHbTRmi3eDxcSzwqAnb31YXJWA@mail.gmail.com>
 <CAJKmMz_uN-JNcSiofZwMDxYMYQLvZQuP1iuvLcjJOODKUOcG5g@mail.gmail.com>
 <CALuQ0m9f6tnR6mT_q5-gnZmQXM3hG21MANgo5D+bq2HLdsB_uQ@mail.gmail.com>
 <CACUTo6zU=3nijeCap=wxrwCywMGRsmObZH-S3W8p7Pt6DZF9=Q@mail.gmail.com>
 <CAJKmMz9mNKGLT0S0oX5X+sgkZCwdSDhYpraasT7bwybCJ0frPg@mail.gmail.com>
Message-ID: <CACUTo6wVm74r+SaO=rFxV9-Lp=8wPOnU81LbcVxPWQ3rNa-Dmg@mail.gmail.com>

One common technique is to put all the MR instructions gobbedlygook into a
<!-- html comment -->, so they don't end up in the actual description. I
kind of agree the gobbeldy gook should be on the wiki, though, with a
simple <!-- See the merge request guide at https://url/to/guide --> in the
actual template itself. But even that kind of falls down because the link
wouldn't actually be clickable. Maybe a big comment is fine.

At any rate, +1 to making the template an actual template.

On Tue, 27 Jun 2023 at 12:35, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> The majority of contributors don't have the rights to modify labels on
>> merge requests. It might be good to add a few words of advice for that
>> group: What should *they* do if their MR needs attention?
>>
>
> Oh!  That is bad.  It's no good us saying "add label X" if they can't add
> a label.  Can we give everyone rights to modify labels?
>
> Also: I have noticed that many MRs (hilariously including !10709) start
> with "Thank you for your contribution to GHC".  That always irritates me:
> it suggests that the author has not really bothered to write a proper MR
> description.   The template isn't really a template: it's more *guidance *about
> how to submit a MR, which we also supply at
> https://gitlab.haskell.org/ghc/ghc/-/wikis/Contributing-a-Patch.    (And
> if the template is widely used, as it seems to be though I don't know how
> people find it initially, it should point to that wiki page.)
>
> I'm not quite sure how to resolve this.  Maybe make the template be truly
> a template, and point to the wiki page for all content?
>
> Simon
>
> On Tue, 27 Jun 2023 at 06:53, Bryan Richter <bryan at haskell.foundation>
> wrote:
>
>> The majority of contributors don't have the rights to modify labels on
>> merge requests. It might be good to add a few words of advice for that
>> group: What should *they* do if their MR needs attention?
>>
>> Thanks for this effort! The vast, vast majority of GHC contributors are
>> the ones who haven't even heard of it yet, or aren't even born yet. High
>> quality information on how things work and how to get started will be the
>> key to growing the ranks of GHC experts over time.
>>
>> On Fri, 23 Jun 2023 at 18:40, Matthew Pickering <
>> matthewtpickering at gmail.com> wrote:
>>
>>> I have modified the MR template -
>>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10709
>>>
>>> and updated the wiki page that simon points out.
>>>
>>> Matt
>>>
>>> On Fri, Jun 23, 2023 at 11:25 AM Simon Peyton Jones
>>> <simon.peytonjones at gmail.com> wrote:
>>> >
>>> > Terrific.
>>> >
>>> > We just need to add some guidance for contributors about when and how
>>> to use the new tag.
>>> >
>>> > Where should that guidance live?  We have the Contributing to GHC wiki
>>> page.  It in turn (not very prominently) points to Contributing a patch.
>>> Are these our primary pages?  If so, perhaps the latter is the one to edit?
>>> >
>>> > Simon
>>> >
>>> >
>>> >
>>> > On Fri, 23 Jun 2023 at 11:14, Matthew Pickering <
>>> matthewtpickering at gmail.com> wrote:
>>> >>
>>> >> We discussed this in the meeting on Tuesday.
>>> >>
>>> >> The conclusion was that
>>> >>
>>> >> * We now have a new label "Blocked on Review", which people can add to
>>> >> merge requests if they are blocked waiting for a review.
>>> >> * The "Reviewer Group" is taken to be the same as the "GHC Team" (see
>>> >> https://gitlab.haskell.org/ghc/ghc-hq/-/tree/main), hence people
>>> >> trusted to be part of the GHC team are expected to perform review as
>>> >> well.
>>> >> * We will take up some of the time on the Tuesday meeting by talking
>>> >> about merge requests which are blocked and assigning them to people
>>> >> for review.
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Matt
>>> >>
>>> >> On Mon, Jun 19, 2023 at 10:03 PM Matthew Pickering
>>> >> <matthewtpickering at gmail.com> wrote:
>>> >> >
>>> >> > Hi all,
>>> >> >
>>> >> > Recently there has been some discussion about better systems and
>>> >> > processes for keeping the flow of merge requests going smoothly
>>> >> > through the review process. It has become clear that we need to be a
>>> >> > bit more deliberate in handling merge requests in order to make sure
>>> >> > we can correctly triage, review and merge the many fantastic
>>> >> > contributions we get to GHC on a daily basis.
>>> >> >
>>> >> > Therefore we are proposing to introduce a "GHC Reviewer Group" whose
>>> >> > members will share collective responsibility for ensuring that MRs
>>> >> > make their way smoothly from creation to merge.
>>> >> >
>>> >> > The description of the role and responsibility for this group can be
>>> >> > read and commented on here:
>>> >> >
>>> >> >
>>> https://docs.google.com/document/d/1FK9mryjC82DM6e5yxP7BOgu94As2bXccb55L8OrjPf4/edit?usp=sharing
>>> >> >
>>> >> > The motivation for this proposal is two-fold.
>>> >> >
>>> >> > * Ensuring that MRs are reviewed and triaged in a timely manner.
>>> >> > * Documenting where the responsibility for MR reviewing
>>> >> >
>>> >> > We welcome any discussion about this document and other ideas about
>>> >> > how to improve the systems in this regard.
>>> >> >
>>> >> > Cheers,
>>> >> >
>>> >> > Matt
>>> >> _______________________________________________
>>> >> 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/20230627/8058068c/attachment.html>

From bryan at haskell.foundation  Tue Jun 27 12:03:50 2023
From: bryan at haskell.foundation (Bryan Richter)
Date: Tue, 27 Jun 2023 15:03:50 +0300
Subject: SSH on Gitlab
In-Reply-To: <CAJKmMz8x75VAYQ-5MbyZMD7SemJw7C_czm-b0ARjMXL2f9Qjow@mail.gmail.com>
References: <CAJKmMz-=1w9_rt1_iXD7h4RS=0-QY7hNT2TkDj=5LavL+=AWiQ@mail.gmail.com>
 <87v8ffqzbe.fsf@smart-cactus.org>
 <CACUTo6wyvyevJ+0vLRSWL_1aYzCcVxKQCxw2F84xHkZsrdMjew@mail.gmail.com>
 <CAJKmMz8x75VAYQ-5MbyZMD7SemJw7C_czm-b0ARjMXL2f9Qjow@mail.gmail.com>
Message-ID: <CACUTo6xKLjWo+StkBmQiEko+D2APHCBB+p3-AL0RUECPwFrLqw@mail.gmail.com>

Ah - my bet is that the hospital's IT department were simply blocking ssh
as a "better safe than sorry" infosec policy.

On Tue, 27 Jun 2023 at 12:37, Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> Thanks for following up.
>
> I came home from hospital, and it was fine at home.  Maybe there was
> something strange in their Wifi.   If I was there for longer I'd have had
> to investigate more (somehow) but it was a thankfully brief stay.
>
> Simon
>
> On Tue, 27 Jun 2023 at 07:29, Bryan Richter <bryan at haskell.foundation>
> wrote:
>
>> Hi Simon,
>>
>> Did this, in fact, work itself out?
>>
>> On Thu, 22 Jun 2023 at 18:43, Ben Gamari <ben at smart-cactus.org> wrote:
>>
>>> Simon Peyton Jones <simon.peytonjones at gmail.com> writes:
>>>
>>> > Is SSH working on gitlab.haskell.org?  I'm getting this
>>> >
>>> > simonpj at CDW-8FABODHF0V5:~$ ssh -v git at gitlab.haskell.org
>>> > OpenSSH_8.2p1 Ubuntu-4, OpenSSL 1.1.1f  31 Mar 2020
>>> > debug1: Reading configuration data /home/simonpj/.ssh/config
>>> > debug1: Reading configuration data /etc/ssh/ssh_config
>>> > debug1: /etc/ssh/ssh_config line 19: include
>>> /etc/ssh/ssh_config.d/*.conf
>>> > matched no files
>>> > debug1: /etc/ssh/ssh_config line 21: Applying options for *
>>> > debug1: Connecting to gitlab.haskell.org [145.40.64.137] port 22.
>>> > debug1: Connection established.
>>> > debug1: identity file /home/simonpj/.ssh/id_rsa type 0
>>> > debug1: identity file /home/simonpj/.ssh/id_rsa-cert type -1
>>> > debug1: identity file /home/simonpj/.ssh/id_dsa type 1
>>> > debug1: identity file /home/simonpj/.ssh/id_dsa-cert type -1
>>> > debug1: identity file /home/simonpj/.ssh/id_ecdsa type -1
>>> > debug1: identity file /home/simonpj/.ssh/id_ecdsa-cert type -1
>>> > debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk type -1
>>> > debug1: identity file /home/simonpj/.ssh/id_ecdsa_sk-cert type -1
>>> > debug1: identity file /home/simonpj/.ssh/id_ed25519 type 3
>>> > debug1: identity file /home/simonpj/.ssh/id_ed25519-cert type -1
>>> > debug1: identity file /home/simonpj/.ssh/id_ed25519_sk type -1
>>> > debug1: identity file /home/simonpj/.ssh/id_ed25519_sk-cert type -1
>>> > debug1: identity file /home/simonpj/.ssh/id_xmss type -1
>>> > debug1: identity file /home/simonpj/.ssh/id_xmss-cert type -1
>>> > debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4
>>> >
>>> > At this point it hangs.  Stackoverflow suggests
>>> > <
>>> https://superuser.com/questions/1374076/what-does-it-mean-if-ssh-hangs-after-connection-established
>>> >a
>>> > server fault.  But I'm on a new WLAN so I suppose there could be some
>>> > bizarre filtering?
>>> >
>>> I suspect this may be a filtering issue. Like Tom, I am able to connect
>>> without issue. A Wireshark trace [1] may help shed light on the
>>> situation. Happy to have a call to debug if this would be helpful.
>>>
>>> Cheers,
>>>
>>> - Ben
>>>
>>>
>>> [1] https://www.wireshark.org/
>>> _______________________________________________
>>> 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/20230627/5e3ef919/attachment-0001.html>

From juhpetersen at gmail.com  Tue Jun 27 17:10:47 2023
From: juhpetersen at gmail.com (Jens Petersen)
Date: Wed, 28 Jun 2023 01:10:47 +0800
Subject: Inquiry about Supporting RISC-V 32 in Haskell
In-Reply-To: <CACUTo6wqW2_Sjgdmm8T2eu+TO9f_CaEPMDNH8PbTiY4dbcZ8PA@mail.gmail.com>
References: <CAKfdd-w7jeXRYJ2pCC2WpzVyyRinSFvWrxOyTotMjgnEsHLpQQ@mail.gmail.com>
 <APYAmAA5F2sSJemAmeKFbarL.2.1686206637608.Hmail.shiwei.lu@compiler-dev.com>
 <CAKfdd-yRBGswp=kAnVeJo90s-8AauBexY0_TTG1S+mJkEKZcNQ@mail.gmail.com>
 <CACUTo6wqW2_Sjgdmm8T2eu+TO9f_CaEPMDNH8PbTiY4dbcZ8PA@mail.gmail.com>
Message-ID: <CAEDGBq+Fi3o0Afm394vf2Jbz1j1i0Cyj+FwVPjnAiAfE3QtrTw@mail.gmail.com>

Adding David fyi, who is working on riscv64 bootstrapping for Fedora

On Wed, 14 Jun 2023 at 20:59, Bryan Richter via ghc-devs <
ghc-devs at haskell.org> wrote:

> Hello!
>
> I can't assist with RISC-V, but let me know if you have any trouble with
> https://gitlab.haskell.org. In particular, approving accounts is
> currently a manual process. When you create an account, let me know the
> username, and I will approve it.
>
> Best wishes,
>
> -Bryan
>
> On Thu, 8 Jun 2023 at 14:42, Moritz Angermann <moritz.angermann at gmail.com>
> wrote:
>
>> Hi Shiwei,
>>
>> Let me try to draw up a more visual representation do the current
>> pipelines over the weekend. That might also explain why I think the subset
>> might work as the intermediate steps *do* carry register width.
>>
>> Cheers,
>>  Moritz
>>
>> On Thu, 8 Jun 2023 at 2:44 PM, 卢诗炜 <shiwei.lu at compiler-dev.com> wrote:
>>
>>> Moritz,
>>>
>>> Thank you for your detailed response. However, we think that RV32 is not
>>> a subset of RV64, and that the instruction selection logic for RV32 and
>>> RV64 may differ. Because RV32 and RV64 have different register widths, it
>>> is sometimes necessary to use different instructions than RV64 to ensure
>>> correct results.
>>>
>>> We plan to support RV32 in Native Code Generation. And we may draw
>>> inspiration from your support for RV64.  We do want to be able to
>>> support RV32I+MAF, also include C extensions.
>>>
>>> Do you have any comments or suggestions?
>>>
>>> Thank you so much for your answer and help!
>>>
>>> Best regards，
>>>   Shiwei
>>>
>>>
>>>
>>>
>>> 卢诗炜
>>> shiwei.lu at compiler-dev.com
>>>
>>> <https://lingxi.office.163.com/static_html/signature.html?id=69484630301586661&show=>
>>> 签名由 网易灵犀办公 <https://hubble.netease.com/sl/aaagLd> 定制
>>>
>>>
>>>
>>> Original:
>>>
>>>    - From：moritz.angermann<moritz.angermann at gmail.com>
>>>    - Date：2023-06-08 09:59:38(中国(GMT+08:00))
>>>
>>>
>>>    - To：卢诗炜<shiwei.lu at compiler-dev.com>
>>>    - Cc：
>>>    - Subject：Re: Inquiry about Supporting RISC-V 32 in Haskell
>>>
>>>
>>>
>>> 诗炜,
>>>
>>> This is a bit hard to answer. As GHC is a fairly distributed open source
>>> project, everyone can effectively just contribute (by opening a Merge
>>> Request on gitlab.haskell.org/ghc), and then the discussion around it
>>> will start. There is no fixed plan as to what ends up in e.g. GHC 9.8
>>> (merge window will close June 16th), or even what GHC 9.10 will look like
>>> or when it will be release (likely the merge window will close mid
>>> December).
>>>
>>> GHC has various ways to generate code:
>>> - Via a C backend (compile Haskell to C, use a C compiler to compile to
>>> machine code). This backend is quite slow (compile time, and runtime)
>>> - Via LLVM (comile Haskell to LLVM textual IR, then use LLVM's `opt` and
>>> `llc` to compile it to machine code). This backend produces good performing
>>> code, but is very slow to compile.
>>> - Via Native Code Generation (this turns Haskell into assembly, and then
>>> uses usually the CC compiler to just turn .S into .o). This has good
>>> compile time performance, and often competitive runtime performance.
>>> However this lacks for all supposed architectures proper SIMD support.
>>>
>>> The LLVM backend can _in theory_ compile to any LLVM supported target.
>>> (The LLVM RV64 backend in GHC is that effectively). The Native Code
>>> Generator (NCG), support x86_64, i686, aarch64, and soon rv64. There are
>>> also powerpc, sparc and mips NCG backends, however the state of most cross
>>> compilation targets are only on a best effort basis and are not tested in
>>> CI. Since GHC 9.2 there are also JavaScript and WASM backends in GHC.
>>>
>>> If you just want to cross compile for RV32, going down the LLVM route
>>> might be the easiest.
>>>
>>> _my_ current plans are to work on
>>> - The RV64 NCG
>>> - The linker/loader for ELF/RV64
>>> - aarch32 NCG
>>>
>>> For RV32, we are in the lucky position that the instruction set is
>>> effectively just a subset of the RV64 instruction set. So we might be able
>>> to request some of the RV64 backend, or even better make the RV64 backend a
>>> superset of the RV32 backend.
>>>
>>> I assume you are looking to support RV32I+MAF?
>>>
>>> Happy to help with any follow up questions.
>>>
>>> Cheers,
>>>  Moritz
>>>
>>> On Thu, 8 Jun 2023 at 08:38, 卢诗炜 <shiwei.lu at compiler-dev.com> wrote:
>>>
>>>> Thank you for your prompt reply. We have seen the support for your team
>>>> working for RV64 in the GHC. You've done a great job.
>>>>
>>>>
>>>>
>>>> We'd like to do what your team does for GHC by supporting new compile
>>>> backends, like RV32, to contribute to the community. We are more
>>>> focused on  _cross compilation_  from x86_64 to RV32 on Linux. But we dont
>>>> know much about GHC's current dynamics and plans, whether there is a need
>>>> for this or whether support is being provided.
>>>>
>>>> Do we need to support RV32 for GHC? Or is there anything else you
>>>> think we can contribute to?
>>>>
>>>> Looking forward to your reply, Thanks!
>>>>
>>>> Best regards，
>>>>   Shiwei
>>>>
>>>>
>>>> 卢诗炜
>>>> shiwei.lu at compiler-dev.com
>>>>
>>>> <https://lingxi.office.163.com/static_html/signature.html?id=69484630301586661&show=>
>>>> 签名由 网易灵犀办公 <https://hubble.netease.com/sl/aaagLd> 定制
>>>>
>>>>
>>>>
>>>> Original:
>>>>
>>>>    - From：moritz.angermann<moritz.angermann at gmail.com>
>>>>    - Date：2023-06-07 19:45:32
>>>>    - To：卢诗炜<shiwei.lu at compiler-dev.com>
>>>>    - Cc：
>>>>    - Subject：Re: Inquiry about Supporting RISC-V 32 in Haskell
>>>>
>>>> 您好诗炜！
>>>> 对不起，我的中文不很好。写英语。
>>>> I assume you've found my email from the ghc source repo? Yes, I have
>>>> extensive experience adding compiler backends to GHC, including GHC's
>>>> internal static linker.
>>>> Recently a friend and I have started working on RV64 support in GHC
>>>> (See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10367). So we
>>>> have some prior experience
>>>> with RISC-V.
>>>>
>>>> I understand you want to have support for RV32 in ghc? Are you looking
>>>> for _native_ RV32 support GHC the compiler running natively on RISC-V 32
>>>> hardware? Or are you
>>>> primarily interested in _cross compilation_ to RV32 from e.g. RV64,
>>>> x86_64, aarch64?
>>>>
>>>> Also which platform are you interested in? Linux?
>>>>
>>>> Happy to provide more concrete feedback based on your exact
>>>> requirements and vision. Ultimately GHC is a community project and everyone
>>>> can contribute. I can certainly
>>>> provide guidance and assistance here.
>>>>
>>>> Cheers,
>>>>  Moritz
>>>>
>>>> On Wed, 7 Jun 2023 at 18:16, 卢诗炜 <shiwei.lu at compiler-dev.com> wrote:
>>>>
>>>>> Dear Moritz Angermann，
>>>>>
>>>>> Hello! I am writing on behalf of Hunan Compiler Technology Co., Ltd.
>>>>> to inquire about the possibility of supporting RISC-V 32 in Haskell o
>>>>>
>>>>> r if you're supporting it
>>>>> . We are a technology company based in China and we would like to
>>>>> contribute to the Haskell community by providing support for this
>>>>> architecture.
>>>>>
>>>>> As you may know, RISC-V is an open-source instruction set architecture
>>>>> that is gaining popularity in the industry. It is important for us to
>>>>> ensure that our products are compatible with this architecture, and we
>>>>> believe that supporting RISC-V in Haskell would be a valuable contribution
>>>>> to the community.
>>>>>
>>>>>
>>>>> We are willing to work closely with the community to understand the
>>>>> requirements and challenges of supporting RISC-V in Haskell. We have a team
>>>>> of experienced engineers who are familiar with both Haskell and RISC-V, and
>>>>> we are confident that we can provide high-quality support for this
>>>>> architecture.
>>>>>
>>>>>
>>>>> We would appreciate any guidance or feedback from the community on
>>>>> this matter. Please let us know if there are any specific requirements or
>>>>> challenges that we should be aware of. We look forward to working with the
>>>>> Haskell community to support RISC-V.
>>>>>
>>>>>
>>>>> Thank you for your time and consideration.
>>>>>
>>>>>
>>>>> Sincerely, Shiwei LU, Hunan Compiler Technology Co., Ltd.
>>>>>
>>>>>
>>>>>
>>>>> <https://lingxi.office.163.com/static_html/signature.html?id=69484630301586661&show=>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>> 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/20230628/4b3598a5/attachment.html>

From ben at smart-cactus.org  Tue Jun 27 18:35:32 2023
From: ben at smart-cactus.org (Ben Gamari)
Date: Tue, 27 Jun 2023 14:35:32 -0400
Subject: Inquiry about Supporting RISC-V 32 in Haskell
In-Reply-To: <CAKfdd-yRBGswp=kAnVeJo90s-8AauBexY0_TTG1S+mJkEKZcNQ@mail.gmail.com>
References: <CAKfdd-w7jeXRYJ2pCC2WpzVyyRinSFvWrxOyTotMjgnEsHLpQQ@mail.gmail.com>
 <APYAmAA5F2sSJemAmeKFbarL.2.1686206637608.Hmail.shiwei.lu@compiler-dev.com>
 <CAKfdd-yRBGswp=kAnVeJo90s-8AauBexY0_TTG1S+mJkEKZcNQ@mail.gmail.com>
Message-ID: <87pm5ghhxq.fsf@smart-cactus.org>

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

> Hi Shiwei,
>
> Let me try to draw up a more visual representation do the current pipelines
> over the weekend. That might also explain why I think the subset might work
> as the intermediate steps *do* carry register width.
>
> Cheers,
>  Moritz
>
> On Thu, 8 Jun 2023 at 2:44 PM, 卢诗炜 <shiwei.lu at compiler-dev.com> wrote:
>
>> Moritz,
>>
>> Thank you for your detailed response. However, we think that RV32 is not a
>> subset of RV64, and that the instruction selection logic for RV32 and RV64
>> may differ. Because RV32 and RV64 have different register widths, it is
>> sometimes necessary to use different instructions than RV64 to ensure
>> correct results.
>>
>> We plan to support RV32 in Native Code Generation. And we may draw
>> inspiration from your support for RV64.  We do want to be able to support RV32I+MAF,
>> also include C extensions.
>>
>> Do you have any comments or suggestions?
>>
For what it's worth, I generally agree with MOritz that it should be
possible for one RISC-V NCG backend to handle both RV32 and RV64. While
it's true that RV32 may not be a strict subset of RV64, it is similar
enough that it should be possible to work.

For instance, the same approach is used within GHC to handle x86-64 and
i386; in that case the NCG implementation is quite maintainable despite
the rather considerable differences between the two ISAs.

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/20230627/a5fbe7ed/attachment.sig>

From lexi.lambda at gmail.com  Tue Jun 27 21:53:19 2023
From: lexi.lambda at gmail.com (Alexis King)
Date: Tue, 27 Jun 2023 16:53:19 -0500
Subject: Distinct closure types vs. known infotables for stack frames
In-Reply-To: <CAJKmMz-5uuF9V6gNYoQUsQ=t6Z_XEVPgBO09tkhXYBQKCR0Ttw@mail.gmail.com>
References: <CAA8dsadwcgmg6+GKR+kV7myNxvaYZ_+Vwir+dndNKx59AteZhA@mail.gmail.com>
 <CAJKmMz-5uuF9V6gNYoQUsQ=t6Z_XEVPgBO09tkhXYBQKCR0Ttw@mail.gmail.com>
Message-ID: <CAA8dsafDw1zx9=ptskdiMPWosQsQxZ6iNZ8yjMBuStK0mGz8yw@mail.gmail.com>

On Tue, Jun 27, 2023 at 4:13 AM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:

> In short, why are the design considerations for stack frames different to
> heap objects?  I think of a stack frame simply as a heap object that
> happens to be allocated on the stack
>

I agree with this perspective—I think it is generally an accurate one.
Indeed, I think it may very well be true that what I’ve described largely
applies to heap objects as well as stack frames, and working on
continuations just means I’ve much more time thinking about stacks. Perhaps
if I were working on the garbage collector I would be asking the same
question about heap objects.

For example, we have MVAR_CLEAN and MVAR_DIRTY, but each of those types is
only used by one statically-allocated infotable, as far as I can tell. In
some parts of the code, we check that the closure type is MVAR_CLEAN or
MVAR_DIRTY, but in other places, we check whether the infotable is
stg_MVAR_CLEAN_info or stg_MVAR_DIRTY_info. Meanwhile, we have both
stg_TVAR_CLEAN_info and stg_TVAR_DIRTY_info, but they share the same TVAR
closure type!

The decisions here seem fairly arbitrary. But perhaps there is some method
to the madness, or perhaps someone prefers one approach over the others, in
which case I would like to hear it! And if not, well, at least I’ll know. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230627/e926e182/attachment.html>

From bryan at haskell.foundation  Wed Jun 28 05:41:46 2023
From: bryan at haskell.foundation (Bryan Richter)
Date: Wed, 28 Jun 2023 08:41:46 +0300
Subject: CI *sad face*
Message-ID: <CACUTo6yDEC5bOZXxeDED4iEZMPv4-=XhjJeAmsq_i+kknXWFKw@mail.gmail.com>

Two things are negatively impacting GHC CI right now:

Darwin runner capacity is down to one machine, since the other three are
paused. The problem and solution are known[1], but until the fix is
implemented in GHC, expect pipelines to get backed up. I will work on a
patch this morning

[1]: https://gitlab.haskell.org/ghc/ghc/-/issues/23561

The other problem is one I just noticed, and I don't have any good info
about it yet. The symptom is that Marge batch merges are failing reliably.
Three patches that do fine individually somehow cause a type error in the
hadrian-ghc-in-ghci job when combined[2]. The only clue is the error
itself, which complains of an out-of-scope data constructor
"ArchJavaScript" in the file compiler/GHC/Driver/Main.hs. A cursory look at
the individual patches doesn't shed any light. I just rebased all of them
to see if I can shake the error out of them that way. Any knowledge that
can be brought to bear would be appreciated

[2]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10745#note_507418

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

From rodrigo.m.mesquita at gmail.com  Wed Jun 28 06:14:56 2023
From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita)
Date: Wed, 28 Jun 2023 07:14:56 +0100
Subject: CI *sad face*
In-Reply-To: <CACUTo6yDEC5bOZXxeDED4iEZMPv4-=XhjJeAmsq_i+kknXWFKw@mail.gmail.com>
References: <CACUTo6yDEC5bOZXxeDED4iEZMPv4-=XhjJeAmsq_i+kknXWFKw@mail.gmail.com>
Message-ID: <D42620B9-07F3-4BF9-97CC-DCF385110988@gmail.com>

The root of the second problem was !10723, which started failing on its own pipeline after being rebased.
I’m pushing a fix.

- Rodrigo

> On 28 Jun 2023, at 06:41, Bryan Richter via ghc-devs <ghc-devs at haskell.org> wrote:
> 
> Two things are negatively impacting GHC CI right now:
> 
> Darwin runner capacity is down to one machine, since the other three are paused. The problem and solution are known[1], but until the fix is implemented in GHC, expect pipelines to get backed up. I will work on a patch this morning
> 
> [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/23561
> 
> The other problem is one I just noticed, and I don't have any good info about it yet. The symptom is that Marge batch merges are failing reliably. Three patches that do fine individually somehow cause a type error in the hadrian-ghc-in-ghci job when combined[2]. The only clue is the error itself, which complains of an out-of-scope data constructor "ArchJavaScript" in the file compiler/GHC/Driver/Main.hs. A cursory look at the individual patches doesn't shed any light. I just rebased all of them to see if I can shake the error out of them that way. Any knowledge that can be brought to bear would be appreciated
> 
> [2]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10745#note_507418
> 
> -Bryan
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230628/11d81f1f/attachment.html>

From bryan at haskell.foundation  Wed Jun 28 06:20:59 2023
From: bryan at haskell.foundation (Bryan Richter)
Date: Wed, 28 Jun 2023 09:20:59 +0300
Subject: CI *sad face*
In-Reply-To: <D42620B9-07F3-4BF9-97CC-DCF385110988@gmail.com>
References: <CACUTo6yDEC5bOZXxeDED4iEZMPv4-=XhjJeAmsq_i+kknXWFKw@mail.gmail.com>
 <D42620B9-07F3-4BF9-97CC-DCF385110988@gmail.com>
Message-ID: <CACUTo6wp3iwyN6FuXbLvd6kstRWJgoNhr+K8A3Xs7DFTF52fTQ@mail.gmail.com>

Nice!

Other good news is that I lost track of all the Mac runners we actually
have, and our current capacity is actually 3/6 rather than 1/4.

On Wed, 28 Jun 2023 at 09:15, Rodrigo Mesquita <rodrigo.m.mesquita at gmail.com>
wrote:

> The root of the second problem was !10723, which started failing on its
> own pipeline after being rebased.
> I’m pushing a fix.
>
> - Rodrigo
>
> On 28 Jun 2023, at 06:41, Bryan Richter via ghc-devs <ghc-devs at haskell.org>
> wrote:
>
> Two things are negatively impacting GHC CI right now:
>
> Darwin runner capacity is down to one machine, since the other three are
> paused. The problem and solution are known[1], but until the fix is
> implemented in GHC, expect pipelines to get backed up. I will work on a
> patch this morning
>
> [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/23561
>
> The other problem is one I just noticed, and I don't have any good info
> about it yet. The symptom is that Marge batch merges are failing reliably.
> Three patches that do fine individually somehow cause a type error in the
> hadrian-ghc-in-ghci job when combined[2]. The only clue is the error
> itself, which complains of an out-of-scope data constructor
> "ArchJavaScript" in the file compiler/GHC/Driver/Main.hs. A cursory look at
> the individual patches doesn't shed any light. I just rebased all of them
> to see if I can shake the error out of them that way. Any knowledge that
> can be brought to bear would be appreciated
>
> [2]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10745#note_507418
>
> -Bryan
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230628/c10f9e6d/attachment.html>

From simon.peytonjones at gmail.com  Wed Jun 28 09:14:11 2023
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Wed, 28 Jun 2023 10:14:11 +0100
Subject: Distinct closure types vs. known infotables for stack frames
In-Reply-To: <CAA8dsafDw1zx9=ptskdiMPWosQsQxZ6iNZ8yjMBuStK0mGz8yw@mail.gmail.com>
References: <CAA8dsadwcgmg6+GKR+kV7myNxvaYZ_+Vwir+dndNKx59AteZhA@mail.gmail.com>
 <CAJKmMz-5uuF9V6gNYoQUsQ=t6Z_XEVPgBO09tkhXYBQKCR0Ttw@mail.gmail.com>
 <CAA8dsafDw1zx9=ptskdiMPWosQsQxZ6iNZ8yjMBuStK0mGz8yw@mail.gmail.com>
Message-ID: <CAJKmMz8Ky=u37sE7T3ZqoRSqbFNLGqht7Zguyt0nhEmw0hi6sA@mail.gmail.com>

> The decisions here seem fairly arbitrary. But perhaps there is some
method to the madness, or perhaps someone prefers one approach over the
others, in which case I would like to hear it! And if not, well, at least
I’ll know. :)

I suspect it's all just happenstance.   Maybe @Ben Gamari
<bgamari at gmail.com> knows.

One you've had all responses, perhaps document your conclusions in a Note
somewhere, and point to it copiously.



On Tue, 27 Jun 2023 at 22:53, Alexis King <lexi.lambda at gmail.com> wrote:

> On Tue, Jun 27, 2023 at 4:13 AM Simon Peyton Jones <
> simon.peytonjones at gmail.com> wrote:
>
>> In short, why are the design considerations for stack frames different to
>> heap objects?  I think of a stack frame simply as a heap object that
>> happens to be allocated on the stack
>>
>
> I agree with this perspective—I think it is generally an accurate one.
> Indeed, I think it may very well be true that what I’ve described largely
> applies to heap objects as well as stack frames, and working on
> continuations just means I’ve much more time thinking about stacks. Perhaps
> if I were working on the garbage collector I would be asking the same
> question about heap objects.
>
> For example, we have MVAR_CLEAN and MVAR_DIRTY, but each of those types is
> only used by one statically-allocated infotable, as far as I can tell. In
> some parts of the code, we check that the closure type is MVAR_CLEAN or
> MVAR_DIRTY, but in other places, we check whether the infotable is
> stg_MVAR_CLEAN_info or stg_MVAR_DIRTY_info. Meanwhile, we have both
> stg_TVAR_CLEAN_info and stg_TVAR_DIRTY_info, but they share the same TVAR
> closure type!
>
> The decisions here seem fairly arbitrary. But perhaps there is some method
> to the madness, or perhaps someone prefers one approach over the others, in
> which case I would like to hear it! And if not, well, at least I’ll know. :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230628/382a2cb7/attachment.html>

From ben at smart-cactus.org  Wed Jun 28 12:49:18 2023
From: ben at smart-cactus.org (Ben Gamari)
Date: Wed, 28 Jun 2023 08:49:18 -0400
Subject: Distinct closure types vs. known infotables for stack frames
In-Reply-To: <CAA8dsadwcgmg6+GKR+kV7myNxvaYZ_+Vwir+dndNKx59AteZhA@mail.gmail.com>
References: <CAA8dsadwcgmg6+GKR+kV7myNxvaYZ_+Vwir+dndNKx59AteZhA@mail.gmail.com>
Message-ID: <87edlvhhv8.fsf@smart-cactus.org>

Alexis King <lexi.lambda at gmail.com> writes:

> Hello all,
>
> I am tinkering with the RTS again while trying to fix #23513
> <https://gitlab.haskell.org/ghc/ghc/-/issues/23513>, and every time I touch
> the exceptions/continuations code, I find myself waffling about whether to
> introduce more closure types. I’d like to get a second opinion so I can
> stop changing my mind!
>
Indeed I have had similar questions in the past. In principle, I personally
think that using closure types to distinguish special info tables is
conceptually cleaner.

However, the trouble is that it is also, at least in principle, more
costly. Specifically, branching on closure type requires that we examine
the info table, which may incur a cache/TLB miss. While one would hope
and expect that "common" info tables are already in a nearby cache, it's
ultimately very easy to side-step this cost entirely by simply branching
on the info table pointer.

This tension has lead me to waffle in similar ways as you report. On the
other hand, it seems hard to avoid given the tricky trade-offs involved.

My (rather loose) policy when working on the RTS has typically been:

 * When introducing a new closure/stack-frame info table that differs
   markedly from any that already exist, give it a new closure type.

 * When matching on the info table, follow the example of surrounding
   code when deciding whether to match on the closure type or info table
   pointer

 * If there is no appropriate nearby similar logic to follow, use my gut
   to assess how hot the check will be and unless it is quite warm, use
   the closure type.

However, I'll admit that this policy likely only contributes to the
inconsistency. Perhaps you have some clever idea on how things could be
improved?

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/20230628/6da0eb17/attachment.sig>

From bryan at haskell.foundation  Fri Jun 30 06:47:44 2023
From: bryan at haskell.foundation (Bryan Richter)
Date: Fri, 30 Jun 2023 09:47:44 +0300
Subject: CI *sad face*
In-Reply-To: <CACUTo6wp3iwyN6FuXbLvd6kstRWJgoNhr+K8A3Xs7DFTF52fTQ@mail.gmail.com>
References: <CACUTo6yDEC5bOZXxeDED4iEZMPv4-=XhjJeAmsq_i+kknXWFKw@mail.gmail.com>
 <D42620B9-07F3-4BF9-97CC-DCF385110988@gmail.com>
 <CACUTo6wp3iwyN6FuXbLvd6kstRWJgoNhr+K8A3Xs7DFTF52fTQ@mail.gmail.com>
Message-ID: <CACUTo6wbqDc4uo8gycsD8c-=6g4HC-MjMWisk-AP=EGoi9vCMA@mail.gmail.com>

Final update: both problems are solved!

Now we just need to wait for the wheels of time to do their magic. The
final patch is still waiting to get picked up and merged.

The queue for CI jobs is still a bit longer than usual right now, but I
think it's legitimate. There are simply more open MRs on GitLab than usual,
which is a good thing. (Darwin jobs aren't the source of the bottleneck.)

-Bryan

P.S. A quick shoutout to Marge for preventing two patches that merged
cleanly but created invalid results from making their way into the master
branch.

On Wed, 28 Jun 2023 at 09:20, Bryan Richter <bryan at haskell.foundation>
wrote:

> Nice!
>
> Other good news is that I lost track of all the Mac runners we actually
> have, and our current capacity is actually 3/6 rather than 1/4.
>
> On Wed, 28 Jun 2023 at 09:15, Rodrigo Mesquita <
> rodrigo.m.mesquita at gmail.com> wrote:
>
>> The root of the second problem was !10723, which started failing on its
>> own pipeline after being rebased.
>> I’m pushing a fix.
>>
>> - Rodrigo
>>
>> On 28 Jun 2023, at 06:41, Bryan Richter via ghc-devs <
>> ghc-devs at haskell.org> wrote:
>>
>> Two things are negatively impacting GHC CI right now:
>>
>> Darwin runner capacity is down to one machine, since the other three are
>> paused. The problem and solution are known[1], but until the fix is
>> implemented in GHC, expect pipelines to get backed up. I will work on a
>> patch this morning
>>
>> [1]: https://gitlab.haskell.org/ghc/ghc/-/issues/23561
>>
>> The other problem is one I just noticed, and I don't have any good info
>> about it yet. The symptom is that Marge batch merges are failing reliably.
>> Three patches that do fine individually somehow cause a type error in the
>> hadrian-ghc-in-ghci job when combined[2]. The only clue is the error
>> itself, which complains of an out-of-scope data constructor
>> "ArchJavaScript" in the file compiler/GHC/Driver/Main.hs. A cursory look at
>> the individual patches doesn't shed any light. I just rebased all of them
>> to see if I can shake the error out of them that way. Any knowledge that
>> can be brought to bear would be appreciated
>>
>> [2]:
>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10745#note_507418
>>
>> -Bryan
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20230630/ebf58a01/attachment.html>