- ghc-devs - Haskell.org

GitLab: Cmd+Enter considered harmful on reviews
by Richard Eisenberg 04 Jan '19

04 Jan '19

PSA: When reviewing an MR on GitLab, every comment has two buttons: (1) add to review, and (2) add comment now. Cmd+Enter (on my machine at least), does option (2), even though option (1) is bold and green. This is not what I wanted. (By the way, "comments" actually open these things called "discussions", which can be resolved. But that's another matter.) I've now removed all my comments and added them to my review. But I wanted you all to know about this in case you stumble across the same problem. Richard

2 2

Default options for -threaded
by lonetiger＠gmail.com 04 Jan '19

04 Jan '19

Hi All, A user on https://ghc.haskell.org/trac/ghc/ticket/11054 has asked why -N -qa isn’t the default for -threaded. I’m afraid I don’t know a good reason why it’s not. Can anyone help shed some light on this? If there is no good reason, Would anyone object to making it the default? Thanks, Tamar

7 10

Type family equation violates injectivity?
by Dominick Samperi 04 Jan '19

04 Jan '19

When I use v8.6.3 of GHC under Ubuntu to install the inline-r package I get the error "Type family equation violates injectivity annotation," and a type variable on the LHS cannot be inferred from the RHS, due to the lack of injectivity (I suppose). On the other hand, v8.0.2 of GHC (shipped with Haskell Platform under Ubuntu) does not have this problem (it has other problems). Has something changed in the latest version of the compiler that might cause this? Possible work-around? FYI, the line that triggers the error is: type instance G.Mutable (W t ty s) = Mutable.W t ty The variable that cannot be inferred is 's'. Thanks, Dominick

4 12

Getting ghc/Main.hs to import modules
by Anton Xue 04 Jan '19

04 Jan '19

Hey all, I want to make modifications to a custom version of ghc/Main.hs that depends on packages not natively shipped with GHC 8.2.2. In short, I want to be able to write "import Network" ( http://hackage.haskell.org/package/network-2.8.0.0) in ghc/Main.hs and then build GHC from source. However, I am running into some problems, and here is what I have attempted based on the Building/Modifying page ( https://ghc.haskell.org/trac/ghc/wiki/Building/Modifying) 1. I downloaded a copy of the network package and placed it in libraries/network. 2. I added an entry to the packages file for library/network, and used dashes for all the other entries. 3. perl boot 4. I modified ghc.mk and placed libraries/network as the first PACKAGES_STAGE1 append right before ghc-prim 5. make -j5 The build then fails complaining that: ghc/Main.hs:77:8: error: Could not find module ‘Network’ Use -v to see a list of the files searched for. | 77 | import Network A similar problem also appears when I replace "import Network" with "import System.Console.Haskeline", which is strange considering that haskeline was shipped with GHC 8.2.2. However, other imports such as "import System.CPUTime", which was defined in base, do not raise this error. Otherwise GHC builds fine with no errors. I am wondering what I should do to solve this issue. Thank you, Anton

2 2

Phab and trac are gonna stay online in read only mode right?
by Carter Schonwald 30 Dec '18

30 Dec '18

I’m still fuzzy on the long term hosting plans , but I worry that If we don’t keep them online as sort of read only sites with maybe a “look at this new gitlab ” top bar, that a lot of links to stuff will start dying Is there a post wiki / ticket migration plan for this ?

1 0

The Trac Wiki and the GitLab Migration
by Ara Adkins 29 Dec '18

29 Dec '18

Hey All, I’ve been doing a decent amount of thinking about the GitLab migration and realised that I’d not seen any discussion of what we plan to do with all the information in the Trac Wiki. If there has been some and I’ve missed it I apologise. In essence, I’m wondering what the current plan is! Will we leave it in place, or so we plan to move the content to a wiki on GitLab? Best. _ara

3 3

Current Stable Release = 8.6.2 on haskell.org
by Artem Pelenitsyn 28 Dec '18

28 Dec '18

Hello devs, I assume, the version of the current release should be bumped up to 8.6.3 here [1]? [1]: https://www.haskell.org/ghc/download.html -- Best wishes, Artem

4 5

Re: Welcome to GitLab!
by Ara Adkins 27 Dec '18

27 Dec '18

Thanks ben! Great to know. CC the list in case anyone else was interested. _ara > On 27 Dec 2018, at 15:06, Ben Gamari <ben(a)smart-cactus.org> wrote: > > Ara Adkins <me(a)ara.io> writes: > >> Along the lines of things needing to be adapted, are we moving the >> ghc-commits mailing list over to GL? >> > Yes, although I haven't quite worked out how best to do that yet. In the > meantime I have inverted the mirroring relationship between > git.haskell.org and gitlab.haskell.org such that the old commit > notification continue to fire. > > Cheers, > > - Ben >

1 0

Re: GitLab Migration (CI heads-up)
by Gabor Greif 23 Dec '18

23 Dec '18

Hi Ben, I was wondering why my pull request (merely to trigger a bit more of CI than what I have at my local disposal) was suddenly failing (1), when it worked in a previous incarnation (2). It turns out that either CI or the entire tree is broken since (3) being the last sound one. Looks like x86-64 is affected on the linux platform only. Darwin seems to work, i386 too, and my PR (2) has been validated for PPC64le recently. So this is just a heads up that there is something fishy with github->CircleCI (at least). Cheers, Gabor (1) https://circleci.com/gh/ghc/ghc/tree/pull/242 (2) https://circleci.com/gh/ghc/ghc/tree/pull/224 (3) https://circleci.com/gh/ghc/ghc/tree/pull/239 On 12/21/18, Ben Gamari <ben(a)smart-cactus.org> wrote: > Ara Adkins <me(a)ara.io> writes: > >> Hey All, >> >> Sorry for my confusion, but I'm a bit unclear as to when we're meant to >> start working against the GHC repo on the gitlab.haskell.org instance. I >> had in mind that the cutover was intended to be the 18th, but going on >> there it still appears as if it's mirrored from git.haskell.org. Can >> somebody clarify this for me? >> > Sorry for the confusion. I have been reluctant to formally announce the > cut-over until CI is green but this has taken a fair bit longer than > anticipated due to the long CI cycle time. Nevertheless people have > started submitting MRs against the GitLab instance and you are more than > welcome to do so. > > As far as the official upstream repository, indeed > gitlab.haskell.org/ghc/ghc is still mirroring git.haskell.org/ghc. This > will change when I formally announce the switchover. > > Cheers, > > - Ben > >

3 7

Linker speed on GHC
by Ben Gamari 22 Dec '18

22 Dec '18

Hi Tamar, I have recently been looking quite a bit at our continuous integration due to the transition to GitLab and have found that the Windows builder is almost always the rate-limiting step. Builds routinely take three hours or more, with much of the time being spent in the bfd linker. I am working to add more builders but ultimately there is only so much that we can do with the resources we have, especially given that Windows VM instances are essentially twice the cost of their Linux counterparts due to Windows licensing fees. I know in the past you have thought about ld performance on Windows. Has there been any development on this front? Is there anything obvious we can do to improve the situation? Cheers, - Ben

1 1