November 2009 - Glasgow-haskell-users

-package-name flag in 6.10.x
by Malcolm Wallace 25 Nov '09

25 Nov '09

The ghc documentation at http://www.haskell.org/ghc/docs/latest/html/users_guide/packages.html says the following: > -package-name foo > Tells GHC the the module being compiled forms part of package foo. If this flag is omitted (a very common case) then the default package main is assumed. > Note: the argument to -package-name should be the full package identifier for the package, that is it should include the version number. For example: -package mypkg-1.2. I observe that the example uses -package rather than -package-name, and wonder if this is a mistake. Moreover, when I attempt to use the flag, like so: $ ghc -package-name hat-2.06 ... <command line>: cannot parse 'hat-2.06' as a package identifier This used to work with ghc-6.6.x and ghc-6.8.x, but seems to have stopped working with ghc-6.10.x. I surmise that the leading zero after the version point separator is to blame? It seems an unfortunate regression. Regards, Malcolm

2 1

ANNOUNCE: GHC 6.12.1 Release Candidate 2
by Ian Lynagh 24 Nov '09

24 Nov '09

Hi all, We are pleased to announce the second release candidate for GHC 6.12.1: http://www.haskell.org/ghc/dist/6.12.1-rc2/ As well as the source tarball: ghc-6.12.0.20091121-src.tar.bz2 there are installers for Windows (i386) and OS X (i386), and binary distributions for x86_64/Linux and i386/Linux. For the Linux binary distributions, the "linux-n" tarballs are recommended over the "linux" tarballs. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

8 15

"ghc-paths" package build error with GHC 6.12.1 RC2
by Daniel Schüssler 24 Nov '09

24 Nov '09

