Re: Weird pipeline failures

[Matthew Pickering]

A bad commit made it into master (my fault) and I have now fixed this
and rebased your patch over it.

Matt

On Tue, Aug 22, 2023 at 7:19 AM Erdi, Gergo via ghc-devs
 wrote:
>
> PUBLIC
>
>
> Hi,
>
>
>
> On e.g. 
> https://gitlab.haskell.org/ghc/ghc/-/commit/9b4fe2a39952b0a463bcf67f1b357b8364f6725e/pipelines
>  I am seeing very weird failures tagged “yaml invalid”:
>
>
>
> Unable to create pipeline
>
> 'test-primops-validate' job needs 'x86_64-linux-deb10-validate+debug_info' 
> job, but 'x86_64-linux-deb10-validate+debug_info' is not in any previous stage
> 'test-primops-validate' job needs 'x86_64-darwin-validate' job, but 
> 'x86_64-darwin-validate' is not in any previous stage
>
> Is the CI setup experiencing some temporary hiccup, or is `master` broken?
>
>
>
> Thanks,
>
> Gergo
>
>
> This email and any attachments are confidential and may also be privileged. 
> If you are not the intended recipient, please delete all copies and notify 
> the sender immediately. You may wish to refer to the incorporation details of 
> Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
> https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard Chartered PLC, 
> Standard Chartered Bank and their subsidiaries (the "Group"), information on 
> the regulatory standards we adhere to and how it may affect you can be found 
> in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and 
> Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and 
> contains any market commentary, the market commentary has been prepared by 
> the sales and/or trading desk of Standard Chartered Bank or its affiliate. It 
> is not and does not constitute research material, independent research, 
> recommendation or financial advice. Any market commentary is for information 
> purpose only and shall not be relied on for any other purpose and is subject 
> to the relevant disclaimers available at https: 
> //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and 
> contains any research materials prepared by members of the team, the research 
> material is for information purpose only and shall not be relied on for any 
> other purpose, and is subject to the relevant disclaimers available at https: 
> //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction, by 
> responding affirmatively to this e-mail, you agree that you have understood 
> the terms and conditions in the attached term sheet and evaluated the merits 
> and risks of the transaction. We may at times also request you to sign the 
> term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for 
> important information with respect to derivative products.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

ghc-9.4.6 is being prepared

[Matthew Pickering]

Hi all,

Zubin is preparing the 9.4.6 release so we expect to release it within
the next two weeks.

The focus of the release ot back-port the quite large number of fixes
which are marked for backport to 9.4.

https://gitlab.haskell.org/ghc/ghc/-/merge_requests?scope=all=opened_name[]=backport%20needed%3A9.4

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: I can't build HEAD

[Matthew Pickering]

The ticket which tracks bumping the bootstrap compiler to 9.4 is
https://gitlab.haskell.org/ghc/ghc/-/issues/23195

We should bump all the images and update the configure check *before*
merging changes which require a newer bootstrap compiler.

I imagine this problem has been introduced by
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/10827 so I will
revert that commit for now until the relevant other parts have been
updated.

Cheers,

Matt

On Sun, Jul 9, 2023 at 9:53 PM Simon Peyton Jones
 wrote:
>>
>> Upgrade your bootstrap compiler to >= 9.4. We have now bumped HEAD's
>> version to 9.8, which means that 9.4 is the earliest possible bootstrap
>> compiler (which `text` now takes advantage of, as you see here). I have
>
>
> Aha.  I'll do that.
>
> You have to admit, the error message is not helpful :-).  A suggestion for 
> the future: when bumping the minimum bootstrap compiler, it would be possible 
> (in the same commit) to fix configure to complain about too-early versions?
>
> Anyway I'm now building with 9.6, and doubtless that will be fine.  Thanks.
>
> Simon
>
>
>
> On Sun, 9 Jul 2023 at 18:49, Ben Gamari  wrote:
>>
>> Simon Peyton Jones  writes:
>>
>> > in a clean HEAD build, including "git submodule update", I get this.
>> >
>> > Can anyone help?
>> >
>> Upgrade your bootstrap compiler to >= 9.4. We have now bumped HEAD's
>> version to 9.8, which means that 9.4 is the earliest possible bootstrap
>> compiler (which `text` now takes advantage of, as you see here). I have
>> a patch bumping the `configure` check stewing in my 9.8 preparation
>> branch.
>>
>> Cheers,
>>
>> - Ben
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Improving Merge Request review processes

[Matthew Pickering]

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
 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  
> 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
>>  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@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Improving Merge Request review processes

[Matthew Pickering]

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
 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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Improving Merge Request review processes

[Matthew Pickering]

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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

End of 9.2.* release series

[Matthew Pickering]

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
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trouble building GHC

[Matthew Pickering]

Hi Lyle,

It seems that you set-up a proper native toolchain (without nix) and
that you might be running into this issue:
https://gitlab.haskell.org/ghc/ghc/-/issues/22451

Do you have any symlinks anywhere around the build folder?

Cheers,

Matt

On Wed, May 31, 2023 at 4:14 AM Lyle Kopnicky  wrote:
>
> 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 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 

Release schedules: 9.6.2 and 9.8.1

[Matthew Pickering]

Hi all,

* We are preparing the 9.6.2 release to happen within 1-2 weeks.

* The proposed 9.8.1 schedule is as follows:

Fork Date: June 16th
Release Date: Early September

Feature patches not in the tree by June 16th will not be included in
the release.

This is the six-month release cadence which we have proposed to follow.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 9.2.7 on FreeBSD - HSC2HS_EXTRA issue

[Matthew Pickering]

The HSC2HS_EXTRA option was fixed in

```
commit 99623358754d812b8b4bdfcdc57190d38617b9cc
Author: Matthew Pickering 
Date:   Thu Mar 10 20:48:44 2022 +

hadrian: Correct generation of hsc2hs wrapper

If you inspect the inside of a wrapper script for hsc2hs you will see
that the cflag and lflag values are concatenated incorrectly.

```
HSC2HS_EXTRA="--cflag=-U__i686--lflag=-fuse-ld=gold"
```

It should instead be

```
HSC2HS_EXTRA="--cflag=-U__i686 --lflag=-fuse-ld=gold"
```

Fixes #21221
```

On Tue, Mar 21, 2023 at 1:28 PM Matthew Pickering
 wrote:
