- Glasgow-haskell-users

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

Compiling large source files
by Günther Schmidt 07 Aug '09

07 Aug '09

Hi all, I'm having trouble compiling very large source files, the compiler eats 2GB and then dies. Is there a way around it? Günther

6 9

GHC 6.10.2 consuming lots of memory while compiling - help?
by Justin Bailey 06 Aug '09

06 Aug '09

I apologize in advance for the vagueness of my report here - it's one of those situations I'm not sure how to cut it down to size yet. I have a module that uses HaskellDB and Template Haskell together. The module itself depends on 23 other modules, each of which give a type definition for a particular database table or view. I only mention that to emphasize that the module depends on some "big" types (HList records w/ 20+ members) and on compile-time generated code. My problem is this - when GHC compile the module, it consumes 1.2 GB of memory, takes about 10 minutes, and finally produces an object file. The memory usage seems related to template haskell, but I'm not positive. I've attached verbose output from compiling the module in question. The command line I used was: ghc -v --make -c DeliveryManagementQueries.hs -XEmptyDataDecls -XTypeSynonymInstances -XTemplateHa skell Now for my question - please ignore the specifics of haskelldb/template haskell - any suggestions for figuring out what GHC is doing, besides tried-and-true divide and conquer? Justin

4 6

What is the mutator?
by Jason Dusek 06 Aug '09

06 Aug '09

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? -- Jason Dusek

3 2