April 2019 - ghc-devs

RE: In-tree invocation of GHC built with Hadrian
by Simon Peyton Jones 04 Apr '19

04 Apr '19

No, setting GHC_ENVIRONMNT to "-" doesn't change anything tmp$ GHC_ENVIRONMENT=- ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs Foo.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 "80920190404", got "8064") | 1 | module Foo where | ^^^ | -----Original Message----- | From: Moritz Angermann <moritz.angermann(a)gmail.com> | Sent: 04 April 2019 12:47 | To: Simon Peyton Jones <simonpj(a)microsoft.com> | Subject: Re: In-tree invocation of GHC built with Hadrian | | Yes, that looks wrong indeed. It shouldn't pick up the ghc-8.6.4 library. | | After the recent env files discussion, maybe it's picking up some env | files? | It's just a wild guess though, I've never had ghc do that to me yet(!). | Does | | GHC_ENVIRONMENT=- ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs | | yield any better results? | | Cheers, | Moritz | > On Apr 4, 2019, at 7:21 PM, Simon Peyton Jones via ghc-devs <ghc- | devs(a)haskell.org> wrote: | > | > How can I run the inplace binary built by Hadrian. I tried this | > | > ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs | > | > but I got this | > | > ~/code/HEAD/_build/stage0/bin/ghc -c Foo.hs | > | > Foo.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 "80920190403", got | "8064") | > | | > 1 | module Foo where | > | ^^^ | > simonpj@MSRC-3645512:~/tmp$ | > | > Somehow the inplace binary built by Hadrian is looking for library files | in completely the wrong place. | > | > What should I do? | > | > Simon | > | > _______________________________________________ | > ghc-devs mailing list | > ghc-devs(a)haskell.org | > | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc- | devs&data=02%7C01%7Csimonpj%40microsoft.com%7C350a796ae8db4e3f8fc708d6 | b8f34549%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636899752311716865&a | mp;sdata=FCMavvoIcAGUQVO0ggOxNJwIKZw2EC%2BSbmhZFSacywg%3D&reserved=0

1 0

Help with cabal
by Simon Peyton Jones 04 Apr '19

04 Apr '19

I'm setting up my GHC builds on a new machine, and this time I'm using WSL (windows subsystem for Linux). Small problem. I've installed cabal-3.0, and say "cabal update". But I get Unexpected response 502for http://hackage.haskell.org/timestamp.json And indeed, that's what a web browser says for that same URL. What do to? Oddly, on another also-new Windows machine, I do exactly the same thing, and with 'cabal update -v' I can see that it gets the same error, but then moves on to try hackages.fpcomplete.com, which works. Why does the behaviour differ? And, at least for now, how can I get the first machine to look at hackage.fpcomplete.com? Thanks Simon

2 2

GHC label conventions
by Ben Gamari 02 Apr '19

02 Apr '19

Hello everyone, I have documented our current conventions regarding GitLab label usage on the Wiki [1]. Please do keep this up-to-date if you create, remove, or rename a label. As always, feedback is welcome Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/wikis/GitLab-Labels/

3 9

Re: GitLab conventions
by Ryan Scott 02 Apr '19

02 Apr '19

Thanks for writing these up! These will be handy references that I'm sure I'll come back to many times. Question: once I've marked my MR as "backport-needed" (and it is merged into master), whose responsibility is it to ensure that it gets merged into the latest release branch (e.g., ghc-8.8)? It it the responsibility of the person who made the MR originally, or is there a process in place for collecting these backport-needed patches into batches and merging them? Ryan S.

2 5

Gitlab email
by Simon Peyton Jones 02 Apr '19

02 Apr '19

Ben I get a lot of email from GitLab. But I miss some that I expect. In particular I've just posted a Discussion comment on https://gitlab.haskell.org/ghc/ghc/issues/16517. I expected to see that comment come to me by email. But it didn't! It's as if Gitlab sends you everyone else's comments, but not your own. Is that right? Is it a setting one can change? Thanks Simon

3 2

GitLab conventions
by Ben Gamari 01 Apr '19

01 Apr '19