>
> Hi Martin,
>
> Thanks for your reports.
>
> I have approved your account on gitlab now.
>
> * The FreeBSD bindists are not officially created during the release
> process. The ones you are using from ghcup are created (and
> maintained) by the ghcup maintainers.
> * Most linux bindists are created using the old make build system on
> the 9.2.* series but it seems these bindists were not.
> * We will gladly fix the bugs you report with the  hsc2hs wrapper.
> * Please open an issue for the problem with --target flag
>
> Cheers,
>
> Matt
>
> On Mon, Mar 20, 2023 at 2:05 AM Martin Baulig via ghc-devs
>  wrote:
> >
> > Hello,
> >
> > I am a FreeBSD user, running FreeBSD 13.1 with Clang 13 and GCC 12.2, and 
> > still fairly new to the Haskell Platform.
> >
> > When I tried to upgrade a hobby project to Stackage's latest LTS 20.15, I 
> > realized that neither the GHC 9.2.6 nor
> > the GHC 9.2.7 binary packages from GHCUP work anymore.
> >
> > There are two issues - and I wrote a detailed article about my 
> > investigation on Medium:
> > https://medium.com/@martin.baulig/ghc-9-2-7-on-freebsd-22afab71c715
> >
> > The first one is a trivial one-line change - in 
> > hadrian/src/Rules/BinaryDist.hs, we need to change
> >
> > ( "HSC2HS_EXTRA=\"" <> unwords ccArgs <> unwords ldFlags <> "\""
> >
> >
> > into
> >
> > ( "HSC2HS_EXTRA=\"" <> unwords (ccArgs <> ldFlags) <> "\""
> >
> >
> > Otherwise, this will break when both ccArgs and ldFlags are non-empty:
> >
> > HSC2HS_EXTRA="--cflag=--target=x86_64-portbld-freebsd--lflag=--target=x86_64-portbld-freebsd
> >  --lflag=-fuse-ld=lld"
> >
> >
> > Unfortunately, this is not quite it just yet.
> >
> > The problem is that Clang supports the --target= argument, but GCC does not 
> > - and it looks like Cabal insists on always
> > invoking hsc2hs with an explicit --cc= argument.
> >
> > Overriding that in ~/.cabal/config doesn't work either - because then Cabal 
> > passes "-pgmc /usr/bin/cc" to GHC, but no
> > "-pgma" and GHC tries to invoke GCC for assembling with a Clang-only 
> > argument.
> >
> > I am a bit lost here now about what the correct path forward is, but would 
> > very much like to help fixing this problem,
> > so I created an account on gitlab.haskell.org to report this issue, but got 
> > a message saying that it is awaiting admin
> > approval.  Looking a bit further in the documentation for new contributors, 
> > I saw a comment suggesting I should
> > post on this mailing list and ask for approval.  Could an admin please have 
> > a look at that?  My user name is my last
> > name in lowercase, baulig.
> >
> > Looking forward to hear back from you,
> >
> > Martin
> >
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 9.2.7 on FreeBSD - HSC2HS_EXTRA issue

[Matthew Pickering]

Hi Martin,

Thanks for your reports.

I have approved your account on gitlab now.

* The FreeBSD bindists are not officially created during the release
process. The ones you are using from ghcup are created (and
maintained) by the ghcup maintainers.
* Most linux bindists are created using the old make build system on
the 9.2.* series but it seems these bindists were not.
* We will gladly fix the bugs you report with the  hsc2hs wrapper.
* Please open an issue for the problem with --target flag

Cheers,

Matt

On Mon, Mar 20, 2023 at 2:05 AM Martin Baulig via ghc-devs
 wrote:
>
> Hello,
>
> I am a FreeBSD user, running FreeBSD 13.1 with Clang 13 and GCC 12.2, and 
> still fairly new to the Haskell Platform.
>
> When I tried to upgrade a hobby project to Stackage's latest LTS 20.15, I 
> realized that neither the GHC 9.2.6 nor
> the GHC 9.2.7 binary packages from GHCUP work anymore.
>
> There are two issues - and I wrote a detailed article about my investigation 
> on Medium:
> https://medium.com/@martin.baulig/ghc-9-2-7-on-freebsd-22afab71c715
>
> The first one is a trivial one-line change - in 
> hadrian/src/Rules/BinaryDist.hs, we need to change
>
> ( "HSC2HS_EXTRA=\"" <> unwords ccArgs <> unwords ldFlags <> "\""
>
>
> into
>
> ( "HSC2HS_EXTRA=\"" <> unwords (ccArgs <> ldFlags) <> "\""
>
>
> Otherwise, this will break when both ccArgs and ldFlags are non-empty:
>
> HSC2HS_EXTRA="--cflag=--target=x86_64-portbld-freebsd--lflag=--target=x86_64-portbld-freebsd
>  --lflag=-fuse-ld=lld"
>
>
> Unfortunately, this is not quite it just yet.
>
> The problem is that Clang supports the --target= argument, but GCC does not - 
> and it looks like Cabal insists on always
> invoking hsc2hs with an explicit --cc= argument.
>
> Overriding that in ~/.cabal/config doesn't work either - because then Cabal 
> passes "-pgmc /usr/bin/cc" to GHC, but no
> "-pgma" and GHC tries to invoke GCC for assembling with a Clang-only argument.
>
> I am a bit lost here now about what the correct path forward is, but would 
> very much like to help fixing this problem,
> so I created an account on gitlab.haskell.org to report this issue, but got a 
> message saying that it is awaiting admin
> approval.  Looking a bit further in the documentation for new contributors, I 
> saw a comment suggesting I should
> post on this mailing list and ask for approval.  Could an admin please have a 
> look at that?  My user name is my last
> name in lowercase, baulig.
>
> Looking forward to hear back from you,
>
> Martin
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Help! Can't build HEAD

[Matthew Pickering]

You need to run `git submodule update` I think.

On Wed, Mar 15, 2023 at 12:36 PM Simon Peyton Jones
 wrote:
>
> Aargh!  I can't build HEAD!
>
> I get this:
> ./hadrian/build
> Up to date
> ]0;Starting... ]0;Finished in 0.04s Error, file does not exist and no rule 
> available:
>   utils/hpc/hpc-bin.cabal
> Build failed.
>
>
> This is after
> hadrian/build clean
> ./boot
> ./configure
>
> I'm very stalled.  All my trees are borked.  Can anyone help?
>
> Simon
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Using GHC API with multiple targets

[Matthew Pickering]

The GHC API code you give is fine, and works correctly. In the whole
reproducer there is some additional code `getCoreFS` which is where
the error comes from.

On Mon, Feb 6, 2023 at 1:56 PM Matthew Pickering
 wrote:
>
> Can you put the whole example into a github repo and then I will look
> at what is wrong?
>
> Matt
>
> On Mon, Feb 6, 2023 at 1:34 PM Eternal Recursion via ghc-devs
>  wrote:
> >
> > Thanks, Andreas!
> >
> > I will check out the hint package and also play with verbosity and 
> > workingDirectory.
> >
> > I considered using the Cabal library to derive the inputs from the 
> > project's cabal file, but it does help first to know what the needful 
> > inputs are, and where to stash them in the DynFlags session settings.
> >
> > It's got to be one of those "One Weird Trick (tm)" gotcha settings that 
> > make it suddenly work. It seems obvious what some of the settings mean, but 
> > I suppose with more familiarity will come appreciation of nuances that make 
> > the apparently obvious meaning seem obviously wrong.
> >
> > Sincerely,
> >
> > Bob
> >
> > Sent with Proton Mail secure email.
> >
> > --- Original Message ---
> > On Monday, February 6th, 2023 at 7:53 AM, Andreas Klebinger 
> >  wrote:
> >
> > I think this is an ok forum for this kind of question. You could also try 
> > the haskell mailing list but I'm not sure if you will get more
> > help tehre.
> >
> > I recently played around with the ghc api and I found the `hint` package to 
> > be quite helpful as an example on how to do various
> > things when using the ghc api to implement your own interpreter.
> >
> > Have you tried setting verbose? Perhaps the include dir is relative to the 
> > working directory. In that case setting:
> >
> > , workingDirectory = Just targetDir
> > , importPaths = [targetDir] ++ importPaths dynflags
> >
> > would mean ghc will search in targetDir/targetDir for Lib/Lib2. Should be 
> > easy to say for sure by enabling verbosity and looking at the output.
> >
> > Am 06/02/2023 um 13:42 schrieb Eternal Recursion via ghc-devs:
> >
> > If this is the wrong forum for this question (which as I think about it, I 
> > suppose it is) then redirection to a more appropriate mailing list or forum 
> > (or any advice, really) would be appreciated. I just figured this would be 
> > the forum with the best understanding of how the GHC API works (and has 
> > changed over time), and my longer term goal is indeed to contribute to it 
> > after I get past my learning curve.
> >
> > Sincerely,
> >
> > Bob
> >
> > Sent with Proton Mail secure email.
> >
> > --- Original Message ---
> > On Saturday, February 4th, 2023 at 4:04 PM, Eternal Recursion via ghc-devs 
> >  wrote:
> >
> > Hi Everyone!
> >
> > I'm new here, trying to learn the GHC API. using 944 with cabal 3.8.1.0.
> >
> > How do I correctly set a GHC Session's DynFlags (and/or other properties) 
> > to ensure local libraries imported by the main target are resolved properly 
> > at compile time?
> >
> > What flags need to be set so that GHC is able to load/analyze/compile all 
> > relevant Libraries in a package?
> >
> > This is my current code:
> >
> > withPath :: FilePath -> IO ()
> > withPath target = do
> > let targetDir = takeDirectory target
> > let targetFile = takeFileName target
> > listing <- listDirectory targetDir
> > let imports = filter (\f -> takeExtension f == ".hs") listing
> > print imports
> > let moduleName = mkModuleName targetFile
> > g <- defaultErrorHandler defaultFatalMessager defaultFlushOut
> > $ runGhc (Just libdir) $ do
> > initGhcMonad (Just libdir)
> > dynflags <- getSessionDynFlags
> > setSessionDynFlags $ dynflags { ghcLink = LinkInMemory
> > , ghcMode = CompManager
> > , backend = Interpreter
> > , mainModuleNameIs = moduleName
> > , workingDirectory = Just targetDir
> > , importPaths = [targetDir] ++ importPaths dynflags
> > }
> > targets <- mapM (\t -> guessTarget t Nothing Nothing) imports
> > setTargets targets
> > setContext [ IIDecl $ simpleImportDecl (mkModuleName "Prelude") ]
> > load LoadAllTargets
> > liftIO . print . ppr =<< getTargets
> > getModuleGraph
> > putStrLn "Here we go!"
> > print $ ppr $ mgModSummaries g
> > putStrLn "☝️ "
> >
> > However, when I run it (passing to example/app/M

Re: Using GHC API with multiple targets

[Matthew Pickering]

Can you put the whole example into a github repo and then I will look
at what is wrong?

Matt

On Mon, Feb 6, 2023 at 1:34 PM Eternal Recursion via ghc-devs
 wrote:
>
> Thanks, Andreas!
>
> I will check out the hint package and also play with verbosity and 
> workingDirectory.
>
> I considered using the Cabal library to derive the inputs from the project's 
> cabal file, but it does help first to know what the needful inputs are, and 
> where to stash them in the DynFlags session settings.
>
> It's got to be one of those "One Weird Trick (tm)" gotcha settings that make 
> it suddenly work. It seems obvious what some of the settings mean, but I 
> suppose with more familiarity will come appreciation of nuances that make the 
> apparently obvious meaning seem obviously wrong.
>
> Sincerely,
>
> Bob
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Monday, February 6th, 2023 at 7:53 AM, Andreas Klebinger 
>  wrote:
>
> I think this is an ok forum for this kind of question. You could also try the 
> haskell mailing list but I'm not sure if you will get more
> help tehre.
>
> I recently played around with the ghc api and I found the `hint` package to 
> be quite helpful as an example on how to do various
> things when using the ghc api to implement your own interpreter.
>
> Have you tried setting verbose? Perhaps the include dir is relative to the 
> working directory. In that case setting:
>
> , workingDirectory = Just targetDir
> , importPaths = [targetDir] ++ importPaths dynflags
>
> would mean ghc will search in targetDir/targetDir for Lib/Lib2. Should be 
> easy to say for sure by enabling verbosity and looking at the output.
>
> Am 06/02/2023 um 13:42 schrieb Eternal Recursion via ghc-devs:
>
> If this is the wrong forum for this question (which as I think about it, I 
> suppose it is) then redirection to a more appropriate mailing list or forum 
> (or any advice, really) would be appreciated. I just figured this would be 
> the forum with the best understanding of how the GHC API works (and has 
> changed over time), and my longer term goal is indeed to contribute to it 
> after I get past my learning curve.
>
> Sincerely,
>
> Bob
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Saturday, February 4th, 2023 at 4:04 PM, Eternal Recursion via ghc-devs 
>  wrote:
>
> Hi Everyone!
>
> I'm new here, trying to learn the GHC API. using 944 with cabal 3.8.1.0.
>
> How do I correctly set a GHC Session's DynFlags (and/or other properties) to 
> ensure local libraries imported by the main target are resolved properly at 
> compile time?
>
> What flags need to be set so that GHC is able to load/analyze/compile all 
> relevant Libraries in a package?
>
> This is my current code:
>
> withPath :: FilePath -> IO ()
> withPath target = do
> let targetDir = takeDirectory target
> let targetFile = takeFileName target
> listing <- listDirectory targetDir
> let imports = filter (\f -> takeExtension f == ".hs") listing
> print imports
> let moduleName = mkModuleName targetFile
> g <- defaultErrorHandler defaultFatalMessager defaultFlushOut
> $ runGhc (Just libdir) $ do
> initGhcMonad (Just libdir)
> dynflags <- getSessionDynFlags
> setSessionDynFlags $ dynflags { ghcLink = LinkInMemory
> , ghcMode = CompManager
> , backend = Interpreter
> , mainModuleNameIs = moduleName
> , workingDirectory = Just targetDir
> , importPaths = [targetDir] ++ importPaths dynflags
> }
> targets <- mapM (\t -> guessTarget t Nothing Nothing) imports
> setTargets targets
> setContext [ IIDecl $ simpleImportDecl (mkModuleName "Prelude") ]
> load LoadAllTargets
> liftIO . print . ppr =<< getTargets
> getModuleGraph
> putStrLn "Here we go!"
> print $ ppr $ mgModSummaries g
> putStrLn "☝️ "
>
> However, when I run it (passing to example/app/Main.hs, in which directory 
> are Lib.hs and Lib2.hs, the latter being imported into Main), I get:
>
> $ cabal run cli -- example/app/Main.hs
> Up to date
> ["Main.hs","Lib.hs","Lib2.hs"]
> [main:Main.hs, main:Lib.hs, main:Lib2.hs]
> Here we go!
> [ModSummary {
> ms_hs_hash = 23f9c4415bad851a1e36db9d813f34be
> ms_mod = Lib,
> unit = main
> ms_textual_imps = [(, Prelude)]
> ms_srcimps = []
> },
> ModSummary {
> ms_hs_hash = e1eccc23af49f3498a5a9566e63abefd
> ms_mod = Lib2,
> unit = main
> ms_textual_imps = [(, Prelude)]
> ms_srcimps = []
> },
> ModSummary {
> ms_hs_hash = 5f6751d7f0d5547a1bdf39af84f8c07f
> ms_mod = Main,
> unit = main
> ms_textual_imps = [(, Prelude), (, Lib2)]
> ms_srcimps = []
> }]
> ☝
>
> example/app/Main.hs:4:1: error:
> Could not find module ‘Lib2’
> Use -v (or `:set -v` in ghci) to see a list of the files searched for.
> |
> 4 | import qualified Lib2 as L2
> | ^^^
> cli: example/app/Main.hs:4:1: error:
> Could not find module `Lib2'
> Use -v (or `:set -v` in ghci) to see a list of the files searched for.
>
> What do I need to do differently to make this work?
>
> I have a local Cabal file I could use, but 

Re: Using GHC API with multiple targets

[Matthew Pickering]

Looks like it would work to me if you remove

```
setContext [ IIDecl $ simpleImportDecl (mkModuleName "Prelude") ]
```

Why do you have this line?

Matt

On Mon, Feb 6, 2023 at 12:54 PM Andreas Klebinger
 wrote:
>
> I think this is an ok forum for this kind of question. You could also try the 
> haskell mailing list but I'm not sure if you will get more
> help tehre.
>
> I recently played around with the ghc api and I found the `hint` package to 
> be quite helpful as an example on how to do various
> things when using the ghc api to implement your own interpreter.
>
> Have you tried setting verbose? Perhaps the include dir is relative to the 
> working directory. In that case setting:
>
>   , workingDirectory = Just targetDir
>   , importPaths  = [targetDir] ++ 
> importPaths dynflags
>
> would mean ghc will search in targetDir/targetDir for Lib/Lib2. Should be 
> easy to say for sure by enabling verbosity and looking at the output.
>
> Am 06/02/2023 um 13:42 schrieb Eternal Recursion via ghc-devs:
>
> If this is the wrong forum for this question (which as I think about it, I 
> suppose it is) then redirection to a more appropriate mailing list or forum 
> (or any advice, really) would be appreciated. I just figured this would be 
> the forum with the best understanding of how the GHC API works (and has 
> changed over time), and my longer term goal is indeed to contribute to it 
> after I get past my learning curve.
>
> Sincerely,
>
> Bob
>
> Sent with Proton Mail secure email.
>
> --- Original Message ---
> On Saturday, February 4th, 2023 at 4:04 PM, Eternal Recursion via ghc-devs 
>  wrote:
>
> Hi Everyone!
>
> I'm new here, trying to learn the GHC API. using 944 with cabal 3.8.1.0.
>
> How do I correctly set a GHC Session's DynFlags (and/or other properties) to 
> ensure local libraries imported by the main target are resolved properly at 
> compile time?
>
> What flags need to be set so that GHC is able to load/analyze/compile all 
> relevant Libraries in a package?
>
> This is my current code:
>
> withPath :: FilePath -> IO ()
> withPath target = do
>   let targetDir = takeDirectory target
>   let targetFile = takeFileName target
>   listing <- listDirectory targetDir
>   let imports = filter (\f -> takeExtension f == ".hs") listing
>   print imports
>   let moduleName = mkModuleName targetFile
>   g <- defaultErrorHandler defaultFatalMessager defaultFlushOut
> $ runGhc (Just libdir) $ do
> initGhcMonad (Just libdir)
> dynflags <- getSessionDynFlags
> setSessionDynFlags $ dynflags { ghcLink  = LinkInMemory
>   , ghcMode  = CompManager
>   , backend  = Interpreter
>   , mainModuleNameIs = moduleName
>   , workingDirectory = Just targetDir
>   , importPaths  = [targetDir] ++ 
> importPaths dynflags
>   }
>
> targets <- mapM (\t -> guessTarget t Nothing Nothing) imports
> setTargets targets
> setContext [ IIDecl $ simpleImportDecl (mkModuleName "Prelude") ]
> load LoadAllTargets
> liftIO . print . ppr =<< getTargets
> getModuleGraph
>   putStrLn "Here we go!"
>   print $ ppr $ mgModSummaries g
>   putStrLn "☝️ "
>
> However, when I run it (passing to example/app/Main.hs, in which directory 
> are Lib.hs and Lib2.hs, the latter being imported into Main), I get:
>
> $ cabal run cli -- example/app/Main.hs
> Up to date
> ["Main.hs","Lib.hs","Lib2.hs"]
> [main:Main.hs, main:Lib.hs, main:Lib2.hs]
> Here we go!
> [ModSummary {
>ms_hs_hash = 23f9c4415bad851a1e36db9d813f34be
>ms_mod = Lib,
>unit = main
>ms_textual_imps = [(, Prelude)]
>ms_srcimps = []
> },
> ModSummary {
>ms_hs_hash = e1eccc23af49f3498a5a9566e63abefd
>ms_mod = Lib2,
>unit = main
>ms_textual_imps = [(, Prelude)]
>ms_srcimps = []
> },
> ModSummary {
>ms_hs_hash = 5f6751d7f0d5547a1bdf39af84f8c07f
>ms_mod = Main,
>unit = main
>ms_textual_imps = [(, Prelude), (, Lib2)]
>ms_srcimps = []
> }]
> ☝
>
> example/app/Main.hs:4:1: error:
>Could not find module ‘Lib2’
>Use -v (or `:set -v` in ghci) to see a list of the files searched for.
>  |
> 4 | import qualified Lib2 as L2
>  | ^^^
> cli: example/app/Main.hs:4:1: error:
>Could not find module `Lib2'
>Use -v (or `:set -v` in ghci) to see a list of the files searched for.
>
> What do I need to do differently to make this work?
>
> I have a local Cabal file I could use, but to know what I need out of it, I 
> need to understand the minimum required info to get this to work. TIA!
>
> Sincerely,
>
> Bob
>
> Sent with Proton Mail secure email.
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> 

LLVM Support Range Bump (dropping LLVM 10 support)

[Matthew Pickering]

Hi all,

We are intending to bump the range of supported LLVM versions in the
9.6, release.

For 9.4 the range is 10-14 (inclusive)

For 9.6 we will support 11-15 (inclusive)

If dropping support for LLVM 10 is a concern for anyone please let us know.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

9.2.6 forthcoming release

[Matthew Pickering]

Hi all,

We are preparing potentially the final release in the 9.2.* series.

Zubin is preparing the release and we hope to deliver the release in
the next 1-2 weeks.

The two most critical bugs which 9.2.6 will fix is

* #22425 which is a performance regression introduced in 9.2.5.
* #22497 which will fix 9.2.* on recent aarch64-darwin platforms.

There are a few other bugs which will be fixed in the release but we
are being very conservative at this stage about introducing potential
breakage.

The backport set is being prepared on this branch:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9775

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Marge-bot outage over the weekend

[Matthew Pickering]

Thanks Bryan for unsticking things.

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

Re: Will there be a GHC 9.2.6?

[Matthew Pickering]

Hi Clinton,

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

Cheers,

Matt

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

Re: 9.4.4 release

[Matthew Pickering]

!9153 is already present in 9.4.3 at commit hash
edfa9f4653b10cb0a897ace15b25b3b52cde5c39 (which was from this specific
fix for the 9.4 branch
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9137)

Cheers,

Matt

On Thu, Dec 15, 2022 at 1:23 AM Erdi, Gergo  wrote:
>
> PUBLIC
>
> I'd like to nominate !9153 since it fixes a regression from 9.2 to 9.4.
> Also, I don't know why but I was unable to make this comment on the MR, 
> because I keep getting:
>
> "Your comment could not be submitted! Please check your network connection 
> and try again."
>
> Even though I can otherwise browse around Gitlab.
>
> -Original Message-
> From: ghc-devs  On Behalf Of Matthew Pickering
> Sent: Wednesday, December 14, 2022 8:51 PM
> To: GHC developers ; hasuf...@posteo.de; 
> juhpeter...@gmail.com
> Subject: [External] 9.4.4 release
>
>
> Hi all,
>
> We are going to release the latest release in the 9.4.* series before 
> Christmas.
>
> The release fixes a number of small bugs which have surfaced to do with 9.4.
>
> For the current full list of backports see:
>
> https://clicktime.symantec.com/15tSyRHEtFR816m1QoQTB?h=nKTqAjBvyF3MovWDef-WEenA4Y75aM3oDv2bE0u5ZmI==https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9523
>
> I am preparing the release branch and then Ben will perform the final steps 
> necessary for the release.
>
> Cheers,
>
> Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> https://clicktime.symantec.com/15tStb5xRdjXb9w5sF1JZ?h=sH-g7rK8uaH4H-qR-px1N-_RFZw104O5bEveNx9eEqo==http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> This email and any attachments are confidential and may also be privileged. 
> If you are not the intended recipient, please delete all copies and notify 
> the sender immediately. You may wish to refer to the incorporation details of 
> Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
> https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard Chartered PLC, 
> Standard Chartered Bank and their subsidiaries (the "Group"), information on 
> the regulatory standards we adhere to and how it may affect you can be found 
> in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and 
> Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and 
> contains any market commentary, the market commentary has been prepared by 
> the sales and/or trading desk of Standard Chartered Bank or its affiliate. It 
> is not and does not constitute research material, independent research, 
> recommendation or financial advice. Any market commentary is for information 
> purpose only and shall not be relied on for any other purpose and is subject 
> to the relevant disclaimers available at https: 
> //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and 
> contains any research materials prepared by members of the team, the research 
> material is for information purpose only and shall not be relied on for any 
> other purpose, and is subject to the relevant disclaimers available at https: 
> //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction, by 
> responding affirmatively to this e-mail, you agree that you have understood 
> the terms and conditions in the attached term sheet and evaluated the merits 
> and risks of the transaction. We may at times also request you to sign the 
> term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for 
> important information with respect to derivative products.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 9.4.4 release

[Matthew Pickering]

That issue has not been resolved for 9.4.4 but we will still provide
CentOS7 builds (which link against the older glibc).

On Thu, Dec 15, 2022 at 1:19 AM Julian Ospald  wrote:
>
> Has there been any changes to the bindists? Does 
> https://gitlab.haskell.org/ghc/ghc/-/issues/22268 still exist?
>
> On December 14, 2022 12:51:00 PM UTC, Matthew Pickering 
>  wrote:
>>
>> Hi all,
>>
>> We are going to release the latest release in the 9.4.* series before 
>> Christmas.
>>
>> The release fixes a number of small bugs which have surfaced to do with 9.4.
>>
>> For the current full list of backports see:
>>
>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9523
>>
>> I am preparing the release branch and then Ben will perform the final
>> steps necessary for the release.
>>
>> Cheers,
>>
>> Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

9.4.4 release

[Matthew Pickering]

Hi all,

We are going to release the latest release in the 9.4.* series before Christmas.

The release fixes a number of small bugs which have surfaced to do with 9.4.

For the current full list of backports see:

https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9523

I am preparing the release branch and then Ben will perform the final
steps necessary for the release.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

9.6.1 branch date - Wednesday 7th Nov

[Matthew Pickering]

Hi all,

In order to keep up the 6-month release cadence it is nearly time to
take the branch for the 9.6.1 release.

The date the branch will be taken is Wednesday 7th Nov.

Please reply to this email if there are any in-flight patches which
should be included in the 9.6 release.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Release Timelines

[Matthew Pickering]

Hi all,

Three releases are currently cooking.

* 9.2.5 (End of October)
   - Fixes to performance regressions introduced in 9.2.4.
   - Fix to interface file determinism
   - Critical correctness fix for AArch64 code generation

* 9.4.3 (End of October)
   - Critical correctness fix for AArch64 code generation
   - Fixes to performance regressions introduced in 9.4.2.
   - Fix to interface file determinism

* 9.6.1 (Early 2023)
   - Branch will be taken in early november.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Serious bug in GHC 9.4 on basic math on aarch64

[Matthew Pickering]

Thank you for bringing this bug to our attention Ian, we have triaged
it as highest priority and will include a fix in the next release in
the 9.4 series.

Cheers,

Matt

On Wed, Oct 12, 2022 at 12:46 AM Ian-Woo Kim  wrote:
>
> Hi,
>
> We found a reproducible error with a simple math test (div/mod) on
> aarch64. (on linux, on macos), so we want to call for attention on
> this.
> https://gitlab.haskell.org/ghc/ghc/-/issues/22282
> This was originally caught by this issue:
> https://github.com/haskell-foundation/foundation/issues/571
>
> Thank you!
>
> Ian-Woo Kim
> Mercury Technologies
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Implementing a compilation server

[Matthew Pickering]

Sorry Facundo I didn't realise this reply had remaining questions in it.

On Mon, May 30, 2022 at 3:35 AM Domínguez, Facundo
 wrote:
>
> Thanks Matthew for your pointers.
>
> Since originally posting, I managed to simplify the problem by terminating 
> the compilation server at the end of a build, which allows to introduce the 
> assumption that the code doesn't change during the lifetime of the server.
>
> Now, I'm observing that sometimes different compilation requests place the 
> same package databases at different paths using the -package-db flags. From 
> the point of view of GHC, it is as if the package databases had been moved 
> from one location to another. In newer requests, GHC still looks for the 
> interface files at the old locations, and fails when it doesn't find them.

I think you mean that your build system is putting the package
database at different paths. If you modify the package database
arguments at all you need to call `setSessionDynFlags` to update the
state of the package databases again. You might also need to clear the
finder cache if by "package database" you also mean the location of
the interface files.

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

I don't think I can comment on this without more information. It
sounds like you have a missing dependency in your build graph so the
right .hi files are not present? Need a reproducer to comment
properly.

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

The EPS does not contain "packages" but interface files from packages
and the interface files are only loaded if they are needed. Once the
interface file is loaded into the EPS I would not expect it to matter
where the file came from on disk, as now GHC can just read it from
memory. Was there a specific bug you had here?

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

I don't think you need to engineer this requirement. GHC should work
fine if you only have the transitive interface files. This is how
hadrian now works and also multi-component support in GHC 9.4. I can't
comment so much on 8.10.7 as it was a long time ago!

Matt

>
> Thanks,
> Facundo
>
> On Thu, May 5, 2022 at 5:13 AM Matthew Pickering 
>  wrote:
>>
>> Hi Facundo
>>
>> Some pointers...
>>
>> 1. Only put things in the EPS if they are not going to change
>> throughout the whole compilation
>> 2. Treat everything which can change as a home package
>> 2a. I suppose you have performed your own dependency analysis, so
>> build your own `ModGraph` and start looking from `load'`, you might
>> just want to call `upsweep_mod/compileOne'` directly yourself.
>> 2b. I suppose you are NOT targeting 9.4.1 yet, but that will make
>> things easier as you can use support for multiple home packages,
>> otherwise you will get into severe difficulties if you load a package
>> you later want to compile into the EPS. The only thing you can do here
>>   is restart the compilation session I think.
>> 3. To my knowledge, there is no issue using different -this-unit-id in
>> the same session. Not sure what errors you have seen.
>> 4. You need to use --make mode rather than -c (oneshot) because
>> oneshot mode loads all interfaces into the EPS (see point 1)
>>
>> ghcide is the closest program to this kind of compilation server you
>> imagine so you can look at how that uses the GHC API.
>>
>> Cheers,
>>
>> Matt
>>
>>
>> On Thu, May 5, 2022 at 1:06 AM Domínguez, Facundo
>>  wrote:
>> >
>> > Dear ghc devs,
>> >
>> > I'm using the ghc API to write a compilation server (a.k.a. persistent 
>> > worker). The id

Re: Benchmarking lexical scan during the downsweep for the ImplicitQualifiedImport proposal

[Matthew Pickering]

1. You want to test this in the context of recompilation, that is
where the cost of downsweep is most prominent. Ie, compile all the
modules normally once and then test how long it takes to recompile.
There is already a test in tree which does this
(MultiLayerModulesRecomp).

2. You can build GHC using `--make` mode with an invocation something like..

 $GHC -O -hidir $out -odir $out -i$dir -Icompiler
-I_perf/stage1/compiler/build/ -i_perf/stage1/compiler/build/ GHC
-XNoImplicitPrelude -XNoPolyKinds -O

3. The way to extract timing information is to use the `+RTS -s` option.

Matt


On Sun, Aug 28, 2022 at 7:55 PM Tristan Cacqueray  wrote:
>
>
> Hello all,
>
> In the context of https://github.com/ghc-proposals/ghc-proposals/pull/500,
> I am looking for a strategy to measure the impact of resolving modules
> dependencies using a lexical scan during the downsweep phase.
>
> For example, in this branch: 
> https://gitlab.haskell.org/TristanCacqueray/ghc/-/tree/make-lexical-analysis
> I've added a tokenizer pass in the GHC.Driver.Make.getPreprocessedImports 
> function,
> and using `/usr/bin/time -o /dev/stdout -v _build/stage1/bin/ghc 
> compiler/GHC/Tc/TyCl.hs 2> /dev/null`
> I measure:
>
>   LexicalAnalysis found 91 qualified name, and lasted: 150msec
>   Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.72
>   Maximum resident set size (kbytes): 142396
>
> Using a clean build I get:
>
>   Elapsed (wall clock) time (h:mm:ss or m:ss): 0:00.68
>   Maximum resident set size (kbytes): 140012
>
>
> Now my question is, how would you measure the time and space cost of
> such change. For example, what profiling tool would you recommend and
> how can I test a modified ghc to build ghc itself?
>
> Thanks in advance,
> -Tristan
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

9.4.2 release plans

[Matthew Pickering]

Hi all,

Within the next week we are planning to release 9.4.2 to fix the
critical issues found in 9.4.1.

The 9.4.2 milestone is up-to-date with all the issues which are
planned to be fixed in this release.

https://gitlab.haskell.org/ghc/ghc/-/milestones/378#tab-issues

Amongst these are:

* -x option broken on command line (#22044 )
* Darwin bindists can't be installed (#21974)
* Bytecode interpreter incorrect result when inlining constructor
wrappers (#22042)
* Some fixes to the make build system (#22047)

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Recompilation avoidance on ABI hash changes

[Matthew Pickering]

Facundo,

If the interface in question is from a home package module, then it's
required that the ABI of the specifically used function is modified
rather than the ABI hash of the whole module. If the interface is from
an external package then if the ABI of the entire module changes then
that is sufficient to trigger recompilation.

Matt

On Thu, Aug 11, 2022 at 12:11 PM Domínguez, Facundo
 wrote:
>
> Dear devs,
>
> rules_haskell [1] recently earned the ability to skip recompiling modules 
> when the ABI hashes of dependencies don't change in interface files.
>
> We have noticed since then that sometimes ghc --make does avoid rebuilding 
> even when ABI hashes change. However, so far I've been unable to reproduce 
> this in the small. The wiki page on recompilation avoidance does remark that 
> a changing ABI hash is a necessary but not sufficient condition for 
> recompilation [2].
>
> Does anyone have a small example showing how ghc avoids rebuilding even when 
> the ABI hash of a dependency changes?
>
> Thanks in advance!
> Facundo
>
> [1] https://github.com/tweag/rules_haskell/issues/1760#issuecomment-1179102232
> [2] 
> https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/compiler/recompilation-avoidance#interface-file-invariants
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [ANNOUNCE] GHC 9.4.1-rc1 is now available

[Matthew Pickering]

George, Kazu,

I also can't reproduce on the mac which I can access over SSH.

I downloaded the bindist for 9.2.4 and 9.4.1-rc1 and could install
them both and run the binaries.

Matt

On Mon, Jul 25, 2022 at 5:23 AM Kazu Yamamoto (山本和彦) via ghc-devs
 wrote:
>
> Hi George,
>
> > I've duplicated the issue on both of my machines. It would be good to know
> > if anybody else is seeing it. Kazu, I know you have seen this in the past.
> > Do you get the same error installing rc1?
> > When I run sudo make install I get a popup that says:
>
> I had no problem on 9.4.1-rc1.
> "xattr -rc ." and "make install" worked perfectly.
>
> macOS Monterey v12.4
> Xcode 13.4.1
>
> --Kazu
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

9.4.1 Final Call

[Matthew Pickering]

Hello all,

This is the final call for patches which need to be included in 9.4.1.

The status of which I do not know the answer:

* GHC 9.4 infinite loop in typechecker - #21530 (@simonpj, @rae) ?

To my knowledge the remaining unfinished work list is:

* Resolve static linking issues with text-2.0 - #21787 (Unresolved)
(Matt/Ben/Zubin/Tamar/Andreww)
* CAF reachability bug with -fprof-late - !7797 (WIP) (Andreas/Ben)
* XMonad segfault - #21708 (WIP) (Ben/Andreas)
* HIE File Fixes - !7888 (landing) (Zubin)
* template-haskell-2.19.0.0 depends on filepath - !8516 (landing) (Matt)
* Module loops and multiple home units leads to a panic - !8573
(nearly ready to land) (Matt)
* extendMG leaks memory - #21816 (Zubin/Matt)

To my knowledge, the following are not making it into 9.4.1.. but are
not critical to revert:

* Tidy up withDict and friends - #21568

Looking like a great release.

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RST Documentation Trick for reference links

[Matthew Pickering]

Hello,

I noticed myself writing things like:

```
and enable the eventlog using :rts-flag:`-l ⟨flags⟩`.
```

When in fact what I wanted was to create a link the eventlog options
but render the link as just -l rather than -l .. but I thought
I had to write the whole thing to get the linter to not complain.

It turns out can achieve this goal using the following syntax:

```
and enable the eventlog using :rts-flag:`-l <-l ⟨flags⟩>`.
```

ie, include the thing you actually want to reference in angular
brackets < > and the text you want to render before that.

Yet another thing which has changed my life for good.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Guide for testing hackage documentation upload

[Matthew Pickering]

Hi all,

In case anyone needs this in the future or is interested then I wrote
a little guide about how to test the upload of hackage documentation
locally.

https://gitlab.haskell.org/ghc/ghc/-/wikis/testing-hackage-documentation

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Imminent Removal of Make Build System

[Matthew Pickering]

Hi all,

We are imminently going to remove the make build system.

See: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7094

There is quite extensive documentation about using hadrian, the best
place to start is the in-tree documentation:

https://gitlab.haskell.org/ghc/ghc/-/blob/master/hadrian/README.md

For packagers:

* The 9.4.* series will be the last release series which can be built
with the make build system.
* 9.6.* will only be able to be built using hadrian.
* See ghcs-nix for an example of how to modify your own build system
to use hadrian:
https://gitlab.haskell.org/bgamari/ghcs-nix/-/blob/master/hadrian.nix
* Sam Derbyshire is creating a guide aimed at packagers describing how
to migrate their build plans.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Release Plans - 9.4.1 and 9.2.4

[Matthew Pickering]

Hello all,

Welcome to another update on our release plans.

9.4.1 (Ben Gamari)


We proceed smoothly onwards towards the release at the end of July.

The alpha3 was released last week -
https://discourse.haskell.org/t/ghc-9-4-1-alpha3-now-available/4701

The next release is scheduled to be the first release candidate.

9.2.4 (Zubin Duggal)


We intend to also publish a new version in the 9.2 series before the
end of July.

The priority of this release is motivated by:

* Adding support for the DeepSubsumption language extension
* Fixing some critical RTS bugs

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Migration guide for multiple home units

[Matthew Pickering]

My issue was caused by running the program in a dirty tree :)

Find the modified program here -
https://gist.github.com/df64f8cda24dd0c66137f10ad9488912

I compiled it with HEAD. Hope you can make sense of it, I think it's
simpler than before.

Cheers,

Matt

On Mon, Jun 20, 2022 at 5:47 PM Matthew Pickering
 wrote:
>
> Gergo, I rewrote your example program for the new API but didn't quite
> manage to finish today. I will finish it off and post it tomorrow.
>
> Matt
>
> On Mon, Jun 20, 2022 at 6:16 AM Erdi, Gergo  wrote:
> >
> > PUBLIC
> >
> > I managed to get this working, but I would like some feedback from Matt or 
> > others on whether this is the intended way of doing this.
> >
> > 1. The `extendMG` change can be brute-forced just to keep things going, by 
> > looking up dependency `ModSummary`s by `ModName` (we don't have full 
> > `Module`s at this point yet!):
> >
> > registerModSummary :: (GhcMonad m) => ModSummary -> m () registerModSummary 
> > ms = modifySession \env ->
> > let mg = hsc_mod_graph env
> > -- TODO: of course with a bit more housekeeping we can do better 
> > than this...
> > edges = [ NodeKey_Module $ msKey ms' | dep <- deps, ms' <- 
> > mgModSummaries mg, ms_mod_name ms' == dep ]
> > mg' = extendMG mg edges ms
> > in env{ hsc_mod_graph = mg' }
> >   where
> > deps = map (unLoc . snd) $ ms_textual_imps ms
> >
> > 2. `registerModule` can be kept mostly as-is, since it only uses 
> > `modifyUnitState` to change the active unit:
> >
> > registerModule :: (GhcMonad m) => ModDetails -> ModIface -> m () 
> > registerModule details iface = modifySession $ extendHpt . addModule
> >   where
> > hmi = HomeModInfo iface details Nothing
> >
> > mod = mi_module iface
> > modOrig = ModOrigin (Just True) [] [] True
> >
> > addModule = modifyUnitState $ \us -> us
> > { moduleNameProvidersMap = M.insert (moduleName mod) (M.singleton 
> > mod modOrig) $ moduleNameProvidersMap us
> > }
> >
> > extendHpt = hscUpdateHUG $ addHomeModInfoToHug hmi
> >
> > modifyUnitState :: (UnitState -> UnitState) -> HscEnv -> HscEnv 
> > modifyUnitState f env = env
> > { hsc_unit_env = let ue = hsc_unit_env env in
> > let units = ue_units ue
> > units' = f units
> > in ue_setUnits units' ue
> > }
> >
> > 3. The tricky part is getting `addUnit` right. For this, based on the 
> > implementation of `initUnits`, I came up with the following:
> >
> > modifyUnitEnv :: (UnitEnv -> UnitEnv) -> HscEnv -> HscEnv modifyUnitEnv f 
> > env = env
> > { hsc_unit_env = let ue = hsc_unit_env env in f ue
> > }
> >
> > addUnit :: DynFlags -> UnitId -> HscEnv -> HscEnv addUnit dflags unitId = 
> > modifyUnitEnv $ \ue ->
> > let dbs = ue_unit_dbs ue
> > unit_state = ue_units ue
> > home_unit = ue_homeUnit ue
> > in flip updateHug ue $ unitEnv_insert unitId $ HomeUnitEnv
> >{ homeUnitEnv_units = unit_state
> >, homeUnitEnv_unit_dbs = dbs
> >, homeUnitEnv_dflags = dflags
> >, homeUnitEnv_hpt = emptyHomePackageTable
> >, homeUnitEnv_home_unit = home_unit
> >}
> >
> > setCurrentUnit :: UnitId -> HscEnv -> HscEnv setCurrentUnit unitId = 
> > modifyUnitEnv $ ue_setActiveUnit unitId
> >
> >
> > So my questions about this:
> >
> > 1. How does setting the home unit make sense? By doing this, I am 
> > effectively setting the home unit to `main` for all units, since that's the 
> > initial `ue_homeUnit` of the initial unit environment. Or does it not 
> > matter because after `addUnit`, I call `setCurrentUnit` anyway? I've found 
> > that I can't use the unit I am just adding as its own home unit, because 
> > that then leads to module name resolution problems in `main`: every 
> > imported module from `main` is searched for in `main` instead of its 
> > correct unit.
> >
> > 2. Speaking of `main`, why is it that when adding units, I have to skip 
> > `mainUnitId`, otherwise module resolution breaks again?
> >
> > 3. Unlike the previous version, I am no longer creating and putting 
> > `UnitInfo`s anywhere. Where is this going to bite me? Where (if anywhere) 
> > should I put `UnitInfo`s with the new setup?
> >
> > Thanks,
> > Gergo
> >
> >
> > -Original Message-
> > From: ÉRD

Re: Migration guide for multiple home units

[Matthew Pickering]

Gergo, I rewrote your example program for the new API but didn't quite
manage to finish today. I will finish it off and post it tomorrow.

Matt

On Mon, Jun 20, 2022 at 6:16 AM Erdi, Gergo  wrote:
>
> PUBLIC
>
> I managed to get this working, but I would like some feedback from Matt or 
> others on whether this is the intended way of doing this.
>
> 1. The `extendMG` change can be brute-forced just to keep things going, by 
> looking up dependency `ModSummary`s by `ModName` (we don't have full 
> `Module`s at this point yet!):
>
> registerModSummary :: (GhcMonad m) => ModSummary -> m () registerModSummary 
> ms = modifySession \env ->
> let mg = hsc_mod_graph env
> -- TODO: of course with a bit more housekeeping we can do better than 
> this...
> edges = [ NodeKey_Module $ msKey ms' | dep <- deps, ms' <- 
> mgModSummaries mg, ms_mod_name ms' == dep ]
> mg' = extendMG mg edges ms
> in env{ hsc_mod_graph = mg' }
>   where
> deps = map (unLoc . snd) $ ms_textual_imps ms
>
> 2. `registerModule` can be kept mostly as-is, since it only uses 
> `modifyUnitState` to change the active unit:
>
> registerModule :: (GhcMonad m) => ModDetails -> ModIface -> m () 
> registerModule details iface = modifySession $ extendHpt . addModule
>   where
> hmi = HomeModInfo iface details Nothing
>
> mod = mi_module iface
> modOrig = ModOrigin (Just True) [] [] True
>
> addModule = modifyUnitState $ \us -> us
> { moduleNameProvidersMap = M.insert (moduleName mod) (M.singleton mod 
> modOrig) $ moduleNameProvidersMap us
> }
>
> extendHpt = hscUpdateHUG $ addHomeModInfoToHug hmi
>
> modifyUnitState :: (UnitState -> UnitState) -> HscEnv -> HscEnv 
> modifyUnitState f env = env
> { hsc_unit_env = let ue = hsc_unit_env env in
> let units = ue_units ue
> units' = f units
> in ue_setUnits units' ue
> }
>
> 3. The tricky part is getting `addUnit` right. For this, based on the 
> implementation of `initUnits`, I came up with the following:
>
> modifyUnitEnv :: (UnitEnv -> UnitEnv) -> HscEnv -> HscEnv modifyUnitEnv f env 
> = env
> { hsc_unit_env = let ue = hsc_unit_env env in f ue
> }
>
> addUnit :: DynFlags -> UnitId -> HscEnv -> HscEnv addUnit dflags unitId = 
> modifyUnitEnv $ \ue ->
> let dbs = ue_unit_dbs ue
> unit_state = ue_units ue
> home_unit = ue_homeUnit ue
> in flip updateHug ue $ unitEnv_insert unitId $ HomeUnitEnv
>{ homeUnitEnv_units = unit_state
>, homeUnitEnv_unit_dbs = dbs
>, homeUnitEnv_dflags = dflags
>, homeUnitEnv_hpt = emptyHomePackageTable
>, homeUnitEnv_home_unit = home_unit
>}
>
> setCurrentUnit :: UnitId -> HscEnv -> HscEnv setCurrentUnit unitId = 
> modifyUnitEnv $ ue_setActiveUnit unitId
>
>
> So my questions about this:
>
> 1. How does setting the home unit make sense? By doing this, I am effectively 
> setting the home unit to `main` for all units, since that's the initial 
> `ue_homeUnit` of the initial unit environment. Or does it not matter because 
> after `addUnit`, I call `setCurrentUnit` anyway? I've found that I can't use 
> the unit I am just adding as its own home unit, because that then leads to 
> module name resolution problems in `main`: every imported module from `main` 
> is searched for in `main` instead of its correct unit.
>
> 2. Speaking of `main`, why is it that when adding units, I have to skip 
> `mainUnitId`, otherwise module resolution breaks again?
>
> 3. Unlike the previous version, I am no longer creating and putting 
> `UnitInfo`s anywhere. Where is this going to bite me? Where (if anywhere) 
> should I put `UnitInfo`s with the new setup?
>
> Thanks,
> Gergo
>
>
> -Original Message-
> From: ÉRDI Gergő 
> Sent: Sunday, June 19, 2022 12:32 PM
> To: Erdi, Gergo 
> Cc: GHC Devs ; Montelatici, Raphael Laurent 
> 
> Subject: [External] Re: Migration guide for multiple home units
>
>
> On Thu, 16 Jun 2022, Erdi, Gergo via ghc-devs wrote:
>
> > Is there a migration guide for GHC API clients for the new “multiple home 
> > units”
> > feature?
>
> OK so in concrete terms, please see my attached program which is a heavily 
> cut-down, standalone version of my real program. On commit 
> fd42ab5fa1df847a6b595dfe4b63d9c7eecbf400^ (i.e.
> 3219610e3ba6cb6a5cd1f4e32e2b4befea5bd384) it compiles and works as expected. 
> On commit fd42ab5fa1df847a6b595dfe4b63d9c7eecbf400 onwards, two problems pop 
> up:
>
> 1. `extendMG` has changed and now requires manually specifying outgoing 
> dependency edges. I thought the whole point of `summariseFile` was to collect 
> this information? The reason I need to `extendMG` at that point is to get 
> intra-unit orphan instances working.
>
> 2. `modifyUnitState` and its two uses (`addUnit` and `registerModule`) need 
> to be updated to the new API. I think it makes sense that these need 
> changing, since they touch exactly on the issue of which units 

Re: Migration guide for multiple home units

[Matthew Pickering]

Hi Gergo

The error tells you what you only have setup the HscEnv so that
there's one unit called main, but you are attempting to compile
something with unit id cortex-prim.

Perhaps you could be inspired by `setSessionDynFlags` which deals with
renaming the main unit id if you are compiling a unit which have a
different unit id. (See setUnitDynFlagsNoCheck).

Matt


On Thu, Jun 16, 2022 at 5:01 AM Erdi, Gergo via ghc-devs
 wrote:
>
> PUBLIC
>
>
> Hi,
>
>
>
> Is there a migration guide for GHC API clients for the new “multiple home 
> units” feature?
>
>
>
> In particular, I have the following two functions in my code that used to 
> interact with related features of GHC:
>
>
>
> addUnit :: UnitInfo -> HscEnv -> HscEnv
>
> addUnit unitInfo@GenericUnitInfo{..} = modifyUnitState $ \us -> us
>
> { packageNameMap = addToUFM (packageNameMap us) unitPackageName unitId
>
> , unitInfoMap = M.insert unitId unitInfo $ unitInfoMap us
>
> }
>
>
>
> registerModule :: (GhcMonad m) => ModDetails -> ModIface -> m ()
>
> registerModule details iface = modifySession $ extendHpt . addModule
>
>   where
>
> hmi = HomeModInfo iface details Nothing
>
>
>
> mod = mi_module iface
>
> modOrig = ModOrigin (Just True) [] [] True
>
>
>
> addModule = modifyUnitState $ \us -> us
>
> { moduleNameProvidersMap = M.insert (moduleName mod) (M.singleton mod 
> modOrig) $ moduleNameProvidersMap us
>
> }
>
>
>
> extendHpt env = env
>
> { hsc_unit_env = let ue = hsc_unit_env env in ue
>
> { ue_hpt = addHomeModInfoToHpt hmi (hsc_HPT env)
>
> }
>
> }
>
>
>
> I implemented these using the following utility function:
>
>
>
> modifyUnitState :: (UnitState -> UnitState) -> HscEnv -> HscEnv
>
> modifyUnitState f env = env
>
> { hsc_unit_env = let ue = hsc_unit_env env in ue
>
> { ue_units = f (ue_units ue)
>
> }
>
> }
>
>
>
> With the recent changes to GHC, `modifyUnitState` doesn’t work anymore 
> because there is no single `UnitEnv` in the `HscEnv`. I tried updating the 
> `HomeUnitEnv` of the current unit:
>
>
>
> modifyUnitState :: (UnitState -> UnitState) -> HscEnv -> HscEnv
>
> modifyUnitState f env = env
>
> { hsc_unit_env = let ue = hsc_unit_env env in
>
> ue_updateHomeUnitEnv f' (ue_currentUnit ue) ue
>
> }
>
>   where
>
> f' hue = let units = homeUnitEnv_units hue in hue
>
> { homeUnitEnv_units = f units
>
> }
>
>
>
> but this leads to a panic:
>
>
>
>   GHC version 9.5.20220613:
>
> Unit unknown to the internal unit environment
>
>
>
> unit (cortex-prim)
>
> pprInternalUnitMap
>
>   main (flags: main, Just main) ->
>
> Call stack:
>
> CallStack (from HasCallStack):
>
>   callStackDoc, called at compiler/GHC/Utils/Panic.hs:182:37 in 
> ghc-lib-0.20220613-HQTH0nHhxeOCnJy5jYkZiX:GHC.Utils.Panic
>
>   pprPanic, called at compiler/GHC/Unit/Env.hs:450:14 in 
> ghc-lib-0.20220613-HQTH0nHhxeOCnJy5jYkZiX:GHC.Unit.Env
>
>   ue_findHomeUnitEnv, called at compiler/GHC/Unit/Env.hs:394:48 in 
> ghc-lib-0.20220613-HQTH0nHhxeOCnJy5jYkZiX:GHC.Unit.Env
>
>   ue_unitFlags, called at compiler/GHC/Driver/Env.hs:421:18 in 
> ghc-lib-0.20220613-HQTH0nHhxeOCnJy5jYkZiX:GHC.Driver.Env
>
>   hscSetActiveUnitId, called at compiler/GHC/Driver/Env.hs:416:34 in 
> ghc-lib-0.20220613-HQTH0nHhxeOCnJy5jYkZiX:GHC.Driver.Env
>
>   hscSetActiveHomeUnit, called at compiler/GHC/Driver/Make.hs:1853:15 in 
> ghc-lib-0.20220613-HQTH0nHhxeOCnJy5jYkZiX:GHC.Driver.Make
>
>
>
>
>
> What is the new way of registering a new unit or new module with GHC?
>
>
>
> Thanks,
>
> Gergo
>
>
> This email and any attachments are confidential and may also be privileged. 
> If you are not the intended recipient, please delete all copies and notify 
> the sender immediately. You may wish to refer to the incorporation details of 
> Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
> https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard Chartered PLC, 
> Standard Chartered Bank and their subsidiaries (the "Group"), information on 
> the regulatory standards we adhere to and how it may affect you can be found 
> in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and 
> Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and 
> contains any market commentary, the market commentary has been prepared by 
> the sales and/or trading desk of Standard Chartered Bank or its affiliate. It 
> is not and does not constitute research material, independent research, 
> recommendation or financial advice. Any market commentary is for information 
> purpose only and shall not be relied on for any other purpose and is subject 
> to the relevant disclaimers available at https: 
> //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as 

Deep Subsumption Proposal

[Matthew Pickering]

Hi all,

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

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

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Release Status - 9.4.1-alpha2/9.2.3/9.0.* series

[Matthew Pickering]

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

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

Release Status - 9.4.1-alpha2/9.2.3/9.0.* series

[Matthew Pickering]

Hi all,

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

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

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

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

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

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

Best Wishes,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Welcome to Bryan (Devops Engineer)

[Matthew Pickering]

Hi all,

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

His username is chreekat.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Extra file in GHC repo

[Matthew Pickering]

Yes, that is correct.

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

Re: Extra file in GHC repo

[Matthew Pickering]

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

Matt

On Fri, May 13, 2022 at 11:46 AM Simon Peyton Jones
 wrote:
>
> Hi devs
>
> I've started to get this a lot
>
> bash$ git rebase origin/master
> First, rewinding head to replay your work on top of it...
> error: The following untracked working tree files would be overwritten by 
> checkout:
> docs/index.html
> Please move or remove them before you switch branches.
> Aborting
> fatal: Could not detach HEAD
>
> Removing docs/index.html makes things work again.  What am I doing wrong?
>
> Simon
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab problem

[Matthew Pickering]

Hi Simon,

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

Matt

On Tue, May 10, 2022 at 4:32 PM Simon Peyton Jones
 wrote:
>
> Friends
>
> I am abruptly unable to push or pull to the GHC repo.  E.g. 'git fetch' just 
> hangs.
>
> Yet ssh g...@gitlab.haskell.org seems to succeed with
> PTY allocation request failed on channel 0
> Welcome to GitLab, @simonpj!
> Connection to gitlab.haskell.org closed.
>
> How could I debug this?  I'm on WSL.  My network appears to be fine.
>
> Thanks.  I'm totally stalled.
>
> Simon
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Implementing a compilation server

[Matthew Pickering]

Hi Facundo

Some pointers...

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

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

Cheers,

Matt


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

Re: Release Updates - 9.4.1 and 9.2.3

[Matthew Pickering]

Hi Sebastian,

I don't think I understand the severity of #21229, is it an incorrect
runtime result? If so, we should definitely fix it before 9.4.1.
Thanks for bringing it to my attention.

Matt


On Wed, Apr 6, 2022 at 1:18 PM Sebastian Graf  wrote:
>
> Hi Matthew,
>
> Depending on whether https://gitlab.haskell.org/ghc/ghc/-/issues/21229 is 
> deemed a blocker for 9.4 (I'd say it is, but YMMV), we should include 
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7788 in the list.
> Perhaps we should make it dependent on whether !7788 is ready to merge by May 
> or whether it ends up as the only patch that holds back the release.
>
> Sebastian
>
> Am Mi., 6. Apr. 2022 um 11:00 Uhr schrieb Matthew Pickering 
> :
>>
>> Hi all,
>>
>> We have now forked the 9.4 branch.
>>
>> There are a few outstanding patches which have not yet been finished
>> but which are essential to the release.
>>
>> * (#21019) Windows Toolchain Updates - Ben
>> * (#20405) Partial Register Stall - Ben/Andreas
>> * (!7812) Syntactic Unification - Sam
>>
>> The target date for the first alpha for 9.4.1 is 1st May.
>>
>> We have started preparing the 9.2.3 release in order to fix issues
>> discovered in the 9.2.2 release. I will post separately to the list
>> shortly when the schedule for this release is confirmed. The release
>> manager for this release is Zubin.
>>
>> Cheers,
>>
>> Matt
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Release Updates - 9.4.1 and 9.2.3

[Matthew Pickering]

Hi all,

We have now forked the 9.4 branch.

There are a few outstanding patches which have not yet been finished
but which are essential to the release.

* (#21019) Windows Toolchain Updates - Ben
* (#20405) Partial Register Stall - Ben/Andreas
* (!7812) Syntactic Unification - Sam

The target date for the first alpha for 9.4.1 is 1st May.

We have started preparing the 9.2.3 release in order to fix issues
discovered in the 9.2.2 release. I will post separately to the list
shortly when the schedule for this release is confirmed. The release
manager for this release is Zubin.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Windows CI instability

[Matthew Pickering]

Hi all,

Currently the windows CI issue is experiencing high amounts of
instability so if your patch fails for this reason then don't worry.
We are attempting to fix it.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

devel2 build flavour thoughts

[Matthew Pickering]

Hi all,

In semi-private I have been making very bold claims about the
unsuitability of the devel2 as a build flavour of choice for the
aspiring developer.

In order to bolster my claim I set out to find out some statistics about

1. devel2 flavour
2. default+no_profiled_libs+omit_pragmas+assertions flavour

The difference between the two is essentially that flavour (2) builds
each module with optimisation but disables cross-module optimisation
(in particular inlining)

In short the difference between the two flavours is negligible from my
testing apart from one larger difference when building larger
packages.

Full build + test: Near identical
Testsuite run: Near identical
Recompile: Near identical - (2) is slower
Build Cabal: 167s vs 259s

So if you want to build packages use flavour 2 but otherwise it seems
to make little difference.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 9.4 release planning (& GHCJS merge process)

[Matthew Pickering]

1. We will provide a migration guide. The draft for the guide is
located here - https://gitlab.haskell.org/ghc/ghc/-/wikis/migration/9.4

2. 8.10 has never officially been an LTS but due to various reasons
has been a larger number of backports than other releases. I suggest
that the decision about whether the 9.4 release will attain a similar
status is left to the community rather than us (the developers) who
lack perspective about
how companies are using releases unless explicitly told about it.

3. The likely highlights was a list produced by Ben after the 9.2
release was finalised. Most (if not all) the features on the list will
be present in the release. Of course, comprehensive release notes will
be produced which detail all the new features and changes.

4. It is an unfortunate fact that whatever the proposed release
schedule has been that the releases have never actually come at those
timings. Again, I think we have to defer the question about release
frequency to the wider community. The decision about this release
cycle was made after considering the state of the master branch, which
features we wanted in the release and the availability of the release
managers.

Cheers,

Matt

On Tue, Feb 22, 2022 at 7:34 PM Hécate  wrote:
>
> Hi Matthew, thank you for this update and the other one regarding your team.
>
> I have multiple questions regarding the release:
>
> 1. Could a migration guide be provided? Or better, a script/tool? From
> what I understand, going from 9.2 to 9.4 means breaking changes have
> been introduced.
>
> 2. The 8.10 series has gained a status of LTS amongst industrial users,
> thanks to both the numerous backports but also the wider support in the
> ecosystem. Could you please clarify whether or not it will still be an
> LTS after this release, and the status of 9.0 and 9.2 (which have
> brought numerous new things themselves but seem to have been quickly
> replaced by the next release each time). It's quite confusing, and when
> the question arises in professional circles, a (seemingly) valid answer
> that is brought up is "We can wait 6 more months and have a breaking
> release that will force us to migrate painfully, let's not move yet".
>
> 3. From what I can see in the "Likely highlights" (this phrasing is
> unclear to me, you don't expect some of those changes to make it to the
> release?), it is mostly an engineering release (which is great). Do you
> think that the 9.4 series could benefit from the same longevity as the
> 8.10 did and take its place as a continuously-improved version while
> Language / R versions of GHC are published anew?
>
> 4. There was a talk of slowing the release schedule to once a year, and
> last I heard, Ben was sympathetic to it. Could you express the official
> position of your team on the matter?
>
> Again, I'd like to echo Richard's words in the other thread, thank you
> and your team for all this work, this is immensely appreciated.
>
> Cheers,
> Hécate
>
> Le 22/02/2022 à 18:14, Matthew Pickering a écrit :
> > Hi all,
> >
> > Firstly we are anticipating branching 9.4 in about 6 weeks time
> > (approx start of April). Most of the major features originally
> > milestoned[1] for this release have landed and the main branch is
> > currently in a nice state. This timeline will be solidified once the
> > 9.2.2 release has been completed.
> >
> > The major outstanding work that I am aware of is
> >
> > Windows toolchain work (#21019) (Ben Gamari)
> > Partial Register Stall (#20405) (Andreas Klebinger)
> > hi-haddock (!6224) (Zubin Duggal / Matthew Pickering )
> > Directed Coercions (!6476) (Sam Derbyshire)
> >
> > Secondly, we are anticipating adding a javascript backend inspired by
> > GHCJS as the highlight of the 9.6 release. This work is led by the
> > team at IOHK.
> >
> > * The planning and progress of this process is tracked on this wiki
> > page - https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend
> > * We anticipate reviewing and merging patches incrementally into a
> > feature branch until the point where test coverage is suitable and the
> > patches can be merged into the main branch.
> >
> > Cheers,
> >
> > Matt
> >
> >
> > [1]: https://gitlab.haskell.org/ghc/ghc/-/milestones/370
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> --
> Hécate ✨
> : @TechnoEmpress
> IRC: Hecate
> WWW: https://glitchbra.in
> RUN: BSD
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Well-Typed GHC team update

[Matthew Pickering]

Hi all,

We have recently reorganised the structure of the Well-Typed team
working on the GHC project.

In short, I am now responsible for more of the management tasks that
Ben has traditionally carried out. In particular I have responsibility
for organising the work between us and keeping track of the tasks that
need to be completed.

With that in mind, if you need something doing, please email/ping me
and not Ben with your request and I will make sure someone deals with
it. On gitlab you can also notify me directly by using the @hq-shepard
tag, which provides the level of indirection for when this changes
again in the future.

The team working at Well-Typed on GHC currently consists of

Myself (Matthew Pickering)
Ben Gamari
Andreas Klebinger
Sam Derbyshire
Zubin Duggal

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

9.4 release planning (& GHCJS merge process)

[Matthew Pickering]

Hi all,

Firstly we are anticipating branching 9.4 in about 6 weeks time
(approx start of April). Most of the major features originally
milestoned[1] for this release have landed and the main branch is
currently in a nice state. This timeline will be solidified once the
9.2.2 release has been completed.

The major outstanding work that I am aware of is

Windows toolchain work (#21019) (Ben Gamari)
Partial Register Stall (#20405) (Andreas Klebinger)
hi-haddock (!6224) (Zubin Duggal / Matthew Pickering )
Directed Coercions (!6476) (Sam Derbyshire)

Secondly, we are anticipating adding a javascript backend inspired by
GHCJS as the highlight of the 9.6 release. This work is led by the
team at IOHK.

* The planning and progress of this process is tracked on this wiki
page - https://gitlab.haskell.org/ghc/ghc/-/wikis/javascript-backend
* We anticipate reviewing and merging patches incrementally into a
feature branch until the point where test coverage is suitable and the
patches can be merged into the main branch.

Cheers,

Matt


[1]: https://gitlab.haskell.org/ghc/ghc/-/milestones/370
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: the linters are killing me slowly

[Matthew Pickering]

I think we could run the linters in the same step as the rest of the
builds. As long as  the hadrian-ghci job runs as the initial step to
weed out any obviously bad commits.

On Wed, Feb 9, 2022 at 7:15 PM Richard Eisenberg  wrote:
>
> Hi devs,
>
> Can we please, please not have the linters stop more useful output during CI? 
> Over the past few months, I've lost several days of productivity due to the 
> current design. Why several days? Because I typically end up with only 1.5-2 
> hours for GHC work in a day, and when I have to spend half of that recreating 
> test results (which, sometimes, don't work, especially if I use Hadrian, as 
> recommended), I often decide to prioritize other tasks that I have a more 
> reasonable chance of actually finishing.
>
> It was floated some time ago that "Draft" MRs could skip linters. But I 
> actually have a non-Draft MR now, and it failed the new Notes linter. (Why, 
> actually, is that even a separate pass? I thought there was a test case for 
> that, which I'm thrilled with.)
>
> It just feels to me that the current workflow is optimized for those of us 
> who work on GHC close to 100% of the time. This is not the way to get new 
> contributors.
>
> Frustrated,
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Runnig a compiler plugin over ALL code

[Matthew Pickering]

The imagine the plugin doesn't run over that definition because it
doesn't exist when your plugin runs. I imagine it's a core plugin, so
you might need to run it earlier in the pipeline?

Matt

On Wed, Feb 9, 2022 at 11:16 AM Tillmann Vogt via ghc-devs
 wrote:
>
> Hi,
>
> I am running a compiler plugin over hundreds of libraries to extract
> statistical data. I use the plugin like it is done here:
>
> https://github.com/coot/ghc-tags-plugin
>
> So I just have to add a cabal.project.local to a library with:
>
>
> ignore-project: False
>
> package test
>  ghc-options: -package-db=/home/till/.cabal/store/ghc-8.10.7/package.db
>   -plugin-package=ghc-core-graph
>   -fplugin=GhcPlugins.Optimind
>
> But unfortunately the plugin only runs over code that is used in the
> main function or that is used in other functions.
>
> Example:
>
> main = putStrLn (show (f 0))
>
> f x = sin x
>
> g = h + i
>
> Then the compiler plugin only runs over f, h, i   but not not g (unused
> top level functions).
>
> Can the plugin be forced to run over all code?
>
> -Tillmann
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Notes Linter

[Matthew Pickering]

Hello,

Just merged is a new linter which checks the consistency of notes. In
particular it checks that all note references reference an existing
Note.

The linter is integrated into the testsuite so you can run the linter
(without building GHC) by saying

./hadrian/build test --only=notes

and can accept the new output of the linter by saying

./hadrian/build test --only=notes --test-accept

But you should probably not need to do this and instead fix your note
references!

Any issues please open a ticket.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: downloading ghc head version

[Matthew Pickering]

Right, it appears the problem was we stopped producing the deb9
bindists due to deb9 being EOL.

https://gitlab.haskell.org/ghc/ghc/-/commit/871ce2a300ed35639a39a86f4c85fbcb605c5d7d

Is your problem sorted now?

Matt

On Tue, Feb 1, 2022 at 12:09 AM Harendra Kumar  wrote:
>
> I replaced deb9 with deb10 in the URL that ghcup install was using
> earlier in the CI and it seems to work. The following command
> installed ghc successfully:
>
> $ ghcup install ghc -u
> https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-deb10-linux-integer-simple.tar.xz?job=validate-x86_64-linux-deb10-integer-simple
> head
> $ ghc-head --version
> The Glorious Glasgow Haskell Compilation System, version 9.3.20220130
>
> Maybe the deb9 build has been retired now? It worked once in our CI a
> few days and then never worked.
>
> -harendra
>
> On Tue, 1 Feb 2022 at 05:24, Harendra Kumar  wrote:
> >
> > Ah, nice. That looks like a useful repo. Thanks!
> >
> > I tried the nix expression:
> >
> > nix run -f 
> > https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz
> > ghcHEAD
> >
> > on my debian linux, but it is trying to download the fedora tar from
> > https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-fedora33-linux.tar.xz?job=validate-x86_64-linux-fedora33
> > . ghc-head-from.sh also downloads from the same link. Is it supposed
> > to work on debian as well? The nix expression as well as
> > ghc-head-from.sh finally failed with the followinf error on my
> > machine:
> >
> > utils/ghc-cabal/dist-install/build/tmp/ghc-cabal: error while loading
> > shared libraries: libstdc++.so.6: cannot open shared object file: No
> > such file or directory
> >
> > I looked at 
> > https://github.com/mpickering/ghc-artefact-nix/blob/master/gitlab-artifact.nix,
> > but it does not seem to have a debian x86_64 config.
> >
> > -harendra
> >
> > On Tue, 1 Feb 2022 at 05:00, Matthew Pickering
> >  wrote:
> > >
> > > I will look tomorrow but see where ghc-head-from gets the bindist from
> > >
> > > https://github.com/mpickering/ghc-artefact-nix/blob/master/ghc-head-from.sh
> > >
> > > On Mon, Jan 31, 2022 at 10:43 PM Harendra Kumar
> > >  wrote:
> > > >
> > > > It seems the latest artifacts download link
> > > > (https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/...) at GHC
> > > > gitlab is not working.
> > > >
> > > > If this is not the right place to ask this, can someone point me to
> > > > the right place?
> > > >
> > > > -harendra
> > > >
> > > > On Wed, 26 Jan 2022 at 18:38, Harendra Kumar  
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I am trying to set up a CI for ghc head version. I am not sure what is
> > > > > the official supported method to install a nightly/head version of
> > > > > GHC. haskell/actions/setup on github seems to support it via ghcup.
> > > > > But it almost always fails, I saw it succeeding once till now. It
> > > > > tries to download it from the following URL, but fails with 404 not
> > > > > found:
> > > > >
> > > > > downloading: 
> > > > > https://gitlab.haskell.org/ghc/ghc/-/jobs/artifacts/master/raw/ghc-x86_64-deb9-linux-integer-simple.tar.xz?job=validate-x86_64-linux-deb9-integer-simple
> > > > >
> > > > > I tried this link in the browser and I get the same error. Is that the
> > > > > right way to install it? If not, can someone suggest a reliable way to
> > > > > get the head version, other than building it myself?
> > > > >
> > > > > Thanks,
> > > > > Harendra
> > > > ___
> > > > ghc-devs mailing list
> > > > ghc-devs@haskell.org
> > > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Not all splices are the same

[Matthew Pickering]

Seems related to https://gitlab.haskell.org/ghc/ghc/-/issues/18211

There is also a small section in my thesis (4.1.2) which explains why
changing the implementation of typed quotations would allow this
program to be accepted.

Matt

On Sun, Jan 23, 2022 at 7:08 PM David Feuer  wrote:
>
> I've been a bit upset by the challenges Template Haskell poses for type 
> inference. For example,
>
> (3 :: Int) == $$(...)
>
> may typecheck when
>
> $$(...) == (3 :: Int)
>
> does not. I don't imagine this problem can be solved in general, but I'm 
> rather curious whether it might be possible to solve for "pure" splices, with 
> types that look like
>
> forall m. Quote m => Code m a
>
> Would it be possible to get full bidirectional inference for these if they 
> were somehow marked specially by the user? For instance, if I wrote
>
> $$$e
>
> that could mean e should be interpreted as having some type
>
> PCode a
>
> where
>
> newtype PCode a = PCode (forall m. Quote m => a)
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Strictness/demand info for a Name

[Matthew Pickering]

You look at `dmdSigInfo` in `IdInfo`.

Matt

On Thu, Jan 13, 2022 at 2:20 PM Alejandro Serrano Mena
 wrote:
>
> Dear all,
>
> I’m trying to bring the information about demand and strictness to the 
> Haskell Language Server, but I cannot find a way to do so. I was wondering 
> whether you could help me :)
>
> Here’s my understanding; please correct me if I’m wrong:
>
> The analysis runs on Core, so getting this information for the current file 
> would require to run the compiler further than type checking, which is quite 
> expensive,
> However, this analysis should somehow use known information about imported 
> functions, which should be readily available somewhere,
> If the above is true, what is the simplest way to get the information for 
> imported things? As I mentioned above, I would prefer not to run the compiler 
> further than the type checking phase, since otherwise it gets too expensive 
> for IDE usage. Right now HLS uses the information from the .hie files.
>
>
> In fact, this goes into the more general question of how to show information 
> from different analyses within the IDE; I guess solving the case for 
> strictness/analysis may open the door to more (maybe everything recorded 
> inside a `Id`?)
>
> Regards,
> Alejandro
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Avoiding full laziness xform / floating-out (Re: What's the benefit of taking "do" blocks apart? Is there a way to turn that off?)

[Matthew Pickering]

Hi Gergo,

Sounds like you might be better off writing your own optimisation pass
rather than relying on making GHC do what you want.

Cheers

Matt

On Thu, Dec 30, 2021 at 9:05 AM Erdi, Gergo via ghc-devs
 wrote:
>
> PUBLIC
>
> Hi Joachim,
>
> Thanks for the hints!
>
> > Hi Gergo,
> >
> > Am Dienstag, dem 28.12.2021 um 15:57 + schrieb Erdi, Gergo via ghc-
> > devs:
> > > PUBLIC
> >
> > phew
>
> Yeah obviously I'm sitting here not only adding these tags, but also
> coming up with the automated systems and also the company policies
> forcing the usage of said systems ;)
>
> > didn't investigate deeper (maybe if you provide a small example I would), 
> > but just from looking at this:
>
> Unfortunately, it's hard to make a small example because this all
> lives in bizarro world where "IO" isn't IO, "String" isn't [Char] etc,
> so I can't just take the input program and pass it to vanilla GHC.
>
> >
> >  * It is generally preferable to turn local lambda expressions
> >into top-level functions. This way, instead of dynamically
> >allocating a FUN heap object, it's just a static function.
> >
> >  * sat_sKv is an IO expression? Then it is actually a function in a way
> >(taking the "State token" as an argument). So the above applies.
>
> This is "IO" but not GHC's IO, just another type with an opaque
> definition and a Monad instance. There's no reason for GHC to think
> that sat_sKv would be a function.
>
> Of course, sat_sKw is necessarily a function since it is the second
> argument to bind. But only now I am noticing that even sat_sKw's
> definition includes *yet another* floated-out variable:
>
> sat_sKv = some complicated expression 1
> sat_sKu = some complicated expression 2
> sat_sKw = \_ -> sat_sKu
> main = bindIO sat_sKv sat_sKw
>
> Here, I don't see why GHC should think that sat_sKv and sat_sKu are
> functions. For example, here's the definition of sat_sKu:
>
> sat_sKu :: IO ()
> [LclId]
> sat_sKu
>   = let {
>   sat_sRy [Occ=Once1] :: String
>   [LclId]
>   sat_sRy
> = let {
> sat_sRx [Occ=Once1] :: String
> [LclId]
> sat_sRx = unpackCStringUtf8# "\n"# } in
>   let {
> sat_sRw [Occ=Once1] :: String
> [LclId]
> sat_sRw
>   = case foobar True of {
>   False -> unpackCStringUtf8# "False"#;
>   True -> unpackCStringUtf8# "True"#
> } } in
>   sApp# sat_sRw sat_sRx } in
> putStrOut sat_sRy
>
> Here, putStrOut is so opaque that it doesn't even have a definition,
> it is merely a name registered into GHC's name tables. So I really
> don't see why this looks "function-y" to GHC.
>
> The reason this is all a problem for me is because I would like to
> then interpret all these let-bindings, including the toplevel ones, as
> eagerly defined variables. But then there is of course a difference between
>
> main =
>   let a1 = someIOAction1
>   a2 = someOtherIOAction2
>   a2' = \_ -> a2
>   in bindIO a1 a2'
>
> and
>
> main =
>   let a1 = someIOAction1
>   a2 = \_ -> someIOAction2
>   in bindIO a1 a2
>
> because if the *definition* of "a2" throws (not its action), then the
> first version will throw immediately whereas the second will only
> throw when "main" is *run*, after running "a1".
>
> >  * I think this is the FloatOut pass. You can turn it out using
> >-fno-full-laziness. Not sure if some others passes might
> >do similar things, though.
>
> I tried turning off Opt_FullLaziness, but unfortunately I am still
> getting the same result. I was also hopeful when I saw there's an
> Opt_FloatIn flag, but alas that doesn't change this behaviour either
> (and it's turned on by default anyway...)
>
> I'll try to make a self-contained minimal example next week.
>
> Thanks,
> Gergo
>
> -Original Message-
> From: ghc-devs  On Behalf Of Joachim Breitner
> Sent: Wednesday, December 29, 2021 8:39 PM
> To: ghc-devs@haskell.org
> Subject: [External] Re: What's the benefit of taking "do" blocks apart? Is 
> there a way to turn that off?
>
> [You don't often get email from m...@joachim-breitner.de. Learn why this is 
> important at http://aka.ms/LearnAboutSenderIdentification.]
>
> ATTENTION: This email came from an external source. Do not open attachments 
> or click on links from unknown senders or unexpected emails. Always report 
> suspicious emails using the Report As Phishing button in Outlook to protect 
> the Bank and our clients.
>
>
> Hi Gergo,
>
> Am Dienstag, dem 28.12.2021 um 15:57 + schrieb Erdi, Gergo via ghc-
> devs:
> > PUBLIC
>
> phew
>
> > I’m seeing ‘do’ blocks getting taking apart into top-level
> > definitions, so e.g.
> >
> > main = do
> >   some complicated expression 1
> >   some complicated expression 2
> >
> > is compiled into
> >
> > sat_sKv = some complicated expression 1 sat_sKw = \_ -> some
> > complicated expression 2 main = bindIO sat_sKv sat_sKw
> >
> > This seems to 

Re: Source locations from Core

[Matthew Pickering]

Hi Gergo,

Source Notes are what you are looking for. Currently the only way to
enable them is to either use `-g` or `-finfo-table-map`. The result
will be core which contains nodes which attempt to describe where the
core expression came from, it's not perfect though!

See Section 5.4 - https://etheses.whiterose.ac.uk/8321/1/thesis.pdf

Matt

On Tue, Dec 28, 2021 at 9:14 AM Erdi, Gergo via ghc-devs
 wrote:
>
> PUBLIC
>
>
> Hi,
>
>
>
> I’m looking for ways to map Core fragments back to source locations.
>
>
>
> I see there is an annotated version of Core in `GHC/Core.hs` called 
> `AnnExpr`, which I could see being useful for this if I set the annotation 
> type to `SrcSpan`, but that’s not what I get out of GHC’s desugarer, 
> simplifier or tidier.
>
>
>
> If there’s no built-in mechanism for this, my only idea would be to create a 
> HsExpr-to-HsExpr transformation that wraps every node in a call that is 
> opaque enough to be persisted through Core-to-Core transformations but still 
> transparent enough that it doesn’t block optimization opportunities. Is that 
> even possible?
>
>
>
> Alternatively, would it make it easer if I was content with only getting 
> source locations for variable occurrences?
>
>
>
> Thanks,
>
>Gergo
>
>
> This email and any attachments are confidential and may also be privileged. 
> If you are not the intended recipient, please delete all copies and notify 
> the sender immediately. You may wish to refer to the incorporation details of 
> Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
> https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard Chartered PLC, 
> Standard Chartered Bank and their subsidiaries (the "Group"), information on 
> the regulatory standards we adhere to and how it may affect you can be found 
> in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and 
> Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and 
> contains any market commentary, the market commentary has been prepared by 
> the sales and/or trading desk of Standard Chartered Bank or its affiliate. It 
> is not and does not constitute research material, independent research, 
> recommendation or financial advice. Any market commentary is for information 
> purpose only and shall not be relied on for any other purpose and is subject 
> to the relevant disclaimers available at https: 
> //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and 
> contains any research materials prepared by members of the team, the research 
> material is for information purpose only and shall not be relied on for any 
> other purpose, and is subject to the relevant disclaimers available at https: 
> //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction, by 
> responding affirmatively to this e-mail, you agree that you have understood 
> the terms and conditions in the attached term sheet and evaluated the merits 
> and risks of the transaction. We may at times also request you to sign the 
> term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for 
> important information with respect to derivative products.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Running GHC in GHCi

[Matthew Pickering]

Looks good Ben.

Would it be good to add a target to hadrian which builds just the
right dependencies for this to work? and then deals with setting
options such as -B as well.

Matt

On Thu, Oct 28, 2021 at 5:26 AM Bryan Richter  wrote:
>
> That's very exciting!
>
> On Thu, 28 Oct 2021, 3.08 Ben Gamari,  wrote:
>>
>> Ben Gamari  writes:
>>
>> > Hi all,
>> >
>> > Today I verified that with Luite's recent work on the interpreter it is
>> > now possible to run GHC entirely within GHCi (when bootstrapping from
>> > GHC 9.2).
>> >
>> > ...
>> >
>> I have fixed the break-array issue noted in the above message in !6848.
>> It is now possible to use `:trace` on GHC itself:
>>
>>
>> $ hadrian/ghci
>> GHCi, version 9.2.1: https://www.haskell.org/ghc/  :? for help
>> .
>> .
>> .
>> λ> import Main
>> λ> :set args -B/opt/exp/ghc/ghc-landing/_build/stage1/lib Hi.hs -v3 
>> -fforce-recomp
>> λ> :set -fbreak-on-error
>> λ> :trace main
>> Glasgow Haskell Compiler, Version 9.3.20211027, stage 1 booted by GHC 
>> version 9.2.1
>> ^CStopped in , 
>> _exception :: e = _
>> [] λ> :hist
>> -1  : fromException 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Utils/Panic.hs:114:19-24)
>> -2  : uniq 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:205:7-10)
>> -3  : moduleNameFS 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:72:33-35)
>> -4  : stableModuleNameCmp 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:62:64-78)
>> -5  : lexicalCompareFS 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:252:18-25)
>> -6  : uniq 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:205:7-10)
>> -7  : moduleNameFS 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:72:33-35)
>> -8  : stableModuleNameCmp 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:62:29-43)
>> -9  : lexicalCompareFS 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:252:6-13)
>> -10 : lexicalCompareFS 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:252:6-25)
>> -11 : lexicalCompareFS 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:(252,3)-(253,54))
>> -12 : stableModuleNameCmp 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:62:29-78)
>> -13 : compare 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:42:23-49)
>> -14 : fs_sbs 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:207:7-12)
>> -15 : lexicalCompareFS 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:253:44-53)
>> -16 : fs_sbs 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:207:7-12)
>> -17 : lexicalCompareFS 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:253:31-40)
>> -18 : lexicalCompareFS 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:253:3-54)
>> -19 : uniq 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:205:7-10)
>> -20 : moduleNameFS 
>> (/opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:72:33-35)
>> ...
>> [] λ> :back
>> Logged breakpoint at 
>> /opt/exp/ghc/ghc-landing/compiler/GHC/Utils/Panic.hs:114:19-24
>> _result :: Maybe GHC.Utils.Panic.Plain.PlainGhcException
>> e :: SomeAsyncException
>> [-1: /opt/exp/ghc/ghc-landing/compiler/GHC/Utils/Panic.hs:114:19-24] λ> :back
>> Logged breakpoint at 
>> /opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:205:7-10
>> _result :: Int
>> uniq :: Int
>> [-2: /opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:205:7-10] λ> 
>> uniq
>> 603980920
>> [-2: /opt/exp/ghc/ghc-landing/compiler/GHC/Data/FastString.hs:205:7-10] λ> 
>> :back
>> Logged breakpoint at 
>> /opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:72:33-35
>> _result :: ModuleName
>> mod :: ModuleName
>> [-3: /opt/exp/ghc/ghc-landing/compiler/GHC/Unit/Module/Name.hs:72:33-35] λ> 
>> mod
>> ModuleName "GHC.Tc.Solver.Canonical"
>>
>> et cetera
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*)

[Matthew Pickering]

Hi,

If there is a ticket then I can look into it next week.

Cheers,

Matt

On Fri, Oct 22, 2021 at 12:11 PM Simon Peyton Jones
 wrote:
>
> I’m out of cycles.  Do please open a ticket. You are more likely to get 
> attention that way.
>
>
>
> Matthew: maybe you can help with reproducing this?
>
>
> SImon
>
>
>
> PS: I am leaving Microsoft at the end of November 2021, at which point 
> simo...@microsoft.com will cease to work.  Use simon.peytonjo...@gmail.com 
> instead.  (For now, it just forwards to simo...@microsoft.com.)
>
>
>
> From: Erdi, Gergo 
> Sent: 19 October 2021 09:36
> To: Simon Peyton Jones ; 'Matthew Pickering' 
> 
> Cc: Montelatici, Raphael Laurent ; 'GHC' 
> 
> Subject: RE: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING 
> EXAMPLE (RE: Instantiation of overloaded definition *in Core*)
>
>
>
> PUBLIC
>
>
>
> PUBLIC
>
>
>
> “settings”? Honestly, I have no idea. GHC looks at these files in the 
> directory passed to runGhc, and in my local setup I have some convoluted 
> ghc-lib-based system to persist these files and also the base package.db into 
> a Stack/cabal-installable package, but these are only needed for environments 
> where there’s no bona-fide GHC build directory.
>
>
>
> I am sure even without Hadrian, you should have these files somewhere under 
> your build directory, since otherwise the same same runGhc function (used 
> inside the GHC executable as well…) wouldn’t work. Maybe someone else with 
> non-Hadrian knowledge can tell you where these files are put in the 
> non-Hadrian build.
>
>
>
> From: Simon Peyton Jones 
> Sent: Tuesday, October 19, 2021 4:08 PM
> To: Erdi, Gergo ; 'Matthew Pickering' 
> 
> Cc: Montelatici, Raphael Laurent ; 'GHC' 
> 
> Subject: [External] RE: Specialisation doesn't kick in -- NOW WITH MINIMAL 
> WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*)
>
>
>
> Yes I have a full build.  No it was not built with Hadrian.  I did not 
> realise that your system relied not only on GHC as a library, but also on the 
> build system that you use to build GHC.
>
>
>
> I guess I can try that, but probably not today.  But what is “settings”?
>
>
>
> Simon
>
>
>
> PS: I am leaving Microsoft at the end of November 2021, at which point 
> simo...@microsoft.com will cease to work.  Use simon.peytonjo...@gmail.com 
> instead.  (For now, it just forwards to simo...@microsoft.com.)
>
>
>
> From: Erdi, Gergo 
> Sent: 19 October 2021 09:03
> To: Simon Peyton Jones ; 'Matthew Pickering' 
> 
> Cc: Montelatici, Raphael Laurent ; 'GHC' 
> 
> Subject: RE: Specialisation doesn't kick in -- NOW WITH MINIMAL WORKING 
> EXAMPLE (RE: Instantiation of overloaded definition *in Core*)
>
>
>
> PUBLIC
>
>
>
> PUBLIC
>
>
>
> Do you have a full GHC build there? Are you using Hadrian? Did you set 
> `libDir`’s definition in the source file to where you have GHC built? I just 
> tried, and if I remove the files from my GHC build, I am able to rebuild them:
>
>
>
> mi@localhost[ghc] $ for i in settings llvm-passes llvm-targets; do rm 
> ~/prog/ghc/_build/stage1/lib/$i; done
>
> mi@localhost[ghc] $ for i in settings llvm-passes llvm-targets; do 
> ./hadrian/build-stack _build/stage1/lib/$i; done
>
> | Successfully generated _build/stage1/lib/settings.
>
> Build completed in 0.41s
>
>
>
> | Copy file: llvm-passes => _build/stage1/lib/llvm-passes
>
> Build completed in 0.40s
>
>
>
> | Copy file: llvm-targets => _build/stage1/lib/llvm-targets
>
> Build completed in 0.52s
>
>
>
>
>
>
>
> From: Simon Peyton Jones 
> Sent: Tuesday, October 19, 2021 3:54 PM
> To: Erdi, Gergo ; 'Matthew Pickering' 
> 
> Cc: Montelatici, Raphael Laurent ; 'GHC' 
> 
> Subject: [External] RE: Specialisation doesn't kick in -- NOW WITH MINIMAL 
> WORKING EXAMPLE (RE: Instantiation of overloaded definition *in Core*)
>
>
>
> As for opening a ticket – a big part of the problem is that I don’t even know 
> yet if I’m doing something wrong, or GHC is! So it’s not clear what the 
> ticket would even be for – “I’m using the GHC API wrongly” is not a strong 
> bug report 
>
>
>
> Plenty of tickets turn out to be non-bugs.  But they are still searchable, 
> and form a permanent record that may help others, perhaps in unexpected ways. 
>  So I encourage you to do so.
>
>
>
> I successfully compiled the attached Main.hs with HEAD, passing ‘-package 
> ghc’ as a command line argument.
>
>
>
> When I run it I get
>
> simonpj@MSRC-3645512:~/tmp$ ./gergo
>
> Missing file: /home/simonp

