- ghc-devs - Haskell.org

No email from gitlab
by Matthew Pickering 01 Feb '19

01 Feb '19

Hi all, I stopped getting emails from gitlab about 12 hours ago. Anyone know what is going on? Cheers, Matt

2 1

Thoughts on the Contributing page
by Ben Gamari 31 Jan '19

31 Jan '19

For those following along at home: David has been looking at revising our contributor documentation. He has started consolidating a variety of relevant content on the Contributing page of the Wiki [1]. Below are my thoughts; feel free to chime in with your own. David, The contributing page is looking quite good. However, I do wonder whether we could reduce the link "fan-out" a bit more: it still rather feels like a collection of links with no clear "beginning". The "Newcomers to GHC" section is a great start but I see two potential issues: * we don't clearly articulate the precise steps that a newcomer will need to take * the first thing we mention are four links which, while useful, constitute a significant volume of reading for a newcomer. I fear we may lose people at this point. Regarding the second point, I think that WorkingConventions/FixingBugs is a good model in that it clearly lists a series of concrete steps that the contributor should take. Admittedly, I think some of the detail should be dropped or moved (e.g. the mention of setting git's user.name variable is likely unnecessary in 2019). I think that something similar to this list should be the first thing one sees when they reach the contributing page. Ideally the "typical" case of a new contributor wanting to submit their first patch would be able to gather everything they need to get started in one or two screenfuls of text. After that prose can come additional links to more in-depth documentation. Other various issues I noticed: * We link to wiki:WorkingConventions from a variety of places (including wiki:Contributing) but it is now just a link to wiki:Contributing. * wiki:WorkingConventions/FixingBugs still has references to Phabricator. In general we should start culling such references. * wiki:WorkingConventions/FixingBugs also has references to Trac documentation. We should try to replace these with the relevant GitLab documentation when we migrate. * wiki:WorkingConventions/FixingBugs should be updated to reflect that GitLab CI is now the source of truth for validation. * I don't know exactly how this should look but I think we need to do a better job of concisely stating what we expect of contributions. That is: * commit messages should be readable and discuss what the patch does. "Fixes #NNNN" is not an adequate commit message. * changes should be commented where necessary (my usual rule of thumb is "write the comment you would have liked to read when you started writing your patch"). We should mention the Note convention. * commit messages and comments should refer to ticket numbers where appropriate (e.g. using usual #NNNN syntax; people often get this wrong). * commits should be either squashed or logically distinct, individually buildable changes. * changes to most of `base` need to go through the CLC (this may be optional as defining what set of `base` this applies to is a bit tricky; in the interest of keeping things concise we may be better off handling this personally on a case-by-case basis) * code changes should conform to GHC's (somewhat fluid, for better or worse) code style (https://ghc.haskell.org/trac/ghc/wiki/Commentary/CodingStyle) * thought should be given to testing Having a document which succinctly summarised these expectations as we could easily refer to it during code review. Even better, we could excerpt it as a checklist in our merge request description template (I have put up an initial attempt at this as !149). Anyways, there is more to be said here but this email is getting a bit long so let's leave it for future discussions. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Contributing

5 13

RE: Thoughts on the Contributing page
by Andrey Mokhov 30 Jan '19

30 Jan '19

Andreas, Alp: > > - On windows build.bat defaults to stack which I think has never > > worked on my box. > Andrey? (cc'd him) Actually `build.bat` calls the Cabal-based build script. This was a relatively recent change, and we plan to stick to it in the long term, while still providing an alternative `build.stack.bat`. > There are also a few quality of life issues like ctrl+c not canceling > the build on windows. > Which I hope will be resolved at some point but not sure if these > should be showstoppers. Indeed. I hope it's not difficult to fix this, but I'm not sure where to start. Any suggestions are very welcome. Cheers, Andrey

2 1

Re: Thoughts on the Contributing page
by Andreas Klebinger 30 Jan '19

30 Jan '19

On hadrian: Documentation will eventually catch up as more people use hadrian but imo things that need to be supported are: - Some workflows: * make fast * ./validate * make EXTRA_HC_OPTS="..." - On windows build.bat defaults to stack which I think has never worked on my box. - It's still too easy to run into hadrian bugs imo, which will probably work itself out in a few months. There are also a few quality of life issues like ctrl+c not canceling the build on windows. Which I hope will be resolved at some point but not sure if these should be showstoppers. ghc-devs-request(a)haskell.org schrieb: > One more thought I'd like to throw out in the open here: > > The current Newcomers' Guide uses the current Makefile workflow, but > this is on a fast track to deprecation - but then, I doubt Hadrian has > seen enough exposure yet to use for a good beginner-friendly "Just > Works" guide. I'm leaning towards sticking with make for now, also > because existing material is already written this way; and then once > Hadrian is truly ready for prime time, we can rewrite the relevant > parts. > > Thoughts?

2 1

Why are nested brackets disallowed?
by Matthew Pickering 30 Jan '19

30 Jan '19

There is a check in `RnSplice` which errors on the following program with nested brackets. ``` prog = [| [| True |] |] T.hs:4:11: error: • Template Haskell brackets cannot be nested (without intervening splices) • In the Template Haskell quotation [| True |] In the Template Haskell quotation [| [| True |] |] | 4 | prog = [| [| True |] |] | ^^^^^^^^^^ ``` As far as I can see the check was added in 2013 in this commit, https://github.com/ghc/ghc/commit/d0d47ba76f8f0501cf3c4966bc83966ab38cac27#… But there is no note, no tests and no comment about why it was added. I removed the check and added a `BracketE` constructor to the template-haskell AST and the code compiles fine. I can also construct a program which needs to be spliced twice and this also works fine. ``` func Add = [| (+) |] func Mul = [| (*) |] f1 "+" = [| Add |] f1 "*" = [| Mul |] comb s = [| func $(f1 s) |] ``` ``` res = $($(comb "*")) ``` So it seems the restriction is quite arbitrary but I was wondering if I was missing some limitation which meant this check was added. I would not be surprised if something more complicated goes wrong with splicing. Cheers, Matt

4 8

hcs2hs failure
by Simon Peyton Jones 30 Jan '19

30 Jan '19

Is anyone else seeing this in a GHC build utils/hsc2hs/HSCParser.hs:170:14: error: [-Wunused-matches, -Werror=unused-matches] Defined but not used: 'd' | 170 | '\'':d:'\'':_ -> do any3Chars_; text -- Case 2 | ^ Indeed, d looks unused. But this line of code has been there since 28 Dec, so I can't understand why it has not bitten before. With -Werror my build fails. I could switch to -Wwarn, but I think -Werror is the default. Simon

2 1

RE: [ANNOUNCE] You should try Hadrian
by Andrey Mokhov 29 Jan '19

29 Jan '19

Hi Tamar, Here is the relevant bullet point from the README: > On Windows, if you do not want to install MSYS, you can > use the Stack-based build script (Stack provides a managed > MSYS environment), as described in these instructions. > If you don't mind installing MSYS yourself or already have it, > you can use the Cabal-based build script. As you can see, `doc/windows.md` is recommended for people who “do not want to install MSYS”. Perhaps, the wording is not clear enough – please feel free to suggest improvements. > In order for ./boot and configure to work already you need to > be in an msys2 environment. Yes, and Stack provides it. This means, if you follow instructions in this file, you don’t need to install MSYS yourself. > There's a dubious claim there that using stack is > "more robust", what is this claim based on? This claim is based on my experience. Installing the MSYS environment has never worked out smoothly for me. Doing this via Stack was indeed more robust (especially, when struggling with building GHC on Windows CI!). Has this been different in your experience? > I'm just confused when it was decided to switch the defaults, > and why, without any consultation. I’m not sure what you mean. Could you clarify? The file `doc/windows.md` is 3 years old and hasn’t changed much since creation. The default build script `build.bat` currently uses Cabal: ``` rem By default on Windows we build Hadrian using Cabal hadrian/build.cabal.bat %* ``` P.S.: I’ve just noticed that `doc/windows.md` hasn’t been updated when moving to GitLab, and created this MR to fix this: https://gitlab.haskell.org/ghc/ghc/merge_requests/239 Please jump into the comments there if you’d like me to fix/clarify anything. Thanks for reaching out! Cheers, Andrey From: Phyx [mailto:lonetiger@gmail.com] Sent: 27 January 2019 21:11 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Ben Gamari <ben(a)well-typed.com> Cc: GHC developers <ghc-devs(a)haskell.org> Subject: Re: [ANNOUNCE] You should try Hadrian Hi Andrey, I'm looking at https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/README.md and https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/windows.md wondering why the default instructions for Windows are using stack, this isn't currently the case. In order for ./boot and configure to work already you need to be in an msys2 environment. So having stack install its own, un-updated msys2 is not a workflow I would recommend. There's a dubious claim there that using stack is "more robust", what is this claim based on? I'm just confused when it was decided to switch the defaults, and why, without any consultation. Regards, Tamar

3 2

Re: Hadrian questions
by Andrey Mokhov 28 Jan '19

28 Jan '19

Hi Richard, First of all, thank you trying Hadrian and generating several new bug reports. This is very helpful! > I think it would be very convenient to make a script we can all install (in our PATH) that will > search for hadrian's build.sh and run it. Then, we can just say `build` (or whatever we name > the script) anywhere in a tree. Of course, I could just do this locally, but I doubt I'm the only > one who would enjoy it. This sounds like a good feature request to me. Could you please add it on Trac, so it's not lost? > Also, I just had a look at https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md, > and I don't see a way to run just one directory of the testsuite. I use that ability currently quite > often (because I know that I've mucked with the typechecker, so I just run the typecheck tests > before doing full CI). Is this possible? Yes, this should be possible. I believe Alp is currently working on the testsuite with the goal of fully matching the functionality provided by the Make build system. I think this feature is already on his list, but I'm CC-ing him just in case. Cheers, Andrey ================================================ Date: Fri, 25 Jan 2019 08:18:08 -0500 From: Richard Eisenberg <rae(a)cs.brynmawr.edu> To: Matthew Pickering <matthewtpickering(a)gmail.com> Cc: GHC <ghc-devs(a)haskell.org> Subject: Re: Hadrian questions Maybe I'm just lazy, but would it be possible to shorten these? Specifically, could there be a root-level file `build` that triggers Hadrian? That way, I could just say ./build instead of hadrian/build.sh. Actually, even that isn't quite right. It is common, for example, for me to be deep in the testsuite, trying to fix a test. I twiddle something (say, the output file), and then I want to rerun the test. But now I have to go back out to the root of my tree to run the test, no? So: I think it would be very convenient to make a script we can all install (in our PATH) that will search for hadrian's build.sh and run it. Then, we can just say `build` (or whatever we name the script) anywhere in a tree. Of course, I could just do this locally, but I doubt I'm the only one who would enjoy it. Also, I just had a look at https://gitlab.haskell.org/ghc/ghc/blob/master/hadrian/doc/testsuite.md, and I don't see a way to run just one directory of the testsuite. I use that ability currently quite often (because I know that I've mucked with the typechecker, so I just run the typecheck tests before doing full CI). Is this possible? Thanks for all the work on this! Richard

2 1

[GitLab] Introducing Marge-bot
by Ben Gamari 28 Jan '19

28 Jan '19

Hi everyone, As you might have noticed there is a new face on GitLab: Meet @marge-bot. Marge will be helping us with the pain of merging merge requests: Currently the typical workflow to merge an accepted MR involves the following: 1. Rebase the MR on top of the current `master` branch 2. Click on the "Merge when pipeline succeeds" button 3. Wait. 4. If another MR is merged before yours, return to step (1) Given the volume of patches that we have, this process gets tiresome quite quickly. Upstream knows [1] about this issue and is actively working towards a solution which will likely be ready in a few months. In the meantime, Marge automates this currently-manual process. With Marge merging a patch involves just two steps: 1. Ensure that the MR has at least one approval. This should happen in the course of normal review but ping @bgamari, @alpmestan, @osa1, or @tdammers if this was forgotten. 2. Use the "Assignee" field in the sidebar on the right side of the MR to assign it to @marge-bot. Once Marge notices your MR she will dutifully watch over it, rebasing it as necessary until it is merged. If something goes awry, she will leave a (hopefully) helpful message and assign the MR back to you. So far Marge has been working out reasonably well and seems to be an improvement over the status quo. However, she still has some quirks so let me know if you think she is behaving erratically or otherwise have questions. Cheers, - Ben

5 4

CI request: a DEBUG compiler
by Richard Eisenberg 27 Jan '19

27 Jan '19

Hi devs, I almost exclusively work with a DEBUG compiler. It continually shocks me that I'm relatively alone in this stance, as the ASSERTs littered throughout GHC have caught many a bug in easier a manner than long stares at -ddump-tc-trace would do. In any case, my goal in this email is not to convince you to follow suit. My goal is to request that our CI infrastructure include at least one testsuite run in a DEBUG compiler. A patch I'm working on is failing a test because of an assertion failure. I doubt my patch is the culprit, but I also can't categorically rule it out. So, I'm left rebuilding HEAD with DEBUG turned on to see if I can repro the ASSERTion failure. Clearly, having a CI trace of this would simplify things -- not to mention catch bugs earlier. Thanks! Richard

3 2