- Glasgow-haskell-users

RE: [Haskell] Re: indirectly recursive dictionaries
by Simon Peyton-Jones 19 Mar '09

19 Mar '09

[Redirecting to GHC users.] | Tom Schrijvers wrote: | > The cyclic dictionaries approach is a bit fragile. The problem appears to | > be here that GHC alternates exhaustive phases of constraint reduction and | > functional dependency improvement. The problem is that in your example you | > need both for detecting a cycle. The whole thing relies on "spotting a loop", and that's inherently a bit fragile. I don't know of any formal work on the subject, although I bet there is some. GHC's current algorithm does not run functional dependencies sufficiently aggressively, because it treats fundeps a different kind of thing to class constraints. Our new solver, long promised but still in the works, fully integrates type classes with type equalities (fundeps, type functions etc), and so should do a better job here. Roughly speaking, the idea is to combine our ICFP'08 paper [1] with a type-class solver. Since writing the ICFP'08 paper we have found some very useful simplifications; and we also have a new plan for the solving strategy "OutsideIn" [2]. That said, solving recursive problems is not our primary focus right now -- getting it working is -- so I can't promise that it'll do a better job, but I think it will. | It seems we can convince GHC to do constraint reduction and | improvement in the order we desire. The key is to use the | continuation-passing style -- which forces things to happen in the | right order, both at the run-time and at the compile time. Oleg you are a master at persuading GHC's somewhat ad-hoc implementation to dance to your tune. But it'd be better just to make the implementation more complete in the solutions it finds. That's what we are working on now. Simon [1] http://research.microsoft.com/~simonpj/papers/assoc-types/index.htm [2] http://research.microsoft.com/~simonpj/papers/gadt

2 1

Advice wanted on parallel processing
by Colin Paul Adams 19 Mar '09

19 Mar '09

I've just managed to build ghc 6.11 (Thanks Simon). I did this for two reasons, one of which is I want to try to improve the speed of the AI for the Chu Shogi program I am writing by making use of parallel processing. I have a 4-core Xeon runing Fedora Linux 10 (AMD64). I have a repeatable scenario for timings. With ghc 6.10.1, no threaded runtime, the computer takes 51 or 52 seconds to move (experimental variation up to 1.2 seconds). With ghc 6.11, it takes the same time. If I switch on the threaded runtime, then it rises slightly (perhaps not significantly - I measure 53-54 seconds). With 2, 3 or 4 processors, I measured (one-off, so not reliable) 65, 55 and 58 seconds respectively. Well, that doesn't really matter, provided I can get the time back with interest by exploiting parallelism. My first thought for an "easy" win is the move generator. At present I have this code: -- | Generate all legal moves from state. -- -- The best moves (according to some heuristic) should come first generate_moves :: (Non_interactive_state, Maybe Move) -> [(Non_interactive_state, Maybe Move)] generate_moves (state, _) = let colour = case is_black_to_play state of True -> Black False -> White pieces' = all_pieces_of_colour (board state) colour unsorted = concatMap (generate_moves_for_piece state) pieces' sorted = sortBy best_move unsorted moves = mapMaybe new_move sorted in {-trace (concat (intersperse "\n" (map (print_move . fromJust . snd) moves)))-} moves where new_move mv = case update_from_move (state, Nothing) mv of Nothing -> Nothing Just (st', Nothing) -> Just (st', Just mv) and my idea was to run the call to generate_moves_for_piece in parallel over the pieces' list. I thought I could do that simply by replacing concatMap with parFlatMap, but discovered I need to supply an extra argument - a Strategy. Not knowing what this should be (where's the best place to read up on this?) I tried specifying rwhnf. My timings then are: -N1 83 seconds -N2 57 seconds -N3 58 seconds -N4 60 seconds so a complete failure. Where should I go from here? -- Colin Adams Preston Lancashire

4 8

A patch to fix getNumberOfProcessors() on OS X
by Austin Seipp 18 Mar '09

18 Mar '09