Re: Gitlab

[Matthew Pickering]

Working for me.

Matt

On Thu, Oct 21, 2021 at 10:01 AM Simon Peyton Jones via ghc-devs
 wrote:
>
> Is it just me, or is Gitlab offline again?  I’m getting error code 500.
>
> Simon
>
>
>
> PS: I am leaving Microsoft at the end of November 2021, at which point 
> simo...@microsoft.com will cease to work.  Use simon.peytonjo...@gmail.com 
> instead.  (For now, it just forwards to simo...@microsoft.com.)
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Another hadrian option you might want to use

[Matthew Pickering]

Hi,

A recent change in the testsuite meant that we now running the haddock
tests with hadrian, this means that haddocks for ghc/base get rebuilt
if you modify anything in the compiler.

This can decrease interaction speed. To disable the documentation
tests from running use

--docs=none

This is similar to the flag which already skips performance tests:

--skip-perf

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: gitlab.haskell.org

[Matthew Pickering]

I restarted the service and things appear to be working atm.. but I
don't understand how the volumes are configured on the machine so will
have to wait for Ben to fix it properly.

On Mon, Oct 18, 2021 at 9:11 AM Zubin Duggal  wrote:
>
> It is not just you, Gitlab has been unstable since yesterday due to a
> lack of disk space.
>
> On 21/10/18 07:29, Simon Peyton Jones via ghc-devs wrote:
> >I'm getting "502" from gitlab.haskell.org.   Is it just me?
> >
> >Thanks
> >
> >Simon
> >
> >PS: I am leaving Microsoft at the end of November 2021, at which point 
> >simo...@microsoft.com will cease to work.  Use 
> >simon.peytonjo...@gmail.com instead.  
> >(For now, it just forwards to simo...@microsoft.com.)
> >
>
> >___
> >ghc-devs mailing list
> >ghc-devs@haskell.org
> >http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Specialisation doesn't kick in (RE: Instantiation of overloaded definition *in Core*)

