April 2019 - ghc-devs

RE: Puzzled by GHC.Types.LiftedRep
by Simon Peyton Jones 24 Apr '19

24 Apr '19

Try this paper<https://www.microsoft.com/en-us/research/publication/levity-polymorphism/> The function type constructor actually has type (->) :: forall (r1::RuntimeRep) (r2::RuntimeRep). TYPE r1 -> TYPE r2 -> TYPE LiftedRep But when it appears applied to two argument, thus ((->) r1 r2 t1 t2), we print it infix (t1 -> t2). So (-> 'GHC.Types.LiftedRep 'GHC.Types.LiftedRep thing thing) is the same as (thing -> thing). I cannot explain why it is being printed in that non-infix way, but your email doesn’t give enough context to know. I hope this helps a bit. Where did you look for information? I’d like to add pointers that would have been helpful to you. Simon From: Ranjit Jhala <jhala(a)cs.ucsd.edu> Sent: 24 April 2019 04:56 To: ghc-devs(a)haskell.org; Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Puzzled by GHC.Types.LiftedRep Hi all, Consider the following program: ``` import Control.Arrow (second) import qualified Control.Monad.Trans.Reader as R myLocal :: (r -> r) -> R.ReaderT r m a -> R.ReaderT r m a myLocal = undefined foo :: (thing -> thing) -> R.ReaderT (d, thing) m a -> R.ReaderT (d, thing) m a foo arg = myLocal (second arg) ``` When compiled with GHC 8.6.4, I get the odd behavior that at the call `second arg`, the type of `arg` is just: thing -> thing but the *input* type of `second` (after applying the various type and dictionary parameters) is something that looks like while the *input* type of `second` (after the various type and dictionary applications etc.) is the mysterious (to me): (-> 'GHC.Types.LiftedRep 'GHC.Types.LiftedRep thing thing) Can someone explain or point me to some documentation or paper that describes what the above means? Specifically, how/why does GHC "equate" the two things above in order to consider the core well-formed? Many thanks in advance! - Ranjit.

1 0

[ANNOUNCE] GHC 8.6.5 is now available
by Ben Gamari 24 Apr '19

24 Apr '19

Hello everyone, The GHC team is proud to announce the release of GHC 8.6.5. The source distribution, binary distributions, and documentation are available at https://downloads.haskell.org/~ghc/8.6.5 Release notes are also available [1]. This release fixes a handful of issues with 8.6.4: - Binary distributions once again ship with Haddock documentation including syntax highlighted source of core libraries (#16445) - A build system issue where use of GCC with `-flto` broke `configure` was fixed (#16440) - An bug affecting Windows platforms wherein XMM register values could be mangled when entering STG has been fixed (#16514) - Several Windows packaging issues resulting from the recent CI rework. (#16408, #16398, #16516) Do note that due to linking issues (see #15934) profiling will be rather unreliable on Windows. This will be fixed in 8.8.1. As always, if anything looks amiss do let us know. Happy compiling! Cheers, - Ben [1] http://downloads.haskell.org/~ghc/8.6.5/docs/html/users_guide/8.6.5-notes.h…

2 1

build .so from boot libraries
by Németh Boldizsár 16 Apr '19

16 Apr '19

Hi, I'm trying to run compiler plugins on the source code of GHC itself. (Has anyone done this before?) Somehow this forces the loading of .so files of boot libraries (like libHSterminfo-0.4.1.3.so and libHSghc-boot-th-8.9.so) during GHC's compilation. The .so files are not built at this stage (only in later stages) by default. Is there an option to create dynamically linked libraries from the boot libraries in stage 0? BR, Boldizsár

2 1

Cabal woes
by Simon Peyton Jones 16 Apr '19

16 Apr '19

I'm trying to install 'hspec' on my WSL (Windows subsystem for Linux) system. But I fail; see below. For some reason cabal complains about installing a library. (That seems peculiar - isn't that what cabal is for?) But it helpfully suggests adding -lib. Alas, cabal then crashes outright, which should never happen. So I'm stuck. What should I do? Thanks Simon simonpj@MSRC-9870733:~$ cabal --version cabal-install version 3.0.0.0 compiled using version 3.0.0.0 of the Cabal library simonpj@MSRC-9870733:~$ cabal install hspec Resolving dependencies... Up to date Warning: You asked to install executables, but there are no executables in target: hspec. Perhaps you want to use --lib to install libraries instead. simonpj@MSRC-9870733:~$ cabal install --lib hspec Resolving dependencies... Up to date Distribution/Simple/GHC.hs:1959:5-56: Irrefutable pattern failed for pattern Just ghcPkgProg simonpj@MSRC-9870733:~$ which ghc /opt/ghc/bin/ghc simonpj@MSRC-9870733:~$ which ghc-pkg /opt/ghc/bin/ghc-pkg simonpj@MSRC-9870733:~$

