- ghc-devs - Haskell.org

Defining a wired-in type of a different kind
by Jan van Brügge 05 Apr '19

05 Apr '19

Hi, when trying to get familiar with the GHC code base for my Bachelor's thesis. I followed the GHC Wiki, especially the case study about the bool type. Now I wanted to add a new kind and a new type inhabiting this kind (without having to expose a data constructor, so without datatype promotion). So in TysWiredIn.hs I added the new TyCons and added them to the list of wired-in types: -- data Row a b rowKindCon :: TyCon rowKindCon = pcTyCon rowKindConName Nothing [alphaTyVar, betaTyVar] [] rowKind :: Kind rowKind = mkTyConTy rowKindCon -- data RNil :: Row a b rnilTyCon :: TyCon rnilTyCon = mkAlgTyCon rnilTyConName [] rowKind [] Nothing [] (mkDataTyConRhs []) (VanillaAlgTyCon (mkPrelTyConRepName rnilTyConName)) False rnilTy :: Type rnilTy = mkTyConTy rnilTyCon I also added two new empty data decls to ghc-prim, but if I inspect the kind of RNil it is not Row, but Type. So I think I am either understanding res_kind wrong or I have to do something completely different. I am also not sure how to verify that the code in TysWiredIn.hs is working at all, from all what I can tell it could just be the declarations in ghc-prim that result in what I see in ghci. Thank you and sorry for my beginner question Jan

5 6

Introducing bugs that are caught by slow validate?
by Ömer Sinan Ağacan 04 Apr '19

04 Apr '19

Hi all, I just run slow validate and it actually catches bugs (#16529) and some configuration problems in the test definitions (#!700). These are not caught by the CI jobs because they run normal validate instead of slow. (Actually they don't even run the validate script, but they run "test" instead of "slowtest", which I think is the main difference between normal validate and slow validate) As far as I can see we have nightly job definitions in .gitlab-ci.yml, which do slow validate, but I'm not sure if those are used? Would it be possible to switch over to slow validate in CI jobs? If slow validate takes too long on the CI servers, could we maybe configure CI tasks so that if the MR submitter is Marge, we run slow validate, otherwise we run fast validate? The problem with nightly jobs (assuming they're used) is that it's too late by the time they catch a test failure because the commits are already in the tree, and because nothing's blocked the bugs are more likely to stay unfixed. Ömer

3 2

Re: Debug printing inside the typechecker knot
by Ryan Scott 04 Apr '19

04 Apr '19

Good to know, thanks. I assume that TcMType.zonkTcTypes is to TcHsType.zonkTcTypeToTypes as TcMType.zonkTcTyVars is to TcHsType.zonkTyBndrs? Also, what exactly is the optimization that ZonkEnv performs in types? And why don't the functions in TcMType make use of this optimization? Ryan S.

2 3

Debug printing inside the typechecker knot
by Ryan Scott 04 Apr '19

04 Apr '19

I've recently found myself wanting to add some pprTrace statements in typechecker-related code but unable to do so, as the code would pull on knot-tied TyCons (leading to an infinite loop if actually ran). In particular, I want to print some code [1] in TcTyClsDecls.tcConDecl: ; (ze, tkvs) <- zonkTyBndrs tkvs ; (ze, user_tvs) <- zonkTyBndrsX ze user_tvs ; arg_tys <- zonkTcTypesToTypesX ze arg_tys ; ctxt <- zonkTcTypesToTypesX ze ctxt ; res_ty <- zonkTcTypeToTypeX ze res_ty ; let (univ_tvs, ex_tvs, tkvs', user_tvs', eq_preds, arg_subst) = rejigConRes tmpl_bndrs res_tmpl tkvs user_tvs res_ty In [2], goldfire claimed that there is a way to work around this problem now: > But you can do this. It just has to be before the final zonk. I see that rejigConRes is used after the final zonk. But there's nothing about that function that requires things be in their final state. The arguments need to be zonked, but they can be zonked by zonkTcType and friends, not zonkTcTypeToType and friends. So, for debugging: zonk everything with the functions in TcMType (not those in TcHsSyn). Then rejigConRes. Then print all the output you like. Then do the final zonk. This double-zonk is redundant, so it's not good to keep going forward, but it shouldn't cause other trouble. Unfortunately, this advice doesn't seem to pan out in practice. I started off by looking for a TcMType equivalent of this function: zonkTcTypeToTypeX :: ZonkEnv -> TcType -> TcM Type However, I am utterly unable to find anything defined in TcMType with a similar type signature. Actually, it's worse than that: there isn't a single mention of ZonkEnv anywhere in TcMType! So as far as I can tell, this advice is completely unimplementable, unless I'm missing something obvious. Any tips? Ryan S. ----- [1] https://gitlab.haskell.org/ghc/ghc/blob/51fd357119b357c52e990ccce9059c423cc… [2] https://phabricator.haskell.org/D4974#137224

2 1

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

04 Apr '19

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

3 5

RE: Help with cabal
by Simon Peyton Jones 04 Apr '19

04 Apr '19

Ah, so you installed the `cabal-install-3.0` package? Yes I attached your repo and then said apt install cabal-install and lo! cabal 3.0 appeared in /opt/cabal/bin I did this because the vanilla Ubuntu distro only had cabal 1.24. And I could not update by saying “cabal install cabal-install” because cabal 1.24 fell over with that “futex error”. In the meantime you can just keep using your current cabal 3.0 exe; does `cabal --version` currently have any noticeable startup latency for you on WSL? No, no noticeable startup latency. I’ll do the reinstall thing in a few hrs, after you’d done your update. Thanks! SImon From: Herbert Valerio Riedel <hvriedel(a)gmail.com> Sent: 04 April 2019 13:45 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: Help with cabal On Thu, Apr 4, 2019 at 2:25 PM Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: But how do I "recompile your cabal 3.0 executable with the new GHC"? The cabal-3.0 I have is (I believe) installed by apt install cabal-install and so I suppose if I "upgrade", the new 'cabal' binary will WSL'd, no? Ah, so you installed the `cabal-install-3.0` package? If so, yes, it *will* be updated to the WSL version.... in about one hour... because it turns out I forgot to push the 3.0 packages to the WSL ppa... and I've just triggered a new build of cabal 3.0 packages which will take about one hour to show up there... :-) In the meantime you can just keep using your current cabal 3.0 exe; does `cabal --version` currently have any noticeable startup latency for you on WSL?

