January 2009 - Glasgow-haskell-users

gcc version to use on sparc/solaris
by Duncan Coutts 11 Jan '09

11 Jan '09

On Fri, 2009-01-02 at 21:06 +1100, Ben Lippmeier wrote: > I'm running into some huge compile times that I'm hoping someone will > have some suggestions about. When compiling Parser.hs the intermediate > .hc file is 4MB big, and is taking GCC 4.2.1 more than 2 hours to get > through. > > Another attempted compile of GHC 6.8.3 is stuck on > libraries/template-haskell/Language/Haskell/TH/Syntax.hs with a 4MB > intermediate .hc file. Here is what I've discovered... I built four versions of gcc and used them to build ghc-6.8.3. I selected the last point release of the last four major gcc releases: gcc-4.0.4 gcc-4.1.2 gcc-4.2.4 gcc-4.3.2 Summary: gcc-4.0.4 or gcc-4.1.2 seems to be the best choice at the moment for ghc on sparc/solaris. gcc-4.0.4 ========= This version passes all expected tests on the gcc testsuite. Using it to build ghc-6.8.3 works fine and it does not take too long. The ghc testsuite result looks like: 2128 total tests, which gave rise to 8040 test cases, of which 1 caused framework failures 1561 were skipped 6130 expected passes 281 expected failures 0 unexpected passes 48 unexpected failures Unexpected failures: 1861(normal,optc,hpc,profc,threaded1,threaded2) barton-mangler-bug(normal,hpc,threaded1) cabal01(normal) conc042(threaded2) conc043(threaded2) conc044(threaded2) conc045(threaded2) conflicting_flags(normal) enum01(hpc) ffi017(ghci) ffi019(normal,optc,hpc,profc,ghci,threaded1,threaded2) ghciprog004(normal) hClose002(normal,optc,hpc,profc,ghci,threaded1,threaded2) joao-circular(normal,optc,hpc,profc,threaded1,threaded2) num012(normal,optc,hpc,profc,ghci,threaded1,threaded2) seward-space-leak(ghci) testblockalloc(normal,threaded1) Some fail in fairly simple ways: cabal01 fails because Solaris tar does not support -C conflicting_flags fails due to a difference in output: -ghc: cannot use `-V' with `--print-libdir' +ghc-6.8.3: cannot use `-V' with `--print-libdir' hClose002 fails with a different error: -Left hClose: invalid argument (Bad file descriptor) +Left hClose: invalid argument (Bad file number) 1861 fails because ghc uses C99 INFINITY macro without using C99 and Solaris header files are more strict about standards than other systems. http://hackage.haskell.org/trac/ghc/ticket/2929 Some look a bit more scary: testblockalloc fails with "out of memory (requested 8388608 bytes)" num012 produces different output: --2147483648 +2147483647 looks like overflow, so definitely something wrong. A number of tests timeout: seward-space-leak(ghci) joao-circular(all) barton-mangler-bug(all) A few tests get bus errors: conc042, conc043, conc044, conc045 ghciprog004 ffi019(all) gcc-4.1.2 ========= This version passes all expected tests on the gcc testsuite. Using it to build ghc-6.8.3 works fine and it does not take too long. The ghc testsuite result looks like: 2128 total tests, which gave rise to 8040 test cases, of which 1 caused framework failures 1561 were skipped 6125 expected passes 281 expected failures 0 unexpected passes 49 unexpected failures Unexpected failures: 1861(normal,optc,hpc,profc,threaded1,threaded2) barton-mangler-bug(normal,optc,hpc,threaded1,threaded2) cabal01(normal) conc042(threaded2) conc043(threaded2) conc044(threaded2) conc045(threaded2) conflicting_flags(normal) ffi017(ghci) ffi019(normal,optc,hpc,profc,ghci,threaded1,threaded2) ghciprog004(normal) hClose002(normal,optc,hpc,profc,ghci,threaded1,threaded2) joao-circular(normal,optc,hpc,profc,threaded1,threaded2) num012(normal,optc,hpc,profc,ghci,threaded1,threaded2) seward-space-leak(ghci) testblockalloc(normal,threaded1) The only difference is that enum01(hpc) does not fail and barton-mangler-bug fails in two more ways (optc, threaded2) gcc-4.2.4 ========= This fails 4 tests on the gcc testsuite. This is the version that gives us massive compile times for larger .hc files (8 hours+ for Syntax.hc). I thought that using -fno-unit-at-a-time would help but ghc is already using that so no luck. It does eventually build but takes nearly 2 days. No testsuite results yet. I'm not sure I can be bothered. gcc-4.3.2 ========= This fails 50 tests on the gcc testsuite. Does not work with ghc-6.8.3 at all, presumably due to the evil mangler. This manifests itself as ./configure failing when it tries to compile and run utils/pwd/pwd: checking for path to top of build tree... /tmp/ghc15055_0/ghc15055_0.hc: In function 'sqD_ret': /tmp/ghc15055_0/ghc15055_0.hc:95:0: note: if this code is reached, the program will abort [...] /tmp/ghc15055_0/ghc15055_0.hc: In function '__stginit_Main': /tmp/ghc15055_0/ghc15055_0.hc:750:0: note: if this code is reached, the program will abort configure: error: cannot determine current directory Indeed it does abort: $ utils/pwd/pwd Illegal Instruction (core dumped) Duncan

