October 2018 - ghc-devs

Visible dependent quantification / CUSKs
by Richard Eisenberg 02 Nov '18

02 Nov '18

Hi all, I see visible dependent quantification and top-level kind signatures on the release plan for GHC 8.8. Is there a diff for these I've missed? Or is something in the works? Sorry if I've just missed it go by! Thanks, Richard

2 2

Validating with LLVM
by Travis Whitaker 01 Nov '18

01 Nov '18

Hello GHC Devs, I'm working on a very tiny patch for GHC. The patch concerns the LLVM code generator, and I'd like to run the validate script. ./validate ignores mk/ build.mk (which is probably correct) and it doesn't seem to be using the LLVM backend. LLVM tools are on the PATH; I'm working from the ghc-8.4 branch so I'm using LLVM 5. Is it possible to validate with the LLVM backend? If not, what's considered a sufficiently thorough test? Apologies if I'm missing something obvious. Thanks! Travis

2 1

ghc-in-ghci memory usage
by Matthew Pickering 31 Oct '18

31 Oct '18

I just tried using the ghc-in-ghci script again and it appears that the memory usage problems have been resolved. Probably thanks to Simon Marlow who fixed a lot of space leaks in ghc. A reminder of how to use it: ./utils/ghc-in-ghci/run.sh -j<n> will load ghc into ghci so you can `:r` to recompile when you make a change. Cheers, Matt

3 3

CircleCI currently failing - possibly due to lack of disk space?
by Matthew Pickering 31 Oct '18

31 Oct '18

The bridge which sends diffs to circleci is currently failing with the following error: {"args":["clone","ssh://git@phabricator-origin.haskell.org:2222/diffusion/GHCDIFF/GHC-Differentials.git","/tmp/ghc-diffs-1008dbb33e68821b"],"prog":"git","code":128,"err":"Clonage dans '/tmp/ghc-diffs-1008dbb33e68821b'...\nfatal: Impossible d'accéder au répertoire de travail courant: No such file or directory\nfatal: échec de index-pack\n","type":"Non-zero exit code","out":""} https://phabricator.haskell.org/harbormaster/build/62371/2/ https://github.com/alpmestan/phab-circleci-bridge/blob/master/src/Main.hs#L… The repo is 150mb big so it is possible that the machine running the bridge has run out of disk space as it clones this repo repeatedly. Could someone look into this? Cheers, Matt

2 1

ghc-prim package-data.mk failed
by Simon Peyton Jones 30 Oct '18

30 Oct '18

