- ghc-devs - Haskell.org

GHC 9.1?
by Richard Eisenberg 02 Mar '21

02 Mar '21

Hi devs, I understand that GHC uses the same version numbering system as the Linux kernel did until 2003(*), using odd numbers for unstable "releases" and even ones for stable ones. I have seen this become a point of confusion, as in: "Quick Look just missed the cutoff for GHC 9.0, so it will be out in GHC 9.2" "Um, what about 9.1?" Is there a reason to keep this practice? Linux moved away from it 18 years ago and seems to have thrived despite. Giving this convention up on a new first-number change (the change from 8 to 9) seems like a good time. I don't feel strongly about this, at all -- just asking a question that maybe no one has asked in a long time. Richard (*) I actually didn't know that Linux stopped doing this until writing this email, wondering why we needed to tie ourselves to Linux. I coincidentally stopped using Linux full-time (and thus administering my own installation) in 2003, when I graduated from university.

6 8

initIface* usage in plugins
by Josh Meredith 27 Feb '21

27 Feb '21

Hi, I'm trying to use initIfaceLoad and initIfaceLcl to lookup core `Name`s within a plugin. My understanding is that functions such as `lookupIfaceTop` are used for this, but I'm running into an issue that I suspect is caused by some `Name`s being inappropriate for this function, so they fail with the error `Iface id out of scope: ...`. Is there a robust way to select which `Name` lookup function to use based on a core binding/expression? Thanks, Josh

3 2

MR template text
by Simon Peyton Jones 23 Feb '21

23 Feb '21

I often see MRs in my inbox that say Thank you for your contribution to GHC! Please take a few moments to verify that your commits fulfill the following: [ ] are either individually buildable or squashed This is because the author hasn't changed the Description of the MR, but rather has left the template text unchanged. As a way to "nudge" authors to give reviewers more information, I suggest replacing the template text with the draft below. Does anyone have any views, for or against? Simon Proposed new template PLEASE REPLACE ALL OF THIS TEXT with a description of your merge request, including * A description of what the Merge Request does. For a single-commit MR, a copy of the commit message is often perfect. * A reference (e.g. #19415) to the ticket that led to this MR, and that describes the problem that this MR solves. Almost all MRs need a ticket, except the tiniest changes (e.g. code formatting) - A ticket describes a *problem* - A merge request describes a *solution* to that problem. While you are encouraged to write a good MR Description, it's not compulsory. You could just be putting up the MR to share with a colleague, for example. But if you want (a) to get code reviews from others, or (b) to land the patch in GHC, please do follow these guidelines. For general style guidance see https://gitlab.haskell.org/ghc/ghc/wikis/commentary/coding-style For completeness, the current template is Thank you for your contribution to GHC! Please take a few moments to verify that your commits fulfill the following: * [ ] are either individually buildable or squashed * [ ] have commit messages which describe *what they do* (referring to [Notes][notes] and tickets using `#NNNN` syntax when appropriate) * [ ] have added source comments describing your change. For larger changes you likely should add a [Note][notes] and cross-reference it from the relevant places. * [ ] add a [testcase to the testsuite](https://gitlab.haskell.org/ghc/ghc/wikis/building/running-tests/…. * [ ] replace this message with a description motivating your change If you have any questions don't hesitate to open your merge request and inquire in a comment. If your patch isn't quite done yet please do add prefix your MR title with `WIP:`. [notes]: https://gitlab.haskell.org/ghc/ghc/wikis/commentary/coding-style#comments-i…

4 5

Changes to performance testing?
by Ben Gamari 23 Feb '21

23 Feb '21