2 3

GHC head Solaris bot failing with HsColour needed but wasn't found.
by Karel Gardas 10 Jan '09

10 Jan '09

Hello, I've noticed that my GHC head solaris bot is failing with HsColour needed but wasn't found. Set HSCOLOUR_SRCS=NO if you don't want to use it message on stage1 build since Jan 04. Please let me know what I need to install in order to make head build able again. Thanks, Karel

3 3

Build system idea
by Simon Marlow 10 Jan '09

10 Jan '09

Simon PJ and I had a talk about the build system earlier today, I thought I'd float the idea we discussed (I should admit that the idea was mine, lest Simon PJ think I'm attributing bad ideas to him :-). This is not completely thought through, but I'm pretty sure a solution exists along these lines that would improve things for us. Ok, the starting point is this: - Cabal has code to generate Makefiles. Almost nobody uses it except for the GHC build system. It essentially duplicates the build system for compiling Haskell source (but not for installation, haddocking, registration, configuration, etc.) - Cabal is a library I propose we do this: - Extract the code from Cabal that generates Makefiles, and treat it as part of the GHC build system. Rather than generating a Makefile complete with build rules, we generate a Makefile that just has the package-specific metadata (list of modules, etc.), and put the code to actually build the package in the GHC build system. This means we still get to use 'make', we still get to use the .cabal files as metadata, but the build system is more private to GHC, more extensible, and hopefully more understandable and modifiable. We can express dependencies that Cabal currently doesn't know about. It would let us avoid the current uncomfortable situation where we have to feed all kinds of configuration information from the GHC build system into Cabal - Cabal would be essentially just a mechanism for translating the .cabal file into Makefile bindings and package metadata for ghc-pkg. There will undoubtedly be some sticking points where we have to tradeoff duplicating things from Cabal against re-using parts of Cabal which might require modifying Cabal itself. For instance, we could use Cabal for installation, but that means that our build system has to leave everything in the places that Cabal's installation code expects, so it might be more feasible to do installation ourselves, but that means duplicating parts of Cabal. It will probably mean that we have a tighter dependency on Cabal, because we use it as a library rather than a black box; but hopefully we can keep our branch of Cabal more stable and not have to update it so often. Anyway, this is an idea that I think is interesting. Obviously it needs a lot more fleshing out to be a real proposal, but I'm interested in whether anyone thinks this idea is worth persuing, or whether there are better alternatives. Cheers, Simon

16 49

GADT Strangeness
by Dominic Steinitz 10 Jan '09

10 Jan '09

