From zubin at well-typed.com  Thu Aug  1 07:36:09 2024
From: zubin at well-typed.com (Zubin Duggal)
Date: Thu, 1 Aug 2024 13:06:09 +0530
Subject: GHC 9.12 release schedule
Message-ID: <yrsll6vjgcmnzswetr3gl6vxq5c7o7pkgdh75jo3vluf6wpze6@yg2glt43abjj>

Hi all,

We are in the process of planning the GHC 9.12 release. The tentative
schedule is a fork date in mid September with a final release in late
November.

If you are working on any major patches that should be included in
this release, please be in touch. Furthermore, please ensure that all
appropriate tickets or MRs are appropriately tagged with the %9.12.1
milestone (https://gitlab.haskell.org/ghc/ghc/-/milestones/393).

You can also use the release tracking ticket for further discussion:
https://gitlab.haskell.org/ghc/ghc/-/issues/25123

Cheers,
Zubin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240801/8fb37a9a/attachment.sig>

From jzullo at purdue.edu  Thu Aug  1 21:11:59 2024
From: jzullo at purdue.edu (Zullo, Joseph Anthony)
Date: Thu, 1 Aug 2024 21:11:59 +0000
Subject: Zero Multiplicities for Linear Haskell
Message-ID: <MN0PR22MB55150F00E9DA29C193B0B218A9B22@MN0PR22MB5515.namprd22.prod.outlook.com>

Hello GHC developers,

I am Joseph Zullo, a PhD student at Purdue University. I am newly subscribed to this mailing list and my approval for GitLab is awaiting approval: my username is jazullo. I may be interested in adding Zero as a multiplicity to Linear Haskell as discussed in the source code notes<https://github.com/ghc/ghc/blob/e258ad546d96fcfffd525f9b51d237cee467ad73/compiler/GHC/Core/Multiplicity.hs#L144>. My current use-case is with Liquid Haskell: I have Liquid Haskell proof terms embedded in linearly typed procedures, but the "ghost" proof terms consume terms nonlinearly even though they have no bearing on the linear style of the procedure (a binary "?" operator is used with terms to the left and proofs to the right). I am looking for any work arounds for this issue, or for any help or interest in adding zero as a multiplicity so that proof terms can be casted as non-consuming. Let me know if there are any proper avenues for this problem and/or proposal. I greatly appreciate any direction or assistance.

Joseph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240801/8bae9e35/attachment.html>

From simon.peytonjones at gmail.com  Fri Aug  2 07:09:48 2024
From: simon.peytonjones at gmail.com (Simon Peyton Jones)
Date: Fri, 2 Aug 2024 08:09:48 +0100
Subject: Zero Multiplicities for Linear Haskell
In-Reply-To: <MN0PR22MB55150F00E9DA29C193B0B218A9B22@MN0PR22MB5515.namprd22.prod.outlook.com>
References: <MN0PR22MB55150F00E9DA29C193B0B218A9B22@MN0PR22MB5515.namprd22.prod.outlook.com>
Message-ID: <CAJKmMz-gwWz9=zwtD7K7C5ZjWRMvjGOk7hfTiAbjPTb-LC4R=w@mail.gmail.com>

Joseph

Great!

At the moment we have one undisputed King of Linear Haskell, and that is
Arnaud Spiwak (cc'd).  He's the person to talk to.

Everyone: it would great to broaden the base.  Relying only on Arnaud puts
him under pressure; it'd be great to have more champions for Linear Haskell
and its implementation in GHC.

Simon

On Thu, 1 Aug 2024 at 22:12, Zullo, Joseph Anthony <jzullo at purdue.edu>
wrote:

> Hello GHC developers,
>
>
>
> I am Joseph Zullo, a PhD student at Purdue University. I am newly
> subscribed to this mailing list and my approval for GitLab is awaiting
> approval: my username is jazullo. I may be interested in adding Zero as a
> multiplicity to Linear Haskell as discussed in the source code notes
> <https://github.com/ghc/ghc/blob/e258ad546d96fcfffd525f9b51d237cee467ad73/compiler/GHC/Core/Multiplicity.hs#L144>.
> My current use-case is with Liquid Haskell: I have Liquid Haskell proof
> terms embedded in linearly typed procedures, but the “ghost” proof terms
> consume terms nonlinearly even though they have no bearing on the linear
> style of the procedure (a binary “?” operator is used with terms to the
> left and proofs to the right). I am looking for any work arounds for this
> issue, or for any help or interest in adding zero as a multiplicity so that
> proof terms can be casted as non-consuming. Let me know if there are any
> proper avenues for this problem and/or proposal. I greatly appreciate any
> direction or assistance.
>
>
>
> Joseph
>
>
> _______________________________________________
> 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/20240802/c4244de3/attachment.html>

From arnaud.spiwack at tweag.io  Fri Aug  2 07:13:08 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 2 Aug 2024 09:13:08 +0200
Subject: Zero Multiplicities for Linear Haskell
In-Reply-To: <MN0PR22MB55150F00E9DA29C193B0B218A9B22@MN0PR22MB5515.namprd22.prod.outlook.com>
References: <MN0PR22MB55150F00E9DA29C193B0B218A9B22@MN0PR22MB5515.namprd22.prod.outlook.com>
Message-ID: <CAGwnsnnSGjuRL2Pas=OKSq9jAxiz1VoRNh8e_E3V63puQ_koDQ@mail.gmail.com>

Dear Joseph,

My familiarity with Liquid Haskell is evidently less than what I'd like to
as I don't know what you mean by a ghost proof term in this context. That
being said, there are design decisions to make regarding the 0
multiplicity. The biggest one is: can we pattern-match on 0-multiplicity
data? The type system is much easier if we can (also it's got pretty
interesting consequences in my opinion, such as the ability to call `seq`
on a linear variable). But as Rodrigo Mesquita indirectly points out in his
master thesis, it's probably unsound to have a case on a 0-multiplicity
expression which isn't a variable. Another obstacle is that type inference
for multiplicity is heuristic, and I don't think I'm being overly prudent
in saying that some of these heuristics will be broken by adding a
multiplicity 0. So it's quite a bit of work to get there. It's not
necessarily a good idea to block your PhD on solving this particular
problem. That being said, don't hesitate to reach out to me: we can have a
call and discuss the particular of your problem, and maybe find
workarounds, and also discuss the design of the 0 multiplicity.

/Arnaud

On Thu, 1 Aug 2024 at 23:12, Zullo, Joseph Anthony <jzullo at purdue.edu>
wrote:

> Hello GHC developers,
>
>
>
> I am Joseph Zullo, a PhD student at Purdue University. I am newly
> subscribed to this mailing list and my approval for GitLab is awaiting
> approval: my username is jazullo. I may be interested in adding Zero as a
> multiplicity to Linear Haskell as discussed in the source code notes
> <https://github.com/ghc/ghc/blob/e258ad546d96fcfffd525f9b51d237cee467ad73/compiler/GHC/Core/Multiplicity.hs#L144>.
> My current use-case is with Liquid Haskell: I have Liquid Haskell proof
> terms embedded in linearly typed procedures, but the “ghost” proof terms
> consume terms nonlinearly even though they have no bearing on the linear
> style of the procedure (a binary “?” operator is used with terms to the
> left and proofs to the right). I am looking for any work arounds for this
> issue, or for any help or interest in adding zero as a multiplicity so that
> proof terms can be casted as non-consuming. Let me know if there are any
> proper avenues for this problem and/or proposal. I greatly appreciate any
> direction or assistance.
>
>
>
> Joseph
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240802/443ddaea/attachment.html>

From arnaud.spiwack at tweag.io  Fri Aug  2 10:04:24 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 2 Aug 2024 12:04:24 +0200
Subject: Can't initialise vendored submodule
Message-ID: <CAGwnsnnyFb4AcsQKPNRM359_dqKu646+_boKJqttwx_=KR6Dag@mail.gmail.com>

Dear all,

I'm currently unable to build GHC's master branch as some of the submodules
(presumably used by Hadrian) are making git pretty unhappy (I've used
various variants of the command below, in a cleaned repository):

```console
$  git submodule update --init
error: submodule git dir
'/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
is inside git dir
'/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian'
fatal: refusing to create/use
'/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
in another submodule's git dir
Failed to clone 'hadrian/vendored/Cabal'. Retry scheduled
error: submodule git dir
'/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
is inside git dir
'/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian'
fatal: refusing to create/use
'/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
in another submodule's git dir
Failed to clone 'hadrian/vendored/Cabal' a second time, aborting
```

Please advise on how to get unblocked.

And, if I'm allowed to conclude with a plea: please be careful not to abuse
Git's submodule system, it's wonky enough when used simply.

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240802/68a31dde/attachment.html>

From vaibhavsagar at gmail.com  Fri Aug  2 10:07:56 2024
From: vaibhavsagar at gmail.com (Vaibhav Sagar)
Date: Fri, 2 Aug 2024 20:07:56 +1000
Subject: Can't initialise vendored submodule
In-Reply-To: <CAGwnsnnyFb4AcsQKPNRM359_dqKu646+_boKJqttwx_=KR6Dag@mail.gmail.com>
References: <CAGwnsnnyFb4AcsQKPNRM359_dqKu646+_boKJqttwx_=KR6Dag@mail.gmail.com>
Message-ID: <CACK-K+3UEvv9Dd=jP-_mV5fJzkPaSFTtqFK01sdVGr6xmejpKg@mail.gmail.com>

I think you want --recursive

On Fri, 2 Aug 2024, 8:05 pm Arnaud Spiwack, <arnaud.spiwack at tweag.io> wrote:

> Dear all,
>
> I'm currently unable to build GHC's master branch as some of the
> submodules (presumably used by Hadrian) are making git pretty unhappy (I've
> used various variants of the command below, in a cleaned repository):
>
> ```console
> $  git submodule update --init
> error: submodule git dir
> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
> is inside git dir
> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian'
> fatal: refusing to create/use
> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
> in another submodule's git dir
> Failed to clone 'hadrian/vendored/Cabal'. Retry scheduled
> error: submodule git dir
> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
> is inside git dir
> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian'
> fatal: refusing to create/use
> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
> in another submodule's git dir
> Failed to clone 'hadrian/vendored/Cabal' a second time, aborting
> ```
>
> Please advise on how to get unblocked.
>
> And, if I'm allowed to conclude with a plea: please be careful not to
> abuse Git's submodule system, it's wonky enough when used simply.
>
> --
> Arnaud Spiwack
> Director, Research at https://moduscreate.com and https://tweag.io.
> _______________________________________________
> 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/20240802/fd3ca2c4/attachment.html>

From matthewtpickering at gmail.com  Fri Aug  2 10:11:34 2024
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Fri, 2 Aug 2024 11:11:34 +0100
Subject: Can't initialise vendored submodule
In-Reply-To: <CACK-K+3UEvv9Dd=jP-_mV5fJzkPaSFTtqFK01sdVGr6xmejpKg@mail.gmail.com>
References: <CAGwnsnnyFb4AcsQKPNRM359_dqKu646+_boKJqttwx_=KR6Dag@mail.gmail.com>
 <CACK-K+3UEvv9Dd=jP-_mV5fJzkPaSFTtqFK01sdVGr6xmejpKg@mail.gmail.com>
Message-ID: <CALuQ0m-SjPaO0zZ4MyYf-URKPdahFqLMcjs1sym5u51hCNMCag@mail.gmail.com>

It seems you might have a some very old configuration from when hadrian
used to be a submodule? Perhaps a fresh clone would help things along?

The usage of submodules in `hadrian/vendored` is a standard usage.

Cheers,

Matt

On Fri, Aug 2, 2024 at 11:08 AM Vaibhav Sagar <vaibhavsagar at gmail.com>
wrote:

> I think you want --recursive
>
> On Fri, 2 Aug 2024, 8:05 pm Arnaud Spiwack, <arnaud.spiwack at tweag.io>
> wrote:
>
>> Dear all,
>>
>> I'm currently unable to build GHC's master branch as some of the
>> submodules (presumably used by Hadrian) are making git pretty unhappy (I've
>> used various variants of the command below, in a cleaned repository):
>>
>> ```console
>> $  git submodule update --init
>> error: submodule git dir
>> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
>> is inside git dir
>> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian'
>> fatal: refusing to create/use
>> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
>> in another submodule's git dir
>> Failed to clone 'hadrian/vendored/Cabal'. Retry scheduled
>> error: submodule git dir
>> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
>> is inside git dir
>> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian'
>> fatal: refusing to create/use
>> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
>> in another submodule's git dir
>> Failed to clone 'hadrian/vendored/Cabal' a second time, aborting
>> ```
>>
>> Please advise on how to get unblocked.
>>
>> And, if I'm allowed to conclude with a plea: please be careful not to
>> abuse Git's submodule system, it's wonky enough when used simply.
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>> _______________________________________________
>> 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/20240802/c8636f4e/attachment.html>

From arnaud.spiwack at tweag.io  Fri Aug  2 13:27:23 2024
From: arnaud.spiwack at tweag.io (Arnaud Spiwack)
Date: Fri, 2 Aug 2024 15:27:23 +0200
Subject: Can't initialise vendored submodule
In-Reply-To: <CALuQ0m-SjPaO0zZ4MyYf-URKPdahFqLMcjs1sym5u51hCNMCag@mail.gmail.com>
References: <CAGwnsnnyFb4AcsQKPNRM359_dqKu646+_boKJqttwx_=KR6Dag@mail.gmail.com>
 <CACK-K+3UEvv9Dd=jP-_mV5fJzkPaSFTtqFK01sdVGr6xmejpKg@mail.gmail.com>
 <CALuQ0m-SjPaO0zZ4MyYf-URKPdahFqLMcjs1sym5u51hCNMCag@mail.gmail.com>
Message-ID: <CAGwnsnn2jJtZrSmzuL-G6WxHkifBarMeJWNEy6t2PcHiyxL7Kg@mail.gmail.com>

Thanks Matthew, this helped me find the solution.

Which, is turn out, was simply to remove the old directory:

$  rm -rf .git/modules/hadrian/

It's not removed by `git submodule desync` or any command that I could find
(though, now that I think about it, I didn't try to garbage collect the
repo, so maybe?). But it's sound to just delete, as far as I can tell: it's
just a cache.

> The usage of submodules in `hadrian/vendored` is a standard usage.

This goes to show that I was at least right when saying that submodules are
wonky :D .

On Fri, 2 Aug 2024 at 12:11, Matthew Pickering <matthewtpickering at gmail.com>
wrote:

> It seems you might have a some very old configuration from when hadrian
> used to be a submodule? Perhaps a fresh clone would help things along?
>
> The usage of submodules in `hadrian/vendored` is a standard usage.
>
> Cheers,
>
> Matt
>
> On Fri, Aug 2, 2024 at 11:08 AM Vaibhav Sagar <vaibhavsagar at gmail.com>
> wrote:
>
>> I think you want --recursive
>>
>> On Fri, 2 Aug 2024, 8:05 pm Arnaud Spiwack, <arnaud.spiwack at tweag.io>
>> wrote:
>>
>>> Dear all,
>>>
>>> I'm currently unable to build GHC's master branch as some of the
>>> submodules (presumably used by Hadrian) are making git pretty unhappy (I've
>>> used various variants of the command below, in a cleaned repository):
>>>
>>> ```console
>>> $  git submodule update --init
>>> error: submodule git dir
>>> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
>>> is inside git dir
>>> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian'
>>> fatal: refusing to create/use
>>> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
>>> in another submodule's git dir
>>> Failed to clone 'hadrian/vendored/Cabal'. Retry scheduled
>>> error: submodule git dir
>>> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
>>> is inside git dir
>>> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian'
>>> fatal: refusing to create/use
>>> '/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal'
>>> in another submodule's git dir
>>> Failed to clone 'hadrian/vendored/Cabal' a second time, aborting
>>> ```
>>>
>>> Please advise on how to get unblocked.
>>>
>>> And, if I'm allowed to conclude with a plea: please be careful not to
>>> abuse Git's submodule system, it's wonky enough when used simply.
>>>
>>> --
>>> Arnaud Spiwack
>>> Director, Research at https://moduscreate.com and https://tweag.io.
>>> _______________________________________________
>>> 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
>>
>

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240802/dd024ff4/attachment.html>

From bryan at haskell.foundation  Mon Aug  5 08:48:36 2024
From: bryan at haskell.foundation (Bryan Richter)
Date: Mon, 5 Aug 2024 11:48:36 +0300
Subject: Acknowledgement of CI instability
In-Reply-To: <CAKfdd-yHDq4h9Yt=O_cTpUwYTNYm6Z0Ye-ievwYQnXxn=GABWA@mail.gmail.com>
References: <CAA1CnJO15XAgwSG6K_=MXwNQhwwK5juXRwGwZAWjB+U7m9Qg0Q@mail.gmail.com>
 <CAKfdd-yHDq4h9Yt=O_cTpUwYTNYm6Z0Ye-ievwYQnXxn=GABWA@mail.gmail.com>
Message-ID: <CACUTo6xQr78gLD+t7vvmkZK0SWPuQ0p+A2bLrXHq8Ni1QniZ3A@mail.gmail.com>

On the topic of Macs: I'm back from vacation now, and I've done the thing
that makes the four other Mac runners available again. (Deleting a spurious
route that perennially reappears on the gateway's routing table, and
restarting the gitlab-runner services that don't revive properly after the
nightly reboot.)

On Wed, 24 Jul 2024 at 02:57, Moritz Angermann <moritz.angermann at gmail.com>
wrote:

> Hi,
>
> As I’ve now arrived in Seoul and have my Mac’s back, I can bring two more
> M1 Mac’s back online today. However they are hooked up on a serviced
> apartment internet which might not be the fastest.
>
> Best,
>  Moritz
>
> On Tue, 23 Jul 2024 at 11:36 PM, Sam Derbyshire <sam.derbyshire at gmail.com>
> wrote:
>
>> Hi all,
>>
>> The GHC team would like to acknowledge some ongoing CI instabilities in
>> the GHC project:
>>
>>   - regular failures of the i386 job, possibly related to the bump to
>> debian 12
>> <https://gitlab.haskell.org/ghc/ghc/-/commit/203830065b81fe29003c1640a354f11661ffc604>
>> (although the job still failed occasionally before this),
>>   - flakiness of the MultiLayerModulesDefsGhciReload test causing the
>> fedora33-release job to fail,
>>   - lack of availability of darwin runners, causing aarch64-darwin and
>> x86_64-darwin jobs to time out.
>>
>> These issues are currently causing a string of marge batch failures,
>> holding up several MRs.
>>
>> We are currently short on resources for addressing problems with CI, so
>> please bear with us while we sort the situation out. In the meantime, feel
>> free to let us know of any other CI issues that are impacting your work on
>> GHC.
>>
>> Best,
>>
>> Sam
>> _______________________________________________
>> 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/20240805/17479831/attachment.html>

From teofilcamarasu at gmail.com  Mon Aug  5 08:54:15 2024
From: teofilcamarasu at gmail.com (Teofil Camarasu)
Date: Mon, 5 Aug 2024 09:54:15 +0100
Subject: Question about profiling reports
In-Reply-To: <CAB5aLxqu0WKBNC2E1d=0QTdZ_715LfLre5t1Y5f=4-7qqdzMPw@mail.gmail.com>
References: <CAB5aLxqu0WKBNC2E1d=0QTdZ_715LfLre5t1Y5f=4-7qqdzMPw@mail.gmail.com>
Message-ID: <CAPBO51Ewa8KjbzTXmSJcX1k1o_967M2sc8R=vaZdyGSTnNR4=w@mail.gmail.com>

Hi Celeste,

It looks like by default only cost centers that account for at least 1% of
either allocations or time are shown. But all cost centers are shown when
the -pa flag is passed.

See:
https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html?highlight=cost%20centre#rts-flag--pa
and
https://gitlab.haskell.org/ghc/ghc/-/blob/cf47b96f8b8100d9f9ad1b8121cbfb65fd7eaf2a/rts/ProfilerReport.c#L124

If you are processing these reports, it might be worth checking out the
eventlog interface via the ghc-events library (if you haven't already).

Cheers,
Teo


On Tue, Jul 30, 2024 at 3:58 PM Celeste Hollenbeck <
celeste.hollenbeck at gmail.com> wrote:

> Hi GHC Team,
>
> I have a question for a research project. I'm looking at GHC's profiler,
> and the documentation says a profiling report displays "a break-down by
> cost centre of the most costly functions in the program". Here's an example
> of the report that I'm talking about:
>
>
> MAIN        MAIN                    102           0    0.0    0.0   100.0
>  100.0
>  CAF        GHC.IO.Handle.FD        128           0    0.0    0.0     0.0
>    0.0
>  CAF        GHC.IO.Encoding.Iconv   120           0    0.0    0.0     0.0
>    0.0
>  CAF        GHC.Conc.Signal         110           0    0.0    0.0     0.0
>    0.0
>  CAF        Main                    108           0    0.0    0.0   100.0
>  100.0
>   main      Main                    204           1    0.0    0.0   100.0
>  100.0
>    fib      Main                    205     2692537  100.0  100.0   100.0
>  100.0
>
> This example is under Section 8.1 of the GHC User's Guide
>
> https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#:~:text=GHC's%20profiling%20system%20assigns%20costs,to%20the%20enclosing%20cost%20centre.
>
> It looks like the numbers often add up to less than 100% for the %time,
> but I don't see any documentation on a threshold for what makes a cost
> centre "costly"—so I assume that "costly" means that it takes up any time
> whatsoever, and any cost centres that take up any time at all are included
> in the report? So perhaps the numbers under %time don't add up to 100% all
> the time because of rounding error or perhaps garbage collection? Or
> something else that is not profiled?
>
> Is that correct?
>
> Thanks,
>
> Celeste
> _______________________________________________
> 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/20240805/9929eeb3/attachment.html>

From rodrigo.m.mesquita at gmail.com  Mon Aug  5 08:59:36 2024
From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita)
Date: Mon, 5 Aug 2024 09:59:36 +0100
Subject: Question about profiling reports
In-Reply-To: <CAB5aLxqu0WKBNC2E1d=0QTdZ_715LfLre5t1Y5f=4-7qqdzMPw@mail.gmail.com>
References: <CAB5aLxqu0WKBNC2E1d=0QTdZ_715LfLre5t1Y5f=4-7qqdzMPw@mail.gmail.com>
Message-ID: <BDDF1784-B3C0-4566-A320-9551CB424400@gmail.com>

Hi Celeste,

You may already be aware, but there’s an alternative format to visualise profiles graphically.
Instead of `-p`, use `-pj` to produce the profiling report in JSON format, and then load the resulting .prof file into speedscope.app <https://www.speedscope.app/>.

Cheers,
Rodrigo Mesquita

> On 30 Jul 2024, at 15:57, Celeste Hollenbeck <celeste.hollenbeck at gmail.com> wrote:
> 
> Hi GHC Team,
> 
> I have a question for a research project. I'm looking at GHC's profiler, and the documentation says a profiling report displays "a break-down by cost centre of the most costly functions in the program". Here's an example of the report that I'm talking about:
> 
> 
> MAIN        MAIN                    102           0    0.0    0.0   100.0  100.0
>  CAF        GHC.IO.Handle.FD        128           0    0.0    0.0     0.0    0.0
>  CAF        GHC.IO.Encoding.Iconv   120           0    0.0    0.0     0.0    0.0
>  CAF        GHC.Conc.Signal         110           0    0.0    0.0     0.0    0.0
>  CAF        Main                    108           0    0.0    0.0   100.0  100.0
>   main      Main                    204           1    0.0    0.0   100.0  100.0
>    fib      Main                    205     2692537  100.0  100.0   100.0  100.0
> 
> This example is under Section 8.1 of the GHC User's Guide 
> https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#:~:text=GHC's%20profiling%20system%20assigns%20costs,to%20the%20enclosing%20cost%20centre.
> 
> It looks like the numbers often add up to less than 100% for the %time, but I don't see any documentation on a threshold for what makes a cost centre "costly"—so I assume that "costly" means that it takes up any time whatsoever, and any cost centres that take up any time at all are included in the report? So perhaps the numbers under %time don't add up to 100% all the time because of rounding error or perhaps garbage collection? Or something else that is not profiled?
> 
> Is that correct?
> 
> Thanks,
> 
> Celeste
> _______________________________________________
> 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/20240805/9ad6664c/attachment.html>

From rodrigo.m.mesquita at gmail.com  Mon Aug  5 08:59:36 2024
From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita)
Date: Mon, 5 Aug 2024 09:59:36 +0100
Subject: Question about profiling reports
In-Reply-To: <CAB5aLxqu0WKBNC2E1d=0QTdZ_715LfLre5t1Y5f=4-7qqdzMPw@mail.gmail.com>
References: <CAB5aLxqu0WKBNC2E1d=0QTdZ_715LfLre5t1Y5f=4-7qqdzMPw@mail.gmail.com>
Message-ID: <BDDF1784-B3C0-4566-A320-9551CB424400@gmail.com>

Hi Celeste,

You may already be aware, but there’s an alternative format to visualise profiles graphically.
Instead of `-p`, use `-pj` to produce the profiling report in JSON format, and then load the resulting .prof file into speedscope.app <https://www.speedscope.app/>.

Cheers,
Rodrigo Mesquita

> On 30 Jul 2024, at 15:57, Celeste Hollenbeck <celeste.hollenbeck at gmail.com> wrote:
> 
> Hi GHC Team,
> 
> I have a question for a research project. I'm looking at GHC's profiler, and the documentation says a profiling report displays "a break-down by cost centre of the most costly functions in the program". Here's an example of the report that I'm talking about:
> 
> 
> MAIN        MAIN                    102           0    0.0    0.0   100.0  100.0
>  CAF        GHC.IO.Handle.FD        128           0    0.0    0.0     0.0    0.0
>  CAF        GHC.IO.Encoding.Iconv   120           0    0.0    0.0     0.0    0.0
>  CAF        GHC.Conc.Signal         110           0    0.0    0.0     0.0    0.0
>  CAF        Main                    108           0    0.0    0.0   100.0  100.0
>   main      Main                    204           1    0.0    0.0   100.0  100.0
>    fib      Main                    205     2692537  100.0  100.0   100.0  100.0
> 
> This example is under Section 8.1 of the GHC User's Guide 
> https://downloads.haskell.org/ghc/latest/docs/users_guide/profiling.html#:~:text=GHC's%20profiling%20system%20assigns%20costs,to%20the%20enclosing%20cost%20centre.
> 
> It looks like the numbers often add up to less than 100% for the %time, but I don't see any documentation on a threshold for what makes a cost centre "costly"—so I assume that "costly" means that it takes up any time whatsoever, and any cost centres that take up any time at all are included in the report? So perhaps the numbers under %time don't add up to 100% all the time because of rounding error or perhaps garbage collection? Or something else that is not profiled?
> 
> Is that correct?
> 
> Thanks,
> 
> Celeste
> _______________________________________________
> 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/20240805/9ad6664c/attachment-0001.html>

From dariankline at outlook.com  Tue Aug  6 12:56:54 2024
From: dariankline at outlook.com (Jose Lane)
Date: Tue, 6 Aug 2024 12:56:54 +0000
Subject: GitLab Approval
Message-ID: <TYZPR04MB80941C6907BF89085CBA7D4EA8BF2@TYZPR04MB8094.apcprd04.prod.outlook.com>

I am looking to get my gitlab account approved. user name: Forist2034
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240806/73151c00/attachment.html>

From rodrigo.m.mesquita at gmail.com  Tue Aug  6 13:15:11 2024
From: rodrigo.m.mesquita at gmail.com (Rodrigo Mesquita)
Date: Tue, 6 Aug 2024 14:15:11 +0100
Subject: GitLab Approval
In-Reply-To: <TYZPR04MB80941C6907BF89085CBA7D4EA8BF2@TYZPR04MB8094.apcprd04.prod.outlook.com>
References: <TYZPR04MB80941C6907BF89085CBA7D4EA8BF2@TYZPR04MB8094.apcprd04.prod.outlook.com>
Message-ID: <E87C4CB4-E077-41A6-A94B-1B6279FE27FC@gmail.com>

Hello Jose,

I’ve approved your account.
Welcome! Feel free to reach out if you have any questions.

Cheers,
Rodrigo Mesquita

> On 6 Aug 2024, at 13:56, Jose Lane <dariankline at outlook.com> wrote:
> 
> I am looking to get my gitlab account approved. user name: Forist2034
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org <mailto:ghc-devs at haskell.org>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240806/3918a54a/attachment.html>

From jonathan.arnoult at tweag.io  Tue Aug  6 14:08:45 2024
From: jonathan.arnoult at tweag.io (Jonathan Arnoult)
Date: Tue, 6 Aug 2024 16:08:45 +0200
Subject: How to get unfoldings inside a GHC plugin
Message-ID: <CAF962cSD3kG2svKfOwufyPvZ9nf-WONsi8fwa7MKDAQEr-=fbQ@mail.gmail.com>

Hello,

I am working on Liquid Haskell, and I'd like to use the unfoldings of
definitions located in interface files to unfold them in proofs.

Liquid Haskell is a GHC plugin that runs in the type checking phase at the
moment, and for analysis purposes it also compiles the module down to Core.
I have found that unfolding information is available in the mi_decls field
of ModIface, and in the field realUnfoldingInfo of IdInfo. However, my
first attempts to grab for these fields yield no unfoldings either because
they have been erased (mi_decls is filled with an error call in
loadInterface) or they were not constructed to begin with
(realUnfoldingInfo is set to NoUnfolding).

In my setting, I have the name of a function, and I would need to retrieve
the unfoldings (if they exist) from some environment. Does this environment
exist already that is reachable to a plugin? Or do I need to construct it
somehow?

I also found that GHC makes a distinction between interface files in
external packages and the home package, while I really would like to get
the unfolding from wherever they happen to be.

Any advice is appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240806/6a19958f/attachment.html>

From matthewtpickering at gmail.com  Tue Aug  6 15:44:05 2024
From: matthewtpickering at gmail.com (Matthew Pickering)
Date: Tue, 6 Aug 2024 16:44:05 +0100
Subject: How to get unfoldings inside a GHC plugin
In-Reply-To: <CAF962cSD3kG2svKfOwufyPvZ9nf-WONsi8fwa7MKDAQEr-=fbQ@mail.gmail.com>
References: <CAF962cSD3kG2svKfOwufyPvZ9nf-WONsi8fwa7MKDAQEr-=fbQ@mail.gmail.com>
Message-ID: <CALuQ0m9mBji9bjs=fn22NpQ5hUEDj4SJZU_YXjUxe-0PnGqDpw@mail.gmail.com>

Hi Jonathan,

If you want to make sure unfoldings are available for all ids then you can
compile a module with `-fexpose-all-unfoldings`. Perhaps you have to
compile `base` and all GHC libraries with `-fexpose-all-unfoldings` as well?

Once you have an `Id`, you can look at the unfolding using
`realIdUnfolding`, this works the same whether it is from the home package
or not.

The `mi_decls` field isn't the right place to look, these store dehydrated
unfoldings.

Cheers,

Matt

On Tue, Aug 6, 2024 at 3:09 PM Jonathan Arnoult <jonathan.arnoult at tweag.io>
wrote:

> Hello,
>
> I am working on Liquid Haskell, and I'd like to use the unfoldings of
> definitions located in interface files to unfold them in proofs.
>
> Liquid Haskell is a GHC plugin that runs in the type checking phase at the
> moment, and for analysis purposes it also compiles the module down to Core.
> I have found that unfolding information is available in the mi_decls field
> of ModIface, and in the field realUnfoldingInfo of IdInfo. However, my
> first attempts to grab for these fields yield no unfoldings either because
> they have been erased (mi_decls is filled with an error call in
> loadInterface) or they were not constructed to begin with
> (realUnfoldingInfo is set to NoUnfolding).
>
> In my setting, I have the name of a function, and I would need to retrieve
> the unfoldings (if they exist) from some environment. Does this environment
> exist already that is reachable to a plugin? Or do I need to construct it
> somehow?
>
> I also found that GHC makes a distinction between interface files in
> external packages and the home package, while I really would like to get
> the unfolding from wherever they happen to be.
>
> Any advice is appreciated.
> _______________________________________________
> 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/20240806/bd3d99d2/attachment.html>

From sylvain at haskus.fr  Wed Aug  7 15:27:34 2024
From: sylvain at haskus.fr (Sylvain Henry)
Date: Wed, 7 Aug 2024 17:27:34 +0200
Subject: Reinstallable - base
In-Reply-To: <CAJKmMz9C_9dYkSvr0HVkGtj4HArVLVYk4XG_SVu+Y=Nm=O6XNg@mail.gmail.com>
References: <CAJKmMz9g+CvXoC=nK6+ehGaBq2Zyyh5DBdFhJcZyDYFg4NEwPg@mail.gmail.com>
 <790db448-edc1-42c4-8e65-f736feed484c@well-typed.com>
 <33bcf746-dc06-8cdb-3b0e-fb84d9ab1718@iki.fi>
 <CAGwnsnmz++aOvtC7fMNeAZprqpBH4ehrkv+St-Y-Wuf=u79Z5A@mail.gmail.com>
 <CAJKmMz9C_9dYkSvr0HVkGtj4HArVLVYk4XG_SVu+Y=Nm=O6XNg@mail.gmail.com>
Message-ID: <a6ff386b-e542-4111-a0fd-9cd13cacd345@haskus.fr>

Hi Simon,

As this came up again during the GHC call yesterday, I've written some 
notes to explain the issues and the current status (as I understand 
them): https://hsyl20.fr/posts/2024-08-07-about-ghcs-stability.html

I hope that helps. Happy to get some feedback about this by other people 
involved in the process.

Sylvain


On 20/10/2023 10:00, Simon Peyton Jones wrote:
>
>     A very large proportion of libraries, and virtually all end-user
>     applications, transitively depend on Template Haskell. Whether
>     they use Template Haskell directly or not. So if we're saying
>     “base is reinstallable, except when you have Template Haskell
>     somewhere”, we're effectively saying “base is not reinstallable”.
>     Now, it could be a good stepping-stone, from an engineering
>     standpoint, but I don't think we could deliver this and be
>     satisfied that we've accomplished anything.
>
>
> No one has yet answered my naive question (from 3 days ago) asking why 
> Template Haskell stops base being reinstallable. I'll quote it here 
> for completeness.
>
>     Let's say that
>
>       * An old library mylib (which uses TH) depends on base-4.7.
>       * A new GHC, say GHC 9.10, depends on a newer version of
>         base-4.9, which in turn depends on ghc-internal-9.10.
>       * At the same time, though, we release base-4.7.1, which depends
>         on ghc-internal-9.10, and exposes the base-4.7 API.
>
>     At this point we use ghc-9.10 to compile L, against base-4.7.1.  
>     (Note that the ghc-9.10 binary includes a compiled form of
>     `base-4.9`.)
>
>           * That produces compiled object files, such as, mylib:M.o.
>           * To run TH we need to link them with the running binary
>           * So we need to link the compiled `base-4.7.1` as well.  No
>             problem: it contains very little code; it is mostly a shim
>             for ghc-internal-9.10
>
>     So the only thing we need is the ability to have a single linked
>     binary that includes (the compiled form for) two different
>     versions/instantiations of `base`.   I think that's already
>     supported: each has a distinct "installed package id".
>
> (End of quote)
>
> What am I missing?
>
> Simon
>
> On Fri, 20 Oct 2023 at 08:57, Arnaud Spiwack <arnaud.spiwack at tweag.io> 
> wrote:
>
>     A very large proportion of libraries, and virtually all end-user
>     applications, transitively depend on Template Haskell. Whether
>     they use Template Haskell directly or not. So if we're saying
>     “base is reinstallable, except when you have Template Haskell
>     somewhere”, we're effectively saying “base is not reinstallable”.
>     Now, it could be a good stepping-stone, from an engineering
>     standpoint, but I don't think we could deliver this and be
>     satisfied that we've accomplished anything.
>
>     On Thu, 19 Oct 2023 at 13:47, Oleg Grenrus <oleg.grenrus at iki.fi>
>     wrote:
>
>         For what it worth, `template-haskell` itself depends on a
>         `base`. So if
>         `base` if different base is used, different `template-haskell`
>         is to be
>         used.
>
>         In my opinion is not *too unfair* to require that if you
>         actually splice
>         in (i.e. the code not only provides template-haskell
>         combinators to
>         create/modify splices) then you must have base and
>         template-haskell
>         versions aligned with host GHC used versions.
>
>         The same restriction is GHC plugins, isn't it, except
>         `template-haskell`
>         is replaced with `ghc`?
>
>         - Oleg
>
>         On 17.10.2023 18.54, Adam Gundry wrote:
>         > Hi Simon,
>         >
>         > Thanks for starting this discussion, it would be good to see
>         progress
>         > in this direction. As it happens I was discussing this
>         question with
>         > Ben and Matt over dinner last night, and unfortunately they
>         explained
>         > to me that it is more difficult than I naively hoped, even once
>         > wired-in and known-key things are moved to ghc-internal.
>         >
>         > The difficulty is that, as a normal Haskell library, ghc
>         itself will
>         > be compiled against a particular version of base. Then when
>         Template
>         > Haskell is used (with the internal interpreter), code will be
>         > dynamically loaded into a process that already has symbols
>         for ghc's
>         > version of base, which means it is not safe for the code to
>         depend on
>         > a different version of base. This is rather like the
>         situation with TH
>         > and cross-compilers.
>         >
>         > Adam
>         >
>         >
>         >
>         > On 17/10/2023 11:08, Simon Peyton Jones wrote:
>         >> Dear GHC devs
>         >>
>         >> Given the now-agreed split between ghc-internal and base
>         >>
>         <https://github.com/haskellfoundation/tech-proposals/pull/51>,
>         what
>         >> stands in the way of a "reinstallable base"?
>         >>
>         >> Specifically, suppose that
>         >>
>         >>   * GHC 9.8 comes out with base-4.9
>         >>   * The CLC decides to make some change to `base`, so we
>         get base-4.10
>         >>   * Then GHC 9.10 comes out with base-4.10
>         >>
>         >> I think we'd all like it if someone could use GHC 9.10 to
>         compile a
>         >> library L that depends on base-4.9 and either L doesn't
>         work at all
>         >> with base-4.10, or L's dependency bounds have not yet been
>         adjusted
>         >> to allow base-4.10.
>         >>
>         >> We'd like to have a version of `base`, say `base-4.9.1`
>         that has the
>         >> exact same API as `base-4.9` but works with GHC 9.10.
>         >>
>         >> Today, GHC 9.10 comes with a specific version of base, /and
>         you can't
>         >> change it/. The original reason for that was, I recall,
>         that GHC
>         >> knows the precise place where (say) the type Int is
>         declared, and
>         >> it'll get very confused if that data type definition moves
>         around.
>         >>
>         >> But now we have `ghc-internal`, all these "things that GHC
>         magically
>         >> knows" are in `ghc-internal`, not `base`.
>         >>
>         >> *Hence my question: what (now) stops us making `base`
>         behave like any
>         >> other library*?  That would be a big step forward, because
>         it would
>         >> mean that a newer GHC could compile old libraries against
>         their old
>         >> dependencies.
>         >>
>         >> (Some changes would still be difficult.  If, for example,
>         we removed
>         >> Monad and replaced it with classes Mo1 and Mo2, it might be
>         hard to
>         >> simulate the old `base` with a shim.  But getting 99% of
>         the way
>         >> there would still be fantastic.)
>         >>
>         >> Simon
>         >
>         _______________________________________________
>         ghc-devs mailing list
>         ghc-devs at haskell.org
>         http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
>     -- 
>     Arnaud Spiwack
>     Director, Research at https://moduscreate.com and https://tweag.io.
>     _______________________________________________
>     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/20240807/3ee8cafb/attachment.html>

From teofilcamarasu at gmail.com  Wed Aug  7 15:37:41 2024
From: teofilcamarasu at gmail.com (Teofil Camarasu)
Date: Wed, 7 Aug 2024 16:37:41 +0100
Subject: Reinstallable - base
In-Reply-To: <a6ff386b-e542-4111-a0fd-9cd13cacd345@haskus.fr>
References: <CAJKmMz9g+CvXoC=nK6+ehGaBq2Zyyh5DBdFhJcZyDYFg4NEwPg@mail.gmail.com>
 <790db448-edc1-42c4-8e65-f736feed484c@well-typed.com>
 <33bcf746-dc06-8cdb-3b0e-fb84d9ab1718@iki.fi>
 <CAGwnsnmz++aOvtC7fMNeAZprqpBH4ehrkv+St-Y-Wuf=u79Z5A@mail.gmail.com>
 <CAJKmMz9C_9dYkSvr0HVkGtj4HArVLVYk4XG_SVu+Y=Nm=O6XNg@mail.gmail.com>
 <a6ff386b-e542-4111-a0fd-9cd13cacd345@haskus.fr>
Message-ID: <CAPBO51Gi1ULGyYZdogOA5DRg1FuuQLm_nNXri=aEENgaEA3-nA@mail.gmail.com>

Thanks for writing this up!

> Note: should template-haskell be merged into base to make dependencies
simpler?


I think the answer is "no" because it has non-base dependencies. We could
vendor all of these like we do for the containers and filepath dependencies
ATM, but I'm not sure if it's worth it.

Cheers,
Teo

On Wed, 7 Aug 2024, 16:27 Sylvain Henry, <sylvain at haskus.fr> wrote:

> Hi Simon,
>
> As this came up again during the GHC call yesterday, I've written some
> notes to explain the issues and the current status (as I understand them):
> https://hsyl20.fr/posts/2024-08-07-about-ghcs-stability.html
>
> I hope that helps. Happy to get some feedback about this by other people
> involved in the process.
>
> Sylvain
>
>
> On 20/10/2023 10:00, Simon Peyton Jones wrote:
>
> A very large proportion of libraries, and virtually all end-user
>> applications, transitively depend on Template Haskell. Whether they use
>> Template Haskell directly or not. So if we're saying “base is
>> reinstallable, except when you have Template Haskell somewhere”, we're
>> effectively saying “base is not reinstallable”. Now, it could be a good
>> stepping-stone, from an engineering standpoint, but I don't think we could
>> deliver this and be satisfied that we've accomplished anything.
>>
>
> No one has yet answered my naive question (from 3 days ago) asking why
> Template Haskell stops base being reinstallable.  I'll quote it here for
> completeness.
>
> Let's say that
>>
>
>    - An old library mylib (which uses TH) depends on base-4.7.
>    - A new GHC, say GHC 9.10, depends on a newer version of base-4.9,
>    which in turn depends on ghc-internal-9.10.
>    - At the same time, though, we release base-4.7.1, which depends on
>    ghc-internal-9.10, and exposes the base-4.7 API.
>
> At this point we use ghc-9.10 to compile L, against base-4.7.1.   (Note
> that the ghc-9.10 binary includes a compiled form of `base-4.9`.)
>
>
>    - That produces compiled object files, such as, mylib:M.o.
>    - To run TH we need to link them with the running binary
>    - So we need to link the compiled `base-4.7.1` as well.  No problem:
>    it contains very little code; it is mostly a shim for ghc-internal-9.10
>
> So the only thing we need is the ability to have a single linked binary
> that includes (the compiled form for) two different versions/instantiations
> of `base`.   I think that's already supported: each has a distinct
> "installed package id".
>
> (End of quote)
>
> What am I missing?
>
> Simon
>
> On Fri, 20 Oct 2023 at 08:57, Arnaud Spiwack <arnaud.spiwack at tweag.io>
> wrote:
>
>> A very large proportion of libraries, and virtually all end-user
>> applications, transitively depend on Template Haskell. Whether they use
>> Template Haskell directly or not. So if we're saying “base is
>> reinstallable, except when you have Template Haskell somewhere”, we're
>> effectively saying “base is not reinstallable”. Now, it could be a good
>> stepping-stone, from an engineering standpoint, but I don't think we could
>> deliver this and be satisfied that we've accomplished anything.
>>
>> On Thu, 19 Oct 2023 at 13:47, Oleg Grenrus <oleg.grenrus at iki.fi> wrote:
>>
>>> For what it worth, `template-haskell` itself depends on a `base`. So if
>>> `base` if different base is used, different `template-haskell` is to be
>>> used.
>>>
>>> In my opinion is not *too unfair* to require that if you actually splice
>>> in (i.e. the code not only provides template-haskell combinators to
>>> create/modify splices) then you must have base and template-haskell
>>> versions aligned with host GHC used versions.
>>>
>>> The same restriction is GHC plugins, isn't it, except `template-haskell`
>>> is replaced with `ghc`?
>>>
>>> - Oleg
>>>
>>> On 17.10.2023 18.54, Adam Gundry wrote:
>>> > Hi Simon,
>>> >
>>> > Thanks for starting this discussion, it would be good to see progress
>>> > in this direction. As it happens I was discussing this question with
>>> > Ben and Matt over dinner last night, and unfortunately they explained
>>> > to me that it is more difficult than I naively hoped, even once
>>> > wired-in and known-key things are moved to ghc-internal.
>>> >
>>> > The difficulty is that, as a normal Haskell library, ghc itself will
>>> > be compiled against a particular version of base. Then when Template
>>> > Haskell is used (with the internal interpreter), code will be
>>> > dynamically loaded into a process that already has symbols for ghc's
>>> > version of base, which means it is not safe for the code to depend on
>>> > a different version of base. This is rather like the situation with TH
>>> > and cross-compilers.
>>> >
>>> > Adam
>>> >
>>> >
>>> >
>>> > On 17/10/2023 11:08, Simon Peyton Jones wrote:
>>> >> Dear GHC devs
>>> >>
>>> >> Given the now-agreed split between ghc-internal and base
>>> >> <https://github.com/haskellfoundation/tech-proposals/pull/51>, what
>>> >> stands in the way of a "reinstallable base"?
>>> >>
>>> >> Specifically, suppose that
>>> >>
>>> >>   * GHC 9.8 comes out with base-4.9
>>> >>   * The CLC decides to make some change to `base`, so we get base-4.10
>>> >>   * Then GHC 9.10 comes out with base-4.10
>>> >>
>>> >> I think we'd all like it if someone could use GHC 9.10 to compile a
>>> >> library L that depends on base-4.9 and either L doesn't work at all
>>> >> with base-4.10, or L's dependency bounds have not yet been adjusted
>>> >> to allow base-4.10.
>>> >>
>>> >> We'd like to have a version of `base`, say `base-4.9.1` that has the
>>> >> exact same API as `base-4.9` but works with GHC 9.10.
>>> >>
>>> >> Today, GHC 9.10 comes with a specific version of base, /and you can't
>>> >> change it/. The original reason for that was, I recall, that GHC
>>> >> knows the precise place where (say) the type Int is declared, and
>>> >> it'll get very confused if that data type definition moves around.
>>> >>
>>> >> But now we have `ghc-internal`, all these "things that GHC magically
>>> >> knows" are in `ghc-internal`, not `base`.
>>> >>
>>> >> *Hence my question: what (now) stops us making `base` behave like any
>>> >> other library*?  That would be a big step forward, because it would
>>> >> mean that a newer GHC could compile old libraries against their old
>>> >> dependencies.
>>> >>
>>> >> (Some changes would still be difficult.  If, for example, we removed
>>> >> Monad and replaced it with classes Mo1 and Mo2, it might be hard to
>>> >> simulate the old `base` with a shim.  But getting 99% of the way
>>> >> there would still be fantastic.)
>>> >>
>>> >> Simon
>>> >
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
>>
>> --
>> Arnaud Spiwack
>> Director, Research at https://moduscreate.com and https://tweag.io.
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240807/02346099/attachment.html>

From george.colpitts at gmail.com  Wed Aug  7 15:39:20 2024
From: george.colpitts at gmail.com (George Colpitts)
Date: Wed, 7 Aug 2024 12:39:20 -0300
Subject: GHC 9.12 release schedule
In-Reply-To: <yrsll6vjgcmnzswetr3gl6vxq5c7o7pkgdh75jo3vluf6wpze6@yg2glt43abjj>
References: <yrsll6vjgcmnzswetr3gl6vxq5c7o7pkgdh75jo3vluf6wpze6@yg2glt43abjj>
Message-ID: <CAB-d4A79rmUTJ46n9LjerjCA5R-==qSsLT_Utkea4kDybu5qaA@mail.gmail.com>

In case people haven't seen this, I assume it might affect the release for
the Mac although it seems that the release won't have to be signed. Just a
little harder to install:

https://www.macrumors.com/2024/08/06/macos-sequoia-gatekeeper-security-change/



On Thu, Aug 1, 2024 at 4:36 AM Zubin Duggal <zubin at well-typed.com> wrote:

> Hi all,
>
> We are in the process of planning the GHC 9.12 release. The tentative
> schedule is a fork date in mid September with a final release in late
> November.
>
> If you are working on any major patches that should be included in
> this release, please be in touch. Furthermore, please ensure that all
> appropriate tickets or MRs are appropriately tagged with the %9.12.1
> milestone (https://gitlab.haskell.org/ghc/ghc/-/milestones/393).
>
> You can also use the release tracking ticket for further discussion:
> https://gitlab.haskell.org/ghc/ghc/-/issues/25123
>
> Cheers,
> Zubin
> _______________________________________________
> 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/20240807/a26521b5/attachment.html>

From moritz.angermann at gmail.com  Thu Aug  8 01:36:28 2024
From: moritz.angermann at gmail.com (Moritz Angermann)
Date: Thu, 8 Aug 2024 10:36:28 +0900
Subject: GHC 9.12 release schedule
In-Reply-To: <CAB-d4A79rmUTJ46n9LjerjCA5R-==qSsLT_Utkea4kDybu5qaA@mail.gmail.com>
References: <yrsll6vjgcmnzswetr3gl6vxq5c7o7pkgdh75jo3vluf6wpze6@yg2glt43abjj>
 <CAB-d4A79rmUTJ46n9LjerjCA5R-==qSsLT_Utkea4kDybu5qaA@mail.gmail.com>
Message-ID: <CAKfdd-wJCCmGbjO_=cks6HhJcD8hz0nYsE0FaJqQTuYCX5tupw@mail.gmail.com>

I'll try to experiment with sequoria on one of my macs and report back.

On Thu, 8 Aug 2024 at 00:40, George Colpitts <george.colpitts at gmail.com>
wrote:

> In case people haven't seen this, I assume it might affect the release for
> the Mac although it seems that the release won't have to be signed. Just a
> little harder to install:
>
>
> https://www.macrumors.com/2024/08/06/macos-sequoia-gatekeeper-security-change/
>
>
>
> On Thu, Aug 1, 2024 at 4:36 AM Zubin Duggal <zubin at well-typed.com> wrote:
>
>> Hi all,
>>
>> We are in the process of planning the GHC 9.12 release. The tentative
>> schedule is a fork date in mid September with a final release in late
>> November.
>>
>> If you are working on any major patches that should be included in
>> this release, please be in touch. Furthermore, please ensure that all
>> appropriate tickets or MRs are appropriately tagged with the %9.12.1
>> milestone (https://gitlab.haskell.org/ghc/ghc/-/milestones/393).
>>
>> You can also use the release tracking ticket for further discussion:
>> https://gitlab.haskell.org/ghc/ghc/-/issues/25123
>>
>> Cheers,
>> Zubin
>> _______________________________________________
>> 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/20240808/fe793a0d/attachment.html>

From carter.schonwald at gmail.com  Sat Aug 10 13:50:53 2024
From: carter.schonwald at gmail.com (Carter Schonwald)
Date: Sat, 10 Aug 2024 09:50:53 -0400
Subject: How to implement type-level list concatenation as a GHC primitive
 type family
In-Reply-To: <39bd21c7-eee5-46a9-82b1-99c28ad4e6b2@glitchbra.in>
References: <69589ef1-7c32-41f8-878e-1180433276fa@glitchbra.in>
 <0638f8c8-8ad3-59be-6d1b-d998392d70fe@erdi.hu>
 <39bd21c7-eee5-46a9-82b1-99c28ad4e6b2@glitchbra.in>
Message-ID: <CAHYVw0wHw=1yfMvRqun7AmWZJqzjFtxRF0E8ndt67FmD4xyPKA@mail.gmail.com>

One thing that’s worth noting: type level sets or  maps, whether ord or
hash plus eq based, will have much algorithmics for a lot of uses of type
level lists. And this difference could be even more dramatic if they’re
internalized / primitive

On Wed, Jul 3, 2024 at 3:42 AM Hécate via ghc-devs <ghc-devs at haskell.org>
wrote:

> Thank you Gergő, this delightfully cursed! :D
>
> I was pointed by someone off-list to “Note [Adding built-in type
> families]” which is actually very complete!
>
> One last thing is that since everything is Xi-typed (new form of
> "stringly-typed" uncovered), the meaning of the parameters is a bit
> blurred when they all are called x1, z1, y1, in GHC.Builtin.Types.Literals.
>
> See for instance:
>
> https://hackage.haskell.org/package/ghc-9.10.1/docs/src/GHC.Builtin.Types.Literals.html#interactInertAppendSymbol
>
> Le 03/07/2024 à 06:35, ÉRDI Gergő a écrit :
> > I know this is not exactly what you're asking, but in similar
> > situations I've had very good results from implementing my type family
> > as a type checker plugin. Unfortunately it's not code that I can
> > share, but it roughly goes like this:
> >
> > 1. Declare a closed type family without defining any clauses:
> >
> >     type family Append (xs :: [k]) (ys :: [k]) :: [k] where
> >
> > 2. Create a typechecker plugin that in `tcPluginInit` looks up this
> > `Append` tyfam's tycon, and in `tcPluginRewrite` maps it to a
> > `TcPluginRewriter`
> >
> > 3. Inside the `TcPluginRewriter`, you have a `[TcType]` which are your
> > arguments (so the two type-level lists that are concatenated in your
> > example). If you can compute your tyfam result from that, you can then
> > return a `TcPluginRewriteTo` with the "trust-me" coercion `UnivCo`.
> > This is what really helps with performance vs. a native
> > Haskell-defined tyfam, since it avoids Core passing around huge
> > coercion terms corresponding to every reduction step.
> > (https://gitlab.haskell.org/ghc/ghc/-/issues/8095
> > https://gitlab.haskell.org/ghc/ghc/-/issues/22323 and many more)
> >
> > The only tricky part is that in step 3, you have to be prepared to
> > handle pratially meta arguments. For example, if your arguments are
> > `String : Double : []` and `Int : Bool : α` (with some typechecker
> > metavariable `α`), you can of course reduce that to `String : Double :
> > Int : Bool : α`. But if they are flipped, you can either bail out
> > until `α` is solved, or make partial progress to `Int : Bool : Append
> > α (String : Double : [])`. I don't know which is the right choice in
> > general, since bailing out might expose less info to type inference,
> > but partial progressing means your coercion terms will grow, since
> > you're restoring some of that step-by-step representation.
> >
> > Let me know if any of this makes sense, I've got the flu atm so the
> > above might be too rambly :)
> >
> > Bye,
> >     Gergo
> >
> > On Wed, 3 Jul 2024, Hécate via ghc-devs wrote:
> >
> >> Hi GHC devs,
> >>
> >> I was wondering recently, considering that type family evaluation is
> >> notoriously slow, how one would implement type-level list
> >> concatenation directly within GHC in a way that is much less
> >> expensive to run. So I am looking for pointers, as this part of GHC
> >> is fairly unknown to me.
> >>
> >> Thinking about it, I'm actually unsure where the tyfam evaluation is
> >> happening.
> >>
> >> Any advice would be appreciated.
> >>
> >> Cheers,
> >> Hécate
> >>
> >>
> >
> --
> Hécate ✨
> 🐦: @TechnoEmpress
> IRC: Hecate
> WWW: https://glitchbra.in
> RUN: BSD
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240810/b67398ca/attachment.html>

From iavor.diatchki at gmail.com  Sat Aug 10 14:48:33 2024
From: iavor.diatchki at gmail.com (Iavor Diatchki)
Date: Sat, 10 Aug 2024 07:48:33 -0700
Subject: How to implement type-level list concatenation as a GHC primitive
 type family
In-Reply-To: <69589ef1-7c32-41f8-878e-1180433276fa@glitchbra.in>
References: <69589ef1-7c32-41f8-878e-1180433276fa@glitchbra.in>
Message-ID: <CAGK9nuqh-kEzu1tzkLaO78X80Rax5OchnpFWnEDKc7A5GKd-Qw@mail.gmail.com>

I'd say the main reason to implement `append` in GHC would be to handle
rules that can't be solved by evaluation (e.g., eliminate append [] on the
right, some associativity rule, etc.).

The speed of evaluation shouldn't really be much different as it should be
doing the same thing, more or less.

If there is a big performance hit for just straight evaluation, it might be
better to work on that part of GHC, which would also benefit other
functions, rather than adding more special cased functions.

Cheers,
Iavor

On Tue, Jul 2, 2024, 3:30 PM Hécate via ghc-devs <ghc-devs at haskell.org>
wrote:

> Hi GHC devs,
>
> I was wondering recently, considering that type family evaluation is
> notoriously slow, how one would implement type-level list concatenation
> directly within GHC in a way that is much less expensive to run. So I am
> looking for pointers, as this part of GHC is fairly unknown to me.
>
> Thinking about it, I'm actually unsure where the tyfam evaluation is
> happening.
>
> Any advice would be appreciated.
>
> Cheers,
> Hécate
>
> --
> Hécate ✨
> 🐦: @TechnoEmpress
> IRC: Hecate
> WWW: https://glitchbra.in
> RUN: BSD
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240810/e6b9a6f6/attachment.html>

From allbery.b at gmail.com  Sun Aug 11 02:50:21 2024
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 10 Aug 2024 22:50:21 -0400
Subject: HIE using ideclImplicit
Message-ID: <CAKFCL4U61yXcmgQBAQ8ea3WzLHuL55DbQKvM5m5AO5Tap7uUeA@mail.gmail.com>

I've been sitting on a potential proposal to enable per-import disabling of
-Wunused-imports and -Wmissing-import-lists for a while now, and
https://mail.haskell.org/pipermail/haskell-cafe/2024-August/136852.html has
me thinking of moving forward with it.

It turns out that this would be very easy to implement within ghc, as the
ideclImplicit field of ideclExt (itself a field of ImportDecl) already does
what's needed; it exists to track the implicit Prelude import, and would be
almost trivial to set when parsing an import. I did a check to see if
anything used it as a proxy for "this is the Prelude", and everything that
wants that explicitly looks for the Prelude module, with one exception: HIE
information excludes anything from an import with ideclImplicit set.

My questions are:
1. Is this (omitting imports with ideclImplicit) even sane? What happens
with HIE information when Prelude definitions are used in the module?
2. Is this use of ideclImplicit going to cause problems with my proposed
use?
2a. Should HIE be checking explicitly for Prelude as other things do, or is
it more correct for other imports with ideclImplicit set to be treated the
same way?

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

From allbery.b at gmail.com  Thu Aug 15 03:02:31 2024
From: allbery.b at gmail.com (Brandon Allbery)
Date: Wed, 14 Aug 2024 23:02:31 -0400
Subject: HIE using ideclImplicit
In-Reply-To: <CAKFCL4U61yXcmgQBAQ8ea3WzLHuL55DbQKvM5m5AO5Tap7uUeA@mail.gmail.com>
References: <CAKFCL4U61yXcmgQBAQ8ea3WzLHuL55DbQKvM5m5AO5Tap7uUeA@mail.gmail.com>
Message-ID: <CAKFCL4X--4uUmnRMWKN6J+9qq1LpgYb3KiQCX8VvMpoP0csODQ@mail.gmail.com>

Anyone with comments?

On Sat, Aug 10, 2024 at 10:50 PM Brandon Allbery <allbery.b at gmail.com>
wrote:

> I've been sitting on a potential proposal to enable per-import disabling
> of -Wunused-imports and -Wmissing-import-lists for a while now, and
> https://mail.haskell.org/pipermail/haskell-cafe/2024-August/136852.html
> has me thinking of moving forward with it.
>
> It turns out that this would be very easy to implement within ghc, as the
> ideclImplicit field of ideclExt (itself a field of ImportDecl) already does
> what's needed; it exists to track the implicit Prelude import, and would be
> almost trivial to set when parsing an import. I did a check to see if
> anything used it as a proxy for "this is the Prelude", and everything that
> wants that explicitly looks for the Prelude module, with one exception: HIE
> information excludes anything from an import with ideclImplicit set.
>
> My questions are:
> 1. Is this (omitting imports with ideclImplicit) even sane? What happens
> with HIE information when Prelude definitions are used in the module?
> 2. Is this use of ideclImplicit going to cause problems with my proposed
> use?
> 2a. Should HIE be checking explicitly for Prelude as other things do, or
> is it more correct for other imports with ideclImplicit set to be treated
> the same way?
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
>


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

From sgraf1337 at gmail.com  Sun Aug 18 08:54:40 2024
From: sgraf1337 at gmail.com (Sebastian Graf)
Date: Sun, 18 Aug 2024 08:54:40 +0000
Subject: Can't initialise vendored submodule
In-Reply-To: <CAGwnsnn2jJtZrSmzuL-G6WxHkifBarMeJWNEy6t2PcHiyxL7Kg@mail.gmail.com>
References: <CAGwnsnnyFb4AcsQKPNRM359_dqKu646+_boKJqttwx_=KR6Dag@mail.gmail.com>
 <CACK-K+3UEvv9Dd=jP-_mV5fJzkPaSFTtqFK01sdVGr6xmejpKg@mail.gmail.com>
 <CALuQ0m-SjPaO0zZ4MyYf-URKPdahFqLMcjs1sym5u51hCNMCag@mail.gmail.com>
 <CAGwnsnn2jJtZrSmzuL-G6WxHkifBarMeJWNEy6t2PcHiyxL7Kg@mail.gmail.com>
Message-ID: <em4d4b97fa-3739-48d6-8908-bea6b6abe22a@3400117b.com>

Hi,

I also frequently encounter these errors.
I think they are caused by me copying from an ancient local clone, one 
that still has historic account of when hadrian used to live in its own 
submodule.
Recently, the hadrian system vendored Cabal into hadrian/vendored/Cabal, 
but the root repository had still listed a submodule at 
.git/modules/hadrian, explaining the error.
Indeed, just removing the ancient .git/modules/hadrian is the solution.

Note that the vendored submodule means you cannot easily check out a 
branch from ... 5 years (?) ago, because then you will get the reverse 
error.
Fresh clones should not be affected.

Cheers,
Sebastian


------ Originalnachricht ------
Von "Arnaud Spiwack" <arnaud.spiwack at tweag.io>
An "Matthew Pickering" <matthewtpickering at gmail.com>
Cc "GHC developers" <ghc-devs at haskell.org>
Datum 02.08.2024 15:27:23
Betreff Re: Can't initialise vendored submodule

>Thanks Matthew, this helped me find the solution.
>
>Which, is turn out, was simply to remove the old directory:
>
>$  rm -rf .git/modules/hadrian/
>
>It's not removed by `git submodule desync` or any command that I could 
>find (though, now that I think about it, I didn't try to garbage 
>collect the repo, so maybe?). But it's sound to just delete, as far as 
>I can tell: it's just a cache.
>
> > The usage of submodules in `hadrian/vendored` is a standard usage.
>
>This goes to show that I was at least right when saying that submodules 
>are wonky :D .
>
>On Fri, 2 Aug 2024 at 12:11, Matthew Pickering 
><matthewtpickering at gmail.com> wrote:
>>It seems you might have a some very old configuration from when 
>>hadrian used to be a submodule? Perhaps a fresh clone would help 
>>things along?
>>
>>The usage of submodules in `hadrian/vendored` is a standard usage.
>>
>>Cheers,
>>
>>Matt
>>
>>On Fri, Aug 2, 2024 at 11:08 AM Vaibhav Sagar <vaibhavsagar at gmail.com> 
>>wrote:
>>>I think you want --recursive
>>>
>>>
>>>On Fri, 2 Aug 2024, 8:05 pm Arnaud Spiwack, <arnaud.spiwack at tweag.io> 
>>>wrote:
>>>>Dear all,
>>>>
>>>>I'm currently unable to build GHC's master branch as some of the 
>>>>submodules (presumably used by Hadrian) are making git pretty 
>>>>unhappy (I've used various variants of the command below, in a 
>>>>cleaned repository):
>>>>
>>>>```console
>>>>$  git submodule update --init
>>>>error: submodule git dir 
>>>>'/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal' 
>>>>is inside git dir 
>>>>'/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian'
>>>>fatal: refusing to create/use 
>>>>'/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal' 
>>>>in another submodule's git dir
>>>>Failed to clone 'hadrian/vendored/Cabal'. Retry scheduled
>>>>error: submodule git dir 
>>>>'/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal' 
>>>>is inside git dir 
>>>>'/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian'
>>>>fatal: refusing to create/use 
>>>>'/home/aspiwack/projects/tweag/ghc/master/.git/modules/hadrian/vendored/Cabal' 
>>>>in another submodule's git dir
>>>>Failed to clone 'hadrian/vendored/Cabal' a second time, aborting
>>>>```
>>>>
>>>>Please advise on how to get unblocked.
>>>>
>>>>And, if I'm allowed to conclude with a plea: please be careful not 
>>>>to abuse Git's submodule system, it's wonky enough when used simply.
>>>>
>>>>--
>>>>Arnaud Spiwack
>>>>Director, Research at https://moduscreate.com and https://tweag.io.
>>>>_______________________________________________
>>>>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
>
>
>--
>Arnaud Spiwack
>Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20240818/a6b9b0cf/attachment.html>

From gergo at erdi.hu  Mon Aug 19 03:33:50 2024
From: gergo at erdi.hu (=?ISO-8859-2?Q?=C9RDI_Gerg=F5?=)
Date: Mon, 19 Aug 2024 11:33:50 +0800 (+08)
Subject: stack.yaml.lock gets dirty by building with build-stack
Message-ID: <85198e90-0e27-1860-e78a-2e775fb5af1b@erdi.hu>

Hi,

I have no local changes to hadrian/stack.yaml, but after running 
hadrian/build-stack, my hadrian/stack.yaml.lock file gets changed (all the 
custom package hashes are removed).

Could someone check that the newly generated file is indeed the correct 
current one, and bump `master` if so?

Thanks,
 	Gergo

From gergo at erdi.hu  Mon Aug 19 03:34:45 2024
From: gergo at erdi.hu (=?ISO-8859-2?Q?=C9RDI_Gerg=F5?=)
Date: Mon, 19 Aug 2024 11:34:45 +0800 (+08)
Subject: stack.yaml.lock gets dirty by building with build-stack
In-Reply-To: <85198e90-0e27-1860-e78a-2e775fb5af1b@erdi.hu>
References: <85198e90-0e27-1860-e78a-2e775fb5af1b@erdi.hu>
Message-ID: <ba3bf6e8-b255-9d61-7012-83de3c288b08@erdi.hu>

> I have no local changes to hadrian/stack.yaml, but after running 
> hadrian/build-stack, my hadrian/stack.yaml.lock file gets changed (all the 
> custom package hashes are removed).

I think the cause is commit 145a6477854d4003a07573d5e7ffa0c9a64ae29c which 
removed Cabal from Stack's `extra-deps`.