- ghc-devs - Haskell.org

Re: Request for comments on dry-run Trac -> GitLab migration
by Ryan Scott 05 Feb '19

05 Feb '19

There appears to be some impedance mismatches between GitLab's formatting and Trac's formatting in certain places. For example, see the bottom of this issue [1], which has a long, hyperlinked line with the phrase: Icanproducethe`missinginstance`issuewithouthavingtorecompileGHC,whichiswhyIthinkitmightbeindependentofthisbug. Ryan S. ----- [1] https://gitlab.staging.haskell.org/ghc/ghc/issues/16211

2 1

Request for comments on dry-run Trac -> GitLab migration
by Ben Gamari 05 Feb '19

05 Feb '19

TL;DR. Have a look at this [2] test import of GHC's Trac tickets. Tell us what issues you find. Hello everyone, As you likely know, we are currently in the process of consolidating GHC's infrastructure on GitLab [1]. The last step of this process is to migrate our tickets and wiki from Trac. Towards this end I am happy to announce the availability of a test GitLab instance [2] for the community's review. This is a clone of gitlab.haskell.org but with the addition of tickets [3] and GHC wiki [4] content imported from a Trac dump from earlier this month. There are a few known issues: * There are currently around 50 tickets missing from the import; we are working on identifying where they escaped to * The revision history of the Wiki is currently squashed due to performance issues [6] with GitLab's wiki implementation We intend to resolve both of these problems by the time of the final migration. If you find a ticket on the staging instance with problems that are not in the above list please do add the `import problems` label to it so we can have a look. There are a few aesthetic questions that could use community input: * Should the "Trac Metadata" boxes be always visible? * How do we make the Wiki index [7] more usable? Imposing more hierarchy to the page names would likely help but I'm still a bit worried that it will be hard to browse. Please do take a few minutes to peruse the test import and check for mistakes or potential usability issues. GHC's Trac tickets are one of the crown-jewels of the project; we want to make sure we get this migration right as will be living with the result for a long time to come. Cheers, - Ben [1] https://gitlab.haskell.org/ [2] https://gitlab.staging.haskell.org/ghc/ghc/ [3] https://gitlab.staging.haskell.org/ghc/ghc/issues [4] https://gitlab.staging.haskell.org/ghc/ghc/wiki [6] https://gitlab.com/gitlab-org/gitlab-ce/issues/57179 [7] https://ghc.haskell.org/trac/ghc/ticket/16212

5 8

How to teach Hadrian not to build ghctags and haddock
by Roland Senn 04 Feb '19

04 Feb '19

I switched to Hadrian. Normally I hack somewhere in the compiler. So I use "hadrian/build.sh --flavour=devel2 --freeze1" to quickly rebuild GHC after some little changes to the code. It normally builds - library 'ghc' (Stage1, way v) - program 'ghctags' (Stage1) - program 'ghc-bin' (Stage1) - program 'haddock' (Stage1) When hacking GHC, I never use ghctags or haddock. Building ghctags is very fast, 1-2 seconds. However building haddock takes 15 to 20 seconds. Is there a way to teach hadrian not to build haddock and ghctags? Many thanks! Roland

4 4

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