If I remove -XScopedTypeVariables from this http://hpaste.org/13230 then I get the following error message: > Asn1cTestNew.hs:55:27: > GADT pattern match in non-rigid context for `INTEGER' > Solution: add a type signature > In the pattern: INTEGER > In the definition of `referenceTypeAndValAux2': > referenceTypeAndValAux2 ns INTEGER x > = lhs ns <> text " = " <> text (show x) <> semi > Failed, modules loaded: Language.ASN1, ASNTYPE. At the very least the message is unhelpful. It was only by accident I decided to put in -XScopedTypeVariables. Can anyone offer an explanation as to what is happening? Dominic.

3 6

ghc 6.10.1 on freebsd 7 amd64 - ghci problems
by Markus Barenhoff 08 Jan '09

08 Jan '09

Hi! Because the ports seem not to get updated, I tried to compile ghc 6.10.1 under freebsd 7 on amd64 myself. For compiling I first used the ports ghc version (6.8.3) and then, in a second try I used the self build 6.10.1 to build it again. I added building of api docs with: $ echo "HADDOCK_DOCS = YES" >> mk/build.mk I configured it with a simple ./configure and not more options. The compiler seems to work well on both versions. But if i try to start ghci I get the following: ---- snip ---- $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: Unable to mmap() for jump islands Loading package ghc-prim ... ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for x86_64-unknown-freebsd): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ---- snip ---- It looks he has some kind of library loading problems? Any ideas? Thnx and regards Markus

3 13

ghc 6.10.2 - when?
by Bulat Ziganshin 08 Jan '09

08 Jan '09

Hello glasgow-haskell-users, are you have any plans of releasing ghc 6.10.2 soon? i ask since there are plans to issue gtk2hs soon, it will be great to have cleaned up 6.10 behind it -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

building ghc-6.10.1 against readline
by Reid Barton 08 Jan '09

08 Jan '09

