- Glasgow-haskell-users

Testsuite failures and some easy fixes
by Daniel Fischer 28 Jun '11

28 Jun '11

Today's HEAD produced 49 unexpected failures, most of which are caused by trivia. - tcrun006 and tcrun029 use datatype contexts which were removed from HEAD (7 ways each), can be fixed by adding a language pragma (cf. also http://hackage.haskell.org/trac/ghc/ticket/5229) - ghcpk01.stdout hasn't yet been updated to include the new trusted field - ffi005 fails to compile (7 ways) due to an ambiguous occurrence of unsafePerformIO (Foreign and System.IO.Unsafe) - cg005 and T4059 have unexpected stderr due to a warning about unsafePerformIO going to be removed from Foreign - T4437 fails to compile due to a type change: T4437.hs:9:39: Couldn't match expected type `(String, CmdLineParser.FlagSafety, ExtensionFlag, DynFlags.TurnOnFlag -> DynFlags.DynP ())' with actual type `(t0, t1, t2)' In the pattern: (ext, _, _) In a stmt of a list comprehension: (ext, _, _) <- xFlags In the expression: [ext | (ext, _, _) <- xFlags] Those are easily fixed by the attached patches (but some may need a more principled fix). Further, 17 unexpected failures are due to hpc output being formatted differently from the expectation (5x hpc_fork, 6x hpc001, 6x tough). Two unexpected failures (T4809, cgrun068) are due to mtl not being built the dyn way. The remaining 5 are - T4801 (allocating too little because there are fewer Generic instances for tuples) - dph-diophantine-opt (3 ways) - dph-words-opt On my 32-bit box, also T3294 unexpectedly fails since about a week ago due to too little allocation (a bit below 690M, minimum allowed 800M). If that's reproducible and not known to be temporary, the bounds should be adjusted. Cheers, Daniel

2 1

Hoopl: Combining CheckingFuelMonad with State?
by Justin Bailey 27 Jun '11

27 Jun '11

I'd like to carry around some state when rewriting. It seems like CheckingFuelMonad, etc. are set up to use with other monads but I can't get the types to agree. Using MTL I've managed to come up with these types: > newtype RewriteOnce a = R (State Bool a) > deriving (Monad) > > instance MonadState s (CheckingFuelMonad RewriteOnce) where > get = undefined > put = undefined But I cannot write the definitions for get and put. Is this possible or am I misundersanding CheckingFuelMonad? Is there a better approach altogether? Thanks in advance for any help! Justin

2 2

GHC HEAD broken on OS X
by austin seipp 27 Jun '11

27 Jun '11

After doing a 'git pull origin master && ./sync-all pull origin master', I get the following build failure when stage1 attempts to compile the RTS code: http://paste.debian.net/121097/ A quick glance at the errors seem to indicate this work is related to the new events stuff for GHC. Duncan was working on this last I think - is anybody else experiencing this failure? -- Regards, Austin

3 3

Experiencing libffi related problem with GHC HEAD on Ubuntu 11.04
by Ryan Newton 27 Jun '11

27 Jun '11

Has anyone seen this one before? # libffi.so needs to be built with the correct soname. # NOTE: this builds libffi_convience.so with the incorrect # soname, but we don't need that anyway! cd libffi && \ "cp" build/libtool build/libtool.orig; \ sed -e s/soname_spec=.*/soname_spec="libHSffi-ghc7.1.20110609.so<http://libhsffi-ghc7.1.20110609.so/>"/ build/libtool.orig > build/libtool cp: cannot stat `build/libtool': No such file or directory sed: can't read build/libtool.orig: No such file or directory make[2]: *** [libffi/stamp.ffi.configure] Error 2 make[1]: *** [all_libffi] Error 2 make[1]: Leaving directory `/home/newton/build/haskell2/ghc-validate' make: *** [all] Error 2 Thanks, -Ryan P.S. It's not new. I just did a "git pull origin master && ./sync-all pull origin master" and got this error but I also got the same error on this machine back on June 9th. However, this package has built GHC HEAD in the past. It has the standard ubuntu libffi-dev and libffi5 packages installed.

1 0

gitweb on darcs.haskell.org?
by Iavor Diatchki 26 Jun '11

26 Jun '11

Hello, Do we have an instance of "gitweb" for the various ghc related repos running somewhere? If not, I'd be happy to setup an instance, would anyone object? "gitweb" is a web-interface which makes it easy to get a quick overview of what's going on with a collection of repositories. It shows commits, branches, tags, etc. Also, it provides RSS/Atom feeds, which makes it easy to subscribe to changes for repos of interest. -Iavor PS: you can try it out locally by typing "git instaweb" in a git repository.

4 4

Hoopl: Examples of wrapFR or wrapBR?
by Justin Bailey 25 Jun '11

25 Jun '11

Can someone provide an example of how to use wrapFR/wrapBR? I know they are deprecated, but I would really like to see them in action if they are used anywhere at all ... Thanks so much! Justin

2 1

GHC and Haskell 98
by Simon Peyton-Jones 24 Jun '11

24 Jun '11

Friends, this is to ask your opinion about a possible change in GHC 7.2. The current implementation in GHC 7.2 is Plan A below. Plan A is a bit easier for us, but I think it may be a bit draconian, and therefore propose Plan B as an alternative. Opinions? Simon ============================================== With GHC 7.0 if you say ghc -c Main.hs the import of Prelude, whether implicit or explicit, will come from package 'base'. This is also true if you say ghc -c Main.hs -package haskell98 The package 'haskell98' exposes 'List' and 'Random' but not 'Prelude'. That still comes from 'base'. This isn't good, because it means that if in the future we change 'Prelude' in package 'base', a Haskell98 module might fail to compile. And later iterations of Haskell might well want to expand or change the Prelude. There appear to be two alternatives: (Plan A) Add a module 'Prelude' to package 'haskell98'. Now you can compile a pure H98 program thus: ghc -c Main.hs -hide-all-packages -package haskell98 (Cabal puts the -hide-all-packages in for you.) And this will continue to work even if later iterations of Haskell change the Prelude. BUT (A) means that this module becomes un-compilable: module Main where import Random import Data.List Why? Because 'Random' comes from 'haskell98' and 'Data.List' comes from 'base'. But if you say ghc -c Main.hs -package base -package haskell98 then the (implicit) import of 'Prelude' will say "Ambiguous module name: Prelude", because it's exported by both 'base' and 'haskell98'. To fix this you have to change 'import Random' to 'import System.Random'. But the latter's API is different, so you may have to change the source code that uses it. So the second alternative is this: (Plan B) Like Plan A, but in addition, if you say "{-# LANGUAGE Haskell98 #-}" in the file, or -XHaskell98 on the command line, the implicit import of Prelude comes from package 'haskell98', provided -package haskell98 is specified, but regardless of what other in-scope packages expose a Prelude module. Variation: an explicit 'import Prelude' is similarly directed to package 'haskell98' as well. So: Under Plan A, some Hackage packages will become un-compilable, and will require source code changes to fix them. I do not have any idea how many Hackage packages would fail in this way. Unser Plan B, Hackage package that compile now will continue to compile, if their Cabal file is altered. No source code changes. (Well, unless they depend on some innards of GHC.IO or something like that.) But Plan A is simpler. And by breaking packages it will encourage [force] libraries that use a mixture of H98 and more modern modules to move towards the more modern story.

11 11

Reducing the cost of garbage collecting small arrays
by Johan Tibell 24 Jun '11

24 Jun '11

Hi, Now when we can efficiently copy small arrays I've gone back to benchmarking/optimizing my hash array mapped trie data structure. The data structure's performance depends on how efficiently we can allocate/collect/copy Array#s and MutableArrays#s of size <=32. Speeding up copying helped quite a bit, but the HAMT is still slower than a Patricia tree for inserts. If you look at the data below you can see that GC time totally dominates the runtime. Is there anything that can be done to make the GC cheaper in this case? If I'm reading the output below right it's not allocating the space that takes most of the time, but later evacuating/scavenging it. Benchmark ========= {-# LANGUAGE BangPatterns #-} module Main (main) where import Data.List import qualified Data.HashMap as HM test :: HM.HashMap Int Int -> Int -> HM.HashMap Int Int test !m 0 = m test m n = test (HM.insert n n m) (n-1) {-# NOINLINE test #-} main = print $ HM.null $ test HM.empty 1000000 Hash array mapped trie ====================== $ time perf record -f ./test False [ perf record: Woken up 13 times to write data ] [ perf record: Captured and wrote 1.672 MB perf.data (~73041 samples) ] real 0m2.562s user 0m0.020s sys 0m0.010s # Samples: 72980 # # Overhead Command Shared Object Symbol # ........ ............... .......................... ...... # 52.79% test ./test [.] evacuate 9.49% test ./test [.] 0x000000000b4544 8.47% test ./test [.] scavenge_block 6.27% test ./test [.] s4UJ_info 4.67% test ./test [.] s1Od_info 4.22% test ./test [.] scavenge_mut_arr_ptrs 3.68% test ./test [.] s4N7_info 0.72% test ./test [.] todo_block_full 0.55% test ./test [.] GarbageCollect 0.55% test ./test [.] freeGroup Patricia tree ============= $ time perf record -f ./test False [ perf record: Woken up 11 times to write data ] [ perf record: Captured and wrote 1.292 MB perf.data (~56470 samples) ] real 0m1.984s user 0m0.020s sys 0m0.010s # Samples: 56409 # # Overhead Command Shared Object Symbol # ........ ............... .................... ...... # 49.30% test ./test [.] evacuate 24.75% test ./test [.] sa4B_info 14.56% test ./test [.] scavenge_block 1.31% test ./test [.] sa4k_info 1.25% test ./test [.] sa4m_info 1.25% test ./test [.] 0x00000000004108 0.72% test [kernel] [k] clear_page_c 0.66% test ./test [.] todo_block_full 0.46% test [kernel] [k] page_fault 0.44% test ./test [.] GarbageCollect P.S. I also need to figure out what 0x000000000b4544 corresponds to in the first perf events report. I thought my fix to the generated assembly files should have taken care of the unknown symbol problem. Cheers, Johan

3 6

Superclass equalities
by Simon Peyton-Jones 23 Jun '11

23 Jun '11

Friends I have long advertised a plan to allow so-called superclass equalities. I've just pushed patches to implement them. So now you can write class (F a ~ b) => C a b where { ... } This email is just to encourage you to try them out. Currently this is just in the HEAD git repository. It'll appear in GHC 7.2, a release we are now actively preparing. But the feature isn't heavily tested (since it didn't exist until today), so I'd appreciate people trying it out. Thanks Simon

3 2

Re: [GHC] #5051: Typechecker behaviour change
by Serge D. Mechveliani 23 Jun '11

23 Jun '11

Simon, thank you. Currently, DoCon works under ghc-7.0.1. And as I understand, the next release which is going to support DoCon (with its heavy use of overlapping instances) will be ghc-7.2. Regards, -------- Serge Mechveliani, mechvel(a)botik.ru On Wed, Jun 22, 2011 at 11:01:53AM -0000, GHC wrote: > #5051: Typechecker behaviour change > ---------------------------+------------------------------------------------ > Reporter: igloo | Owner: simonpj > Type: bug | Status: closed > Priority: high | Milestone: 7.2.1 > Component: Compiler | Version: 7.0.2 > Resolution: fixed | Keywords: > > [..] > > GHC 7 indeed falls over on `DoCon` 2.12. It turns out to be a rather > subtle interaction of overlapping instances with the ill-fated "silent > superclass parameters" I introduced to solve a problem in the > typechecker's constraint solver. > [..]

2 1