7 17

RE: Hadrian
by Andrey Mokhov 16 Apr '19

16 Apr '19

Hi all, Here is a patch for generating wrapper scripts from Hadrian: https://gitlab.haskell.org/ghc/ghc/merge_requests/780 While it's being reviewed and merged, you can create script `<build-root>/ghc-stage1` with the following line yourself: "_build/stage0/bin/ghc.exe" "-package-db _build/stage1/lib/package.conf.d" "$@" It works for me, e.g. I can do ================ $ _build/ghc-stage1 helloWorld.hs [1 of 1] Compiling Main ( helloWorld.hs, helloWorld.o ) Linking helloWorld.exe ... $ ./helloWorld.exe Hello World ================ Cheers, Andrey -----Original Message----- From: Simon Peyton Jones [mailto:simonpj@microsoft.com] Sent: 15 April 2019 14:37 To: Moritz Angermann <moritz(a)lichtzwerge.com> Cc: Matthew Pickering <matthewtpickering(a)gmail.com>; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; ghc-devs(a)haskell.org Subject: RE: Hadrian sounds good to me! | -----Original Message----- | From: Moritz Angermann <moritz(a)lichtzwerge.com> | Sent: 15 April 2019 14:29 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Cc: Matthew Pickering <matthewtpickering(a)gmail.com>; Andrey Mokhov | <andrey.mokhov(a)newcastle.ac.uk>; ghc-devs(a)haskell.org | Subject: Re: Hadrian | | I guess we could add | | $root/ghc-stage1 (shell script) | $root/ghc-stage2 (shell script) | | As long as we understand that those are just convenience scripts. | | Why $root? Because we can have multiple build directories for different | configurations. Thus putting the scripts into the ghc folder would not | know which root you wanted. This for the default root this would be: | | _build/ghc-stage1 | _build/ghc-stage2 | | Does that sound like an intermittent solution? | | Cheers, | Moritz | | Sent from my iPhone | | > On 15 Apr 2019, at 8:47 AM, Simon Peyton Jones via ghc-devs <ghc- | devs(a)haskell.org> wrote: | > | > Ah. I hadn't even tried the stage2 compiler (in the stage1/ directory). | Yes, that works. But perhaps a script to get to it would be helpful, | otherwise invoking stage1 will look entirely different to invoking stage2. | Not a bid deal, I grant you! | > | > S | > | > | -----Original Message----- | > | From: Matthew Pickering <matthewtpickering(a)gmail.com> | > | Sent: 15 April 2019 13:40 | > | To: Simon Peyton Jones <simonpj(a)microsoft.com> | > | Cc: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; | > | ghc-devs(a)haskell.org | > | Subject: Re: Hadrian | > | | > | Does the stage2 compiler which is found in `stage1/bin/ghc` not | > | work for you? I thought the issue was that the stage1 compiler | doesn't work. | > | | > | Matt | > | | > | On Mon, Apr 15, 2019 at 1:11 PM Simon Peyton Jones via ghc-devs | > | <ghc- devs(a)haskell.org> wrote: | > | > | > | > as a temporary workaround we could create a top-level wrapper | > | script, say `ghc-stage1.sh` that will call Stage1 GHC with the | > | right arguments, just like Hadrian itself does during the build. | > | > | > | > That sound fine, thanks. Same for ghc-stage2.sh? | > | > | > | > My difficulty is that as of today I simply do not know how to | > | invoke my freshly built GHC! | > | > | > | > Simon | > | > | > | > | > | > | > | > From: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> > Sent: 15 | > | April 2019 12:53 > To: Simon Peyton Jones <simonpj(a)microsoft.com> | > | > Cc: ghc-devs(a)haskell.org > Subject: RE: Hadrian > > > > Hi | > | Simon, > > Apologies it’s taking so long. It’s not obvious how to | > | fix this properly, and as a temporary workaround we could create a | > | top-level wrapper script, say `ghc-stage1.sh` that will call Stage1 | > | GHC with the right arguments, just like Hadrian itself does during | > | the build. | > | > | > | > Will this work for you? | > | > | > | > Cheers, | > | > Andrey | > | > | > | > | > | > | > | > From: Simon Peyton Jones [mailto:simonpj@microsoft.com] > Sent: | > | 15 April 2019 12:28 > To: Andrey Mokhov | > | <andrey.mokhov(a)newcastle.ac.uk> > Cc: ghc-devs(a)haskell.org > | > | Subject: Hadrian > > > > Andrey and other Hadrian heros > > | > | Just to say that I am 100% stalled on using Hadrian because the > | > | in-tree binary uses the wrong library files. I reported this a few | > | > weeks ago, but it still seems unchanged > > Simon > > > > | > | Bash$ ~/code/HEAD/_build/stage0/bin/ghc --version > > The Glorious | > | Glasgow Haskell Compilation System, version > 8.9.0.20190414 > > | > | simonpj@MSRC-3645512:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc -c > | > | T16566.hs > > > > T16566.hs:1:8: error: | > | > | > | > Bad interface file: | > | > /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi | > | > | > | > mismatched interface file versions (wanted "809020190414", | got | > | > "8064") | > | > | > | > | | > | > | > | > 1 | module T16566 where | > | > | > | > | ^^^^^^ | > | > | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs(a)haskell.org | > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | > | > | > | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C | > | 01 > | > | %7Csimonpj%40microsoft.com%7Cdf9439b6d848493aca9608d6c19f79f6%7C72f9 | > | 88 > | > | bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909288021992421&sdata=dd | > | sV > pnCFLP4D7dGqPtuMdv3oahBrOvRWVDlOV2GSwBU%3D&reserved=0 | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