Hello all, Here are quick and dirty instructions for building ghc-6.10.1 against readline instead of editline, for anyone who may be interested. 1. Unpack the ghc source and extralibs trees into ~/build/ghc-6.10.1 (Where you put your build tree obviously doesn't matter; I just specify it for clarity.) 2. Download this patch to ~/build: http://mauke.ath.cx/stuff/haskell/ghc-6.10.1-readline.diff 3. Apply the patch by running (from ~/build): patch -p0 < ghc-6.10.1-readline.diff 4. Download the readline package to ~/build/ghc-6.10.1/libraries: http://hackage.haskell.org/packages/archive/readline/1.0.1.0/readline-1.0.1… 5. Unpack it, and create a symlink (in ~/build/ghc-6.10.1/libraries): ln -s readline-1.0.1.0 readline 6. Now in ~/build/ghc-6.10.1, you can run ./configure, make, etc. Thanks to mauke on #haskell for the patch, which is also appended to this email for posterity. Regards, Reid ----------- ghc-6.10.1-readline.diff diff -ru ghc-6.10.1/compiler/ghc.cabal.in ghc-6.10.1-hax/compiler/ghc.cabal.in --- ghc-6.10.1/compiler/ghc.cabal.in 2008-11-03 19:13:13.000000000 +0100 +++ ghc-6.10.1-hax/compiler/ghc.cabal.in 2008-11-10 04:17:42.000000000 +0100 @@ -72,7 +72,7 @@ Build-Depends: unix if flag(editline) - Build-Depends: editline + Build-Depends: readline CPP-Options: -DUSE_EDITLINE GHC-Options: -Wall -fno-warn-name-shadowing -fno-warn-orphans diff -ru ghc-6.10.1/compiler/ghci/InteractiveUI.hs ghc-6.10.1-hax/compiler/ghci/InteractiveUI.hs --- ghc-6.10.1/compiler/ghci/InteractiveUI.hs 2008-11-03 19:13:13.000000000 +0100 +++ ghc-6.10.1-hax/compiler/ghci/InteractiveUI.hs 2008-11-10 04:28:39.000000000 +0100 @@ -66,7 +66,7 @@ #ifdef USE_EDITLINE import Control.Concurrent ( yield ) -- Used in readline loop -import System.Console.Editline.Readline as Readline +import System.Console.Readline as Readline #endif --import SystemExts @@ -327,7 +327,7 @@ Readline.initialize withGhcAppData - (\dir -> Readline.readHistory (dir </> "ghci_history")) + (\dir -> return True {- Readline.readHistory (dir </> "ghci_history") -}) (return True) Readline.setAttemptedCompletionFunction (Just completeWord) @@ -367,8 +367,8 @@ #ifdef USE_EDITLINE liftIO $ do - Readline.stifleHistory 100 - withGhcAppData (\dir -> Readline.writeHistory (dir </> "ghci_history")) + -- Readline.stifleHistory 100 + withGhcAppData (\dir -> return True {- Readline.writeHistory (dir </> "ghci_history") -}) (return True) Readline.resetTerminal Nothing #endif diff -ru ghc-6.10.1/libraries/Makefile ghc-6.10.1-hax/libraries/Makefile --- ghc-6.10.1/libraries/Makefile 2008-11-03 19:13:13.000000000 +0100 +++ ghc-6.10.1-hax/libraries/Makefile 2008-11-10 04:12:01.000000000 +0100 @@ -46,7 +46,7 @@ ifeq "$(Windows)" "YES" SUBDIRS += $(wildcard Win32) endif -SUBDIRS += directory process pretty hpc template-haskell editline Cabal random haskell98 +SUBDIRS += directory process pretty hpc template-haskell readline Cabal random haskell98 # Set GhcBootLibs=YES from the command line to work with just the libraries # needed to bootstrap GHC.

1 0

Re: [reactive] Re: black hole detection and concurrency
by Conal Elliott 07 Jan '09

07 Jan '09

Indeed -- many thanks to Bertram, Sterling, Peter & others for the help! I think getting this bug fixed will solve Reactive's mysterious bugs and unblock its progress. - Conal On Sat, Jan 3, 2009 at 1:20 PM, Peter Verswyvelen <bugfact(a)gmail.com> wrote: > That is very good news! Let's hope it's a bug that is easy enough to > fix, since I guess the RTS is very tricky. > > Thanks for all this effort. It would explain a lot of strange behaviour. > > Cheers, > Peter Verswyvelen > CTO - Anygma.com > > > On Sat, Jan 3, 2009 at 4:48 PM, Bertram Felgenhauer > <bertram.felgenhauer(a)googlemail.com> wrote: > > Conal Elliott wrote: > >> Thanks very much for these ideas. Peter Verswyvelen suggested running > the > >> example repeatedly to see if it always runs correctly. He found, and I > >> verified, that the example runs fine with Bertram's last version of > unamb > >> below, *unless* it's compiled with -threaded and run with +RTS -N2. In > the > >> latter case, it locks up after a while. > > > > It seems that we've found an RTS bug. If a thread is started with > > exceptions blocked, then throwTo might never deliver its exception and > > block forever, as can be seen with the following test program, which > > locks up after a while (immediately with the non-threaded RTS) > > > > import Control.Exception > > import Control.Concurrent > > import Control.Monad > > > > test n = do > > t <- block $ forkIO yield > > yield > > putStr $ show n ++ ": kill\n" > > killThread t > > > > main = forM_ [1..] test > > > > Or, even more convincing: > > > > import Control.Exception > > import GHC.Conc > > > > main = do > > t1 <- block $ forkIO yield > > t2 <- forkIO $ killThread t1 > > yield > > yield > > threadStatus t1 >>= print > > threadStatus t2 >>= print > > > > prints (fairly reliably, it seems): > > > > ThreadFinished > > ThreadBlocked BlockedOnException > > > > (Trac is giving me errors right now. I'm planning to report this later.) > > > >> I also tried a version with brackAsync and found that it eventually > locks up > >> even under ghci. When compiled & run multi-threaded, it locks up almost > >> immediately. > > > >> -- This one locks up after a while even in ghci. When compiled > -threaded > >> -- and run +RTS -N2, it locks up almost immediately. > >> a `race` b = do > >> v <- newEmptyMVar > >> let t x = x >>= putMVar v > >> withThread (t a) $ withThread (t b) $ takeMVar v > >> where > >> withThread u v = brackAsync (forkIO u) killThread (const v) > > > > At the point the 'forkIO' is run, exceptions are blocked, making the > > thread basically immortal. Using > > > >> withThread u v = brackAsync (forkIO $ unblock u) killThread (const v) > > > > we get the same behaviour as with my 'race' - it works for a while, but > > locks up eventually. > > > > I believe that the actual lockup is similar to the test programs above > > in all cases - what's different is just the probability of triggering > > it. > > > > regards, > > > > Bertram > > _______________________________________________ > > Reactive mailing list > > Reactive(a)haskell.org > > http://www.haskell.org/mailman/listinfo/reactive > > > _______________________________________________ > Reactive mailing list > Reactive(a)haskell.org > http://www.haskell.org/mailman/listinfo/reactive >

2 4

GADTs and functional dependencies in ghc 6.10.1
by Reid Barton 07 Jan '09

07 Jan '09

Hello all, I think (hope) this question is different from the ones about GADTs recently discussed on this list. The following program compiles under ghc 6.8.2 but not under ghc 6.10.1: > {-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies, GADTs, KindSignatures, ScopedTypeVariables #-} > > class Foo a fa | a -> fa where > n :: a -> Int > > data Bar :: * -> * -> * where > Id :: Bar a a > > baz :: forall a fa b fb. (Foo a fa, Foo b fb) => Bar a b -> Int > baz Id = n (undefined :: a) ghc 6.10.1's error message: /tmp/fundep.hs:10:0: Couldn't match expected type `fb' against inferred type `fa' `fb' is a rigid type variable bound by the type signature for `baz' at /tmp/fundep.hs:9:21 `fa' is a rigid type variable bound by the type signature for `baz' at /tmp/fundep.hs:9:16 When using functional dependencies to combine Foo a fa, arising from a use of `n' at /tmp/fundep.hs:10:9-26 Foo a fb, arising from the type signature for `baz' at /tmp/fundep.hs:10:0-26 When generalising the type(s) for `baz' I find the message about the `Foo a fb' constraint quite confusing. Can anyone explain this error message to me? If I change the type of Id to Id :: Bar a b, then the program compiles. Regards, Reid

2 1

Re: [reactive] Re: black hole detection and concurrency
by Bertram Felgenhauer 06 Jan '09

06 Jan '09

Peter Verswyvelen wrote: > I fail to understand this part of the code: > case fromException e of > Just ThreadKilled -> do > myThreadId >>= killThread > unblock (race a b) > > So the current thread gets killed synchronously, then then the race function > is evaluated again? The latter I don't get. Let's look at what happens when an asynchronous exception arrives. The current thread gets killed. It gets killed asynchronously; as far as the RTS knows, the exceptionit might happen inside a pure computation which may be accessible to other threads. This means that the RTS has to patch things up so that reentering the corresponding thunks continues the computation - because another thread might need the value later. It does that by traversing the stack and turning update frames into ap nodes on the heap, and linking the entered thunks to those using an indirection (again, see RaiseAsync.c for details). Now in fact, IO actions are indistinguishable from pure computations by the RTS, so this mechanism also makes IO actions resumable, in principle, if you can access the corresponding thunk somehow. Normally you can't - there is no reference to that thunk - but unsafePerformIO gives you that reference. So in the above example, the current thread gets killed. However, the IO action (suspended right before the 'unblock (race a b)') is still accessible through the unsafePerformIO thunk. When another thread enters that thunk, execution resumes at that point. It may also be the same thread if it caught the exception further down the stack and later enters the unsafePerformIO thunk again. I don't understand all the interactions here - I don't know why the code is racy in the parallel RTS. Bertram

6 6