Hi, see below. Greetings, Daniel $ cabal install ghc-paths Resolving dependencies... [1 of 1] Compiling Main ( /tmp/ghc-paths-0.1.0.523651/ghc- paths-0.1.0.5/Setup.hs, /tmp/ghc-paths-0.1.0.523651/ghc- paths-0.1.0.5/dist/setup/Main.o ) /tmp/ghc-paths-0.1.0.523651/ghc-paths-0.1.0.5/Setup.hs:18:22: `preMakefile' is not a (visible) constructor field name cabal: Error: some packages failed to install: ghc-paths-0.1.0.5 failed during the configure step. The exception was: ExitFailure 1

2 2

testing 6.12.1-pre
by Serge D. Mechveliani 23 Nov '09

23 Nov '09

Dear GHC team, I have tested ghc-6.12.0.20091121 by 1) installing its binary and making and running the DoCon and Dumatel programs, 2) making it from source by its binary, making and running on it the DoCon and Dumatel programs. It looks all right. I skipped profiling. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Mail System Error - Returned Mail
by jgoerzen＠complete.org 21 Nov '09

21 Nov '09

The original message was received at Sat, 21 Nov 2009 15:53:18 +0530 from [185.65.254.58] ----- The following addresses had permanent fatal errors ----- <glasgow-haskell-users(a)haskell.org> ----- Transcript of session follows ----- ... while talking to haskell.org.: 554 <glasgow-haskell-users(a)haskell.org>... Mail quota exceeded 554 <glasgow-haskell-users(a)haskell.org>... Service unavailable

1 0

:set -fbreak-on-exception in GHCi causes exception in readFile
by Sean Leather 20 Nov '09

20 Nov '09

Perhaps I don't quite get how this works, but when I :set -fbreak-on-exception in GHCi, I get an exception using readFile. It reads the entire file and then throws what appears to be an EOF exception. Prelude> readFile "blah.txt" > "blah\nblah\nblah\nStopped at <exception thrown> > _exception :: > e = GHC.Exception.SomeException (GHC.Exception.:DException _ > > (GHC.Show.:DShow ...) ....) > (GHC.IOBase.IOError Nothing > GHC.IOBase.EOF ....) > When I :set -fno-break-on-exception, I see no exception. I thought that lazy IO reads until it reaches the EOF, then closes the file. This happens with both 6.10.1 and 6.8.3, so perhaps this is standard stuff, and I'm missing something. Regards, Sean

4 6

GHC Trac says database is locked
by Sean Leather 20 Nov '09

20 Nov '09

I tried to submit a comment on #2530 and got this error. Sean ------- Oops... *Trac detected an internal error:* If you think this really should work and you can reproduce it. Then you should consider to report this problem to the Trac team. Go to http://trac.edgewall.org/ and create a new ticket where you describe the problem, how to reproduce it. Don't forget to include the python traceback found below. TracGuide <http://hackage.haskell.org/trac/ghc/wiki/TracGuide> — The Trac User and Administration Guide Python traceback Traceback (most recent call last): File "/var/lib/python-support/python2.4/trac/web/main.py", line 387, in dispatch_request dispatcher.dispatch(req) File "/var/lib/python-support/python2.4/trac/web/main.py", line 237, in dispatch resp = chosen_handler.process_request(req) File "/var/lib/python-support/python2.4/trac/ticket/web_ui.py", line 279, in process_request self._do_save(req, db, ticket) File "/var/lib/python-support/python2.4/trac/ticket/web_ui.py", line 546, in _do_save cnum=internal_cnum): File "/var/lib/python-support/python2.4/trac/ticket/model.py", line 250, in save_changes (self.id, when, author, cnum, comment)) File "/var/lib/python-support/python2.4/trac/db/util.py", line 50, in execute return self.cursor.execute(sql_escape_percent(sql), args) File "/usr/lib/python2.4/site-packages/sqlite/main.py", line 237, in execute self.con._begin() File "/usr/lib/python2.4/site-packages/sqlite/main.py", line 503, in _begin self.db.execute("BEGIN") OperationalError: database is locked

3 4

ANNOUNCE: parallel-2.0.0.0
by Simon Marlow 18 Nov '09

18 Nov '09

I've just uploaded parallel-2.0.0.0 to Hackage. If you're using Strategies at all, I'd advise updating to this version of the parallel package. It's not completely API compatible, but if you're just using the supplied Strategies such as parList, the changes should be relatively minor. The Haddock docs include a full description of the changes, reproduced below. Haddock docs are also here, until Hackage catches up: http://www.haskell.org/~simonmar/parallel/index.html The Strategy-using programs I've tried so far go faster. Enjoy! Cheers, Simon --------------------------------------------------------------------- Version 1.x The original Strategies design is described in <http://www.macs.hw.ac.uk/~dsg/gph/papers/html/Strategies/strategies.html> and the code was written by Phil Trinder, Hans-Wolfgang Loidl, Kevin Hammond et al. Version 2.x Later, during work on the shared-memory implementation of parallelism in GHC, we discovered that the original formulation of Strategies had some problems, in particular it lead to space leaks and difficulties expressing speculative parallelism. Details are in the paper \"Runtime Support for Multicore Haskell\" <http://www.haskell.org/~simonmar/papers/multicore-ghc.pdf>. This module has been rewritten in version 2. The main change is to the 'Strategy a' type synonym, which was previously @a -> Done@ and is now @a -> a@. This change helps to fix the space leak described in \"Runtime Support for Multicore Haskell\". The problem is that the runtime will currently retain the memory referenced by all sparks, until they are evaluated. Hence, we must arrange to evaluate all the sparks eventually, just in case they aren't evaluated in parallel, so that they don't cause a space leak. This is why we must return a \"new\" value after applying a 'Strategy', so that the application can evaluate each spark created by the 'Strategy'. The simple rule is this: you /must/ use the result of applying a 'Strategy' if the strategy creates parallel sparks, and you should probably discard the the original value. If you don't do this, currently it may result in a space leak. In the future (GHC 6.14), it will probably result in lost parallelism instead, as we plan to change GHC so that unreferenced sparks are discarded rather than retained (we can't make this change until most code is switched over to this new version of Strategies, because code using the old verison of Strategies would be broken by the change in policy). The other changes in version 2.x are: * Strategies can now be defined using a convenient Applicative type Eval. e.g. parList s = unEval $ traverse (Par . s) * 'parList' has been generalised to 'parTraverse', which works on any 'Traversable' type. * 'parList' and 'parBuffer' have versions specialised to 'rwhnf', and there are transformation rules that automatically translate e.g. @parList rwnhf@ into a call to the optimised version. * 'NFData' is deprecated; please use the @DeepSeq@ class in the @deepseq@ package instead. Note that since the 'Strategy' type changed, 'rnf' is no longer a 'Strategy': use 'rdeepseq' instead.

1 0

Announcing the GHC Bug Sweep
by Simon Marlow 18 Nov '09

18 Nov '09

Help us weed the GHC ticket database, and get a warm fuzzy feeling from contributing to Haskell core technology! There are currently ~750 tickets against GHC. Many of them have not been looked at in months or years. Often when I go through old tickets I find easy targets: bugs that have already been fixed, duplicates, bugs that are not reproducible and the submitter has gone away. So the idea we have is this: do an incremental sweep of the whole database, starting from the oldest tickets. Check each one, and try to make some progress on it. If we get enough momentum going we can make sure every ticket gets looked at every few months at the least. This is a game for the whole family! We don't care how much progress you make on each ticket, just as long as someone has taken a look and moved the ticket forward in some way. For example, you might check for duplicates, update the metadata, ask for more information from the submitter, try to reproduce the bug against the latest version of GHC. To claim a ticket all you have to do is remove it from the list on the wiki. Full instructions are here http://hackage.haskell.org/trac/ghc/wiki/BugSweep including a list of suggestions for ways to make progress on a ticket. Cheers! Simon & the GHC team

2 3

Inliner behaviour - tiny changes lead to huge performance differences
by Bryan O'Sullivan 17 Nov '09

17 Nov '09

I'm working on measuring and improving the performance of the text library at the moment, and the very first test I tried demonstrated a piece of behaviour that I'm not completely able to understand. Actually, I'm not able to understand what's going on at all, beyond a very shallow level. All the comments below pertain to GHC 6.10.4. The text library uses stream fusion, and I want to measure the performance of UTF-8 decoding. The code I'm measuring is very simple: import qualified Data.ByteString as B import Data.Text.Encoding as T import qualified Data.Text as T import System.Environment (getArgs) import Control.Monad (forM_) main = do args <- getArgs forM_ args $ \a -> do s <- B.readFile a let t = T.decodeUtf8 s print (T.length t) The streamUtf8 function looks roughly like this: streamUtf8 :: OnDecodeError -> ByteString -> Stream Char streamUtf8 onErr bs = Stream next 0 (maxSize l) where l = B.length bs next i | i >= l = Done | U8.validate1 x1 = Yield (unsafeChr8 x1) (i+1) | {- etc. -} {-# INLINE [0] streamUtf8 #-} The values being Yielded from the inner function are, as you can see, themselves constructed by functions. Originally, with the inner next function manually marked as INLINE, I found that functions like unsafeChr8 were not being inlined by GHC, and performance was terrible due to the amount of boxing and unboxing happening in the inner loop. I somehow stumbled on the idea of removing the INLINE annotation from next, and performance suddenly improved by a significant integer multiple. This caused the body of streamUtf8 to be inlined into my test program, as I hoped. However, I wasn't yet out of the woods. The length function is defined as follows: length :: Text -> Int length t = Stream.length (Stream.stream t) {-# INLINE length #-} And the streaming length is: length :: Stream Char -> Int length = S.lengthI {-# INLINE[1] length #-} And the lengthI function is defined more generally, in the hope that I could use it for both Int and Int64 lengths: lengthI :: Integral a => Stream Char -> a lengthI (Stream next s0 _len) = loop_length 0 s0 where loop_length !z s = case next s of Done -> z Skip s' -> loop_length z s' Yield _ s' -> loop_length (z + 1) s' {-# INLINE[0] lengthI #-} Unfortunately, although lengthI is inlined into the Int-typed streaming length function, that function is not in turn marked with __inline_me in simplifier output, so the length/decodeUtf8 loops do not fuse. The code is pretty fast, but there's still a lot of boxing and unboxing happening for all the Yields. So. I am quite baffled by this, and I confess to having no idea what to do to get the remaining functions to fuse. But that's not quite confusing enough! Here's a one-byte change to my test code: main = do args <- getArgs forM_ args $ \a -> do s <- B.readFile a let !t = decodeUtf8 s *{- <-- notice the strictness annotation -}* print (T.length t) In principle, this should make the code a little slower, because I'm deliberately forcing a Text value to be created, instead of allowing stream/unstream fusion to occur. Now the length function seems to get inlined properly, but while the decodeUtf8 function is inlined, the functions in its inner loop that must be inlined for performance purposes are not. The result is very slow code. I found another site for this one test where removing a single INLINEannotation makes the strictified code above 2x faster, but that change causes the stream/unstream fusion rule to fail to fire entirely, so the strictness annotation no longer makes a difference to performance. All of these flip-flops in inliner behaviour are very difficult to understand, and they seem to be exceedingly fragile. Should I expect the situation to be better with the new inliner in 6.12? Thanks for bearing with that rather long narrative, Bryan.

9 13