- ghc-devs - Haskell.org

Compiling projects with dependencies using GHC HEAD
by Alexis King 05 Oct '19

05 Oct '19

Hi all, I have a project that I’d like to try to build with GHC HEAD, but it’s a large project with a lot of dependencies, and while there’s a lot of information on building GHC itself, I haven’t been able to find very many resources on what workflow people use to actually build projects in the wild using it. I found this wiki page, “Installing packages in your test compiler,” which has a little guidance, but the details are sparse: https://gitlab.haskell.org/ghc/ghc/wikis/debugging/installing-packages-inpl… However, I’ve been struggling to actually get my project to build using cabal-install paired with a stage 2 compiler. I realize some of this is just fundamental—various libraries need to be updated for new versions of GHC—but I’m willing to go to the effort to manually resolve those conflicts so long as I know the right way to go about doing it. One simple thing I did try (and failed at) is building an updated version of cabal-install itself using my updated GHC. From inside my checkout of the GHC repo, I tried the following: $ cd libraries/Cabal/cabal-install $ cabal --version cabal --version cabal-install version 2.4.1.0 compiled using version 2.4.1.0 of the Cabal library $ cabal --with-compiler=<path to ghc> --package-db=<path to package db> \ new-build cabal-install However, this failed to compile due to out-of-bounds versions of certain packages, so I tried again with --allow-newer: $ cabal --with-compiler=<path to ghc> --package-db=<path to package db> \ new-build cabal-install --allow-newer=base,ghc-prim,template-haskell This time, it managed to produce a build plan, but for reasons I don’t understand, both Cabal-3.1.0.0 and Cabal-2.4.1.0 are in the build plan, and the latter fails to compile against newer versions of base (due to the MonadFail changes). I tried to figure out what was causing Cabal-2.4.1.0 to end up in the build plan, but running new-build with the -v3 option didn’t seem to give me any more explanation. Apologies if this is really a request for support with cabal-install, and it doesn’t belong on this list, but I figured I’d start here, since I imagine the people on this list are best-equipped to answer questions involving using GHC HEAD. I’d appreciate any pointers or resources anyone has! Thanks, Alexis

2 4

How to work out why a data constructor is allocated using gdb?
by Matthew Pickering 04 Oct '19

04 Oct '19

Hi, I am trying to work out questions such as * Why are there thousands of Module data constructors allocated when building something with GHC * What is allocating all a lot of strings when building GHC? In order to do this I can use gdb in order to find some of the Module/String closures but then I'm a bit stuck about what to do. gdb displays a list of all the Module closures for example and then you can usually try to find the retainer for Module by using findPtr. If the retainer is a THUNK closure, it would be easy, as THUNK closures have DWARF information which maps straight to a particular line. However if the retainer is just some other data constructor, for example, the Module is stored in a Map, it's data constructors all the way up and none of them have DWARF info. I need to fall back to domain specific knowledge to work out where such a sequence of constructors might appear in my program. * Is there anything better I can do to map a constructor allocation to a more precise source location? The string closures were causing me some particular issues as `findPtr` was not showing any retainers so it's hard to work out why they are not GCd. * What situations can an object be retained but show no retainer when using findPtr? Cheers, Matt

2 3

SPAM snippets on GitLab
by Takenobu Tani 03 Oct '19

03 Oct '19

Hi Ben, devs, It looks like GHC gitlab snipeets [1] are exposed to spam. Could we control them? [1] https://gitlab.haskell.org/explore/snippets Regards, Takenobu

2 2

GitLab upgrade soon
by Ben Gamari 02 Oct '19

02 Oct '19

Hi everyone, In about 30 minutes I will start an upgrade of gitlab.haskell.org. I expect it shouldn't take long but there will be a few minutes of outage. Cheers, - Ben

1 2

GHC's module hierarchy
by Simon Peyton Jones 02 Oct '19

02 Oct '19

Dear ghc-devs hsyl20 proposes a radical overhaul of the module structure of GHC itself. He or she suggested it six months ago in https://ghc.haskell.org/trac/ghc/ticket/13009 and has now offered a monster patch https://phabricator.haskell.org/D3647 It's clearly the result of a lot of work, but I was the only one who responded on the original ticket, and it'll affect all of your lives in a very immediate way. So, would you like to * consider the idea * look at the actual re-mapping of modules hsyl20 proposals * express an opinion about whether to go ahead Probably the ticket, rather than Phab, is the best place to comment on the general idea. I'd like to thank hsyl20. GHC's rather flat module structure has grown incrementally over years. But still, there are pros and cons. Simon

