- ghc-devs - Haskell.org

Newcomer looking for mentorship on a HPC / Coverage related issue
by Javran Cheng 03 Mar '21

03 Mar '21

Hi all, I'm a newcomer (not entirely new as I did have some contribution few years back but the workflow seems to have changed a lot) and is working on https://gitlab.haskell.org/ghc/ghc/-/issues/15932. I'm looking for some (informal) mentorship on that issue - I think I know what the problem is <https://gitlab.haskell.org/ghc/ghc/-/issues/15932#note_283252>, but I need someone with more experience to help developing a concrete plan before working on a fix, as this might involve two parts in GHC codebase: HPC source code and GHC/HsToCore/Coverage. I tried to ask for comments and other related bits on IRC few months back but that doesn't attract much attention. Now that I'm in the mood of hacking GHC again, I figure probably finding a mentorship might work better. Thanks! Javran

2 1

Plan for GHC 9.2
by Ben Gamari 02 Mar '21

02 Mar '21

tl;dr. Provisional release schedule for 9.2 enclosed. Please discuss, especially if you have something you would like merged for 9.2.1. Hello all, With GHC 9.0.1 at long-last out the door, it is time that we start turning attention to GHC 9.2. I would like to avoid making the mistake made in the 9.0 series in starting the fork in a state that required a significant amount of backporting to be releaseable. Consequently, I want to make sure that we have a fork schedule that is realistic given the things that need to be merged for 9.2. These include: * Update haddock submodule in `master` (Ben) * Bumping bytestring to 0.11 (#19091, Ben) * Finishing the rework of sized integer primops (#19026, John Ericson) * Merge of ghc-exactprint into GHC? (Alan Zimmerman, Henry) * Merge BoxedRep (#17526, Ben) * ARM NCG backend and further stabilize Apple ARM support? (Moritz) * Some form of coercion zapping (Ben, Simon, Richard) * Tag inference analysis and tag check elision (Andreas) If you see something that you would like to see in 9.2.1 please do holler. Otherwise, if you see your name in this list it would be great if you could let me know when you think your project may be in a mergeable state. Ideally we would strive for a schedule like the following: 4 February 2021: We are here ~4 weeks pass 3 March 2021: Release branch forked 1 week passes 10 March 2021: Alpha 1 released 3 weeks pass 31 March 2021: Alpha 2 released 2 weeks pass 14 April 2021: Alpha 3 released 2 weeks pass 28 April 2021: Alpha 4 released 1 week passes 5 May 2021: Beta 1 released 1 week passes 12 May 2021: Release candidate 1 released 2 weeks pass 26 May 2021: Final release This provides ample time for stabilization while avoiding deviation from the usual May release timeframe. However, this would require that we move aggressively to start getting the tree into shape since the fork would be less than four weeks away. I would appreciate contributors' thoughts on the viability of this timeline. Cheers, - Ben

6 7

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