April 2014 - ghc-devs

Strange checkout message
by Simon Peyton Jones 28 Apr '14

28 Apr '14

Herbert or others, What does this mean (in a clean tree) git checkout wip/orf Checking out files: 100% (159/159), done. M utils/haddock Branch wip/orf set up to track remote branch wip/orf from origin. Switched to a new branch 'wip/orf' simonpj@cam-05-unx:~/code/HEAD-3$ What's all this about haddock being modified? I've just checked out a branch, which is supposed to make everything line up, isn't it? Do you need to say "git submodule update" as well? Could this be documented in the (upcoming?) workflows page? Thanks Simon

3 2

Status updates
by Austin Seipp 27 Apr '14

27 Apr '14

Hello all, At the behast of Simon&Simon, we're going to start doing weekly summary updates. We generally meet every week, but lots of times people may not be privvy to our plans. Here's to fixing that! (I would have started last week actually - but I got cut off by a hardware failure last week due to a lightning storm that fried some stuff! Nothing ultra critical, and after a little time and some replacements, though, everything seems OK.) So here's a status summary of what I've been up to, and what the plans are: - Last week, I was cut short on time due to hardware failure, but I spent time this past weekend playing catch-up a bit. - The new OverloadedRecordFields extension is Ready To Go, as I hinted on the list earlier. You can find the work on 'wip/orf' branches in GHC and Haddock. Thanks to Adam, catching this back up to HEAD did not take very long. I would like to merge it within the next week before it bitrots any further. If you're working on a branch dealing with the renamer, name resolution, desugaring, be warned! Big patch incoming! - The Applicative/Monad changes are on their way. After some minor fiddling this morning, the patches are about 95% complete I'd say - they just require a few minor touchups to some upstream libraries. I'd like to merge the AMP patches within the week if possible. They're pending review from the Core Libraries committee now. This patch should not negatively impact anyone working on base right now, I imagine. Or at least not very much. - I spent some time on a new optimization for low-level memory copies, and support for -march/-mcpu in GHC as a side project, so we can take advantage of CPU-specific features more easily. After some fumbling on Saturday and wanting to merge them, I got stalled by a problem, but I think I see my (horrific, stupid, stupid) error now upon review. Hopefully I can get this in soon. - I also spent time this week trying something else fun: I spent a few hours dealing with the Coverity static analyzer tool, attempting to run it over the GHC Runtime system. I succeeded! According to their statistics, it has a total of 124,074 LOC analyzed (this includes header files), with 44 detected possible defects throughout, with a defect ratio of 0.35. If their claims are to be believed, they typically hit within a 5-20% false positive rate. That would mean 30 of these bugs could be real, in fact. At the moment, Scan results are not public, and I do not (yet) have access to the defects. If you'd like access, don't worry - I'll be sending out another email soon about this, and who wants access to the reports... If you'd like to know more, see https://scan.coverity.com - I made some merges to the GHC branch, and all outstanding merges are now done, minus one from Carter, which I will take care of soon (I made it fall out of date, totally my fault). So far, the 7.8.3 branch contains about 7 bug fixes, but more are surely going to be on the way. - There's a new 7.8 FAQ page - https://ghc.haskell.org/trac/ghc/wiki/GHC-7.8-FAQ - over the past few weeks, I've spent time talking to users and collecting some pitfalls they've run into, since a lot of things changed this cycle. This page is preliminary, but *many* people have been tripped up by the few things in there! If you've encountered some stumbling block with 7.8, please add it to the page. Also, if the wording is confusing, please re-word it if you can, or tell me! I will advertise this FAQ more widely to glasgow-haskell-users soon. ------------------------------------------------------------------------------------------ But what about this week? Well: - Like I said above, I'll be merging some things, hopefully including: my optimization, ORF, and the AMP changes. Watch this space. - I will be triaging bugs. I've been putting this off because it's a bit tedious, but I'm likely going to start after this email and Just Do It. Prepare your inbox, depending on how well I can wield the 'bulk edit' feature. By the end of it, we should have an accurate depiction of what we want in 7.8.3. - On that note, we'll be using a new milestoning policy. Things filed at 7.4 stage will now be demoted in priority, since the 7.8 branch is done. The 7.6 tickets will NOT be re-milestoned at all - they could be young, and their priority shouldn't be touched unfairly and preemptively. Most people don't need to care about this, except possibly me and Herbert. But if you do want to move something around, please let me know, and I'll fill you in on the details. - I've been looking into our CI setup for GHC, and evaluating things. Right now though, I am directly working on getting Windows build bots set up on Gabor's infrastructure. He gave me the credentials, and hopefully this should not take long, it just slipped my mind. But mostly I've been looking at CI systems for Hackage, so that we can try to continuously integrate a subset of important packages against GHC over time. Right now, we have Travis-CI thanks to Herbert, but not quite everyone uses this (or doesn't properly configure it to e.g. test HEAD). This would really help find things in the future, I think, especially closer to release. It would also really help find nasty bugs in the RCs, like the dreaded #8978 Right now, after some thought, I'm looking into Michael's Stackage as a starting point for this, as he's done some awesome work. But I haven't yet done so in anger, and there are some other things I want to try too. ------------------------------------------------------------------------------------------ I think that's all for now. Do let me know if you have questions. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