2 1

How does the ambiguity check work
by Jan van Brügge 30 Sep '19

30 Sep '19

Hi lovely people, I am currently trying to wrap my head around the ambiguity check in GHC. In particular for those two instances: ``` class RowEquality where rowEqual :: Bool instance (1 ~ 2) => RowEquality where rowEqual = True instance ( ("foo" ::: Int & RNil) ~ ("bar" ::: String & "foo" ::: Int & RNil) ) => RowEquality where rowEqual = True ``` I would expect them to behave the same but the second one throws an error when trying to compile the module (*before* using `rowEqual` - that would obviously throw a type error in both cases): ``` Test.hs:24:10: error: • Could not deduce: (| "foo" :: Int |) ~ (| "bar" :: [Char], "foo" :: Int |) from the context: (("foo" ::: Int) & RNil) ~ (("bar" ::: String) & (("foo" ::: Int) & RNil)) bound by an instance declaration: ((("foo" ::: Int) & RNil) ~ (("bar" ::: String) & (("foo" ::: Int) & RNil))) => RowEquality at Test.hs:24:10-94 • In the ambiguity check for an instance declaration To defer the ambiguity check to use sites, enable AllowAmbiguousTypes In the instance declaration for 'RowEquality ``` I have troubles to understand why GHC tries to solve the constraint there. I worked through `checkAmbiguity` in `TcValidity` and the function it calls, but from what I can see is that it also tries to solve the `(1 ~ 2)` and fails in the same way as with the second one. I cannot find any reason why the two are treated differently. Thank you Jan

3 2

fragile tests
by Richard Eisenberg 26 Sep '19

26 Sep '19

Hi devs, I believe threadstatus-9333 is more fragile than it's listed as. See https://gitlab.haskell.org/rae/ghc/-/jobs/163182 <https://gitlab.haskell.org/rae/ghc/-/jobs/163182>, where I haven't been anywhere near this area of the code... Also, on a separate test, I found that compact_gc got killed. See https://gitlab.haskell.org/rae/ghc/-/jobs/163526 <https://gitlab.haskell.org/rae/ghc/-/jobs/163526>. Should these be fragile? Thanks, Richard

2 1

Tracking Progress of #7353 (New Windows IO Manager)
by Travis Whitaker 24 Sep '19

24 Sep '19

Hello Haskell friends, Even though I no longer work at a Windows shop, I've been watching https://gitlab.haskell.org/ghc/ghc/issues/7353 with great interest. Last I knew Tamar Christina was heroically hacking away on a new IO manager for Windows. Although my low-level Windows knowledge is likely insufficient for me to contribute significantly, I'd be very interested in testing the new IO manager and helping with debugging in any way I can. How might one go about building a GHC with this new Windows IO manager? Thanks, as always, for all your hard work, Travis Whitaker

2 1

What does a milestone mean?
by Matthew Pickering 24 Sep '19

24 Sep '19

Hi, It seems that basically every new issues gets triaged with the 8.10.1 milestone, what does this mean? It seems like a lot of the issue's won't get fixed for 8.10, or at any foreseeable point in the future which dilutes the milestoning. Therefore I don't think we should assign a certain milestone to a ticket unless either 1. The issue is considered necessary to fix for that milestone (ie, a regression) 2. Someone is planning to work on the ticket for that milestone (ie, a feature/improvement) Then the milestone actually has some meaning. Cheers, Matt

2 1

Filtering GitLab mentions
by Ben Gamari 24 Sep '19

24 Sep '19

Hi everyone, During a discussion on procedural matters earlier today it was (yet again) noted that GitLab notification emails are quite chatty and consequently it is easy to lose the signal in the noise. However, during this discussion we also realized that much of the issue can be mitigated with a simple email filter to identify explicit @-mentions. I find that: from:gitlab.haskell.org and @bgamari and header:X-GitLab-Discussion-Id isolates emails arising from @-mentions fairly effetively. If your MUA doesn't support filtering by arbitrary headers you can replace the "header" predicate with simply a mention of the word "commented". If you are active on GitLab I would encourage you to setup such a filter; I was surprised by how many comments I had overlooked. Cheers, - Ben

1 0