(Tried sending to cvs-ghc, said it was blocked for moderation because it matched a certain pattern...) Hello, I have a patch to fix the runtime system's getNumberOfProcessors() function to work properly on OS X and detect the number of CPUs. However, when I run validate, these are the final results: OVERALL SUMMARY for test run started at Tue Mar 17 21:34:36 CDT 2009 2318 total tests, which gave rise to 8661 test cases, of which 0 caused framework failures 6662 were skipped 1923 expected passes 74 expected failures 1 unexpected passes 1 unexpected failures Unexpected passes: hpc_ghc_ghci(normal) Unexpected failures: break017(ghci) Are these to be expected on OS X, or did my patch really break something? Patch is attached. Austin

1 0

Bootstrapping the compiler
by Colin Paul Adams 18 Mar '09

18 Mar '09

I have just downloaded a darcs snapshot, pulled patches and followed the instructions at http://hackage.haskell.org/trac/ghc/wiki/Building/QuickStart When I got to do make it didn't work. The tail of the output looks like this: [55 of 55] Compiling Main ( cabal-bin.hs, /home/colin/ghc/libraries/bootstrapping/Main.o ) Linking cabal-bin ... echo "[]" > bootstrapping.conf.tmp cd extensible-exceptions && /home/colin/ghc/libraries/cabal-bin ghc --make -fno-warn-unrecognised-pragmas /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 clean --distpref=dist-bootstrapping unrecognised command: /home/colin/ghc/libraries/bootstrapping.conf (try --help) make[1]: [bootstrapping.conf] Error 1 (ignored) cd extensible-exceptions && /home/colin/ghc/libraries/cabal-bin ghc --make -fno-warn-unrecognised-pragmas /home/colin/ghc/libraries/bootstrapping.conf 1.7.0 configure --distpref=dist-bootstrapping --with-compiler=ghc --make -fno-warn-unrecognised-pragmas --with-hc-pkg=/usr/local/bin/ghc-pkg --package-db=/home/colin/ghc/libraries/bootstrapping.conf.tmp unrecognised command: /home/colin/ghc/libraries/bootstrapping.conf (try --help) make[1]: *** [bootstrapping.conf] Error 1 make[1]: Leaving directory `/home/colin/ghc/libraries' make: *** [stage1] Error 2 I then tried the following: [colin@susannah ghc]$ ls libraries/bootstrapping.conf ls: cannot access libraries/bootstrapping.conf: No such file or directory [colin@susannah ghc]$ ls libraries/bootstrapping.conf.tmp libraries/bootstrapping.conf.tmp It looks to me like all I have to do is to rename libraries/bootstrapping.conf.tmp to libraries/bootstrapping.conf but I don't see why this is happening. -- Colin Adams Preston Lancashire

2 4

Solaris 8 and libm.so.2
by Ralph Crawford 17 Mar '09

17 Mar '09