This has started happening when I do 'sh validate -no-clean' "inplace/bin/ghc-cabal" configure libraries/ghc-prim dist-install --with-ghc="/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-stage1" --with-ghc-pkg="/home/simonpj/5builds/HEAD-5/inplace/bin/ghc-pkg" --disable-library-for-ghci --enable-library-vanilla --enable-library-for-ghci --disable-library-profiling --enable-shared --with-hscolour="/home/simonpj/.cabal/bin/HsColour" --configure-option=CFLAGS="-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline" --configure-option=LDFLAGS=" " --configure-option=CPPFLAGS=" " --gcc-options="-Wall -fno-stack-protector -Werror=unused-but-set-variable -Wno-error=inline " --with-gcc="gcc" --with-ld="ld.gold" --with-ar="ar" --with-alex="/home/simonpj/.cabal/bin/alex" --with-happy="/home/simonpj/.cabal/bin/happy" Configuring ghc-prim-0.5.3... configure: WARNING: unrecognized options: --with-compiler checking for gcc... /usr/bin/gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc accepts -g... yes checking for /usr/bin/gcc option to accept ISO C89... none needed checking whether GCC supports __atomic_ builtins... no configure: creating ./config.status config.status: error: cannot find input file: `ghc-prim.buildinfo.in' libraries/ghc-prim/ghc.mk:4: recipe for target 'libraries/ghc-prim/dist-install/package-data.mk' failed make[1]: *** [libraries/ghc-prim/dist-install/package-data.mk] Error 1 Makefile:122: recipe for target 'all' failed make: *** [all] Error 2 I think it is fixed by saying 'sh validate' (i.e. start from scratch). But that is slow. I'm not 100% certain about the circumstances under which it happens, but can anyone help me diagnose what is going on when it does? Thanks SImon

3 3

Hitting RTS bug on GHC 8.0.2
by Harendra Kumar 30 Oct '18

30 Oct '18

Hi, I got the following crash in one of my CI tests ( https://travis-ci.org/composewell/streamly/jobs/448112763) test: internal error: RELEASE_LOCK: I do not own this lock: rts/Messages.c 54 (GHC version 8.0.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug I have hit this just once yet. Is this worth opening a ticket, given that this is an older version of the compiler? Has something like been fixed since then or might this be present in newer versions as well? -harendra

2 2

Re: [GHC DevOps Group] The future of Phabricator
by Ben Gamari 30 Oct '18

30 Oct '18

Andres Löh <andres(a)well-typed.com> writes: > Hi. > >> Unfortunately, if I am not mistaken, GitLab also has a big problem. It requires the use of GitLab CI — i.e., we cannot use CircleCI and Appveyor with it. (At least, that is my current understanding. Please correct me if I am wrong.) > > Just a clarification on this issue. > > I might be wrong, but my understanding is that: > > - Gitlab offers its own Gitlab CI, but it doesn't force you to use it, > and doesn't prevent you from using other CI solutions. > > - Web-based CI solutions have to specifically support Gitlab for you to > be able to use them with Gitlab. > > - To my knowledge, Appveyor supports Gitlab, but Circle and Travis > currently do not. I know that there are issues open for these systems > to support Gitlab, but I have no idea whether this is likely to happen > anytime soon. For example, for Circle, the discussion seems to be > here: https://circleci.com/ideas/?idea=CCI-I-248 > That is entirely correct; however, we have already invested the effort to build a bridge between Phabricator and CircleCI (only to have deployment complicated by an apparent Phabricator bug). The implementation of this didn't take particularly long and I expect migrating this work to GitLab would be if anything easier (since GitLab has a more-standard REST interface than Phabricator's Conduit). Cheers, - ben

1 0

Using GHC Core as a Language Target
by Ara Adkins 29 Oct '18

29 Oct '18

Hey All, I was chatting to SPJ about the possibility of using GHC Core + the rest of the GHC compilation pipeline as a target for a functional language, and he mentioned that asking here would likely be more productive when it comes to the GHC API. I'm wondering where the best place would be for me to look in the API for building core expressions, and also whether it is possible to trigger the GHC code-generation pipeline from the core stage onwards. Best, Ara

3 4

CI status
by Ben Gamari 29 Oct '18

29 Oct '18

Hi everyone, As you likely have noticed, GHC's CI is a bit of a mess since the Hadrian merge, especially for differentials based on commits prior to the merge. The problem is a tiresome limitation of Harbormaster's CI strategy [1]. I have taken this opportunity to finally move testing of Differentials to CircleCI. Unfortunately this has taken longer than anticipated due to more tiresome Phabricator issues. At the moment the only guidance I can offer for those in need of CI is to sit tight; the problem is being worked on. Cheers, - Ben [1] Namely, Harbormaster attempts to reuse working trees to perform builds. However, it fails to remove stale submodules, meaning any attempt to checkout a post-Hadrian-merge commit fails.

1 0

Treatment of unknown pragmas
by Ben Gamari 28 Oct '18

28 Oct '18

Hi everyone, Recently Neil Mitchell opened a pull request [1] proposing a single-line change: Adding `{-# HLINT ... #-}` to the list of pragmas ignored by the lexer. I'm a bit skeptical of this idea. Afterall, adding cases to the lexer for every tool that wants a pragma seems quite unsustainable. On the other hand, a reasonable counter-argument could be made on the basis of the Haskell Report, which specifically says that implementations should ignore unrecognized pragmas. If GHC did this (instead of warning, as it now does) then this wouldn't be a problem. Of course, silently ignoring mis-typed pragmas sounds terrible from a usability perspective. For this reason I proposed that the following happen: * The `{-# ... #-}` syntax be reserved in particular for compilers (it largely already is; the Report defines it as "compiler pragma" syntax). The next Report should also allow implementations to warn in the case of unrecognized pragmas. * We introduce a "tool pragma" convention (perhaps even standardized in the next Report). For this we can follow the model of Liquid Haskell: `{-@ $TOOL_NAME ... @-}`. Does this sound sensible? Cheers, - Ben [1] https://github.com/ghc/ghc/pull/204

14 36