Near-daily "Remote mirror update failed" e-mails from GitLab
by Ryan Scott 15 Apr '19

15 Apr '19

Almost every day now I receive an e-mail from GitLab titled "Remote mirror update failed", which contains something like: To ! [remote rejected] wip/dmd-arity -> wip/dmd-arity (cannot lock ref 'refs/heads/wip/dmd-arity': is at e1cc1254b81a7adadd8db77c7be625497264ab2b but expected f07b61d047967129a3ae0c56f8894d41c5a9b036) error: failed to push some refs to '[FILTERED](a)github.com/ghc/ghc' Is there a way to make these stop? Ryan S.

3 5

Proposal section numbering messed up
by Simon Peyton Jones 15 Apr '19

15 Apr '19

Why does this proposal https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0036-k… start with Section 36? (It is proposal 36.) Lots of other proposals do this too. Can it be fixed? Thanks Simon

3 3

RE: Hadrian
by Simon Peyton Jones 15 Apr '19

15 Apr '19

sounds good to me! | -----Original Message----- | From: Moritz Angermann <moritz(a)lichtzwerge.com> | Sent: 15 April 2019 14:29 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Cc: Matthew Pickering <matthewtpickering(a)gmail.com>; Andrey Mokhov | <andrey.mokhov(a)newcastle.ac.uk>; ghc-devs(a)haskell.org | Subject: Re: Hadrian | | I guess we could add | | $root/ghc-stage1 (shell script) | $root/ghc-stage2 (shell script) | | As long as we understand that those are just convenience scripts. | | Why $root? Because we can have multiple build directories for different | configurations. Thus putting the scripts into the ghc folder would not | know which root you wanted. This for the default root this would be: | | _build/ghc-stage1 | _build/ghc-stage2 | | Does that sound like an intermittent solution? | | Cheers, | Moritz | | Sent from my iPhone | | > On 15 Apr 2019, at 8:47 AM, Simon Peyton Jones via ghc-devs <ghc- | devs(a)haskell.org> wrote: | > | > Ah. I hadn't even tried the stage2 compiler (in the stage1/ directory). | Yes, that works. But perhaps a script to get to it would be helpful, | otherwise invoking stage1 will look entirely different to invoking stage2. | Not a bid deal, I grant you! | > | > S | > | > | -----Original Message----- | > | From: Matthew Pickering <matthewtpickering(a)gmail.com> | > | Sent: 15 April 2019 13:40 | > | To: Simon Peyton Jones <simonpj(a)microsoft.com> | > | Cc: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; | > | ghc-devs(a)haskell.org | > | Subject: Re: Hadrian | > | | > | Does the stage2 compiler which is found in `stage1/bin/ghc` not | > | work for you? I thought the issue was that the stage1 compiler | doesn't work. | > | | > | Matt | > | | > | On Mon, Apr 15, 2019 at 1:11 PM Simon Peyton Jones via ghc-devs | > | <ghc- devs(a)haskell.org> wrote: | > | > | > | > as a temporary workaround we could create a top-level wrapper | > | script, say `ghc-stage1.sh` that will call Stage1 GHC with the | > | right arguments, just like Hadrian itself does during the build. | > | > | > | > That sound fine, thanks. Same for ghc-stage2.sh? | > | > | > | > My difficulty is that as of today I simply do not know how to | > | invoke my freshly built GHC! | > | > | > | > Simon | > | > | > | > | > | > | > | > From: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> > Sent: 15 | > | April 2019 12:53 > To: Simon Peyton Jones <simonpj(a)microsoft.com> | > | > Cc: ghc-devs(a)haskell.org > Subject: RE: Hadrian > > > > Hi | > | Simon, > > Apologies it’s taking so long. It’s not obvious how to | > | fix this properly, and as a temporary workaround we could create a | > | top-level wrapper script, say `ghc-stage1.sh` that will call Stage1 | > | GHC with the right arguments, just like Hadrian itself does during | > | the build. | > | > | > | > Will this work for you? | > | > | > | > Cheers, | > | > Andrey | > | > | > | > | > | > | > | > From: Simon Peyton Jones [mailto:simonpj@microsoft.com] > Sent: | > | 15 April 2019 12:28 > To: Andrey Mokhov | > | <andrey.mokhov(a)newcastle.ac.uk> > Cc: ghc-devs(a)haskell.org > | > | Subject: Hadrian > > > > Andrey and other Hadrian heros > > | > | Just to say that I am 100% stalled on using Hadrian because the > | > | in-tree binary uses the wrong library files. I reported this a few | > | > weeks ago, but it still seems unchanged > > Simon > > > > | > | Bash$ ~/code/HEAD/_build/stage0/bin/ghc --version > > The Glorious | > | Glasgow Haskell Compilation System, version > 8.9.0.20190414 > > | > | simonpj@MSRC-3645512:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc -c > | > | T16566.hs > > > > T16566.hs:1:8: error: | > | > | > | > Bad interface file: | > | > /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi | > | > | > | > mismatched interface file versions (wanted "809020190414", | got | > | > "8064") | > | > | > | > | | > | > | > | > 1 | module T16566 where | > | > | > | > | ^^^^^^ | > | > | > | > _______________________________________________ | > | > ghc-devs mailing list | > | > ghc-devs(a)haskell.org | > | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail. | > | > | > | haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-devs&data=02%7C | > | 01 > | > | %7Csimonpj%40microsoft.com%7Cdf9439b6d848493aca9608d6c19f79f6%7C72f9 | > | 88 > | > | bf86f141af91ab2d7cd011db47%7C1%7C0%7C636909288021992421&sdata=dd | > | sV > pnCFLP4D7dGqPtuMdv3oahBrOvRWVDlOV2GSwBU%3D&reserved=0 | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

