August 2009 - Glasgow-haskell-users

Building just a stage 1 compiler?
by Tim Chevalier 19 Aug '09

19 Aug '09

Hi, Is there a way to tell the GHC build system that I only want to build a stage 1 compiler and the libraries, not a stage 2 compiler? Executing: $ sh boot $ ./configure $ make stage=1 in my build tree still builds the stage 2 compiler as well. Thanks, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc/ * Often in error, never in doubt

3 2

Generating valid Haskell code using the GHC API pretty printer
by Jan Schaumlöffel 18 Aug '09

18 Aug '09

Hello everyone, we are trying to use the GHC API for a source-to-source transformation on Haskell programs. The result of parsing and typechecking a module enables us to apply the transformation, but writing the transformed module back using the pretty printer (Outputable) generates invalid Haskell code. For one thing, since even the names defined in the current module are fully qualified, the resulting code is not valid anymore. This can be worked around, but there is another issue: Simply reading the following program and then writing it out using the pretty printer renders the resulting code invalid. > module Main where > main = do > if True then putStrLn "longlonglonglonglonglongline" > else return () > longlonglonglonglonglonglonglonglonglonglonglongname $ "test" > longlonglonglonglonglonglonglonglonglonglonglongname = putStrLn The result looks like this: > Main.main = do if GHC.Bool.True then > System.IO.putStrLn "longlonglonglonglonglongline" > else > GHC.Base.return () > Main.longlonglonglonglonglonglonglonglonglonglonglongname > GHC.Base.$ > "test" > Main.longlonglonglonglonglonglonglonglonglonglonglongname = System.IO.putStrLn There are two different problems in this output: 1) the indentation of "if ... then ... else" violates the "do"-block layout rule 2) the indentation of the long function call is invalid It looks like those problems could be avoided if the pretty printer could be configured to consistently use "do { ... ; ... }" notation, but we have been unable to figure out how. Is there a canonical way to use the GHC API to pretty print to valid Haskell code? Kind regards, Jan Appended is our current code to execute the transformation above (the module to be read is expected in a file "dummy.hs" for simplicity). Please excuse if this might not be a minimal example. module Main where import GHC import GHC.Paths import Outputable main = do x <- runGhc (Just libdir) $ do dflags <- getSessionDynFlags setSessionDynFlags (dflags { hscTarget = HscNothing, ghcLink = NoLink }) target <- guessTarget "dummy.hs" Nothing setTargets [target] load LoadAllTargets graph <- getModuleGraph let unparsedmod = head graph parsedmod <- parseModule unparsedmod typecheckedmod <- typecheckModule parsedmod let Just renamedsource = renamedSource typecheckedmod (group,_,_,_,_) = renamedsource moduledings = (ms_mod unparsedmod) return (showSDoc (ppr group)) putStr $ x ++ "\n" -- If you're happy and you know it, syntax error!

3 3

what is the path to a particular module?
by S. Alexander Jacobson 15 Aug '09

15 Aug '09

Is there a way from GHCi to discover the path to a particular module that you have imported or loaded? -Alex-

3 2

FFI: Problem with Signal Handler Interruptions
by Levi Greenspan 15 Aug '09

15 Aug '09

Apologies for re-posting this subject here since I had sent already a message to haskell-café 3 days ago, but I just learned about this mailing list and it seems more appropriate to ask this question here I guess. I already got a reply from Simon Marlow but I posted some further (so far unanswered) questions. The thread starts here: http://www.haskell.org//pipermail/haskell-cafe/2009-August/064880.html. Basically my remaining questions are: 1. How can one safely perform a blocking wait on a system call via FFI when compiling with -threaded and avoid signal interruptions which cause the call to return with EINTR? 2. Could 1. be achieved by blocking SIGVTALRM in the thread doing the call? For details please cf. the original maling list thread. Many thanks, Levi

3 5

Re: What is the mutator?
by Jost Berthold 14 Aug '09

14 Aug '09

