:PostID: 97 :Title: 7.8.1-rc1 Gentoo experience :Keywords: gentoo, ghc, ghci, haskell :Categories: news `A week ago `_ Austin Seipp and **GHC** team announced first release candidate from 7.8 branch. As a packager I was especially interested in following features: 1. **GHCi** (and dynamic linking) on unregisterised arches, like **ia64** and **powerpc64** 2. **jobs** argument for **ghc make**. Parallel builds for free. 3. what did seriously break, what was fixed? First off, **-rc1** is packaged in `gentoo-haskell overlay `_ (not keyworded as quite a bit of packages fail to build against **ghc-7.8**). **GHCi** (and dynamic linking) ============================== Dynamic linking works like a charm! **GHCi** loads binaries noticeaby faster. Let's test it! Simplest synthetic test: how fast do you get prompt from interpreter? :: # ghc-7.6: $ time { echo '1+1' | ghci -package yesod-core >/dev/null; } real 0m0.626s user 0m0.550s sys 0m0.074s # ghc-7.8: $ time { echo '1+1' | ghci -package yesod-core >/dev/null; } real 0m0.209s user 0m0.172s sys 0m0.034s It's a case, when files are cached in **RAM**. **3-4** times faster. The same boost should apply every time when you compile something template-haskell related. **jobs** argument for **ghc make** ================================== I've went ahead and tried to enable it `for all ebuilds `_. For some reason ghc eats a lot of system time in that mode. Likely **jobs** without arguments is not very good idea and i'll need to limit it by minimum of **MAKEOPTS** value and some **N** (**Cabal** picked **64**). Even in this mode 2-time speedup is visible on large packages. So what did break? ================== Not _that_ much, actually. alex and happy generated parsers -------------------------------- All package maintainers who ship lexers generated by **alex** and parsers generated by **happy** are strongly advised **to update those tools locally and reissue hackage update**, as old parsers do not compile against **ghc-7.8**. If you have happened to use low-level .. code-block:: haskell (==#) :: Int# -> Int# -> Bool primitives, you might need to port your code a bit, as how their type is a bit different: .. code-block:: haskell (==#) :: Int# -> Int# -> Int# Here is our example fix for `arithmoi `_. Type inference changed a bit. ----------------------------- Traditionally `darcs `_ needed a patch :] In that big mostly dumb patch most interesting bit is explicit assignment: .. code-block:: Diff - where copyRepo = + where copyRepo :: IO () + copyRepo = Even more amusing breakage was in `shake `_, where error was in inability to infer **Addr#** argument. No idea was it a bug or feature. Unsafe removals --------------- As we've seen in **darcs** patch many **unsafe**${something} functions went away from **Foreign** modules down to their **Unsafe** counterparts. Typeable -------- **Typeable** representation did change in a substantial way, thus advanced generic stuff will break. I have no example fix, but have a few of broken packages, like **dependent-sum**. Hashtable gone from base ------------------------ Example of fix for `frag `_ package. By the way, **ghc-7.6** used to eat 8GBs of **RAM** compiling **frag**. For **ghc-7.8** it was enough **700MBs** even for 8 building threads. Compiler itself --------------- The thing I expected to try didn't compile: unregisterised arches and **GHCi** on them. I've hacked-up `a workaround `_ to make them build, but in threaded **RTS** mode it still **SIGSEGV**s. **STG** gurus are welcome to help me :] I have fundamental questions like: - can unregisterised builds support SMP in theory? (via __thread attribute for example) - did UNREG ever produce working threaded runtime? :: $ cat __foo/foo.hs main = print 1 # non-threaded works, as always been $ inplace/bin/ghc-stage1 --make __foo/foo.hs -threaded -debug -fforce-recomp # $ gdb --args ./__foo/foo +RTS -D{s,i,w,g,G,b,S,t,p,a,l,m,z,c,r} ... (gdb) run ... 7ffff7fb9700: resuming capability 0 7ffff7fb9700: cap 0: created thread 1 7ffff7fb9700: new bound thread (1) 7ffff7fb9700: cap 0: schedule() 7ffff7fb9700: cap 0: running thread 1 (ThreadRunGHC) Jumping to 0x7ec17f # Program received signal SIGSEGV, Segmentation fault. 0x00000000007ec1a2 in stg_returnToStackTop () (gdb) bt #0 0x00000000007ec1a2 in stg_returnToStackTop () #1 0x00000000007d26d9 in StgRun (f=0x7ec17f , basereg=0xca0648) at rts/StgCRun.c:81 #2 0x00000000007c7a30 in schedule (initialCapability=0xca0630, task=0xcc3b30) at rts/Schedule.c:463 #3 0x00000000007ca2c4 in scheduleWaitThread (tso=0x7ffff6b05390, ret=0x0, pcap=0x7fffffffd218) at rts/Schedule.c:2346 #4 0x00000000007c0162 in rts_evalIO (cap=0x7fffffffd218, p=0xb61450 , ret=0x0) at rts/RtsAPI.c:459 #5 0x00000000007e04c3 in ioManagerStartCap (cap=0x7fffffffd218) at rts/posix/Signals.c:184 #6 0x00000000007e04f6 in ioManagerStart () at rts/posix/Signals.c:194 #7 0x00000000007d1d5d in hs_init_ghc (argc=0xc96570 , argv=0xc96578 , rts_config=...) at rts/RtsStartup.c:262 #8 0x00000000007d000b in real_main () at rts/RtsMain.c:47 #9 0x00000000007d0122 in hs_main (argc=17, argv=0x7fffffffd418, main_closure=0xb527a0 , rts_config=...) at rts/RtsMain.c:114 #10 0x0000000000404df1 in main () Looks like **CurrentTSO** is complete garbage. Should not happen :] Conclusion ========== The experience is positive. I already get bored, when see single-threaded **make** of **ghc-7.6** and want to update a compiler. Things like **yesod**, **darcs**, **hoogle**, **pandoc** and **xmonad** build fine, thus you can get working environment very fast. Package authors are more eager to fix stuff for this release: it turns bug lookup and benchmarking into very interactive process. I want to thank All Of You to make push haskell forward! Thank you!