- ghc-devs - Haskell.org

RE: GHC | Work out how to manage labels (#16458)
by Simon Peyton Jones 18 Mar '19

18 Mar '19

1 0

searching for tickets
by Richard Eisenberg 18 Mar '19

18 Mar '19

Hi devs, Previously, I could effectively use Google as a way to search for contents in tickets, with a query like > site:ghc.haskell.org/blah/blah/tickets <http://ghc.haskell.org/blah/blah/tickets> type families (I can't remember the exact URL, and Trac has been taken down so I can't figure it out.) Now, though, when I search for > site:gitlab.haskell.org/ghc/ghc/issues/ <http://gitlab.haskell.org/ghc/ghc/issues/> type families I get nothing. Is there something in our setup that stops Google from indexing our issues? Or has Google just missed the memo about the issues page being opened up? Thanks! Richard

2 1

Wiki search & pages
by Julian Leviston 17 Mar '19

17 Mar '19

Hi, When I started this message, I couldn't find the commentary in the wiki any more. Also, when I try to search with the “search or jump to” box, it sits on “Loading” for quite a while, then I get impatient (after 20 seconds or so), and click off it, but the drop down box doesn’t go away, so I remove the word “Commentary” from the search box, and the drop down box is replaced by a bunch of preset searches. I can’t seem to get it to go away then. Also, down the right hand side of the wiki are a bunch of links which seem to be the first 20 or so, sorted alphabetically, rather than the relevant navigation links in the old trac wiki side nav. I can’t seem to work out how to navigate my way around to find the commentary anymore :( If I type commentary and hit enter, on other hand, it comes up with search results, but it’s quite slow (takes 5 seconds or so to get that page up generally, and feels kind of buggy). That brings up the main commentary page, except I really miss the side-nav that indicated where I was located in the wiki (I realise there’s a breadcrumbs at the top… it says “GHC > Wiki > commentary”, but the commentary page is definitely *not* on the GHC > Wiki page… this makes me feel kind of “lost”. How is a new person supposed to discover these pages exist? Sorry I don’t want to be whining, but this seems quite important. Navigating between pages seems quite slow (3 or 4 seconds between page loads). Maybe it’s fine and I’ll get used to it with time. Hope so. Julian

2 4

GitLab updates
by Ben Gamari 17 Mar '19

17 Mar '19

Hi everyone, I want to share a few developments on the GitLab migration front: * URLs pointing to tickets or the Wiki which were previously served by Trac (https://ghc.haskell.org/) now redirect to their corresponding GitLab URL. Wiki page names are redirected via this mapping [1]. If you find any cases were this doesn't work as you would expect then please do let me know or open a ticket [4]. If you do want to view Trac you may do so (for the time being) at https://trac.haskell.org/. In the coming days I will be taking a final static archival snapshot of our Trac instance and in the next few weeks we will likely shut it down. * This afternoon I imported [2] a few dozen keywords from Trac that were omitted from the initial import. At this point the ghc/ghc project has nearly 100 labels. It's unclear how usable this will be without either paring down the label space or imposing some sort of order (e.g. adding categorical prefixes to label names) but time will tell. * Our GitLab installation has been upgraded to GitLab 11.8. The changes are relatively minor but I am sure you will spot them. * The source for GHC's homepage (https://www.haskell.org/ghc) is now hosted in the ghc/homepage project [3]. If you find anything wrong with the website feel free to submit a merge request. As always, if you find anything amiss don't hesitate to ping me or open a ticket [4]. Note that the Wiki is still in need of quite a bit of cleanup [5]. If you have some time and want to help out either pick up a ticket or just start browsing and clean-up the first page you find. Many hands makes for light work. However, if you end up renaming any Wiki pages please do open a merge request updating `wiki-mapping.json` [1]. Thank you for your patience while we push through the remaining parts of the migration. Cheers, - Ben [1] https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mappin… [2] https://gitlab.haskell.org/bgamari/trac-to-remarkup/commit/4104086bca53528b… [3] https://gitlab.haskell.org/ghc/homepage [4] https://gitlab.haskell.org/bgamari/gitlab-migration/issues [5] https://gitlab.haskell.org/bgamari/gitlab-migration/issues?label_name%5B%5D…

1 0

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