> Message: 1 > Date: Thu, 6 Aug 2009 00:38:08 -0700 > From: Jason Dusek <jason.dusek(a)gmail.com> > Subject: What is the mutator? > To: glasgow-haskell-users(a)haskell.org > Message-ID: > <42784f260908060038h53d7cc0dy9f80e43f269a2faf(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > I've been reading a little about GC latency and have run > across statements like this: > > One solution to the GC synchronisation problem would be to > implement a concurrent garbage collector. Typically, > however, concurrent GC adds some overhead to the mutator, > since it must synchronise with the collector.some thunks are > never “black-holed”, so giving a potential performance win. > Unfortunately, in the parallel setting, it substantially > enlarges the time window in which two or more duplicate > threads might evaluate the same think, and thus > > -- Comparing and Optimising Parallel Haskell Implementations > for Multicore Machines > > What is the mutator? Hi Jason, as Malcolm already said, the "mutator" in this text is the/a thread evaluating some Haskell expression. Just to add some more details to the picture... In general, a Haskell expression is a computation represented as a graph in the heap. Haskell evaluates lazily and does not have to fully evaluate every part of it for the program to finish. Unevaluated parts are "thunks". As soon as one of potentially several concurrent (mutator) threads starts to evaluate a thunk, it is replaced by a blackhole, which keeps other threads out of it until the node in the graph is evaluated (say, to a list cons (:), with probably unevaluated head and tail). Then the blackhole is updated with the new value. Other threads block on the blackhole in the meantime (so not necessarily an exception in the case of concurrent mutator threads) and are woken up by the update. The passage you quote above is about two separate aspects: 1. Garbage collection and mutator running concurrently: while they usually do, they do not _have_ to exclude each other, but not doing so means that the objects they are treating have to be locked. 2. About "Blackholing": in the sequential evaluation (where hitting a blackhole indeed means to have a loop), some better performance can be gained by not blackholing a thunk immediately, so this was done in GHC earlier. However, it increases the chance for 2 mutator threads to evaluate the same thunk (double work), and we got better performance by blackholing immediately. Cheers, Jost

4 4

Re: Haskell Platform 2009.2.0.2
by Christian Maeder 10 Aug '09

10 Aug '09

Don Stewart wrote: > Heads up lads, we're about 24 hours from Haskell Platform 2009.2.0.2 > > http://code.haskell.org/haskell-platform/haskell-platform.cabal I still see time ==1.1.2.4, although ghc-6.10.4 comes with: time-1.1.4 http://trac.haskell.org/haskell-platform/ticket/74 Is this on purpose (possibly installing two time versions)? I only know that time-1.1.4 and time-1.1.3 supply more Typeable instances (which may break existing code) Cheers Christian

2 1

use gtar and not tar under solaris
by Christian Maeder 10 Aug '09

10 Aug '09

Hi, I've just been informed that unpacking the binary (i386) solaris distribution using bunzip2 and tar: bunzip2 -c ghc-6.10.4-i386-unknown-solaris2.tar.bz2 | tar xvf - does not work properly! Use instead: gtar jxvf ghc-6.10.4-i386-unknown-solaris2.tar.bz2 File names longer than a hundred characters are cut off, i.e. ghc-6.10.4/libraries/dph/dph-prim-seq/dist/build/Data/Array/Parallel/Unlifted/Sequential/Flat/UArr.hi is wrongly extracted as: ghc-6.10.4/libraries/dph/dph-prim-seq/dist/build/Data/Array/Parallel/Unlifted/Sequential/Flat/UArr.h leading to an installation failure: installPackage: Error: Could not find module: Data.Array.Parallel.Unlifted.Sequential.Flat.UArr with any suffix: ["hi"] gmake[1]: *** [install.library.dph/dph-prim-seq] Error 1 Ian, could you place a note about using gtar for unpacking solaris binary-dists? Cheers Christian

4 10

gcc version for GHC 6.10.4 under Sparc/Solaris
by Christian Maeder 10 Aug '09

10 Aug '09

Hi Ian, could you add a note on the download page that GCC version 4.3.x is not suited for: http://www.haskell.org/ghc/dist/6.10.4/maeder/ghc-6.10.4-sparc-sun-solaris2… The binary-dist was compiled using gcc-4.2.2 (but also works i.e. for gcc-3.4.4) page http://hackage.haskell.org/trac/ghc/wiki/Building/Solaris says: "GCC version 4.1.2 is recommended" and "GHC has not yet been updated to understand the assembly output of GCC version 4.3.x." Maybe a ticket should be opened for gcc-4.3.x under Sparc/Solaris Did anyway use gcc-4.3.x under x86 Solaris? (I don't think, it'll have the same problem.) Cheers Christian

3 4

RE: [Haskell-cafe] generalize RecordPuns and RecordWildCards to work with qualified names?
by Simon Peyton-Jones 09 Aug '09

09 Aug '09

Oh, now I get it, thanks. This message concerns design choices for record-syntax-related GHC extensions. Lennart, pls tune in. You don’t need to have read the thread to understand this message. | I think that Even refers to an example like this: | | module A where | data A = A { a :: Int } | | The following works: | | {-# LANGUAGE NamedFieldPuns #-} | module B where | import A | f (A { a }) = a | | However, if we import "A" qualified, then punning does not seem to work: | | {-# LANGUAGE NamedFieldPuns #-} | module B where | import qualified A | f (A.A { a }) = a | | This results in: Not in scope: `a' Right. What is happening is that GHC looks up the first 'a' (the one on the LHS) and finds it not in scope. If you add -XDisambiguateRecordFields, it works fine. But admittedly, the error message is unhelpful. I could improve that. Now on to the suggested change: | {-# LANGUAGE NamedFieldPuns #-} | module B where | import qualified A | | f (A.A { A.a }) = a | | This results in: Qualified variable in pattern: A.a | | Even is suggesting that instead of reporting an error, in the second | case we could use the translation: | | f (A.A { A.a }) = a --> f (A.A { A.a = a }) | | (i.e., when punning occurs with a qualified name, use just the | unqualified part of the name in the pattern) Yes, that'd be possible. But it seems debatable -- it doesn't *look* as if the pattern (A.A { A.a }) binds 'a' -- and it seems even less desirable in record construction and update. To be concrete, would you expect these to work too? g a = A.A { A.a } --> g a = A.A { A.a = a } h x a = x { A.a } --> h x a = a { A.a = a } In these cases, I think the abbreviated code looks too confusing. With -XDisambiguateRecordFields you could say g a = A.A { a } which seems better. (But there's no help for record update, since we don’t know which data constructor is involved.) So my current conclusion is: improve the error message, perhaps suggesting the flag -XDismabiguateRecordFields, but don't add the change you suggest. Comments? Simon

2 1

What would be required to make a LLVM backend for GHC
by Alex Mason 08 Aug '09

08 Aug '09

Hi all, I've been talking to one of the LLVM developers, who's working on an operating system called AuroraUX, which, among other things, is trying to use LLVM as much as possible in the system (using clang as the default compiler, compiler-rt [libgcc replacement from the LLVM team], etc.). He would like to know exactly what would need to be implemented in LLVM to allow ghc to be ported to LLVM, and he would do his best to get these features implemented. I know the LLVM guys are quite open to suggestions, and want to get people using it as much as possible, so if we can let them know what we need, hopefully they can help make life easier for us. Thanks, Alex Mason

2 1