Hi everyone, Today I have been working on better documenting our conventions under GitLab. This has resulted in a handful of documents: * A gitlab/issues wiki page [1], describing our triage and issue resolution workflow * A gitlab/merge-requests wiki page [2], describing our patch backport workflow * issue and merge request templates (e.g. [3] and [4]), which will be used by authors of issues and MR, respectively. If you frequent GHC's issue tracker it may be a good idea to look over the triage guide [1] to make sure you understand the implications of our many labels. Also, on the behest of Simon I propose that we start using a comment convention to note the addition of tests on issues (replacing Trac's "Test Case" field). Specifically, I suggest that a comment containing a line beginning with the token "Testsuite-tests:" followed by a series of comma-separated strings denote a set of test-cases for the issue. I have documented this here [5] If there is consensus that this is a sensible and worthwhile convention I will add these comments for the issues imported from Trac next week. Cheers, - Ben [1] https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/issues [2] https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/merge-requests [3] https://gitlab.haskell.org/ghc/ghc/blob/master/.gitlab/issue_templates/bug.… [4] https://gitlab.haskell.org/ghc/ghc/blob/master/.gitlab/merge_request_templa… [5] https://gitlab.haskell.org/ghc/ghc/wikis/gitlab/issues#marking-an-issue-as-…

1 0

Can't build HEAD with the old build system
by Ömer Sinan Ağacan 01 Apr '19

01 Apr '19

I just updated a few-days-old repo and `make` no longer works: $ make ===--- building phase 0 make --no-print-directory -f ghc.mk phase=0 phase_0_builds make[1]: Nothing to be done for 'phase_0_builds'. ===--- building phase 1 make --no-print-directory -f ghc.mk phase=1 phase_1_builds libraries/ghc-heap/ghc.mk:3: libraries/ghc-heap/dist-boot/build/.depend-v.haskell: No such file or directory libraries/ghci/ghc.mk:3: libraries/ghci/dist-boot/build/.depend-v.haskell: No such file or directory compiler/ghc.mk:437: compiler/stage1/build/.depend-v.haskell: No such file or directory "/home/omer/ghc_bins/ghc-8.6.4-bin/bin/ghc" -o utils/hsc2hs/dist/build/tmp/hsc2hs -hisuf hi -osuf o -hcsuf hc -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/hsc2hs/autogen -Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include -optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id base-4.12.0.0 -package-id containers-0.6.0.1 -package-id directory-1.3.3.0 -package-id filepath-1.4.2.1 -package-id process-1.6.5.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts -outputdir utils/hsc2hs/dist/build -static -H32m -O -Wall -package-db libraries/bootstrapping.conf -hide-all-packages -i -iutils/hsc2hs/. -iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/hsc2hs/autogen -Iutils/hsc2hs/dist/build/hsc2hs/autogen -optP-include -optPutils/hsc2hs/dist/build/hsc2hs/autogen/cabal_macros.h -package-id base-4.12.0.0 -package-id containers-0.6.0.1 -package-id directory-1.3.3.0 -package-id filepath-1.4.2.1 -package-id process-1.6.5.0 -Wall -XHaskell2010 -no-user-package-db -rtsopts utils/hsc2hs/dist/build/Main.o utils/hsc2hs/dist/build/C.o utils/hsc2hs/dist/build/Common.o utils/hsc2hs/dist/build/CrossCodegen.o utils/hsc2hs/dist/build/DirectCodegen.o utils/hsc2hs/dist/build/Flags.o utils/hsc2hs/dist/build/HSCParser.o utils/hsc2hs/dist/build/ATTParser.o utils/hsc2hs/dist/build/UtilsCodegen.o utils/hsc2hs/dist/build/Compat/ResponseFile.o utils/hsc2hs/dist/build/Paths_hsc2hs.o /usr/bin/ld.gold: internal error in find_view, at ../../gold/fileread.cc:336 collect2: error: ld returned 1 exit status `gcc' failed in phase `Linker'. (Exit code: 1) utils/hsc2hs/ghc.mk:21: recipe for target 'utils/hsc2hs/dist/build/tmp/hsc2hs' failed make[1]: *** [utils/hsc2hs/dist/build/tmp/hsc2hs] Error 1 Makefile:123: recipe for target 'all' failed make: *** [all] Error 2 I tried a custom build.mk and with no build.mk, got the same error either way. I also tried to build with hadrian and it worked. Is anyone here able to build with the old build system? If this is about my system, any ideas what might be the problem? Ömer