1 0

RE: Hadrian
by Andrey Mokhov 15 Apr '19

15 Apr '19

Hi Simon, Apologies it's taking so long. It's not obvious how to fix this properly, and as a temporary workaround we could create a top-level wrapper script, say `ghc-stage1.sh` that will call Stage1 GHC with the right arguments, just like Hadrian itself does during the build. Will this work for you? Cheers, Andrey From: Simon Peyton Jones [mailto:simonpj@microsoft.com] Sent: 15 April 2019 12:28 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Cc: ghc-devs(a)haskell.org Subject: Hadrian Andrey and other Hadrian heros Just to say that I am 100% stalled on using Hadrian because the in-tree binary uses the wrong library files. I reported this a few weeks ago, but it still seems unchanged Simon Bash$ ~/code/HEAD/_build/stage0/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 8.9.0.20190414 simonpj@MSRC-3645512:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc -c T16566.hs T16566.hs:1:8: error: Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi mismatched interface file versions (wanted "809020190414", got "8064") | 1 | module T16566 where | ^^^^^^

3 3

Hadrian
by Simon Peyton Jones 15 Apr '19

15 Apr '19

Andrey and other Hadrian heros Just to say that I am 100% stalled on using Hadrian because the in-tree binary uses the wrong library files. I reported this a few weeks ago, but it still seems unchanged Simon Bash$ ~/code/HEAD/_build/stage0/bin/ghc --version The Glorious Glasgow Haskell Compilation System, version 8.9.0.20190414 simonpj@MSRC-3645512:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc -c T16566.hs T16566.hs:1:8: error: Bad interface file: /opt/ghc/8.6.4/lib/ghc-8.6.4/base-4.12.0.0/Prelude.hi mismatched interface file versions (wanted "809020190414", got "8064") | 1 | module T16566 where | ^^^^^^

1 0