5 5

Cross-compiling to Haiku
by Jessica Hamilton 27 Apr '14

27 Apr '14

Hi, I seem to have managed to build a cross-compiler for Haiku, but am having trouble installing it. Possibly I'm missing something during the build, which didn't get pointed out to me at the time. On the Linux host, the build was basically: export PATH=$PATH:/path/to/haiku/gcc4/cross-compiler ./configure --target=i586-pc-haiku --enable-unregisterised --prefix=/opt make make binary-dist In Haiku, after editing configure to set GHC_PWD=pwd (the bundled ghc_pwd is built for the host, not the target...), that part seems to go well. But in make install I get the following errors/output: > ./configure --prefix=/boot/home/config/non-packaged .... Configuration done, ready to 'make install' > make install make -r --no-print-directory -f ghc.mk install BINDIST=YES NO_INCLUDE_DEPS=YES ghc.mk:680: libraries/old-time/ghc.mk: No such file or directory ghc.mk:680: libraries/haskell98/ghc.mk: No such file or directory ghc.mk:680: libraries/haskell2010/ghc.mk: No such file or directory make[1]: *** No rule to make target `libraries/haskell2010/ghc.mk'. Stop. make: *** [install] Error 2 I presume those are the standard libraries it's trying to install? Jessica

2 1

RFC: template-haskell & Data.Map vs. Prelude.lookup use
by Herbert Valerio Riedel 25 Apr '14

25 Apr '14

Hello *, In order to address https://github.com/haskell/cabal/issues/1811 I've prepared a commit for review at https://git.haskell.org/ghc.git/commitdiff/refs/heads/wip/drop-containers-d… However, I'm wondering if we really need Data.Map, or if would be equally ok to simply use O(n) Prelude.lookup-style dictionary Does anyone here happen to have an estimate for how large the dictionary in https://git.haskell.org/ghc.git/blob/HEAD:/libraries/template-haskell/Langu… (which is the only use of Data.Map in TH) typically gets? Cheers, hvr

3 4

Adding Doxygen (or other documentation tool) comments to GHC patches?
by Howard B. Golden 25 Apr '14

25 Apr '14

Hi, I am working on a patch for GHC Trac ticket #9021. I wonder whether it would be welcome or unwelcome to include Doxygen (or other documentation tool) comments in the patch? If another tool is preferred, please recommend it. Thanks. Howard B. Golden Northridge, CA

3 2

make 2 FAST=YES
by Simon Peyton Jones 25 Apr '14

25 Apr '14

When I say "make 2 FAST=YES" in compiler/, the make system is supposed to recompile the stage-2 compiler, but ignoring the fact that the stage-1 compiler has changed. It used to do that. But now it doesn't. It recompiles every module in GHC, and every module in the base libraries on which GHC depends. The recompilation checker then spots that nothing has changed, but it still takes several unnecessary minutes. Would it be possible to restore the old behaviour? It saves quite a lot of time when rebuilding stage2 after a minor change. Thanks! Simon

1 0

Patches fixing a few test failures
by Daniel Fischer 25 Apr '14

25 Apr '14

I've prepared two patches fixing some test failures. The first passes '-ignore-dot-ghci' to all tests, not only the ghci way, which deals with forgetting to pass the flag when the test is invoked with '-- interactive' from a makefile, as was the case with T8333. The second removes the now-obsolete pragma setting '-fno-warn-amp' from spec001. I didn't notice the trailing whitespace that was also removed in time, sorry, but I hope the clutter from that is not too bad. Kindly revise the patches, please.

1 0

More validate failures
by Daniel Fischer 25 Apr '14

25 Apr '14

Running the full testsuite (sh validate --testsuite-only --slow), I get a lot of unexpected failures (45 on this run). typecheck/should_run/tcrun045 fails due to Compile failed (status 256) errors were: [1 of 1] Compiling Main ( tcrun045.hs, tcrun045.o ) tcrun045.hs:24:1: Illegal implict parameter ‘?imp::Int’ In the context: (?imp::Int) While checking the super-classes of class ‘D’ In the class declaration for ‘D’ and 6.12, 7.0, 7.2 and 7.8 refuse the file with the same error, only 7.4 and 7.6 accept it. Is that a regression or are 7.4 and 7.6 wrong and it shouldn't have compiled? Then I get a lot of optllvm failures, like =====> GMapAssoc(optllvm) 891 of 3955 [0, 8, 0] cd ./indexed-types/should_run && '/home/dafis/GHC/virgo/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -ignore-dot-ghci -fno-ghci-history -o GMapAssoc GMapAssoc.hs -O -fllvm -package containers >GMapAssoc.comp.stderr 2>&1 cd ./indexed-types/should_run && ./GMapAssoc </dev/null >GMapAssoc.run.stdout 2>GMapAssoc.run.stderr /bin/sh: Zeile 1: 21331 Speicherzugriffsfehler ./GMapAssoc < /dev/null > GMapAssoc.run.stdout 2> GMapAssoc.run.stderr Wrong exit code (expected 0 , actual 139 ) Stdout: Stderr: *** unexpected failure for GMapAssoc(optllvm) or =====> qq007(optllvm) 1161 of 3955 [0, 10, 0] cd ./quasiquotation/qq007 && $MAKE -s --no-print-directory TH_QQ cd ./quasiquotation/qq007 && '/home/dafis/GHC/virgo/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -ignore-dot-ghci -fno-ghci-history --make Test -O -fllvm -v0 >qq007.comp.stderr 2>&1 /bin/sh: Zeile 1: 25528 Speicherzugriffsfehler '/home/dafis/GHC/virgo/bindisttest/install dir/bin/ghc' -fforce-recomp - dcore-lint -dcmm-lint -dno-debug-output -no-user-package-db -rtsopts -ignore- dot-ghci -fno-ghci-history --make Test -O -fllvm -v0 > qq007.comp.stderr 2>&1 Compile failed (status 35584) errors were: *** unexpected failure for qq007(optllvm) which I don't know what to make of, other optllvm tests work fine. Has anybody an idea what might cause those? T6145 fails to compile with a type error and a missing argument to the `MG` constructor. Apparently the API changed but the test was not updated. T8639_api has unexpected stdout, the type is printed as `Bool` instead of the expected `GHC.Types.Bool`, I guess one should update the expected output, but maybe the type should be printed qualified? =====> T4891(normal) 1610 of 3955 [0, 14, 0] cd ./ghc-api/T4891 && $MAKE -s --no-print-directory T4891 </dev/null >T4891.run.stdout 2>T4891.run.stderr Wrong exit code (expected 0 , actual 2 ) Stdout: Stderr: T4891.hs:23:19: Module ‘PrelNames’ does not export ‘iNTERACTIVE’ gmake[2]: *** [T4891] Fehler 1 *** unexpected failure for T4891(normal) T3064 and T6048 allocate slightly more than they are allowed to (about 1% resp. 0.15% too much). Generally, I have the impression that whoever decides the 64-bit Linux allocation numbers has a system where the figures aresystematically lower than on mine, maybe the expected numbers should be given a bit higher. joao-circular fails the optllvm way with unexpected stdout: Actual stdout output differs from expected: --- ./programs/joao-circular/joao-circular.stdout 2014-04-24 11:18:07.363987627 +0200 +++ ./programs/joao-circular/joao-circular.run.stdout 2014-04-24 14:27:38.927486429 +0200 @@ -68,13 +68,6 @@ PUSHa "recfact" 2 PUSHa "x" 2 LOAD -PUSHa "x" 1 -PUSHa "x" 2 -LOAD -PUSHi 1 -SUB -STORE -CALL "recfact" MUL STORE C_Ident_1 "end_if_1": @@ -83,4 +76,4 @@ Detected Semantic Errors: [C_E_Name_AD_1 (C_Ident_1 "a")] -[] +[C_E_T_NC_1 C_Errortype_1 C_Inttype_1,C_E_T_while_1,C_E_T_BOP_1,C_E_T_NC_1 C_Errortype_1 C_Errortype_1,C_E_T_BOP_1,C_E_T_NC_1 C_Errortype_1 C_Errortype_1,C_E_T_BOP_1,C_E_T_if_t_e_1,C_E_T_BOP_1,C_E_T_NC_1 C_Errortype_1 C_Inttype_1,C_E_T_NC_1 C_Errortype_1 C_Errortype_1,C_E_T_BOP_1] *** unexpected failure for joao-circular(optllvm) which I have no idea how to interpret. T7919 (optllvm) fails to compile. The ghci way, although it passed, uses a lot of memory (~ 2.5 G), temporarily froze my box, and got my browser OOM- killed. The other ways also use a lot of memory (~1.1 G - 1.7 G). While it looks as though it is to be expected that the test uses a fair bit of memory, perhaps it should not use quite as much. If somebody more knowledgeable looks at it that might be good. simplCore/should_compile/spec001 fails due to unexpected stdout, the `-fno- warn-amp` flag is deprecated, the pragma should be removed probably. arr016 (optllvm) failed with what looks serious: =====> arr016(optllvm) 3092 of 3955 [0, 32, 0] cd ./array/should_run && '/home/dafis/GHC/virgo/bindisttest/install dir/bin/ghc' -fforce-recomp -dcore-lint -dcmm-lint -dno-debug-output -no-user- package-db -rtsopts -ignore-dot-ghci -fno-ghci-history -o arr016 arr016.hs -O -fllvm >arr016.comp.stderr 2>&1 cd ./array/should_run && ./arr016 </dev/null >arr016.run.stdout 2>arr016.run.stderr /bin/sh: Zeile 1: 23929 Abgebrochen ./arr016 < /dev/null > arr016.run.stdout 2> arr016.run.stderr Wrong exit code (expected 0 , actual 134 ) Stdout: Stderr: arr016: internal error: MUT_ARR_PTRS_DIRTY object entered! (GHC version 7.9.20140424 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *** unexpected failure for arr016(optllvm) T7653(ghci) managed to get my browser OOM-killed again (yes, I was naive enough to restart it), using ~2.7 G of memory. And the test timed out - also when running only T7653 without the browser to compete for the memory. The threaded1 way uses even more memory (~2.9 G), other ways much, but not that much. posix002(threaded2) failed with +posix002: failed to create OS thread: Resource temporarily unavailable *** unexpected failure for posix002(threaded2) but that isn't replicable running the test alone.

2 1

Help with cast error
by Conal Elliott 25 Apr '14

25 Apr '14

I'd appreciate help with a cast-related Core Lint error I'm getting with a GHC plugin I'm working on: Argument value doesn't match argument type: Fun type: Enc (Vec ('S 'Z) Bool) ~ (Bool, ()) => EP (Enc (Vec ('S 'Z) Bool)) -> EP (Bool, ()) Arg type: ~R# (Enc (Vec ('S 'Z) Bool)) (Bool, ()) Arg: CO Sub (TFCo:R:EncVec[0] <'Z>_N <Bool>_N) ; (Sub TFCo:R:EncBool[0], Sub (TFCo:R:EncVec0[0] <Bool>_N))_R (I omitted the module prefixes for brevity.) Do I have a role wrong here, or maybe something more fundamental? I can easily supply more info if it'd help. Thanks, -- Conal

2 2

RE: Cloning ghc-7.8
by Simon Peyton Jones 24 Apr '14

24 Apr '14

OK. So are you saying that you can't reliably change to a different branch in an existing tree, but rather must freshly clone from the source each time you want to check out a different branch? That seems a bit extreme. I thought switching branches is precisely what git is good at. Still I'll blow away my tree and try what you say. Simon | -----Original Message----- | From: Herbert Valerio Riedel [mailto:hvriedel@gmail.com] | Sent: 24 April 2014 11:30 | To: Simon Peyton Jones | Cc: Austin Seipp | Subject: Re: Cloning ghc-7.8 | | On 2014-04-24 at 12:14:16 +0200, Simon Peyton Jones wrote: | > I tried the sequence below and got this: | | maybe try this sequence that was suggested by Austin on #ghc a couple | of | days ago: | | <thoughtpolice> (sync-all has a little difficulty with the submodules | here, and you'll end up needing to always clean anyway due to interface | changes, etc) | <thoughtpolice> 'git clone -b ghc-7.8 git://git.haskell.org && cd ghc | && ./sync-all get -b ghc-7.8' should do it |

3 2