Hi everyone. I'm trying to build GHC 6.8.3 on a Solaris 8 machine. I'd love to upgrade Solaris to 10, which I believe would solve the problem I'm having by making /usr/lib/libm.so.2 available, but that's not an option at this time. Here's the output of uname -a on the system. SunOS bwddev1 5.8 Generic_117350-53 sun4u sparc SUNW,Ultra-80 The GCC I'm using is gcc Target: sparc-sun-solaris2.8 Configured with: /usr/local/src/gnu/gcc-4.0.1/configure --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --disable-nls --prefix=/usr/local/gcc4 Thread model: posix gcc version 4.0.1 The GHC binary I'm bootstrapping with is 6.4.1. It works fine for compiling complex haskell programs and packages. I've already worked through a couple of problems to get to where I'm at now. What I had to do was... changed #define SIZET_FMT "d" to #define SIZET_FMT "d" in includes/mkDerivedConstances.c. change #include <stdint.h> to #include <inttypes.h> in includes/HsFFI.h added mk/build.mk containing SRC_HC_OPTS=-opta-mcpu=v9 My latest attempt at a build involved the following, where BOS_ROOT points at the root of my build tree, and $BOS_ROOT/gcc4 is where my gcc lives, and $BOS_ROOT/ghc is where the ghc binary lives. This is only the latest attempt. The libm.so.2 symbolic link and the LDFLAGS and LD_LIBRARY_PATH values were added on the most recent attempt. ln -s /usr/lib/libm.so.1 $BOS_ROOT/lib/libm.so.2 PATH=$BOS_ROOT/gcc4/bin:$BOS_ROOT/ghc/bin:$BOS_ROOT/bin:/usr/bin:/bin LD_LIBRARY_PATH=$BOS_ROOT/gcc4/lib:$BOS_ROOT/ghc/lib:$BOS_ROOT/lib:/usr/lib LDFLAGS=-static -L$BOS_ROOT/lib CFLAGS= export PATH LD_LIBRARY_PATH LDFLAGS CFLAGS fp_prog_ld_raw=/usr/ccs/bin/ld ./configure \ --prefix=$BOS_ROOT \ --with-ghc=$BOS_ROOT/ghc/bin/ghc \ --with-as=/usr/ccs/bin/as \ --with-ld=/usr/ccs/bin/ld \ --with-gcc=$BOS_ROOT/gcc4/bin/gcc \ --with-gmp-includes=$BOS_ROOT/include \ --with-gmp-libraries=$BOS_ROOT/lib \ --with-readline-includes=$BOS_ROOT/include \ --with-readline-libraries=$BOS_ROOT/lib Once I made these changes, the build goes on for a number of hours then dies with what's listed below. I understand that this is because the build is looking for libm.so.2, while the lib on Solaris 8 is /usr/lib/libm.so.1. No matter what I do - including the kludge above attempting to create a libm.so.2 symbolic link, I can't get rid of the errors. Any help at all would be very much appreciated. Please. Here's the error listing. make[3]: Entering directory `/winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/compiler' ../compiler/stage1/ghc-inplace -no-user-package-conf -opta-mcpu=v9 -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp -c main/Main.hs -o stage2/main/Main.o -ohi stage2/main/Main.hi <<ghc: 450131408 bytes, 1127 GCs, 6839050/13262620 avg/max bytes residency (8 samples), 35M in use, 0.00 INIT (0.01 elapsed), 13.34 MUT (40.52 elapsed), 8.42 GC (8.81 elapsed) :ghc>> ../compiler/stage1/ghc-inplace -no-user-package-conf -o stage2/ghc-6.8.3 -opta-mcpu=v9 -package ghc -Istage2 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -IcodeGen -InativeGen -Iparser -Rghc-timing -DGHCI -threaded -fforce-recomp stage2/main/Main.o Undefined first referenced symbol in file cosf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__169.o) expf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__173.o) logf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__172.o) powf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__161.o) sinf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__170.o) tanf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__168.o) acosf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__166.o) asinf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__167.o) atanf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__165.o) coshf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__163.o) dlsym /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/rts/libHSrts_thr.a(Linker.thr_o) (symbol belongs to implicit dependency /usr/lib/libdl.so.1) sinhf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__164.o) tanhf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__162.o) sqrtf /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/libraries/base/dist/build/libHSbase-3.0.2.0.a(Float__171.o) dlopen /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/rts/libHSrts_thr.a(Linker.thr_o) (symbol belongs to implicit dependency /usr/lib/libdl.so.1) dlerror /winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/rts/libHSrts_thr.a(Linker.thr_o) (symbol belongs to implicit dependency /usr/lib/libdl.so.1) ld: fatal: Symbol referencing errors. No output written to stage2/ghc-6.8.3 collect2: ld returned 1 exit status <<ghc: 57428604 bytes, 11 GCs, 126372/126372 avg/max bytes residency (1 samples), 7M in use, 0.00 INIT (0.00 elapsed), 1.49 MUT (17.35 elapsed), 0.09 GC (0.10 elapsed) :ghc>> make[3]: *** [stage2/ghc-6.8.3] Error 1 make[3]: Leaving directory `/winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/compiler' make[2]: *** [stage2/ghc-6.8.3] Error 2 make[2]: Leaving directory `/winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3/compiler' make[1]: *** [stage2] Error 2 make[1]: Leaving directory `/winchester/bwd_home/rc4498/cvs_sandboxes/wip/bos-devel/bos/src/ghc-6.8.3' make: *** [bootstrap2] Error 2 -- --------------------------------------------------------------- My web host for www.ralphcrawford.org is... http://www.1and1.com/?k_id=6466911 They're good - I recommend them. I'm switching my email from stryder22204(a)yahoo.com to stryder100(a)gmail.com. Don't worry though I'll still get stuff from the stryder22204 address for about 6 months.

3 2

testing 6.10.2-candidate
by Serge D. Mechveliani 17 Mar '09

17 Mar '09

I have tested ghc-6.10.1.20090314 on Debian Linux, i386-unknown, on making from source by ghc-6.10.1, making itself from source, DoCon. It looks all right. ----------------- Serge Mechveliani mechvel(a)botik.ru

2 1

Developer Wiki & Buildbots
by Philip K.F. Hölzenspies 17 Mar '09

17 Mar '09

Dear all, It seems that the front page of the developer wiki is rather out-of-date. Considering that 6.10.2 is now at rc1-stage, I was rather hoping to find some updated notes on release plans for 6.10.2 and what will be in 6.12, but those notices are still at 6.8.3 and 6.10, resp. On another matter: I've been trying to contact Ian on rejoining the buildbot network, but haven't heard from him in response to any of messages. Ian, I figured I may have - somehow - ended up in your spam-box, so I thought it a good idea to go through the mailing list. Could you maybe check your spam-box for my e-mails? Regards, Philip

2 1

ghci finding include files exported from other packages?
by Conal Elliott 17 Mar '09

17 Mar '09

The applicative-numbers package [1] provides an include file. With ghci, the include file isn't being found, though with cabal+ghc it is found. My test source is just two lines: {-# LANGUAGE CPP #-} #include "ApplicativeNumeric-inc.hs" I'd sure appreciate it if someone could take a look at the .cabal file [2] and tell me if I'm doing something wrong. And/or point me to one or more working examples of cabal packages that export include files that are then findable via ghci. - Conal [1] http://hackage.haskell.org/packages/archive/applicative-numbers [2] http://hackage.haskell.org/packages/archive/applicative-numbers/0.0.2/appli…

3 10

Link errors
by Lingappan, Loganathan 15 Mar '09

15 Mar '09

Hi, If I include import Text.Regex.Posix ((=~)) into a Haskell code, I get the following link error: FindBBUsage.o:fake:(.text+0x44d): undefined reference to `__stginit_regexzmposixzm0zi72zi0zi3_TextziRegexziPosix_' collect2: ld returned 1 exit status Any ideas on how to fix this? I am using GHC version 6.10.1 on Windows XP. Thanks, Logo

2 2

Bug in deriving Data Typeable?
by Bernd Brassel 13 Mar '09

13 Mar '09

Hi folks, I have been surprised by the derived instances of Data/Typeable when using the combinator ext1Q. First look at the following definition: > useExt1 :: Data a => a -> () > useExt1 = undefined `ext1Q` (\ (Just _) -> ()) > testExt1 :: () > testExt1 = useExt1 (Just ()) As I expected, testExt1 yields () But when I define my own version of Maybe and derive the Data/Typeable instances > data MyMaybe a = MyJust a | MyNothing deriving (Data,Typeable) the corresponding test > useExt1' :: Data a => a -> () > useExt1' = undefined `ext1Q` (\ (MyJust _) -> ()) > testExt1' :: () > testExt1' = useExt1' (MyJust ()) yields *** Exception: Prelude.undefined All of this happens with both ghc 6.10.1 and 6.8.2. Is this a bug in the derived instances, e.g., in dataCast1? If so is there a concise tutorial telling me how to write correct instances for the data type I'm interested in (which is not MyMaybe)? Thanks for your time! Bernd

2 3