[Matthew Pickering]

I think you need to run at least one simplifier pass as the
specialisations are applied via rules (created by specProgram).

On Wed, Oct 6, 2021 at 3:10 AM Erdi, Gergo via ghc-devs
 wrote:
>
> PUBLIC
>
>
> PUBLIC
>
>
>
> Hi,
>
>
>
> Thanks! Originally I was going to reply to this saying that my transformation 
> isn’t running in CoreM so where do I get that environment from, but then I 
> realized I can just build it from the md_insts field of ModDetails. However, 
> after thinking more about it, I also realized that I shouldn’t ever really 
> need to conjure up dictionaries from thin air: the whole reason I am making a 
> specific specialization of an overloaded function is because I found 
> somewhere a call at that type. But then, that call also gives me the 
> dictionary!
>
>
>
> Of course at this point, this sounds exactly like what GHC already does in 
> `specProgram`. So maybe I should be able to just use that?
>
>
>
> Unfortunately, my initial testing seems to show that even if I run `specBind` 
> manually on my whole-program collected CoreProgram, it doesn’t do the work I 
> would expect from it!
>
>
>
> In the following example, I have only kept the definitions that are relevant. 
> Before specialisation, I have the following whole-program Core:
>
>
>
> (>>=)
>
>   :: forall (m :: * -> *) a b. Monad m => m a -> (a -> m b) -> m b
>
> [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=]
>
> (>>=)
>
>   = \ (@(m :: * -> *)) (v_sGm [Occ=Once1!] :: Monad m) ->
>
>   case v_sGm of
>
>   { C:Monad _ [Occ=Dead] v_sGp [Occ=Once1] _ [Occ=Dead] ->
>
>   v_sGp
>
>   }
>
> $dm>> :: forall (m :: * -> *) a b. Monad m => m a -> m b -> m b
>
> [GblId, Arity=3, Unf=OtherCon []]
>
> $dm>>
>
>   = \ (@(m :: * -> *))
>
>   ($dMonad [Occ=Once1] :: Monad m)
>
>  (@a)
>
>   (@b)
>
>   (ma [Occ=Once1] :: m a)
>
>   (mb [Occ=OnceL1] :: m b) ->
>
>   let {
>
> sat_sGQ [Occ=Once1] :: a -> m b
>
> [LclId]
>
> sat_sGQ = \ _ [Occ=Dead] -> mb } in
>
>   >>= @m $dMonad @a @b ma sat_sGQ
>
> C:Monad [InlPrag=NOUSERINLINE CONLIKE]
>
>   :: forall (m :: * -> *).
>
>  Applicative m
>
>  -> (forall a b. m a -> (a -> m b) -> m b)
>
>  -> (forall a b. m a -> m b -> m b)
>
>  -> Monad m
>
> [GblId[DataCon], Arity=3, Caf=NoCafRefs, Cpr=m1, Unf=OtherCon []]
>
> C:Monad
>
>   = \ (@(m :: * -> *))
>
>   (eta_B0 [Occ=Once1] :: Applicative m)
>
>   (eta_B1 [Occ=Once1] :: forall a b. m a -> (a -> m b) -> m b)
>
>   (eta_B2 [Occ=Once1] :: forall a b. m a -> m b -> m b) ->
>
>   C:Monad @m eta_B0 eta_B1 eta_B2
>
> $fMonadIO [InlPrag=NOUSERINLINE CONLIKE] :: Monad IO
>
> [GblId[DFunId]]
>
> $fMonadIO = C:Monad @IO $fApplicativeIO bindIO $fMonadIO_$c>>;
>
> $fMonadIO_$c>> [Occ=LoopBreaker]
>
>   :: forall a b. IO a -> IO b -> IO b
>
> [GblId]
>
> $fMonadIO_$c>> = \ (@a) (@b) -> $dm>> @IO $fMonadIO @a @b;
>
> sat_sHr :: IO ()
>
> [LclId]
>
> sat_sHr = returnIO @() ()
>
> sat_sHq :: IO ()
>
> [LclId]
>
> sat_sHq = returnIO @() ()
>
> main :: IO ()
>
> [GblId]
>
> main = $fMonadIO_$c>> @() @() sat_sHq sat_sHr
>
>
>
>
>
> Now I pass this to GHC’s `specBind`, but the output is exactly the same as 
> the input! (or it’s close enough that I can’t spot the difference).
>
>
>
> (>>=)
>
>   :: forall (m :: * -> *) a b. Monad m => m a -> (a -> m b) -> m b
>
> [GblId[ClassOp], Arity=1, Caf=NoCafRefs, Str=]
>
> (>>=)
>
>   = \ (@(m :: * -> *)) (v_sGm [Occ=Once1!] :: Monad m) ->
>
>   case v_sGm of
>
>   { C:Monad _ [Occ=Dead] v_sGp [Occ=Once1] _ [Occ=Dead] ->
>
>   v_sGp
>
>   }
>
> $dm>> :: forall (m :: * -> *) a b. Monad m => m a -> m b -> m b
>
> [GblId, Arity=3, Unf=OtherCon []]
>
> $dm>>
>
>   = \ (@(m :: * -> *))
>
>   ($dMonad [Occ=Once1] :: Monad m)
>
>   (@a)
>
>   (@b)
>
>   (ma [Occ=Once1] :: m a)
>
>   (mb [Occ=OnceL1] :: m b) ->
>
>   let {
>
> sat_MHt [Occ=Once1] :: a -> m b
>
> [LclId]
>
> sat_MHt = \ _ [Occ=Dead] -> mb } in
>
>   >>= @m $dMonad @a @b ma sat_MHt
>
> C:Monad [InlPrag=NOUSERINLINE CONLIKE]
>
>   :: forall (m :: * -> *).
>
>  Applicative m
>
>  -> (forall a b. m a -> (a -> m b) -> m b)
>
>  -> (forall a b. m a -> m b -> m b)
>
>  -> Monad m
>
> [GblId[DataCon], Arity=3, Caf=NoCafRefs, Cpr=m1, Unf=OtherCon []]
>
> C:Monad
>
>   = \ (@(m :: * -> *))
>
>   (eta_B0 [Occ=Once1] :: Applicative m)
>
>   (eta_B1 [Occ=Once1] :: forall a b. m a -> (a -> m b) -> m b)
>
>   (eta_B2 [Occ=Once1] :: forall a b. m a -> m b -> m b) ->
>
>   C:Monad @m eta_B0 eta_B1 eta_B2
>
> $fMonadIO [InlPrag=NOUSERINLINE CONLIKE] :: Monad IO
>
> [GblId[DFunId]]
>
> $fMonadIO = C:Monad @IO $fApplicativeIO bindIO $fMonadIO_$c>>;
>
> $fMonadIO_$c>> [Occ=LoopBreaker]
>
>   :: forall a b. IO a -> IO b -> IO b
>
> [GblId]
>
> $fMonadIO_$c>> = \ (@a) (@b) -> $dm>> @IO $fMonadIO @a @b;
>
> sat_sHr :: IO ()
>
> [LclId]
>
> sat_sHr = returnIO @() ()
>
> sat_sHq :: IO ()
>
> [LclId]

