- ghc-devs - Haskell.org

GHC wiki fixup
by Tobias Dammers 21 Mar '19

21 Mar '19

Hello all, I am about to push a relatively large set of semi-automatic changes to the GHC wiki on GitLab (https://gitlab.haskell.org/ghc/ghc/wikis) This changeset is the result of re-running the original Trac import, with a few bugfixes applied to it, and then cherry-picking the resulting changes to the wiki onto the live wiki. Among other things, this fixes the following issues: - Mangled table layouts (GitLab's Markdown implementation does not support inline markup inside tables): https://gitlab.haskell.org/bgamari/gitlab-migration/issues/45 - Mangled code blocks (for some reason, the original import threw away significant whitespace inside syntax-highlighted code blocks): https://gitlab.haskell.org/bgamari/gitlab-migration/issues/37 - Some links to GHC source files pointing to gitlab.haskell.org/ghc/ghc/wikis/trac/ghc/browse/..., which is of course nonsense, now point to the correct location in the GitLab source code viewer: https://gitlab.haskell.org/bgamari/gitlab-migration/issues/53 - Some remaining links to the old Trac install have been fixed: https://gitlab.haskell.org/bgamari/gitlab-migration/issues/26 - Some incorrectly quoted blocks may or may not be fixed by this as well: https://gitlab.haskell.org/bgamari/gitlab-migration/issues/46 - During the original import, we experienced HTTP errors on some pages, leading to "CONVERSION ERROR" pages being rendered instead. The re-run should have fixed these by sheer virtue of GETting those pages again now that there is less load on the Trac server. Since we used the wiki in its pre-migration state (as currently seen on https://trac.haskell.org/ghc) as the data source, we have to be careful not to accidentally undo changes made to the GitLab wiki in the meantime. I tried to mitigate this by manually picking changes, and I think I got it right, but as with all manual efforts, it is possible that I made a mistake here or there. The changeset is pretty large, and most of it is perfectly boring, so I applied quite a bit of automation to keep it manageable. So if you find anything broken on the wiki that looked OK so far, or if you see any of your edits disappear, please holler, and I'll do my best to fix it. Fortunately, this is a git repo, so nothing is permanently lost either way. And of course I apologize for any inconvenience in advance. Cheers, Tobias

1 1

Windows release quality
by Andreas Klebinger 19 Mar '19

19 Mar '19

Hello Devs, After running into #16408 today I realized there is as of yet no released bindist of the 8.6 series which I would consider stable for windows. GHC 8.6.1 and 8.6.2 had a series of critical bugs which applied to multiple platforms: https://gitlab.haskell.org/ghc/ghc/issues/16408 GHC 8.6.3 loops forever if compiling certain code using TH on windows. This affects some very popular hackage packages: (#16057) <https://gitlab.haskell.org/ghc/ghc/issues/16057> GHC 8.6.4 (marked stable) currently ships without profiling libraries, making profiling impossible. Being stuck with 8.4 is one thing, and if properly communicated not too bad. But it requires work to even find out about these (major) issues and to discover that 8.6 is NOT production ready for windows. We offered the broken 8.6.3 as stable for weeks without any indication that it was broken. We still serve GHC 8.6.4 as stable without any hint about the missing profiling libraries. I can't offer solutions in this case but I feel like something about the release management has to change if . Having to check the GHC bugtracker to find out if the current stable release is actually stable is just not sustainable.

3 3

Discussion: Hadrian's defaults
by Spiwack, Arnaud 19 Mar '19

19 Mar '19

I’ve been using Hadrian for a while. And I really like it. But I think, based on my experience and also the reading of the soon to be freshly reforged newcomers’ guide, that it could be greatly improved by changing the default of some of the more common options: - The -c option should be the default. One of the cool thing about Hadrian is that it needs fewer steps to completion, as it knows how to run the boot and configuration script. It’s not always what you want, but if it isn’t, it should befall to you to specify it. The most common use is the default (-c is, for instance, used in the newcomers’ guide). The reverse flag could be --no-configure. - --freeze1 should be the default. Ok, this one is harder. It’s almost always the right thing to call --freeze1 and forgetting it can have big consequences. So let’s make --freeze1 the default, add a flag --rebuild1 to force the rebuilding of stage 1. However, this requires an exception: if stage 1 was never built, we should build it, even without the flag --rebuild1. - Eventually, the new --share option should be the default as well. But maybe the paint is a bit too fresh on this. If I missed something (other defaults which should be changed, or reason to keep the defaults as they currently are) reply to this thread.

8 14

[ambiguous occurrence bug?]
by Shayne Fletcher 19 Mar '19

19 Mar '19

Sorry in advance if I should be posting questions of this kind elsewhere (please tell me if so!). Consider this two file program: ``` module T where main = undefined module Main where import T main = putStrLn "Hello world!" ``` Both 8.4.3 and 8.6.3 agree: ``` Main.hs:1:1: error: Ambiguous occurrence ‘main’ It could refer to either ‘T.main’, imported from ‘T’ at Main.hs:2:1-8 (and originally defined at Main.hs:2:1-4) or ‘Main.main’, defined at Main.hs:5:1 ``` Is this expected behavior? Does it not contradict "If the export list is omitted, all values, types and classes defined in the module are exported, but not those that are imported" ( https://www.haskell.org/onlinereport/haskell2010/haskellch5.html)? If the latter, is this a bug? What am I missing? -- 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.

4 8

Trac -> Gitlab migration: A little issue with assignees
by Roland Senn 19 Mar '19

19 Mar '19

After some days off, I returned to my work on GHC. I looked up my tickets in Gitlab with a search on assignee=RolandSenn [1]. The system returned a list of 8 open tickets. Two of them are interesting: #14025 and #15336. Once upon a time I assigned them to me, worked on them, but unfortunately then I found them too difficult. So a couple of weeks ago I unassigned them in the good old Trac system. It seems, that these unassign operations weren't copied to Gitlab! For my 2 tickets, this is no problem, I can re-unassign them manually. However, I think, there are other tickets that were unassinged by their previous owners some time ago. Most probably some or all of them now got re-assinged during the migration to Gitlab. [1] https://gitlab.haskell.org/ghc/ghc/issues?scope=all&utf8=%E2%9C%93& state=opened&assignee_username[]=RolandSenn

2 1

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