Hi all, Recently our performance tests have been causing quite some pain. One reason for this is due to our new Darwin runners (see #19025), which (surprisingly) differ significantly in their performance characteristics (perhaps due to running Big Sur or using native tools provided by nix?). However, this is further exacerbated by the fact that there are quite a few people working on compiler performance currently (horray!). This leads to the following failure mode during Marge jobs: 1. Merge request A improves test T1234 by 0.5%, which is within the test's acceptance window and therefore CI passes 2. Merge request B *also* improves test T1234 by another 0.5%, which similarly passes CI 3. Marge tries to merge MRs A and B in a batch but finds that the combined 1% improvement in T1234 is *outside* the acceptance window. Consequently, the batch fails. This is quite painful, especially given that it creates work for those trying to improve GHC (as the saying goes: no good deed goes unpunished). To mitigate this I would suggest that we allow performance test failures in marge-bot pipelines. A slightly weaker variant of this idea would instead only allow performance *improvements*. I suspect the latter would get most of the benefit, while eliminating the possibility that a large regression goes unnoticed. Thoughts? Cheers, - Ben

4 4

On CI
by Moritz Angermann 22 Feb '21

22 Feb '21

Friends, I've been looking at CI recently again, as I was facing CI turnaround times of 9-12hs; and this just keeps dragging out and making progress hard. The pending pipeline currently has 2 darwin, and 15 windows builds waiting. Windows builds on average take ~220minutes. We have five builders, so we can expect this queue to be done in ~660 minutes assuming perfect scheduling and good performance. That is 11hs! The next windows build can be started in 11hs. Please check my math and tell me I'm wrong! If you submit a MR today, with some luck, you'll be able to know if it will be mergeable some time tomorrow. At which point you can assign it to marge, and marge, if you are lucky and the set of patches she tries to merge together is mergeable, will merge you work into master probably some time on Friday. If a job fails, well you have to start over again. What are our options here? Ben has been pretty clear about not wanting a broken commit for windows to end up in the tree, and I'm there with him. Cheers, Moritz

8 15

Weekly show & tell video meeting
by Csaba Hruska 16 Feb '21

16 Feb '21

Hello, Would you be interested in a weekly show & tell video meeting? The topic would be Haskell & compilers in general. Either GHC or non-GHC related. Regards, Csaba

2 3

cep_app traces
by Simon Peyton Jones 15 Feb '21

15 Feb '21

Ben I'm getting a lot of cpe_app(keepAlive#) 3 cpe_app(keepAlive) trace messages from HEAD. Maybe it's a leftover from tracing when you were developing? Remove? Simon

2 1

gitlab.haskell.org certificate expired?
by Richard Eisenberg 15 Feb '21

15 Feb '21

Hi Ben, It looks like the Let's Encrypt certificate for gitlab.haskell.org <http://gitlab.haskell.org/> has expired, as of about 15 minutes ago. I guess it's time to renew. Thanks, Richard

5 4

Slowing down churn in master prior to 9.2 freeze
by Ben Gamari 12 Feb '21

12 Feb '21

Hi all, Since we are in the final weeks of preparation before the 9.2 branch it would be appreciated if we could refrain from pushing work that isn't either a bug-fix or release-critical feature starting next week, especially where the work requires coordination across submodules. At the moment we have quite a backlog in the merge queue, with a number of dependent patches touching submodules. Consequently, I am a tad worried that the three weeks of runway that we currently have may prove to be insufficient unless we try to keep the merge traffic down. I suggest that we set the milestone of non-release-critical patches to %9.4.1 instead of assigning @marge-bot to allow merging to easily proceed after the branch is cut. Cheers, - Ben

1 0

Boot libraries for GHC 9.2
by Ben Gamari 12 Feb '21

12 Feb '21

Hi all, I am currently in the process of planning out the GHC 9.2 release. As you know, part of this process is working out which core library versions we will ship. My current plan is the following: package maintainer version --------------- ------------------ ----------------- Cabal Mikhail Glushenkov 3.6.0.0 Win32 Tamar Christina 2.10.0.0 array GHC HQ 0.5.3.0 binary Lennart Kolmodin 0.8.7.0 bytestring Andrew Lelechenko 0.11.0.0 (see GHC #19091) containers David Feuer/CLC? 0.6.4.1 deepseq CLC 1.4.4.0 directory CLC 1.3.6.1 exceptions Ed Kmett 0.10.4 filepath Neil Mitchell? 1.4.2.1 haddock Hécate ? haskeline Judah Jacobson 0.8.1.0 hsc2hs GHC HQ 0.68.7 mtl Ed Kmett 2.2.2 parsec Herbert Valerio Reidel 3.1.14 pretty David Terei? 1.1.3.6 process Michael Snoyman 1.6.10.0 stm GHC HQ 2.5.0.0 terminfo Judah Jacobson 0.4.1.4 text CLC 1.2.4.0 time Ashley Yakeley 1.11.1 transformers Ross Paterson 0.5.6.2 unix Andrew Lelechenko 2.8.0.0? xhtml Chris Dornan 3000.2.2.1 If you disagree with this plan or see a question mark next to a library that you are responsible for, please do be in touch. Cheers, - Ben

1 0