Re: help needed configuring GHC API client

[Matthew Pickering]

Hi Norman,

I think you are overcomplicating things quite a bit.

1. Build a HEAD (9.3) compiler
2. Setup a normal cabal project to depend on the `ghc` library
3. Use the cabal -w option to point to your HEAD compiler to build the
project (`cabal build -w /path/to/head`)

That will work reliably rather than messing around with package databases.

Matt

On Thu, Sep 23, 2021 at 7:31 PM Norman Ramsey  wrote:
>
> I'm writing client code against the GHC API in HEAD (version 9.3),
> using 9.0.1 as my bootstrap compiler.  To make it possible to build
> this code, I've set up cabal using
>
>cabal v1-configure \
>   --package-db clear \
>   --package-db $STAGE0/lib/package.conf.d/  # stage0 libraries
>
> In my Haskell code I'm invoking `runGhc (Just thelibdir)` where
>
>thelibir = "/home/nr/asterius/ghc/_build/stage0/lib"
>
> which is my `$STAGE0/lib`.
>
> Unfortunuately, when I launch my app, `setSessionDynFlags` panics.
> The output, along with some diagnostic information about some dflags
> that seemed relevant, looks like this:
>
>   libdir = /home/nr/asterius/ghc/_build/stage0/lib
>   includePaths = IncludeSpecs {includePathsQuote = [], includePathsGlobal = 
> [], includePathsQuoteImplicit = []}
>   libraryPaths = []
>   packageDBFlags = []
>   packageEnv = Nothing
>   panic! (the 'impossible' happened)
> GHC version 9.3.20210918:
>   GHC couldn't find the RTS constants (#define HS_CONSTANTS ") in 
> /home/nr/.ghcup/ghc/9.0.1/lib/ghc-9.0.1/include/DerivedConstants.h: the RTS 
> package you are trying to use is perhaps for another GHC version(e.g. you are 
> using the wrong package database) or the package database is broken.
>
>   CallStack (from HasCallStack):
> error, called at 
> _build/stage0/compiler/build/GHC/Platform/Constants.hs:143:20 in 
> ghc:GHC.Platform.Constants
>
>   Please report this as a GHC bug:  https://www.haskell.org/ghc/reportabug
>
>
> I'm a little suprprised that my app is hunting for 9.3 information in
> the tree that belongs to the bootstrap compiler.
>
> I could start tinkering with `packageEnv` or other dflags, but I'm on
> thin ice here, and I thought it made more sense to ask for advice.
>
> What is going on in my configuration, and how can I set up my app so
> it is using the library in my `libdir` rather than the library that
> belongs to the bootstrap compiler?
>
>
> Norman
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC development with VSCode

