May 2019 - ghc-devs - Haskell.org

[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

Is cleaning up old issues worthwhile?
by Kevin Buhr 08 May '19

08 May '19

I presume I can't be the first to ask this question, but I tried searching the ghc-devs archives and didn't find anything. After accidentally clicking on the sort order button in the GitLab issue list, I found myself browsing 18-year-old open issues that are clearly obsolete (e.g., #515 related to bad source location info in LHS files long since fixed, #517 which looks like a transient issue with error messages affecting HEAD in March 2001, #519 which refers to "ghc -M" reading "import" statements from comments which I tried and failed to duplicate. etc.). I would be interested in going through some of these and triaging and closing them where appropriate. But I also don't want to be "that guy" -- you know, the person who systematically works his or her way through the wiki boldfacing all occurrences of the word "GHC" or submits 1200 merge requests to remove doubled-space-after-period occurrences in comments. So, the first question is, would working on cleaning up these issues be useful, or would it generate too much noise to be worthwhile? Second, if it *is* useful, what sort of policy/procedure would be most helpful? There are a bunch of these issues that: * have gone many years without any non-administrative activity * have clear test cases that can't be duplicated with modern GHC * don't involve any apparent unresolved technical issues I'd be pretty comfortable adding a comment documenting my failure to duplicate them and then closing them. So, that might be a good first pass. Is there any reason *not* to simply comment and close them immediately? For example, I already closed #497 and #515 on this basis. Would it be better to comment on them, maybe tag them with a new label like "issue cleanup", and have a grace period before closing them? -- Kevin Buhr <buhr(a)asaurus.net>

6 10

MR titles
by Simon Peyton Jones 08 May '19

08 May '19

Friends In this MR<https://gitlab.haskell.org/ghc/ghc/merge_requests/908>, Vlad includes the number of the ticket it fixes in the title of the MR. That is so helpful: * It links the MR back to the issue * And does so in large font (screen shot below) * And the link is clickable, even in the title. I suggest we document this in our GHC-best-practice guide, and get everyone to do it. Would you agree Simon [cid:image001.jpg@01D50583.988DEB70]

3 3

Keeping track of issues
by Simon Peyton Jones 08 May '19

08 May '19

Ben I'm struggling to establish a clear understanding of the life cycle of an issue. Consider https://gitlab.haskell.org/ghc/ghc/issues/15872. Here is my faithfully recorded chain of thought at 2330 on a Tuesday night. * I can see that it is closed * But I wonder if it was fixed? * Well, scrolling up from the bottom, apparently it was mentioned in no fewer than six patches. That's odd. Why is this issue mentioned in six patches? * Oh, one of those six patches is a dup, mentioned twice. No idea why. * Are any of the five The Patch that is designed to fix this issue. Indeed does The Patch exist at all? And what MR is it in? * Oh, what is that MR? * Hmm. Well Ryan says "I've opened MR 851". Maybe that's it? * Let's head over to MR 851: https://gitlab.haskell.org/ghc/ghc/merge_requests/851 * Oh! It just says "Closed". I was hoping it'd say "merged", but no. * Uh oh. Near the top it says "Closed by Omer"... "the changes were not merged into master". * Then scrolling further down there is a lot of noise from Marge, followed by a presumably hand-written message from Omer saying "Merged as cc495d57</ghc/ghc/commit/cc495d5777c01ef62129df15caacf87b0e430c6b>.". * Huh. So maybe it did get merged after all. You can see how confused I am. It all just feels like much more work to find relevant info than it should be. It's frustrating because all the info is in the system, -- it's just hard (for me) to find. An issue should say prominently: this is The MR (or MRs) that fixes the issue. It should be easy to tell if those MR(s) have been successfully merged - along with their commit messages (this will come Moe Bot). Trac used to let you close a ticket as "fixed" or "wont-fix" or "invalid" etc. This was Jolly Useful. Doesn't Gitlab? Similarly, MRs sould be closed as "merged" or "abandoned". Much of this is not under your control - it's what GitLab does. But maybe we should have stronger best-practice guidelines. Eg "Never just close an issue; always say "Closing as won't fix" or...". etc. Simon

2 1