4 8

Newtypes in STG
by Christopher Done 01 Apr '19

01 Apr '19

Hi all, Could you offer some insight into newtypes at the STG level? Here’s the context: 1. I’m working on this interpreter for STG (https://github.com/chrisdone/prana) and I’m trying to generate a pristine AST where all names in it are resolved to something known to me. 2. I’ve compiled ghc-prim and integer-gmp without issue, and I’m compiling base and there remains one last frontier which is newtypes. These are the culprits pointed out if I compile base: chris@precision:~/Work/chrisdone/prana/ghc-8.4/libraries/base-4.11.1.0$ PRANA_INDEX=../prana.idx stack build --exec './Setup build --ghc-options=-O0' --file-watch Preprocessing library for base-4.11.1.0.. Building library for base-4.11.1.0.. [1 of 244] Compiling GHC.Base [2 of 244] Compiling GHC.IO [3 of 244] Compiling GHC.Real [4 of 244] Compiling Data.Semigroup.Internal ... [snip] ... [242 of 244] Compiling Data.Functor.Compose [243 of 244] Compiling Data.Fixed [244 of 244] Compiling Data.Complex Errors in Data.Foldable: Variable name not found: base:Data.Semigroup.Internal.All Variable name not found: base:Data.Semigroup.Internal.Any Errors in Foreign.Marshal.Pool: Variable name not found: base:Foreign.Marshal.Pool.Pool Errors in GHC.ExecutionStack.Internal: Variable name not found: base:GHC.ExecutionStack.Internal.StackTrace Errors in Data.Bifoldable: Variable name not found: base:Data.Semigroup.Internal.All Variable name not found: base:Data.Semigroup.Internal.Any Errors in System.Timeout: Variable name not found: base:System.Timeout.Timeout Errors in Data.Data: Variable name not found: base:Foreign.Ptr.WordPtr Variable name not found: base:Foreign.Ptr.IntPtr Variable name not found: base:Data.Semigroup.Internal.Any Variable name not found: base:Data.Semigroup.Internal.All I looked these up, and they all appear to be *uses* of a newtype. For example, in the Timeout function: http://hackage.haskell.org/package/base-4.12.0.0/docs/src/System.Timeout.ht… I printed out the full [StgTopBinding] list and got: let { sat_s27NC [Occ=Once] :: IO Timeout [LclId] = [] \u [] fmap $fFunctorIO Timeout newUnique; } in >>= $fMonadIO sat_s27NC sat_s27NT; Oddly (or not?), they’re used as values, not constructors. This error comes from this part of my code: StgSyn.StgApp occ arguments -> AppExpr <$> lookupSomeVarId occ <*> traverse fromStgGenArg arguments If it was used as a constructor, it’d appear in this position, where looking up the ID would produce a “Data constructor name not found” error: StgSyn.StgConApp dataCon arguments types -> ConAppExpr <$> lookupDataConId dataCon <*> traverse fromStgGenArg arguments <*> pure (map (const Type) types) My understanding of newtypes at this stage is hazy. It seems like: - They ought to be erased and replaced with coercions by now. If they’re not replaced, it’s because they’re in a not-quite-id position like fmap Timeout .... (Arguably these could be fixed in base with a Data.Coerce.coerce?) - However, the CoreTidy/PrepPgm processing modules don’t seem to have removed or replaced these, or introduced a binding that would do something. At this stage what would you recommend? At this point type-checking is done, and I only care about interpreting the code. So I suppose they could be id for all it matters to the interpreter? I imagine they aren’t actually supposed to allocate something here. And I’m certain that any pattern matching on a newtype is also erased away by this point. Cheers! Chris

3 4