- ghc-devs - Haskell.org

multiple top level Main.main binders in STG
by Csaba Hruska 02 Nov '18

02 Nov '18

Hello, I added an STG exporter to my modified GHC to do experiments with the STG representation of the program. I noticed that there are multiple top-level binders for *Main.main* function. Is this a convention or a bug? Regards, Csaba Hruska Here is an example code snippet of the exported STG of the Main module: Main.main2 = closure (F:) (B:) { case Main.$wupto 1# 10000000# of sat.s16537 { DEFAULT -> case Main.$wxsum 0# sat.s16537 of ww.s16538 { DEFAULT -> case GHC.Show.$wshowSignedInt 0# ww.s16538 GHC.Types.[] of ww4.s16539 { GHC.Prim.(#,#) ww5.s16540 ww6.s16541 -> GHC.Types.: ww5.s16540 ww6.s16541 } } }} Main.main1 = closure (F:) (B: void.040) { GHC.IO.Handle.Text.hPutStr2 GHC.IO.Handle.FD.stdout Main.main2 GHC.Types.True GHC.Prim.void#} *Main.main* = closure (F:) (B: void.040) { Main.main1 GHC.Prim.void#} Main.main3 = closure (F:) (B: void.040) { GHC.TopHandler.runMainIO1 Main.main1 GHC.Prim.void#} *Main.main* = closure (F:) (B: void.040) { Main.main3 GHC.Prim.void#}

2 3

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

RE: Hadrian build failed
by Andrey Mokhov 01 Nov '18

01 Nov '18

Hello Yotam, Could you please report this as a bug on GHC Trac? https://ghc.haskell.org/trac/ghc/wiki/ReportABug I couldn’t quickly reproduce your issue, however, I run into another seemingly unrelated problem. P.S.: Note that build instructions in my blog post got slightly out of date after the Hadrian move – I’ve fixed this. Cheers, Andrey -------- Forwarded Message -------- Subject: Hadrian build failed Date: Thu, 1 Nov 2018 20:33:14 +0200 From: Yotam Ohad <yotam2206(a)gmail.com><mailto:yotam2206@gmail.com> To: ghc-devs(a)haskell.org<mailto:ghc-devs@haskell.org> Hi, I'm trying to build with hadrian (https://blogs.ncl.ac.uk/andreymokhov/building-ghc-on-windows/) I get an error when running: stack exec hadrian -- --directory ".." -j --flavour=quickest --configure md5sum: 'standard input': no properly formatted MD5 checksum lines found ERROR: mingw-w64-x86_64-crt-git-5.0.0.4795.e3d96cb1-1-any.pkg.tar.xz appears to be corrupted, please delete it and try again. ) Deleting and trying again results in the same error. Any idea on how to solve this? Yotam

1 0

Hadrian build failed
by Yotam Ohad 01 Nov '18

01 Nov '18

Hi, I'm trying to build with hadrian ( https://blogs.ncl.ac.uk/andreymokhov/building-ghc-on-windows/) I get an error when running: stack exec hadrian -- --directory ".." -j --flavour=quickest --configure md5sum: 'standard input': no properly formatted MD5 checksum lines found ERROR: mingw-w64-x86_64-crt-git-5.0.0.4795.e3d96cb1-1-any.pkg.tar.xz appears to be corrupted, please delete it and try again. ) Deleting and trying again results in the same error. Any idea on how to solve this? Yotam

1 0

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