[Matthew Pickering]

I have been using Pepe's branch, it is stable and faster than the release.

Matt

On Thu, Sep 23, 2021 at 12:38 PM Pepe Iborra  wrote:
>
> I have worked on making ghcide scale better to large projects, in the context 
> of Facebook Sigma, bringing down the complexity of "edits" from O(transitive 
> imports) to O(transitive modules).
> The changes have not yet made it into an HLS release, but they are very much 
> ready for use if you are willing to build your own HLS binary:
>
> https://github.com/haskell/haskell-language-server/pull/2060
>
> On Mon, 20 Sept 2021 at 19:05, Ben Gamari  wrote:
>>
>> Richard Eisenberg  writes:
>>
>> > Hi devs,
>> >
>> > I have migrated to use VSCode instead of emacs. There are the usual 
>> > switchover pains, but I'm mostly pleased. One particular point of pleasure 
>> > was that I had to do nothing, at all, to get VSCode working within the GHC 
>> > code base. (Well, I had to switch to Hadrian, but perhaps that's for the 
>> > best.)
>> >
>> > My problem: VSCode over GHC pins my processor at 100% if I edit anything. 
>> > Any advice for fixing this?
>> >
>> > A little more detail: When VSCode starts up, it spends a while 
>> > "processing" and "indexing" (no idea what these mean). OK. I can pay that 
>> > one-time cost. But as I start editing, etc., it needs to process and index 
>> > a lot more. Somewhat continuously. This slows my computer down generally, 
>> > and -- more annoyingly -- slows down my builds (run in a separate 
>> > terminal).
>> >
>> I suspect you are using not just VS Code (which generally performs
>> fairly well on files of "reasonable" size) but also Haskell Language
>> Server; is this so?
>>
>> Indeed it is sadly true that LSP is currently a bit sluggish on GHC.
>> This is something that Matt Pickering has done a bit of work on the
>> past; he may have some concrete guidance for how to improve matters.
>> In the past he has suggested to me that disabling some language server
>> functionality helps matters.
>>
>> Cheers,
>>
>> - Ben
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Where (else) do I need to register instances from loaded modules?

[Matthew Pickering]

Hi Gergo,

Some things I noticed:

* The HPT only contains modules from the current home unit. It seems
that registerModule ignores this so you break this invariant.
* It seems that `Instance` contains an orphan, but you don't fill in
the `deps` field when making a `ModIface`, which should contain all
the orphan modules below the module you are compiling.

I think that if you fill in `deps` correctly then things may work out.
`Dependencies` eventually becomes `ImportAvail`, which gets consulted
by `tcVisibleOrphanMods` which is called in `tcGetInstEnvs` which is
called by `matchInstEnv`.

Matt

On Tue, Aug 24, 2021 at 3:20 AM Erdi, Gergo via ghc-devs
 wrote:
>
> PUBLIC
>
>
> Hi,
>
>
>
> I am trying to typecheck & load three modules using the GHC API. The first 
> one defines a class, the second one defines an instance of said class, and 
> the third one uses the instance (attached as Class.src, Instance.src and 
> Use.src, respectively). The problem is that when I typecheck Use.src, it 
> complains about the missing instance. It should be noted that the class is 
> found, only the instance isn’t.
>
>
>
> My code is bypassing the normal GHC driver to feed it modules instead of 
> letting GHC itself come up with dependencies and then loading them from disk; 
> that is because in my real use case, some dependencies will have interfaces 
> generated on the fly (there is no underlying Haskell source code), or loaded 
> over HTTP, etc. So I am using parseModule and typeCheckModule on each module, 
> make a ModIface from each, and then I try to register them with GHC, by 
> extending the HPT, the moduleNameProvidersMap, and the EPS. Evidently, this 
> is not enough, and the instances should be registered somewhere else as well 
> – where is that place?
>
>
>
> I have attached a simplified version of my code as Main.hs; it is targeting 
> the GHC 9.0 API. It hardcodes the GHC 9.0 package.conf.d due to laziness on 
> my part; please change line 96 to your environment before running it. As 
> written, it fails when typechecing Use.src with:
>
>
>
> input/Use.src:7:7: error:
>
> • No instance for (C X) arising from a use of ‘method’
>
> • In the expression: method
>
>   In an equation for ‘foo’: foo = method
>
>   |
>
> 7 | foo = method
>
>   |   ^^
>
>
>
> Thanks,
>
> Gergo
>
>
> This email and any attachments are confidential and may also be privileged. 
> If you are not the intended recipient, please delete all copies and notify 
> the sender immediately. You may wish to refer to the incorporation details of 
> Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
> https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard Chartered PLC, 
> Standard Chartered Bank and their subsidiaries (the "Group"), information on 
> the regulatory standards we adhere to and how it may affect you can be found 
> in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and 
> Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and 
> contains any market commentary, the market commentary has been prepared by 
> the sales and/or trading desk of Standard Chartered Bank or its affiliate. It 
> is not and does not constitute research material, independent research, 
> recommendation or financial advice. Any market commentary is for information 
> purpose only and shall not be relied on for any other purpose and is subject 
> to the relevant disclaimers available at https: 
> //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and 
> contains any research materials prepared by members of the team, the research 
> material is for information purpose only and shall not be relied on for any 
> other purpose, and is subject to the relevant disclaimers available at https: 
> //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction, by 
> responding affirmatively to this e-mail, you agree that you have understood 
> the terms and conditions in the attached term sheet and evaluated the merits 
> and risks of the transaction. We may at times also request you to sign the 
> term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for 
> important information with respect to derivative products.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Email Threading (finally fixed)

[Matthew Pickering]

Hi all,

If anyone received emails from gitlab you may have noticed that the
comments to issues ended up in different threads to the original issue
description.

This was because of a custom patch on our gitlab instance which I
think I have now fixed.

For example issue #20192 now has the correct threading, the original
issue and comment now appear in the same email thread (at least in my
client).

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to Collect Type Errors?

[Matthew Pickering]

Hi Gunda,

Could you be a bit more precise about what you want to achieve? HLS
already displays type errors in your program, perhaps it would be
better to ask someone on the HLS issue tracker how to use their API to
do what you want.

Matt

On Fri, Jul 30, 2021 at 7:03 PM Guanda Yuan  wrote:
>
> Hello all,
>
> I want to write a plugin for Haskell Language Server, to collect type errors 
> in the code. I'm new to GHC API, so I need some help. My current thought is, 
> I can collect diagnostics or the error messages and extract the type error 
> infos. I have tried to referred to the Haddock documentation for GHC API, but 
> I'm still not sure which function should I use.
>
> Thanks,
> Guanda
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

FYI: Darwin CI currently broken for forks

[Matthew Pickering]

Hi all,

