January 2019 - ghc-devs

Marge: "CI is taking too long"
by Richard Eisenberg 25 Jan '19

25 Jan '19

Marge has complained that https://gitlab.haskell.org/rae/ghc/-/jobs/17206 is taking too long. And indeed it seems stuck. Help? Thanks, Richard

2 1

"resource exhausted" in CI
by Richard Eisenberg 24 Jan '19

24 Jan '19

Hi Ben, The pipeline for a recent patch (https://gitlab.haskell.org/rae/ghc/-/jobs/16793) says: HC [stage 1] compiler/stage2/build/TcForeign.o HC [stage 1] compiler/stage2/build/TcRules.o /tmp/ghc6477_0/ghc_3.s: hClose: resource exhausted (No space left on device) compiler/ghc.mk:445: recipe for target 'compiler/stage2/build/TcTyClsDecls.o' failed make[1]: *** [compiler/stage2/build/TcTyClsDecls.o] Error 1 make[1]: *** Waiting for unfinished jobs.... Is there a way to avoid this? Or should I just restart the CI? And what does Marge think of it all? (As in, if I ask her to take another spin, will she do so on the same commit?) Thanks, Richard

4 7

access failed CI artifacts
by Richard Eisenberg 24 Jan '19

24 Jan '19

A pipeline of mine failed: https://gitlab.haskell.org/rae/ghc/-/jobs/16807 The failures are just some output changes. I could delicately use the log to extract the changes and commit them, but it would be better to have direct access to, say, the *.run.stderr files and then commit those. Is this possible? Note that I do not have a build of this tree locally, as it's the result of a rebase that affected the output. Of course, I could build locally, but it would be nice to skip that step. Thanks! Richard

2 1

Groups and projects
by Simon Peyton Jones 24 Jan '19

24 Jan '19

> Alright, I believe I have found the issue: you are a member of > the GHC group and GitLab's default notification behavior is that > you will receive notifications for all events of repositories in > groups to which you belong. OK thanks, that's helpful. When you say "repository" could you also have said "project". That is, are "projects" and "repositories" in 1-1 correspondence? So, to understand the semantics, you can belong to * A project. * A group What's the difference? The group seems to be "Glasgow Haskell Compiler"; the project seems to be "Glasgow Haskell Compiler / GHC". Does that imply that * every project is part of a group; but * a group may have many projects? Or maybe a project can be part of more than one group? The "Custom settings" on a project seem to be identical to the "custom settings" for a group. If Gitlab is deciding whether to send me a notification N, is it clear whether it's a "project notification" or a "group notification"? If so, then it can consult the appropriate settings; but if not, it's not clear. Sorry for all these questions. It's astonishingly common for large software systems to describe the surface knobs without describing the underlying model that makes sense of all those knobs! Simon -----Original Message----- From: Ben Gamari <ben(a)well-typed.com> Sent: 24 January 2019 03:30 To: Simon Peyton Jones <simonpj(a)microsoft.com> Subject: RE: GHC | hWaitForInput-accurate-pipe test (!21) Simon Peyton Jones <simonpj(a)microsoft.com> writes: > Yes, tons of them! I attach a dozen that arrived in the last few hrs. > Alright, I believe I have found the issue: you are a member of the GHC group and GitLab's default notification behavior is that you will receive notifications for all events of repositories in groups to which you belong. You can view and modify these settings yourself here but I have changed them to be a bit more selective. You should now only receive notifications of new merge requests and new comments on merge requests on which you have previously commented. Do let me know if you receive any more unwanted mail. Cheers, - Ben

2 1

Disabled Travis
by Ben Gamari 23 Jan '19

23 Jan '19

Hi All, Travis appears [1] to be both broken and struggling to keep up with our builds. I have disabled it for now. If you have an interest in maintaining Travis then feel free to fix and reenable it. Cheers, - Ben [1] https://travis-ci.org/ghc/ghc/builds

1 0

Drop into a nix shell with ghcHEAD
by Matthew Pickering 22 Jan '19

22 Jan '19

Hi all, I have written a devastating new script which makes it easy to test snippets and packages with build artefacts built by the gitlab CI. One invocation of `nix-shell` will enter an environment with the most recent build artefact from master. Usage: ``` > nix-shell https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz unpacking 'https://github.com/mpickering/ghc-artefact-nix/archive/master.tar.gz'... <lots more output> > ghc --version The Glorious Glasgow Haskell Compilation System, version 8.7.20190115 ``` Repo: https://github.com/mpickering/ghc-artefact-nix So far we have tested it works on NixOS and darwin but support for other platforms that nix supports and we build artefacts for should be easy. It might already work on i386 and aarch64 as well but I didn't test these. Cheers, Matt

2 3

MR does not merge
by Simon Peyton Jones 21 Jan '19

21 Jan '19

Ben Six days ago I submitted this MR https://gitlab.haskell.org/ghc/ghc/merge_requests/109 Just tiny refactorings. I said "merge when validated" But six days later, it still appears not to have merged. What's up? I was expecting it to merge in a matter of an hour or two. Thanks Simon

9 14

ANN: Multiple positions for GHC developers
by Manuel M T Chakravarty 21 Jan '19

21 Jan '19

Please excuse this non-technical message, but I assume this is interesting for the members of this list: https://iohk.io/careers/#op-302245-ghc-web-backend-developer (There are multiple positions, same spec.) Cheers, Manuel

1 0

Reproducing bugs without Stack
by Eric Crockett 20 Jan '19

20 Jan '19

Devs, I use Stack for all of my Haskell development. I recently ran into several bugs, which I suspected to be GHC bugs. In the process of creating new tickets, I noticed a banner reading "*Please try to provide reproduction instructions which do not require "Stack"." *The request is reasonable to help weed out bugs in Stack itself, but I could use some advice on how to do that. In particular, I'm having trouble reproducing bugs related to profiling. For example, #16182 <https://ghc.haskell.org/trac/ghc/ticket/16182> is about runtime crashes with the -hr profiling option. This was clearly a GHC bug rather than a problem with stack, yet I have so far been unable to produce the bug without Stack. Similarly, for #16166 <https://ghc.haskell.org/trac/ghc/ticket/16166>, I filed the ticket, then after failing to reproduce the bug with cabal, assumed it must be a stack bug. Fortunately, RyanGlScott noticed and was able to confirm that it is in fact a GHC bug. Ryan explained that my problem reproducing with cabal is due to differences in the profiling options used by stack and cabal. In summary, it would be helpful to have some instructions on how to take a bug produced using Stack to one produced without. For example, if `stack build [--profile] foo` produces a compile bug, how should I use cabal to definitively determine if the bug is a problem with Stack or GHC? Presumably it would begin with `cabal sandbox init`. Are there special options to put in the cabal.config file so that cabal uses the same profiling options as stack? Will those options be used when building all dependencies? Thanks, Eric Crockett

2 1

Gitlab pain
by Simon Peyton Jones 19 Jan '19

19 Jan '19

I'm getting lost in a maze of twisty little passages, all alike. I'm looking at https://gitlab.haskell.org/ghc/ghc/merge_requests/10#note_1877 and https://gitlab.haskell.org/ghc/ghc/merge_requests/10 But the note in the former starting "Another module should reference the symbol..." doesn't show up in the latter, anywhere. How can I see the current state of play on this MR, the ground truth? Simon

8 10