2 1

Cannot fetch array @ 58a7ea
by autotaker 04 Apr '19

04 Apr '19

Hi devs, I pulled ghc gitlab repository by ``` git pull --recurse-submodules ``` But it failed with the following error. ``` error: Server does not allow request for unadvertised object 58a7ea0336363b29513164487190f6570b8ea834 Fetched in submodule path 'libraries/array', but it did not contain 58a7ea0336363b29513164487190f6570b8ea834. Direct fetching of that commit failed. ``` It seems the latest commit `58a7ea` of `array` library is not found on the server. Are there any help on this? Best, Taku Terao

2 2

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

04 Apr '19

simonpj@MSRC-9870733:~/tmp$ ~/code/HEAD/_build/stage0/bin/ghc --info [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","gcc") ,("C compiler flags","") ,("C compiler link flags"," -fuse-ld=gold") ,("C compiler supports -no-pie","YES") ,("Haskell CPP command","gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","ld.gold") ,("ld flags","") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","ar") ,("ar flags","q") ,("ar supports at file","YES") ,("ranlib command","ranlib") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("cross compiling","NO") ,("target os","OSLinux") ,("target arch","ArchX86_64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("target has RTS linker","YES") ,("Unregisterised","NO") ,("LLVM llc command","llc") ,("LLVM opt command","opt") ,("LLVM clang command","clang") ,("Project version","8.9.20190404") ,("Project Git commit id","51fd357119b357c52e990ccce9059c423cc49406") ,("Booter version","8.6.4") ,("Stage","1") ,("Build platform","x86_64-unknown-linux") ,("Host platform","x86_64-unknown-linux") ,("Target platform","x86_64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","YES") ,("Support SMP","YES") ,("Tables next to code","YES") ,("RTS ways","v thr") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Support Backpack","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","NO") ,("GHC Profiled","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/home/simonpj/code/HEAD/_build/stage0/lib") ,("Global Package DB","/home/simonpj/code/HEAD/_build/stage0/lib/package.conf.d") ] simonpj@MSRC-9870733:~/tmp$ From: Herbert Valerio Riedel <hvriedel(a)gmail.com> Sent: 04 April 2019 13:41 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: Re: In-tree invocation of GHC built with Hadrian Hi, I haven't tried this with Hadrian yet, but maybe the output from ~/code/HEAD/_build/stage0/bin/ghc --info might provide a hint. As for the ghc-environment theory: if there was a ghc-env file, GHC would tell you it has picked one up... On Thu, Apr 4, 2019 at 1:21 PM Simon Peyton Jones via ghc-devs <ghc-devs(a)haskell.org<mailto:ghc-devs@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<mailto:ghc-devs@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haske…>

1 0

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