There is a configuration issue with the darwin builders which has
meant that for the last 6 days CI has been broken if you have pushed
from a fork because the majority of darwin builders are only
configured to work with branches pushed to the main project. These
failures manifest as timeout errors
(https://gitlab.haskell.org/blamario/ghc/-/jobs/733244).

Hopefully this can be resolved in the coming days.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Trying to speedup GHC compile times...Help!

[Matthew Pickering]

Hi Jeff,

Welcome to ghc-devs and looking forward to seeing you around.

If you are not already aware, there are a set of grafana dashboards
for tracking compiler performance. Ones of particular interest might
be the `head.hackage` and `Cabal test` dashboards.

* Head.hackage 
(https://grafana.gitlab.haskell.org/d/7T7oEMlMz/head-hackage-performance?orgId=2=now-30d=now)
* Cabal test (https://grafana.gitlab.haskell.org/d/Zf4HCvz7z/cabal-test?orgId=2)

Looking at the data it's clear that simplification and code generation
are the two expensive phases in compilation.

So I think some useful things to look at would be:

1. Avoiding pointless work when substituting as suggested by Ben could
reduce allocations significantly in the simplifier.
2. Looking into optimising the pretty printing during code generation.
Ticky profiles indicate that certain pretty printer functions are
called many times and allocate a lot. (I don't have a ticky profile to
hand)
3. Modify the `perf` and `head.hackage` pipeline stages to fetch
recent perf stats from the database and print a comparison to the
baseline.

Cheers,

Matt

On Fri, Jul 2, 2021 at 4:05 PM Simon Peyton Jones via ghc-devs
 wrote:
>
> GHC precisely use “the rapier”.
>
>
>
> S
>
>
>
> From: Christiaan Baaij 
> Sent: 02 July 2021 15:38
> To: Simon Peyton Jones 
> Cc: Richard Eisenberg ; Young, Jeff 
> ; ghc-devs@haskell.org
> Subject: Re: Trying to speedup GHC compile times...Help!
>
>
>
> Somewhat off-topic: does GHC no longer use "the rapier"? I thought the 
> InScopeSet was needed to check that we can safely skip on extending the 
> substitution as you go under binders when the binder is not in the InScopeSet 
> (naively you would always have to rename binders, and thus extend the 
> substitution, in order to avoid capture as you go under binders). i.e. the 
> IntMap is not just used to generate new variable names, but to ensure the 
> compiler does less work in the form of doing fewer substitutions.
>
>
>
> On Fri, 2 Jul 2021 at 16:12, Simon Peyton Jones via ghc-devs 
>  wrote:
>
> There are lot of places where it would be pretty tiresome to plumb a unique 
> supply guaranteed unique from every other.   I think the current setup works 
> pretty well – but I bet we can squeeze cycles out of its implementation.
>
>
>
> Simon
>
>
>
> From: Richard Eisenberg 
> Sent: 02 July 2021 14:26
> To: Simon Peyton Jones 
> Cc: Young, Jeff ; ghc-devs@haskell.org
> Subject: Re: Trying to speedup GHC compile times...Help!
>
>
>
> One piece I'm curious about, reading this thread: why do we have so many 
> IntMaps and operations on them? Name lookup is a fundamental operation a 
> compiler must do, and that would use an IntMap: good. But maybe there are 
> other IntMaps used that are less necessary. A key example: whenever we do 
> substitution, we track an InScopeSet, which is really just an IntMap. This 
> InScopeSet remembers the name of all variables in scope, useful when we need 
> to create a new variable name (this is done by uniqAway). Yet perhaps the 
> tracking of these in-scope variables is very expensive and comprises much of 
> the IntMap time. Might it be better just to always work in a monad capable of 
> giving fresh names? We actually don't even need a monad, if that's too 
> annoying. Instead, we could just pass around an infinite list of fresh 
> uniques. This would still be clutterful, but if it grants us a big speed 
> improvement, the clutter might be worth it.
>
>
>
> The high-level piece here is that there may be good things that come from 
> understanding where these IntMaps arise.
>
>
>
> Richard
>
>
>
> On Jul 2, 2021, at 4:08 AM, Simon Peyton Jones via ghc-devs 
>  wrote:
>
>
>
> Jeff
>
>
>
> Great stuff!  Welcome.
>
>
>
> I strongly urge you to keep a constantly-update status wiki page, which lists 
> the ideas you are working on, and points to relevant resources and tickets.  
> An email thread like this is a good way to gather ideas, but NOT a good way 
> to organise and track them.
>
>
>
> Looking carefully at profiles is a good plan.  That’s the hard data!
>
>
>
> I think that some careful investigation of IntMap (at least the bits that GHC 
> uses heavily) would be a good idea.  Clearly we spend a lot of time in these 
> maps, so speedups here will yield a lot of benefit.  Look at the heavy 
> hitters from the profile, stare at the Core code and see if it’s s good as it 
> can be.
>
>
>
> For example, Sebastian discovered a strange infelicity in IntMap.lookup, 
> which I’ve documented in a new ticket
>
> https://gitlab.haskell.org/ghc/ghc/-/issues/20069
>
>
>
> I think it’d also be worth measuring how unbalanced our IntMap trees get.  See
>
>https://gitlab.haskell.org/ghc/ghc/-/issues/19820
>
> The speculation there is that we are getting very unbalanced trees.  So 
> measure it!  If it’s true, we could improve matters by using a different 
> IntMap; or maybe by scrambling the key a bit --- see the ticket.
>
>
>
> Simon
>
>
>
> From: ghc-devs  On 

Re: Loading a typechecked module and then using it immediately as a package

[Matthew Pickering]

Are you clearing the FinderCache?

On Tue, Jun 29, 2021 at 11:14 AM Erdi, Gergo  wrote:
>
> PUBLIC
>
> I don't know yet what's going on, but one thing I did notice is that 
> `findInstalledHomeModule` returns `InstalledFound` for `MyLib`, which doesn't 
> sound right to me -- `MyLib` should come from the "fake-uid" unit, and `Test` 
> is typechecked in the `mainUnitId`.
>
> -Original Message-
> From: Erdi, Gergo
> Sent: Tuesday, June 29, 2021 5:51 PM
> To: Matthew Pickering 
> Subject: Re: Loading a typechecked module and then using it immediately as a 
> package
>
> PUBLIC
>
> I tried moving `MyLib.hs` into a directory different than `Test.sh`, but the 
> error message still refers to its correct location! So this error is not 
> guessing the file name of where `MyLib.hs` could be loaded from; instead, it 
> seems to refer correctly to where the module (previously loaded) was. Hmm.
>
> -Original Message-
> From: Matthew Pickering 
> Sent: Tuesday, June 29, 2021 5:04 PM
> To: Erdi, Gergo 
> Subject: [External] Re: Loading a typechecked module and then using it 
> immediately as a package
>
>
> Do you have a `MyLib.hs` source file? If you move that somewhere else 
> (another folder) then things might work?
>
> On Tue, Jun 29, 2021 at 9:41 AM Erdi, Gergo  wrote:
> >
> > PUBLIC
> >
> > What's weird about it is that if I print the `moduleNameProvidersMap`, I 
> > can see `MyLib` inside, and it looks no different than any other module 
> > from e.g. `ghc-prim` that I can import into `Test.hs` without any package 
> > qualification. Also, why does the error message refer to the file name 
> > `input/MyLib.hs`? Why does GHC even know that that is where it would have 
> > to be loaded from, if it weren't to be used from an already loaded package?
> >
>
> This email and any attachments are confidential and may also be privileged. 
> If you are not the intended recipient, please delete all copies and notify 
> the sender immediately. You may wish to refer to the incorporation details of 
> Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
> https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard Chartered PLC, 
> Standard Chartered Bank and their subsidiaries (the "Group"), information on 
> the regulatory standards we adhere to and how it may affect you can be found 
> in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and 
> Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and 
> contains any market commentary, the market commentary has been prepared by 
> the sales and/or trading desk of Standard Chartered Bank or its affiliate. It 
> is not and does not constitute research material, independent research, 
> recommendation or financial advice. Any market commentary is for information 
> purpose only and shall not be relied on for any other purpose and is subject 
> to the relevant disclaimers available at https: 
> //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and 
> contains any research materials prepared by members of the team, the research 
> material is for information purpose only and shall not be relied on for any 
> other purpose, and is subject to the relevant disclaimers available at https: 
> //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction, by 
> responding affirmatively to this e-mail, you agree that you have understood 
> the terms and conditions in the attached term sheet and evaluated the merits 
> and risks of the transaction. We may at times also request you to sign the 
> term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for 
> important information with respect to derivative products.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Loading a typechecked module and then using it immediately as a package

[Matthew Pickering]

Hi Gergo,

Please see a minimal example in this gist.

https://gist.github.com/mpickering/5029c7f244c484c91d665bcbc6bc6406

Cheers,

Matt

On Fri, Jun 25, 2021 at 10:20 AM Erdi, Gergo via ghc-devs
 wrote:
>
> PUBLIC
>
>
> Hi,
>
>
>
> I have the following to .hs files:
>
>
>
> MyLib.hs:
>
> module MyLib where
> …
>
> Test.hs:
>
> {-# LANGUAGE PackageImports  #-}
> module Test where
> import “my-pkg” MyLib
> …
>
>
>
> I would like to parse/typecheck/load MyLib.hs into some Unit “my-unit”, then 
> add that to the package “my-pkg”, and then typecheck Test.hs, all in-proc 
> using the GHC API, without putting any other files on disk. How do I do that?
>
>
>
> What I tried is loading MyLib.hs after setting the homeUnitId in the DynFlags 
> to “my-unit”, then editing the packageNameMap in the unitState of the 
> DynFlags to may “my-pkg” to “my-unit”:
>
> setHomeUnit :: (GhcMonad m) => UnitId -> m ()
>
> setHomeUnit unitId = do
>
> dflags <- getSessionDynFlags
>
> modifySession $ \h -> h{ hsc_dflags = dflags{ homeUnitId = unitId } }
>
>
>
> registerUnit :: (GhcMonad m) => PackageName -> UnitId -> m ()
>
> registerUnit pkg unitId = modifySession $ \h -> h{ hsc_dflags = addUnit $ 
> hsc_dflags h }
>
>   where
>
> addUnit dflags = dflags
>
> { unitState = let us = unitState dflags in us
>
> { packageNameMap = M.insert pkg (Indefinite unitId Nothing) $ 
> packageNameMap us
>
> }
>
> }
>
>
>
> pipeline = do
>
> setHomeUnit myUnit
>
> loadModule =<< typecheckModule =<< parseModule =<< modSumarryFor 
> “MyLib”
>
> registerUnit myPkg myUnit
>
>
>
> setHomeUnit mainUnitId
>
> typecheckModule =<< parseModule =<< modSumarryFor “Test”
>
>
>
>
>
> Alas, this doesn’t work: the import of `MyLib` from `my-pkg` fails with:
>
>
>
> input/linking/Test.hs:5:1: error:
>
> Could not find module ‘MyLib’
>
> It is not a module in the current program, or in any known package.
>
>
>
> TBH I’m not very surprised that it didn’t work – that registerUnit function 
> is doing some pretty deep surgery on the unitState that probably breaks 
> several invariants. Still, I wasn’t able to find a better way – all the 
> functions in GHC.Unit.State seem to be for querying only.
>
>
>
> Thanks,
>
> Gergo
>
>
> This email and any attachments are confidential and may also be privileged. 
> If you are not the intended recipient, please delete all copies and notify 
> the sender immediately. You may wish to refer to the incorporation details of 
> Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
> https: //www.sc.com/en/our-locations
>
> Where you have a Financial Markets relationship with Standard Chartered PLC, 
> Standard Chartered Bank and their subsidiaries (the "Group"), information on 
> the regulatory standards we adhere to and how it may affect you can be found 
> in our Regulatory Compliance Statement at https: //www.sc.com/rcs/ and 
> Regulatory Compliance Disclosures at http: //www.sc.com/rcs/fm
>
> Insofar as this communication is not sent by the Global Research team and 
> contains any market commentary, the market commentary has been prepared by 
> the sales and/or trading desk of Standard Chartered Bank or its affiliate. It 
> is not and does not constitute research material, independent research, 
> recommendation or financial advice. Any market commentary is for information 
> purpose only and shall not be relied on for any other purpose and is subject 
> to the relevant disclaimers available at https: 
> //www.sc.com/en/regulatory-disclosures/#market-disclaimer.
>
> Insofar as this communication is sent by the Global Research team and 
> contains any research materials prepared by members of the team, the research 
> material is for information purpose only and shall not be relied on for any 
> other purpose, and is subject to the relevant disclaimers available at https: 
> //research.sc.com/research/api/application/static/terms-and-conditions.
>
> Insofar as this e-mail contains the term sheet for a proposed transaction, by 
> responding affirmatively to this e-mail, you agree that you have understood 
> the terms and conditions in the attached term sheet and evaluated the merits 
> and risks of the transaction. We may at times also request you to sign the 
> term sheet to acknowledge the same.
>
> Please visit https: //www.sc.com/en/regulatory-disclosures/dodd-frank/ for 
> important information with respect to derivative products.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Anyone ever wondered what our favourite merge bot is up to?

[Matthew Pickering]

There are just no logs from the last 3 hours, the default time period. I
have increased the default now to 24hrs.

On Thu, Jun 10, 2021 at 12:11 AM Richard Eisenberg 
wrote:

> This sounds fantastic!
>
> But when I visit that page, I see the attached, which does not appear to
> have much information. Am I doing something wrong?
>
> Thanks,
> Richard
>
>
> On Jun 9, 2021, at 6:29 AM, Matthew Pickering 
> wrote:
>
> Hi all,
>
> I added a new dashboard on grafana which exposes some of the systemd
> logs from marge-bot.
>
> https://grafana.gitlab.haskell.org/d/iiCppweMz/marge-bot?orgId=2=5m
>
> You can use the logs to see why marge doesn't want to merge your MR or
> whether she is dead.
>
> Cheers,
>
> Matt
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Anyone ever wondered what our favourite merge bot is up to?

[Matthew Pickering]

Hi all,

I added a new dashboard on grafana which exposes some of the systemd
logs from marge-bot.

https://grafana.gitlab.haskell.org/d/iiCppweMz/marge-bot?orgId=2=5m

You can use the logs to see why marge doesn't want to merge your MR or
whether she is dead.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC and the future of Freenode

[Matthew Pickering]

I have been trying out Matrix a bit recently. It seems the best of the
options in my opinion and has the advantage of being able to bridge to
IRC (and other platforms).

The NixOS community rapidly moved over without any ill effects after
the demise of freenode.

As with all these things, who feels willing to make a decision for us?

Cheers,

Matt

On Sat, May 22, 2021 at 7:52 PM John Ericson
 wrote:
>
> As Ben and others say, Matrix provides many modern features new users will 
> expect, while preserving the spirit of IRC. Without wading into the details, 
> the design of Matrix I find impressive and to my liking, and it has seemed to 
> get steadily better over time for quite a while now.
>
> Re Zulip, in https://news.ycombinator.com/item?id=27202838 one of the lead 
> Matrix devs says their up-and-coming threading model aims to support what 
> Zulip does and they've been discussing deeper integration with Zulip. 
> Granted, It would be better to hear about those discussions from the Zulip 
> side as Matrix aims to assimilate everything and Zulip could have some 
> reservations, but I remain hopeful. (I certainly would like to see culled the 
> current explosion of mutually-incompatible chat applications, leaving us with 
> fewer protocols but as many competing implementations.)
>
> What I recommend for now that we make some official Matrix channels, but also 
> bridge them with the libera.chat ones once the bridge is up (should be a few 
> days). Creating a matrix room and bridging it is a bit different underneath 
> the hood than using a channel generated by the bridge on demand. We can give 
> them nice names on the matrix side, and basically keep both options open of 
> being "IRC-first" or "Matrix-first" down the road.
>
> For reference, see https://matrix.to/#/#community:nixos.org?via=nixos.org 
> which is the Matrix "Space" (room that is a directory of sub-rooms, filling 
> the role of a Discord "server") that Nix community created while they debate 
> what to do next. See also https://github.com/NixOS/rfcs/pull/94 where this 
> same discussion is playing out.
>
> John
>
> On 5/21/21 4:00 PM, Iavor Diatchki wrote:
>
> As I said, I am not a heavy IRC user, for my online chatting needs I mostly 
> use Mattermost, Discord, and Slack.So I don't have an informed opinion on 
> the technical merits of the various platforms---mostly I've heard that the 
> Matrix clients and servers are quite a bit less robust than IRC ones but I've 
> never personally used them.
>
> If there is a feeling that GHC wants to use a new chatting platform, by all 
> means we should try it out.  I just don't think that the unfortunate 
> situation with free-node is a good reason to drop IRC entirely.   Despite its 
> flows, I think it has served our community well, and while it may look "old" 
> to "young" users it does have the benefit of being pretty stable, unlike the 
> myriad of chatting services that seem to be popping up all the time.
>
> -Iavor
>
>
>
> On Fri, May 21, 2021 at 10:41 AM Ben Gamari  wrote:
>>
>> Iavor Diatchki  writes:
>>
>> > Hello,
>> >
>> > I am not a heavy IRC user, but I'd say it makes most sense to just use
>> > Libera.  It is essentially the same people that were running free-node
>> > running pretty much the exact same service, and I believe they are trying
>> > to make it extra easy to just switch, so this should be the least effort
>> > transition.
>> >
>> > I believe IRC has served the GHC community quite well so far, and there is
>> > a reddit post by Ed Kmett that the normal Haskell channels have already
>> > been transitioned over, so I think it makes sense for GHC to stick with the
>> > rest of the Haskell community.
>> >
>> The problem is that, in order to grow (or even merely not to shrink),
>> the community also needs to adapt to the preferences of younger users.
>>
>> The fact of the matter is the younger users tend to be, at best,
>> unfamiliar with IRC. In the worst case, the need to leave a browser/sign
>> up for a new account means that they simply won't participate. Of the
>> new contributors I have had approach me in the past year, less than half
>> have had any familiarity with IRC.
>>
>> Matrix has the advantage of being accessible to "web-native" community
>> members while being open enough to (at least in principle) allow
>> community members who are accustomed to IRC to continue to participate
>> via a bridge.
>>
>> Cheers,
>>
>> - Ben
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GitLab downtime

[Matthew Pickering]

I restarted the service but somethings still appear to be broken.

On Tue, Jun 1, 2021 at 9:16 AM Shayne Fletcher
 wrote:
>
> Seems to be serving again now
>
> On Tue, Jun 1, 2021 at 4:13 PM Vladislav Zavialov  
> wrote:
>>
>> It is currently down with a 502 error.
>>
>> - Vlad
>>
>> > On 1 Jun 2021, at 04:01, Ben Gamari  wrote:
>> >
>> > Hi all,
>> >
>> > I believe gitlab.haskell.org should be back up at this point. There are
>> > still a few ancillary services (e.g. grafana.gitlab.haskell.org) that I
>> > haven't yet validated but every critical should be functional. Do let me
>> > know if you find anything amiss.
>> >
>> > Cheers,
>> >
>> > - Ben
>> > ___
>> > ghc-devs mailing list
>> > ghc-devs@haskell.org
>> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
>
> --
> Shayne Fletcher
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Productivity Tip from mpickering

[Matthew Pickering]

Hi,

I am now using a new flavour combination which is proving *very* nice
as a compromise between fast recompiles and passing tests.

My normal build command is now:

./hadrian/build --flavour=default+no_profiled_libs+omit_pragmas --freeze1 -j

This has the effect of

* base libraries are compiled with optimisation
* Profiling libraries are not built
* Stage 1 compiler is compiled with -O + -fomit-interface-pragmas, so
recompilation behaviour is much better.

The end result is a nearly clean testsuite run (I think there are two
failures) but much faster iterations when modifying `compiler/*`.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Darwin CI Status

[Matthew Pickering]

Thanks Moritz for that update.

The latest is that currently darwin CI is disabled and the merge train
is unblocked (*choo choo*).

I am testing Moritz's patches to speed-up CI and will merge them in
shortly to get darwin coverage back.

Cheers,

Matt

On Wed, May 19, 2021 at 9:46 AM Moritz Angermann
 wrote:
>
> Matt has access to the M1 builder in my closet now. The darwin performance 
> issue
> is mainly there since BigSur, and (afaik) primarily due to the amount of 
> DYLD_LIBRARY_PATH's
> we pass to GHC invocations. The system linker spends the majority of the time 
> in the
> kernel stat'ing and getelements (or some similar directory) call for each and 
> every possible
> path.
>
> Switching to hadrian will cut down the time from ~5hs to ~2hs. At some point 
> we had make
> builds <90min by just killing all DYLD_LIBRARY_PATH logic we ever had, but 
> that broke
> bindists.
>
> The CI has time values attached and some summary at the end right now, which 
> highlights
> time spent in the system and in user mode. This is up to 80% sys, 20% user, 
> and went to
> something like 20% sys, 80% user after nuking all DYLD_LIBRARY_PATH's, with 
> hadrian it's
> closer to ~25% sys, 75% user.
>
> Of note, this is mostly due to time spent during the *test-suite*, not the 
> actual build. For the
> actual build make and hadrian are comparable, though I've seen hadrian to 
> oddly have a
> much higher variance in how long it takes to *build* ghc, whereas the make 
> build was more
> consistent.
>
> The test-suite quite notoriously calls GHC *a lot of times*, which makes any 
> linker issue due
> to DYLD_LIBRARY_PATH (and similar lookups) much worse.
>
> If we would finally split building and testing, we'd see this more clearly I 
> believe. Maybe this
> is motivation enough for someone to come forward to break build/test into two 
> CI steps?
>
> Cheers,
>  Moritz
>
> On Wed, May 19, 2021 at 4:14 PM Matthew Pickering 
>  wrote:
>>
>> Hi all,
>>
>> The darwin pipelines are gumming up the merge pipeline as they are
>> taking over 4 hours to complete on average.
>>
>> I am going to disable them -
>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5785
>>
>> Please can someone give me access to one of the M1 builders so I can
>> debug why the tests are taking so long. Once I have fixed the issue
>> then I will enable the pipelines.
>>
>> Cheers,
>>
>> Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Darwin CI Status

[Matthew Pickering]

Hi all,

The darwin pipelines are gumming up the merge pipeline as they are
taking over 4 hours to complete on average.

I am going to disable them -
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/5785

Please can someone give me access to one of the M1 builders so I can
debug why the tests are taking so long. Once I have fixed the issue
then I will enable the pipelines.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Running ghc-debug on ghc

[Matthew Pickering]

Hi,

I now have some simple instructions for running ghc-debug on GHC.

1. Cherry-pick 4be70967f1f1ab70cbe31aad8ae69aea87c6f4c4

commit 4be70967f1f1ab70cbe31aad8ae69aea87c6f4c4 (HEAD -> wip/ghc-with-debug)
Author: Matthew Pickering 
Date:   Fri Jan 8 11:26:17 2021 +

Add support for ghc-debug to ghc executable

2. Build GHC
* Add the following to _build/hadrian.settings

```
stage1.*.ghc.hs.opts += -finfo-table-map -fdistinct-constructor-tables
```

* Build GHC as normal

```
./hadrian/build -j8
```

* The result is a ghc-debug enabled compiler

# Building a debugger

* Use the compiler you just built to build ghc-debug

```
cd ghc-debug
cabal update
cabal new-build debugger -w ../_build/stage1/bin/ghc
```

# Running the debugger

Modify `test/Test.hs` to implement the debugging thing you want to do. Perhaps
start with `p30`, which is a program to generate a profile.


* Start the process you want to debug
```
GHC_DEBUG_SOCKET=/tmp/ghc-debug build-cabal
```

* Start the debugger
```
cabal new-run debugger -w ...
```

* Open a ticket about the memory issue you find.

There is the start of some more documentation here -
http://ghc.gitlab.haskell.org/ghc-debug/docs.html

These instructions are also in the instructions.md file in the commit.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: What changed between GHC 8.8 and 8.10 that could cause this?

[Matthew Pickering]

Perhaps related to 0dc7985663efa1739aafb480759e2e2e7fca2a36 ?

commit 0dc7985663efa1739aafb480759e2e2e7fca2a36
Author: Julian Leviston 
Date:   Sat Feb 2 20:10:51 2019 +1100

Allow for multiple linker instances. Fixes Haskell portion of #3372.

On Thu, Mar 4, 2021 at 11:55 AM ÉRDI Gergő  wrote:
>
> Hi,
>
> I'm trying to figure out a Clash  problem and managed to track it down to
> a GHC upgrade; specifically, a given Clash version, when based on GHC
> 8.8, has no problem synthesizing one module after another from one
> process; but the same Clash version with GHC 8.10 fails with link-time
> errors on the second compilation.
>
> The details are at https://github.com/clash-lang/clash-compiler/issues/1686
> but for now I'm just hoping that some lightbulb will go off for someone if
> some handling of internal state has changed in GHC that could mean that
> the symbol tables of loaded modules could persist between GHC invocations
> from the same process.
>
> So, does this ring a bell for anyone?
>
> Thanks,
> Gergo
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Plan for GHC 9.2

[Matthew Pickering]

My patch adding `-finfo-table-map` and `-fdistinct-constructor-tables`
is ready to review and should be included in 9.2.
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3469

There are also a one outstanding patches related to ghc-debug.
(https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4583)

Cheers,

Matt

On Thu, Feb 4, 2021 at 6:56 PM Ben Gamari  wrote:
>
>
> tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss,
>especially if you have something you would like merged for 9.2.1.
>
> Hello all,
>
> With GHC 9.0.1 at long-last out the door, it is time that we start
> turning attention to GHC 9.2. I would like to avoid making the mistake
> made in the 9.0 series in starting the fork in a state that required a
> significant amount of backporting to be releaseable. Consequently, I
> want to make sure that we have a fork schedule that is realistic given
> the things that need to be merged for 9.2. These include:
>
>  * Update haddock submodule in `master` (Ben)
>  * Bumping bytestring to 0.11 (#19091, Ben)
>  * Finishing the rework of sized integer primops (#19026, John Ericson)
>  * Merge of ghc-exactprint into GHC? (Alan Zimmerman, Henry)
>  * Merge BoxedRep (#17526, Ben)
>  * ARM NCG backend and further stabilize Apple ARM support? (Moritz)
>  * Some form of coercion zapping (Ben, Simon, Richard)
>  * Tag inference analysis and tag check elision (Andreas)
>
> If you see something that you would like to see in 9.2.1 please do
> holler. Otherwise, if you see your name in this list it would be great
> if you could let me know when you think your project may be in a
> mergeable state.
>
> Ideally we would strive for a schedule like the following:
>
> 4 February 2021:   We are here
>~4 weeks pass
> 3 March 2021:  Release branch forked
>1 week passes
> 10 March 2021: Alpha 1 released
>3 weeks pass
> 31 March 2021: Alpha 2 released
>2 weeks pass
> 14 April 2021: Alpha 3 released
>2 weeks pass
> 28 April 2021: Alpha 4 released
>1 week passes
> 5 May 2021:Beta 1 released
>1 week passes
> 12 May 2021:   Release candidate 1 released
>2 weeks pass
> 26 May 2021:   Final release
>
> This provides ample time for stabilization while avoiding deviation from
> the usual May release timeframe. However, this would require that we
> move aggressively to start getting the tree into shape since the fork
> would be less than four weeks away. I would appreciate contributors'
> thoughts on the viability of this timeline.
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Inspecting function arguments in GHCi

[Matthew Pickering]

Hi Andrew,

I  updated the README for ghc-debug last week but forget to send this mail!

https://gitlab.haskell.org/ghc/ghc-debug

Cheers,

Matt


On Wed, Jan 27, 2021 at 10:15 PM Andrew Kvapil  wrote:
>
> Hello Ben,
>
> Thanks for your suggestions. The decision to adapt GHCi came out of a
> discussion with my supervisor and his colleagues. At this point the
> entire set of desired capabilities of the work is still unknown, however
> we do consider the GHCi-compatible programs to represent a large enough
> set for future analysis, and the ease of mapping breakpoints back to
> source code is a significant benefit.
>
> I do plan on using the ghc-heap-view (I assume that's what you meant by
> ghc-heap, or is there another library I don't know about?) logic in the
> project, although I'm currently more focused on implementing the proper
> hook mechanism. I expect that events of deeply nested thunks being
> forced will be quite important. The possibility of tracking control
> flow via breakpoints/tracepoints also seems appealing. I'm not aware
> of any existing solutions which would allow dynamic tracing, although
> it's very well possible I didn't look hard enough.
>
> Regarding ghc-debug, I'm not sure what kinds of trade-offs it offers
> compared to the approach I'm currently taking. It looks like it's a
> fairly newborn project, do you think it's mature enough for the
> proposed use cases? I couldn't find docs online, although I did come
> across [0] which Discourse[1] says is related. I've yet to watch the
> introduction video. Support for unboxed tuples and other features not
> supported by GHCi would of course be nice, although performance is not
> a concern. Keeping the relationship between source code spans and
> heap objects in the infotables is an intriguing idea.
>
>  > Note that Luite's recent work on refactoring the bytecode generator to
>
>  > produce code from STG is quite relevant here. In particular, you will
>
>  > likely want to look at !4589 [1], which does the work of refactoring
>
>  > Tickish to follow the Trees That Grow pattern. You would likely want to
>
>  > do the same to capture your free variable information.
>
>
> Excellent, I was not aware of this. Thank you!
>
>
> Regards,
> Andrew
>
>
>
> [0]: https://well-typed.com/blog/2021/01/first-look-at-hi-profiling-mode/
> [1]:
> https://discourse.haskell.org/t/an-introduction-to-ghc-debug-precise-memory-analysis-for-haskell-programs/1771
>
>
> On 26/01/2021 16:28, Ben Gamari wrote:
> > Andrew Kvapil  writes:
> >
> >> Hello,
> >>
> >> I'm interested in inspecting the strictness of functions at runtime
> >> and the depth of thunks "in the wild."
> >
> > Hi Andrew,
> >
> > Interesting. When I first read your introduction my first thought was to
> > rather walk the "normal" heap using ghc-heap or, perhaps, the relatively
> > new ghc-debug library [1] rather than introduce this feature in GHCi.
> > It's hard to know whether non-GHCi-based approach is viable without
> > knowing more about what you are doing, but it potentially brings the
> > benefit of generality: your analysis is not limited to programs with can
> > be run under GHCi.
> >
> > Of course, it also brings some challenges: You would need to find a way
> > to associate info table symbols with whatever information you need of
> > from the Core program and in the presence of simplification tying your
> > results back to the source program may not be possible at all.
> >
> > Cheers,
> >
> > - Ben
> >
> >
> > [1] https://gitlab.haskell.org/ghc/ghc-debug
> >
> >> For this reason I'm modifying
> >> GHC 8.10.2, essentially to add additional information to breakpoints.
> >> I'd like to reuse the logic behind GHCi's :print command
> >> (pprintClosureCommand, obtainTermFromId, ...) for which I suppose I
> >> need Id's. Those however don't exist for destructuring patterns, such
> >> as those in the following equations:
> >>
> >>   last [x] = x
> >>   last (_:xs) = last xs
> >>
> >> So I'm wondering where would be a good place in the pipeline to
> >> transform patterns like these into at-patterns, to give them Id's.
> >> However, the breakpoint logic only looks at the free variables of the
> >> right-hand sides and not transitively, which means that e.g. in the
> >> following example neither ':print arg1' nor ':print as' works when the
> >> interpreter hits a breakpoint in the top level expression on the RHS:
> >>
> >>   qsort arg1@(a:as) = qsort left ++ [a] ++ qsort right
> >> where (left, right) = (filter (<=a) as, filter (>a) as)
> >>
> >> Thus I'd also like to know how to extend the free var logic for
> >> Tickish that eventually leads to CgBreakInfo and :print's ability to
> >> inspect these bindings at runtime. My goal would be to determine to what
> >> extent was a thunk evaluated during function application.
> >>
> > Note that Luite's recent work on refactoring the bytecode generator to
> > produce code from STG is quite relevant here. In particular, you will
> > 

Re: -ddump-json

[Matthew Pickering]

Just grepping Github there appears to be a few users of the flag but
no more than a handful. I think you can probably change it how you
like.

Cheers,

Matt

On Thu, Jan 28, 2021 at 8:20 PM Richard Eisenberg  wrote:
>
> Hi devs,
>
> In my work with Alfredo at revising our error message infrastructure, we ran 
> across some code that renders error messages as JSON. Given that our data 
> structures are changing, it seems natural to change the JSON output, too, but 
> it's unclear whether that's wise. The manual currently lists -ddump-json in 
> the chapter on "Debugging the compiler", suggesting that a change is fine, 
> but I'm not yet convinced.
>
> So:
>  - Is there someone in charge of -ddump-json? Matthew Pickering authored 
> -ddump-json in 
> https://gitlab.haskell.org/ghc/ghc/-/commit/91691117fc194c525f58ccd5b266dd1d10493e5a.
>  - Are there clients of -ddump-json?
>  - Is there a specification of -ddump-json?
>  - There will likely be a desire to evolve this feature. What is the process 
> for doing so?
>
> Thanks!
> Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Unmerged Patch: 3358

[Matthew Pickering]

Hi,

My patch 3358 needs to get merged before the 8.12 fork.

When I finished it (in May), it passed CI and after this point I
lacked time to work on it further. Now I have asked 4 times for this
patch to get merged and it is still open.

The GHC proposal for this patch already took an extortionate amount of
time to get accepted. Please can we close this chapter by merging the
patch.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: How to use the compact regions API to write a compact to a file?

[Matthew Pickering]

Ah thanks, those links are useful. I was looking in `ghc-compact` not
in the `compact` library.

Cheers,

Matt

On Fri, May 22, 2020 at 12:51 PM Shao, Cheng  wrote:
>
> Hi Matthew,
>
> It's possible to use Data.Compact.Serialize to write a compact to a
> file or read it back. Directly serializing via ByteStrings has also
> been discussed before, see link below. Hope this helps!
>
> https://hackage.haskell.org/package/compact
> https://github.com/ezyang/compact/issues/3
>
> On Fri, May 22, 2020 at 1:32 PM Matthew Pickering
>  wrote:
> >
> > Dear devs,
> >
> > I have been under the impression for a while that you can write a
> > compact region to a file and the functions in GHC.Compact.Serialized
> > also seem to suggest this is possible.
> >
> > https://hackage.haskell.org/package/ghc-compact-0.1.0.0/docs/GHC-Compact-Serialized.html
> >
> > It seems like there are some functions missing from the API. There is
> > "importCompactByteStrings"
> > but no function in the API which produces ByteStrings. So in order to
> > use this function you have to convert a SerializedCompact into a
> > ByteString, but in what specific way?
> >
> > Has anyone got any code where they have tried to do this?
> >
> > Cheers,
> >
> > Matt
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

How to use the compact regions API to write a compact to a file?

[Matthew Pickering]

Dear devs,

I have been under the impression for a while that you can write a
compact region to a file and the functions in GHC.Compact.Serialized
also seem to suggest this is possible.

https://hackage.haskell.org/package/ghc-compact-0.1.0.0/docs/GHC-Compact-Serialized.html

It seems like there are some functions missing from the API. There is
"importCompactByteStrings"
but no function in the API which produces ByteStrings. So in order to
use this function you have to convert a SerializedCompact into a
ByteString, but in what specific way?

Has anyone got any code where they have tried to do this?

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: 8.12 plans

[Matthew Pickering]

Patches I would like merged:

* Short ByteString Patch - seems stalled again
* My patches to allow compacting a ModIface - Need to put these up for review
* Make Q (TExp a) a newtype (Proposal 195
-https://github.com/ghc-proposals/ghc-proposals/pull/195) - Not yet
written but will not be a big effort

Cheers,

Matt


On Thu, May 21, 2020 at 8:48 PM Ben Gamari  wrote:
>
> Domínguez, Facundo  writes:
>
> > Hello Ben,
> >
> > Matthías Páll and I are working on an implementation of QualifiedDo [1]
> > with the aim to get it merged on time. We are trying to get a small pull
> > request submitted in the first week of June.
> >
> Thanks for the heads-up, Facundo! I've added this to the milestone.
>
> Cheers,
>
> - Ben
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Iface loading type reflection module bindings

[Matthew Pickering]

So we are clear here you are trying to store additional core bindings
other than the ones stored normally in the interface files?

It sounds like to me you might need to use `forkM` to make your custom
loading lazier.

On Sun, May 17, 2020 at 5:55 PM Josh Meredith
 wrote:
>
> Hi,
>
> In attempting to implement an extensible interface field for Core bindings 
> based
> on my previous interfaces patch, I've run into problems with deserialising the
> special type reflection `$trModule` bindings generated by 
> `GHC.Tc.Instance.Typeable.mkTypeableBinds`.
> These bindings are then stored in the `ModGuts.mg_binds` along with the real 
> exported
> top-level bindings of the module.
>
> Specifically, attempting to load the iface right-hand side expressions with
> `tcIfaceExpr` results in the error "Iface id out of scope" from 
> `GHC.Iface.Env.tcIfaceLclId`.
> My understanding is that this may be because the binding is attempting to look
> itself up within the interface loading environment, without being bound yet -
> though it's unclear to me whether this is the correct behaviour for these 
> special
> type reflection bindings, or if there's some special treatment that should be
> instead applied to load these.
>
> Any advice on how I should proceed would be greatly appreciated.
>
> Cheers,
> Josh
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Strange library git glitch

[Matthew Pickering]

Simon,

I think the issue was a missing entry in the .gitignore file. Ryan
fixed something to with that in this MR
(https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3222) but he says
it was the dist-boot rather than dist-install directory.

Matt

On Fri, May 15, 2020 at 4:03 PM Simon Peyton Jones via ghc-devs
 wrote:
>
> Thanks.  It does have a directory dist-install/ in it – but that’s put there 
> by the build system, so if I remove it, it’ll just come back.  And other 
> libraries (like deepseq) has dist-install too but does not complain.  So 
> mysterious.
>
>
>
> On the other hand git submodule update –recursive *did* fix it.  Seems odd.  
> I’m already saying “submodules” and I don’ think any submodules have further 
> submodules – or do they?
>
>
>
> Simon
>
>
>
> From: ghc-devs  On Behalf Of Hécate
> Sent: 15 May 2020 15:37
> To: ghc-devs@haskell.org
> Subject: Re: Strange library git glitch
>
>
>
> My bad, it seems like this is another issue.
>
> I found this StackOverflow page quite helpful in explaining the hows and whys:
> https://stackoverflow.com/questions/4873980/git-diff-says-subproject-is-dirty
>
> Cheers,
>
> Hécate
>
> Le 15/05/2020 à 16:30, Hécate a écrit :
>
> Hi Simon,
>
> I usually manage to get it to disappear by using `git submodule update 
> --recursive`.
> Is it a flag you've used in your previous attempts?
>
> Cheers,
>
> Hécate.
>
> Le 15/05/2020 à 16:24, Simon Peyton Jones via ghc-devs a écrit :
>
> No amount of git submodule update makes it go away.  Any ideas?
>
>
>
> ___
>
> ghc-devs mailing list
>
> ghc-devs@haskell.org
>
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Removal of UniqMap module

[Matthew Pickering]

Hi,

I noticed that the UniqMap module was removed from the tree

See 1c7c6f1afc8e7f7ba5d256780bc9d5bb5f3e7601

Why was it removed? I needed it today and now I am unsure what the
suitable replacement is.

As a general point, please can we stop with these annoying
refactorings which delete unused code
and move around definitions for no clear purpose. The amount of churn
on the code base has wasted me a lot of time recently.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [RFC] Compiler pipeline timings visualization

[Matthew Pickering]

Hi Sergej,

I definitely agree adding the capability for GHC to emit telemetry
would be useful. I also prefer the eventlog like other people has
already mentioned. We should at least ship with compiler so it can
emit these user events even if it can't emit RTS events.

In future we should probably look more into uprobes in order to make
tracing more efficient but we have what we have for now.

Recently I have been working with Dimity Ivanov on some tooling
related to this. He has implemented a standard tracing format and
exporters for many common diagnostic tools.

https://github.com/ethercrow/opentelemetry-haskell

You can see some examples of eventlogs generated by GHC in this issue:

https://github.com/ethercrow/opentelemetry-haskell/issues/9

Cheers,

Matt


On Fri, May 1, 2020 at 5:55 PM Ben Gamari  wrote:
>
> Sergej Jaskiewicz via ghc-devs  writes:
>
> > tl;dr: I propose adding a new GHC flag for generating a log that allows
> > visualizing how much time each stage in the compiler pipleline took, similar
> > to Clang's -ftime-trace.
> >
> > Hello, everyone.
>
> Hi Sergej,
>
>
> [snip]
>
> > The latter option is much closer to what we need. If we link the GHC 
> > executable
> > with the -eventlog flag, then various significant events will be written to
> > a special log file. For example, "Parser began parsing the Main.hs file 
> > after
> > 5 ms since GHC has started, and ended parsing it 3 ms after that".
> > The resulting log file can be parsed with the ghc-events library [4], and 
> > also
> > visualized using the ThreadScope app [5].
> >
> I'm a bit short on time but here are a few points in no particular order:
>
> Out of curiosity, have you seen Alp's work [1] in this area? This work
> allows use to the ghc-events-analyze package [2] to visualize (e.g. [3])
> the existing withTiming eventlog output in a reasonably easy-to-consume
> format.
>
> That being said, I can certainly see the benefit of using the Chrome
> tracing infrastructure for this; it would make for a nicer user
> experience than the static image that ghc-events-analyze spits out.
>
> I also know that Matthew Pickering has been working in this area and I'm
> sure will have something interesting to add.
>
> I will admit that I am a bit reluctant to add support for a *particular*
> tracing format to GHC itself. I think it would make the most sense for
> GHC to produce a consumer-agnostic trace representation (via our
> existing eventlog mechanism) and for users to transform this into the
> format their tools require.
>
> Our current withTimings infrastructure is quite ad-hoc and could perhaps
> expose more detail. It would be great to know what sorts of detail
> people would find useful.
>
> Cheers,
>
> - Ben
>
>
> [1] https://www.haskell.org/ghc/blog/20190924-eventful-ghc.html
> [2] https://hackage.haskell.org/package/ghc-events-analyze
> [3] https://www.haskell.org/ghc/blog/images/eventful-ghc/ghc-events-viz.svg
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Preview of new profiling mode - profile by info table

[Matthew Pickering]

Hi all,

I have hacked together a new profiling mode code named "Profile by
Info Table" which
uses the address of the info table as the band identity in the profile.

The main point of this is that you can then look up the source
location of the info table in the dwarf information when rendering the
chart.

For example, in this profile I have only included THUNK closures,
which you can reliably look up in the dwarf information. You can't
include things like constructor closures for example as every
constructor has the same info table regardless of where it comes from
in the source.

In the profiles below if you click on the Closure Descs tab you can
see the precise source position the band originated from.

As a test, I compiled the Cabal library with -O2 and here is the
result. Firstly a profile sorted by size of the bands.

https://mpickering.github.io/ghc-hi-cabal-o2.eventlog.html

I also added a mode to eventlog2html which calculates the gradient of
the line so you can more easily spot things which are leaking but not
very big themselves which might be retaining other closures.

https://mpickering.github.io/ghc-hi-cabal-o2-gradient.eventlog.html

We can see clearly here that there are calls to compute unfoldings
which remain unevaluated for a long time and therefore retaining
reference to core expressions. (See the 0x177ff78 closure for
example).

The only issue is that at the moment reading the DWARF information
takes about 48gb of memory.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Hadrian build with DWARF information doesn't contain as much debug information as I would expect

[Matthew Pickering]

Thanks Adam for the tip about dynamic linking, as always.

He was right that the debug information was in the relevant .so files
and that when I statically linked GHC the information was included (as
with cabal). The issue was my program which read the dwarf information
did not work properly for dynamically linked executables (and still
doesn't, I wonder how gdb knows which shared objects to load and what
addresses to use).

Cheers,

Matt

On Sun, May 3, 2020 at 8:20 AM Adam Sandberg Eriksson
 wrote:
>
> I don't know how you read the DWARF info but maybe it's missing info from 
> dynamic libraries? If your GHC is dynamically linked the library DWARF info 
> might be available in their respective .so's.
>
> Cheers,
> Adam Sandberg Eriksson
>
> On Sat, 2 May 2020, at 23:08, Matthew Pickering wrote:
> > I followed the instructions on the wiki to enable debug symbols in my
> > build of GHC.
> > (https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian#enabling-dwarf-debug-symbols)
> >
> > So I added these flags to may hadrian.settings file
> >
> > stage1.*.ghc.hs.opts += -g3
> > stage1.*.cabal.configure.opts += --disable-library-stripping
> > --disable-executable-stripping
> > stage1.ghc-bin.ghc.link.opts += -eventlog
> >
> > The resulting executable has debug information in it for the
> > executable component but not for any of the libraries in including the
> > compiler library.
> >
> > ("../sysdeps/x86_64/start.S",Just 4414944,Just 4414987,139633489318136)
> > ("init.c",Nothing,Nothing,139633489318136)
> > ("../sysdeps/x86_64/crti.S",Nothing,Nothing,139633489318136)
> > ("ghc/Main.hs",Just 4415312,Just 4615455,139633489318136)
> > ("ghc/GHCi/Leak.hs",Just 4615480,Just 4623414,139633489318136)
> > ("ghc/GHCi/UI.hs",Just 4623440,Just 5461990,139633489318136)
> > ("ghc/GHCi/UI/Info.hs",Just 5461992,Just 5571230,139633489318136)
> > ("ghc/GHCi/UI/Monad.hs",Just 5571232,Just 5679695,139633489318136)
> > ("ghc/GHCi/UI/Tags.hs",Just 5679696,Just 5704775,139633489318136)
> > ("ghc/GHCi/Util.hs",Just 24,Just 173,139633489318136)
> > ("../sysdeps/x86_64/crtn.S",Nothing,Nothing,139633489318136)
> >
> > I tried building a project with cabal and the resulting executable had
> > debug information for every file in the dependencies as well as the
> > main project.
> >
> > So how do I convince hadrian to include the correct information? Is it
> > a bug in hadrian?
> >
> > I checked the command line when building the library and `-g3` is passed.
> >
> > Cheers,
> >
> > Matt
> > ___
> > ghc-devs mailing list
> > ghc-devs@haskell.org
> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> >
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Hadrian build with DWARF information doesn't contain as much debug information as I would expect

[Matthew Pickering]

I followed the instructions on the wiki to enable debug symbols in my
build of GHC. 
(https://gitlab.haskell.org/ghc/ghc/-/wikis/building/hadrian#enabling-dwarf-debug-symbols)

So I added these flags to may hadrian.settings file

stage1.*.ghc.hs.opts += -g3
stage1.*.cabal.configure.opts += --disable-library-stripping
--disable-executable-stripping
stage1.ghc-bin.ghc.link.opts += -eventlog

The resulting executable has debug information in it for the
executable component but not for any of the libraries in including the
compiler library.

("../sysdeps/x86_64/start.S",Just 4414944,Just 4414987,139633489318136)
("init.c",Nothing,Nothing,139633489318136)
("../sysdeps/x86_64/crti.S",Nothing,Nothing,139633489318136)
("ghc/Main.hs",Just 4415312,Just 4615455,139633489318136)
("ghc/GHCi/Leak.hs",Just 4615480,Just 4623414,139633489318136)
("ghc/GHCi/UI.hs",Just 4623440,Just 5461990,139633489318136)
("ghc/GHCi/UI/Info.hs",Just 5461992,Just 5571230,139633489318136)
("ghc/GHCi/UI/Monad.hs",Just 5571232,Just 5679695,139633489318136)
("ghc/GHCi/UI/Tags.hs",Just 5679696,Just 5704775,139633489318136)
("ghc/GHCi/Util.hs",Just 24,Just 173,139633489318136)
("../sysdeps/x86_64/crtn.S",Nothing,Nothing,139633489318136)

I tried building a project with cabal and the resulting executable had
debug information for every file in the dependencies as well as the
main project.

So how do I convince hadrian to include the correct information? Is it
a bug in hadrian?

I checked the command line when building the library and `-g3` is passed.

Cheers,

Matt
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: "Extensible interface files" work and ANN pragmas

[Matthew Pickering]

Hi Josh,

I don't think this addresses the points mine or Zubin's email that is
it not correct to write a HIE file with a different BinHandle. If you
do this then you will end up with a HIE file which contains Names
which don't contain any SrcSpan information.

If I am misunderstanding then please forgive me.

Cheers,

Matt

On Thu, Apr 23, 2020 at 4:06 PM Josh Meredith
 wrote:
>
> Since the current HIE serialisation function writes to a BinHandle, which it 
> initialises itself, the simple way to implement the HIE field would be to 
> change the handle to an argument:
>
> writeHieFile :: FilePath -> HieFile -> IO ()
> writeHieFile hie_file_path hiefile = do
>   bh0 <- openBinMem initBinMemSize
>   -- Actual serialisation work
>
> becomes
>
> writeHieFile :: FilePath -> HieFile -> IO ()
> writeHieFile hie_file_path hiefile = do
>   bh0 <- openBinMem initBinMemSize
>   writeHie hiefile bh0
>
> writeHie :: HieFile -> BinHandle -> IO ()
> writeHie hiefile bh = do
>   -- Actual serialisation work
>
> Then the existing discrete file can continue to use writeHieFile, and the 
> field can reuse the existing implementation via writeHie:
>
> writeIfaceFieldWith :: FieldName -> (BinHandle -> IO ()) -> ModIface -> IO 
> ModIface
>
> writeHieField :: HieFile -> ModIface -> IO ModIface
> writeHieField hiefile iface = writeIfaceFieldWith "ghc/hie" (writeHie 
> hiefile) iface
>
> I hope this clarifies how I intend these more edge cases to work?
>
> Cheers,
> Josh
>
>
> On Thu, 23 Apr 2020 at 20:25, Zubin Duggal  wrote:
>>
>> Yes, Matthew is correct, the symbol table for Names used by HIE files is
>> quite distinct from the usual Iface symbol table for Names. Sharing the HIE
>> symbol table and the Iface symbol table for names will be quite tricky.
>>
>> One crucial difference is that we also save information about local names
>> to the symbol table for HIE files.
>>
>> Here is how names are stored in the HIE symbol table:
>>
>> data HieName
>>   = ExternalName !Module !OccName !SrcSpan
>>   | LocalName !OccName !SrcSpan
>>   | KnownKeyName !Unique
>>
>> And the usual symbol table(KnownKeyNames are implicitly handled as a 
>> separate case):
>>
>> type OnDiskName = (UnitId, ModuleName, OccName)
>>
>> So the merge of HIE and HI files will have to be careful about preserving 
>> these
>> semantics. For instance, the `Binary` instances for HIE file data structures 
>> use
>> putName_, which will have the wrong semantics after this merge. We could 
>> possibly
>> get around this by having ExtensibleFields be allowed to override the 
>> UserData
>> field of the BinHandle.
>>
>> Thanks to Matthew for bringing this up this important point.
>>
>> - Zubin
>>
>> On 20/04/23 09:06, Matthew Pickering wrote:
>> > I also looked at this patch briefly now and it's my understanding that
>> > the intention is to use this for HIE files as well?
>> >
>> > HIE files currently serialises Names differently to normal interface
>> > files (to also include the SrcSpan) and it wasn't clear to me that the
>> > current implementation would allow for this.
>> >
>> > Zubin/Josh could you please comment?
>> >
>> > Otherwise looks like a nice patch.
>> >
>> > Cheers,
>> >
>> > Matt
>> >
>> > On Thu, Apr 23, 2020 at 8:57 AM Ömer Sinan Ağacan  
>> > wrote:
>> > >
>> > > The "extensible interface files" [1, 2] work has been discussed at GHC 
>> > > calls a
>> > > few times and the conclusion was we were going to document why current
>> > > annotation mechanism (ANN pragmas) are insufficient and we need yet 
>> > > another way
>> > > to put stuff into interfaces.
>> > >
>> > > Unfortunately the MR was merged before that's done and so it's currently
>> > > undocumented and it's still unclear what's insufficient about ANN 
>> > > pragmas or how
>> > > the new mechanism differs.
>> > >
>> > > I'm currently working on an interface files related patch (#16885) so I 
>> > > have to
>> > > maintain both of these features now. It'd be good to know why both is 
>> > > necessary.
>> > > If ANN is no longer useful or needed could we deprecate it in favor of 
>> > > the new
>> > > mechanism and remove it in a few releases? That's help maintaining the 
>> > > code in
>> > > the future.
>> > >
>> > > Could people involved in this design and patch please document the 
>> > > thought
>> > > process here?
>> > >
>> > > Thanks,
>> > >
>> > > Ömer
>> > >
>> > > [1]: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2948
>> > > [2]: 
>> > > https://gitlab.haskell.org/ghc/ghc/-/wikis/Extensible-Interface-Files
>> > > ___
>> > > ghc-devs mailing list
>> > > ghc-devs@haskell.org
>> > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs