- ghc-devs - Haskell.org

GHC API, GHCi, profiling, shared objects
by Matthew Pickering 16 May '19

16 May '19

Hi, If I write a program using the GHC API then the resulting executable is sensitive to the version of GHC which I used to build the program. For example, if I build a version of GHC which has profiling enabled (prof flavour) then building my application (static linking) with this version means that I can only load packages which were also built with profiling enabled. This happens in particular when you load a module which uses TemplateHaskell which causes all the dependencies to be loaded. If the so isn't built with profiling then you get errors such as ``` <command line>: can't load .so/.DLL for: libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib (dlopen(libHSblaze-html-0.9.1.1-E0enfQtU1ZTDNQ8G8pIpJp.dylib, 5): image not found) ``` This seemed to somewhat make sense to me because compiling with/without profiling changes the heap representation but then I considered whether this also happens in GHCi and I concluded that it didn't. In particular, it seems to me that 1. GHCi is not built by a profiled version of GHC and is still a "GHC API application" 2. There is no problem loading profiled packages into GHCi despite this fact? 1. Does GHCi do something special to mitigate against these kinds of failures? 2. Is this a difference between staticly and dynamically linking the application executable (`ghc` in the case for ghci). ? Hopefully someone familiar with the implementation of the linker will be able to clear this up. Cheers, Matt

1 1

clarification re Note [Deeper level on the left]
by Nicolas Frisby 16 May '19

16 May '19

https://gitlab.haskell.org/ghc/ghc/blob/master/compiler/typecheck/TcUnify.h… contains ``` Note [Deeper level on the left]~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~The most important thing is that we want to put tyvars withthe deepest level on the left. The reason to do so differs forWanteds and Givens, but either way, deepest wins! Simple.* Wanteds. Putting the deepest variable on the left maximise the chances that it's a touchable meta-tyvar which can be solved.* Givens. Suppose we have something like forall a[2]. b[1] ~ a[2] => beta[1] ~ a[2] If we orient the Given a[2] on the left, we'll rewrite the Wanted to (beta[1] ~ b[1]), and that can float out of the implication. Otherwise it can't. By putting the deepest variable on the left we maximise our changes of eliminating skolem capture. See also TcSMonad Note [Let-bound skolems] for another reason to orient with the deepest skolem on the left. IMPORTANT NOTE: this test does a level-number comparison on skolems, so it's important that skolems have (accurate) level numbers.See #15009 for an further analysis of why "deepest on the left"is a good plan.``` I'm wondering about the claim "and that can float out of the implication". The Note does go on to mention #15009 --- and I understand how that Wanted floats *with* #15009 --- but as written, it sounds like the Wanted could float even without #15009. Am I missing something? Roughly: I'm asking because I need to decide if there's a reason for my typechecker plugin to bother with "eliminating skolem capture" when #15009 does *not* apply. Thanks. -Nick

2 1

Re: CI on forked projects: Darwin woes
by Carter Schonwald 15 May '19

15 May '19

Cool. I recommend irc and devs list plus urls / copies of error messages. Hard to debug timeout if we don’t have the literal url or error messages shared ! -Carter ________________________________ From: Kevin Buhr <buhr(a)asaurus.net> Sent: Sunday, May 12, 2019 11:01 AM To: Carter Schonwald Cc: Iavor Diatchki Subject: Re: CI on forked projects: Darwin woes Thanks! I'll send a note if it starts happening again. On 5/12/19 7:23 AM, Carter Schonwald wrote: > [ . . . ] > Next time you hit a failure could you share with the devs list and or > #ghc irc ? -- Kevin Buhr <buhr(a)asaurus.net>

2 2

[hadrian] happy 1.19.10
by Shayne Fletcher 15 May '19

15 May '19

Hi Vlad, Are there imminent plans to update hadrian/stack.yaml with something like, ``` # Specifies the GHC version and set of packages available (e.g., lts-3.5, nightly-2015-09-21, ghc-7.10.2) resolver: lts-13.21 ``` I think this is necessary to get the recent happy upgrade? -- Shayne Fletcher Language Engineer c: +1 917 699 7763 e: shayne.fletcher(a)daml.com Digital Asset Holdings, LLC 4 World Trade Center 150 Greenwich Street, 47th Floor <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> New York, NY 10007, USA <https://maps.google.com/?q=150+Greenwich+Street,+47th+Floor%C2%A0+%C2%A0+%C…> digitalasset.com <http://www.digitalasset.com/> -- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html <http://www.digitalasset.com/emaildisclaimer.html>. If you are not the intended recipient, please delete this message.

2 2

Parser performance: 10% regression in 8.8
by Vladislav Zavialov 15 May '19

15 May '19

Hello ghc-devs, This February I did some changes to the parser that require higher rank types support in ‘happy’. Unfortunately, as I discovered, happy’s --coerce option is severely broken in the presence of higher rank types, so I had to disable it. My benchmarks have shown a 10% slowdown from disabling --coerce (https://gist.github.com/int-index/38af0c5dd801088dc1de59eca4e55df4 <https://gist.github.com/int-index/38af0c5dd801088dc1de59eca4e55df4>). Alongside my changes I submitted a pull request to happy which fixes the issue (https://github.com/simonmar/happy/pull/134 <https://github.com/simonmar/happy/pull/134>), in the hope that it would get merged, released, and I could re-enable --coerce in GHC ‘happy' configuration. Unfortunately, my patch has been ignored to this day (for 3 months now), and the performance regression reached 8.8-alpha. We need to act swiftly if we want to avoid a performance regression in the actual release. Here’s what needs to be done: 1. Merge https://github.com/simonmar/happy/pull/134 <https://github.com/simonmar/happy/pull/134> 2. Release a new ‘happy’ 3. (Optional) Specify in GHC’s build system that it builds only with the latest 'happy' release 4. Restore the --coerce option in GHC’s build system ‘happy’ configuration 5. Backport it to the ghc-8.8 branch I have no access to do 1 & 2, I believe Simon Marlow does. I’d appreciate if someone took care of 3, currently the build system does not install ‘happy’ and assumes a system-wide installation without checking its version. This means that users of all but the newly released version will encounter obscure error messages. We need a version check. Then I will do 4, as planned, and create a merge request for 5. All the best, - Vladislav

2 2

Commit searching
by chessai . 12 May '19

12 May '19

Devs, Is there a way to take the sha1 of a git commit and find which released version of GHC contains that commit, without resorting to a manual cross-reference? Is it possible there could be some sort of webpage where this information could be made accessible, just by pasting in a commit?

3 3

CI on forked projects: Darwin woes
by Kevin Buhr 12 May '19

12 May '19

Over the past few days, I've submitted several merge requests from branches on my forked project (mostly because I didn't even realize pushing to a branch on the main project was an alternative). When those MRs run under CI, I've had a bunch of failures due to timeouts waiting on a darwin-x86_64 runner. I was a little mystified that no other pipelines besides mine seemed to be having this problem, but I've come to understand that MRs submitted from branches on the main project use a different, larger set of runners than the shared runners used by MRs from branches on forked projects. Under my project, I can view the available shared runners under the "Settings" -> "CI/CD" -> "Runners" tab, and the problem seems to be that there's only one darwin runner ("b4bc6410" / mac-mini-x86_64-darwin-davxkc). This machine is a trooper, but it unfortunately shares a circuit breaker with a toaster oven, so it goes offline every time someone wants a bagel, and the rest of the time it must be running CI for a few hundred GHC forks. I ended up deleting an (unreviewed) MR sourced from my branch, and pushing it to the main project and resubmitting just to get the CI to run. (Admittedly, it failed, but at least not on darwin!) I obviously don't want to do this with the merge requests that have already been reviewed. Is this a temporary problem? Is there anything I can do other than keep retrying the darwin jobs every couple days? Also, is there a better place than "ghc-dev" to send these sorts of GitLab/CI issues? I thought there might be a project dedicated to it, but if so I couldn't find it. -- Kevin Buhr <buhr(a)asaurus.net>

3 2

Website for viewing proposals
by Matthew Pickering 10 May '19

10 May '19

Hi, It would be useful if there was a canonical way to link and view GHC proposals rather than relying on github's RST viewer. Can we set up a website, `ghc.haskell.org/proposals`, which is deployed to automatically when a new accepted proposal is merged? FWIW, if the proposals process was also on gitlab then doing this deployment would be easy using our CI infrastructure but I don't know how to set up something similar on github. Cheers, Matt

5 14

Question about Gitlab MR workflow.
by Iavor Diatchki 10 May '19

10 May '19

Hello, I've just had a go at making a small MR on our new Gitlab system, and I am a bit confused about the intended workflow. I was following these instructions : https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/fixing-bugs My question is about the steps after 2 (i.e., 3 and 4). Step 5 about the beer I already did :-) Here was my experience so far: 1. I made the changes I wanted yesterday over lunch: the change was quite trivial, I added a NOINLINE pragma and some comments and I mage the MR. 2. Sometime in the evening (half a day later!) I got an e-mail from the CI system that something had failed. It was quite hard to tell what had failed, and after poking around at the logs, it seemed like it was some sort of spurious failures because things had timed out, I think? 3. Today I got some feedback from a reviewer about some changes I should make to the MR. As I was working on those, I noticed that every time I push to the MR, the CI is forking a new job. I cancelled some of those manually, to save on resources, as they already seem to be taking half a day. 4. After making the changes, I noticed that Gitlab is asking me to rebase my changes because, presumably, some other things have already been merged. It is easy enough to rebase my MR, but every time I do so, this fires up a new CI job. And, of course, this is going to keep happening, until I am lucky enough to rebase just at the right time? This doesn't seem right. So my questions are specifically about step 3 and 4: About 3: wouldn't it make more sense to start firing up CI jobs only after an MR has been approved for merging? About 4: I really don't understand how this rebasing business is intended to work: every time I rebase, I new CI job is fired up. But, presumably, while this is going, other things are going to be merged with `master`, so I'd need to rebase again. So, when would I ever stop rebasing? Furthermore, in my case the rebase is trivial, but with a larger patch, doing multiple rebases seems like a lot of wasted work. Any help would be appreciated! -Iavor

7 8

Old build system broken
by Simon Peyton Jones 09 May '19

09 May '19

I know we are supposed to be using Hadrian now, but is the old build system supposed to be broken? A clean build fails with "inplace/bin/ghc-cabal" check libraries/ghc-prim "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install --with-ghc="/home/simonpj/code/HEAD/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/simonpj/code/HEAD/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --enable-shared --configure-option=CFLAGS="-Wall -Werror=unused-but-set-variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -Werror=unused-but-set-variable -Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold" --with-ar="ar" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" Configuring ghc-prim-0.6.1... ghc-cabal: '/home/simonpj/code/HEAD/inplace/bin/ghc-stage1' exited with an error: Failed to read "target arch" value "" libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/package-data.mk' failed make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 Makefile:123: recipe for target 'all' failed make: *** [all] Error 2 simonpj@MSRC-3645512:~/code/HEAD$

6 7