March 2019 - ghc-devs

Re: Discussion: Hadrian's defaults
by Andrey Mokhov 15 Mar '19

15 Mar '19

Hi Arnaud, Great to hear you've been using Hadrian for a while and like it! As others have already pointed, -c used to be default. I personally was always inclined to run boot and configure by default, because to me they seem like an unnecessary complication on the way to the first GHC build (they confused me a lot when I did my first GHC build). On the other hand, people who strongly oppose -c being default are all expert users of configure, and should be capable of passing --skip-configure when need be (or always). It's good to discuss this and see what proportion of GHC developers would prefer to include -c by default. So far the opponents were much more vocal. Making --freeze1 default is probably fine. If we go this way, there should be a big warning in the documentation saying that this default setting is convenient but unsafe, i.e. can produce wrong binaries. I think --share is not ready to become default. Hopefully, it will be in 1-2 months! Cheers, Andrey

1 0

github ghc.git broken on libraries/binary
by Shayne Fletcher 14 Mar '19

14 Mar '19

`git clone git@github.com:ghc/ghc.git` followed by `git submodule update --init --recursive` results in ``` error: Server does not allow request for unadvertised object 94855814e2e4f7a0f191ffa5b4c98ee0147e3174 Fetched in submodule path 'libraries/binary', but it did not contain 94855814e2e4f7a0f191ffa5b4c98ee0147e3174. Direct fetching of that commit failed. ``` -- 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.

3 4

Re: Haddock tree spongled
by Ryan Scott 14 Mar '19

14 Mar '19

I do think something is afoot here. The current Haddock submodule commit is at 07f2ca [1], but the ghc-head branch of Haddock is still at commit 8459c6 [2]. It would be good if someone could update the ghc-head branch accordingly. Ryan S. ----- [1] https://github.com/haskell/haddock/commit/07f2ca98fd4249dc6ebad053bd6aef90c… [2] https://github.com/haskell/haddock/commit/8459c600e0f6da3f85abefdefe651bbe3…

8 12

CI artifacts moved
by Ben Gamari 13 Mar '19

13 Mar '19

Hello everyone, Note that yesterday I moved CI artifact storage from AWS to Dreamobjects. However, I was not able to move the old artifacts themselves (transferring >500 GB of data that will largely be expired in two weeks between cloud providers is simply not economically feasible). Consequently artifacts produced earlier than today will be unavailable. Cheers, - Ben

1 0

Gitlab Email Broken (again)
by Matthew Pickering 13 Mar '19

13 Mar '19

HI Ben, I am not receiving emails from gitlab again. Is there a way we can make email more robust? Matt

3 3

Re: Trac to GitLab migration underway
by Richard Eisenberg 13 Mar '19

13 Mar '19

> On Mar 11, 2019, at 8:13 PM, Ben Gamari <ben(a)smart-cactus.org> wrote: > > Richard Eisenberg <rae(a)cs.brynmawr.edu> writes: > For instance, consider the case of > #16347 [1]. You will note that below the "Related issues" section there > is a list of related merge requests (strangely formatted completely > differently). Aha. That's exactly what I wanted. If that note is added to an issue when an MR mentions the issue number, I'm quite satisfied. > > To be honest, how this list is formed is a bit of a mystery to me. The > fact that !525 is included is not surprises: !525 mentions #16347 in > its description. However, !436 is a bit less obvious since it does not > mention #16347 at all. My hypothesis is that it is transitively included > via #16344, which does mention #16437 and is related to it. Transitive closures have a habit of sometimes getting large. But we'll tackle that problem when/if it comes up. > Indeed, as I mentioned earlier this may be a bit of a hard thing to > accomplish in the near-term. One measure we could take to ensure that > tests aren't forgotten is to include a "field" in the default merge > request description which contributors would be asked to fill in with > the names of the tests that cover their change. That's not a bad starting point. But it will hit only new contributors, right? Or will I be filling out such a form too (it's been a few weeks since my last patch submission, I'm afraid.) Thanks! Richard

2 1

Newcomers' Guide to GHC Development
by Tobias Dammers 13 Mar '19

13 Mar '19

Dear all, With the migration of our affairs from Trac to GitLab nearing completion, I would like to ask for a final round of feedback on the new Newcomers' Guide to GHC development. The draft can be found here: https://github.com/tdammers/ghc-wiki/blob/wip/newcomers/newcomers-tutorial.… TL;DR: If you have any kind of input / critique / praise regarding this document, feel free to reply, or, even better, issue a PR on github. Some background: The purpose of this document is to provide potential contributors with a practical, no-nonsense tutorial, guiding them from "I know nothing about GHC development" to their first successful merge request. The document has been compiled using existing wiki content, revised and edited to match the current state of affairs (particularly using Hadrian as the recommended build system), and to tune it to the target audience of first-time contributors. As such, we avoid going off on tangents (e.g., we do not explain how to use the make-based alternative build system), and we only explain what you need to understand in order to get going (e.g., we do not provide a complete run-down of all hadrian options). A few nonlinearities were deemed necessary in order to make the tutorial suitable across target platforms; Windows in particular requires some special attention. Other than that, however, we try to provide as linear an experience as we reasonably can. So with that said; all feedback and suggestions on this are welcome. We have gotten some great responses already, but I'd like to gather one more round of feedback before merging it into the freshly-migrated Haskell Wiki on GitLab. Thank you for your attention! -- Tobias Dammers - tdammers(a)gmail.com

5 6

From tickets to merge requests and vice versa
by Simon Peyton Jones 12 Mar '19

12 Mar '19

Ben, Matthew I wrote up notes on how to get from MR to issue, and from issue to MR, in my help page: https://gitlab.haskell.org/ghc/ghc/wikis/working-conventions/git-lab-spj (See "Issues" and "Merge requests" headings) Alas, it seems that I was lying * Issue #16411 does not have a "relevant merge request" link to MR!520, even though the latter plainly mentions the former. That seems deeply strange, and makes it hard to see if the issue has a MR, let alone which one it is. * Somehow MR!520 says "closes #16411" rather than just "mentions #16411". Perhaps this is good, but how did it know to do that? Simon

3 2

Marge Bot Permissions on Trac
by Ara Adkins 12 Mar '19

12 Mar '19

Hey all, though mostly hey Ben, Just figured I should let you know that marge still seems to be making changes to trac tickets as of about four hours ago when sending this email. Best, _ara

1 0

Search on gitlab
by Simon Peyton Jones 12 Mar '19

12 Mar '19

I searched for captureTopConstraints on GitLab, using the search box at the top. But it found nothing. And yet here it is https://gitlab.haskell.org/ghc/ghc/merge_requests/508 What am I doing wrong? Thanks Simon

3 3