- Glasgow-haskell-users

LambdaVM: build fails on Solaris/x86
by Karel Gardas 13 Jan '09

13 Jan '09

Hello Brian and All, I'm curious if anyone here attempted building LambdaVM on non-GNU system. I'm using OpenSolaris/x86 and build fails with: == Recursively making `depend' for ways: '' ... PWD = /export/home/karel/vcs/lambdavm/libraries/Cabal ------------------------------------------------------------------------ case '- --no-print-directory -r' in *-[ik]*) x_on_err=0;; *-r*[ik]*) x_on_err=0;; *) x_on_err=1;; esac; \ if [ -n "" ]; then \ echo "doing the loop :-("; \ for i in ; do \ echo "------------------------------------------------------------------------"; \ echo "== gmake way=$i depend;"; \ echo "PWD = /export/home/karel/vcs/lambdavm/libraries/Cabal"; \ echo "------------------------------------------------------------------------"; \ gmake way=$i --no-print-directory - --no-print-directory -r depend ; \ if [ $? -eq 0 ] ; then true; else exit $x_on_err; fi; \ done \ fi /bin/sh: syntax error at line 4: `;' unexpected gmake[2]: *** [depend] Error 2 Failed making boot in Cabal: 1 gmake[1]: *** [boot] Error 1 gmake[1]: Leaving directory `/export/home/karel/vcs/lambdavm/libraries' gmake: *** [stage1] Error 2 karel@silence:~/vcs/lambdavm$ The only changes which I made to the build systems are following: karel@silence:~/vcs/lambdavm$ darcs w -u { hunk ./darcs-all 1 -#!/bin/sh +#!/usr/bin/bash set -e hunk ./libraries/Makefile 12 # want the Makefile. MFLAGS += -f Makefile -SUBDIRS = base haskell98 template-haskell readline parsec Cabal +#SUBDIRS = base haskell98 template-haskell readline parsec Cabal +SUBDIRS = base haskell98 template-haskell parsec Cabal ifeq "$(GhcLibsWithUnix)" "YES" SUBDIRS += unix hunk ./mk/target.mk 274 ifneq "$(way)" "i" ifeq "$(way)" "j" define BUILD_LIB -@if [ -e $@ ]; then \ +@if [ -f $@ ]; then \ echo "$(JAR) uf $@ ..."; \ for o in $(LIBOBJS:%.$(osuf)=%); do [ $$o.$(osuf) -nt $@ ] && echo $$o*.$(osuf); done | xargs $(JAR) uf $@; \ else \ hunk ./mk/target.mk 1102 # since these are way-independent all docs TAGS clean distclean mostlyclean maintainer-clean install depend :: @echo "------------------------------------------------------------------------" - @echo "== Recursively making \`$@' for ways: $(WAYS) ..." + @echo "== Recursively making \`$@' for ways: '$(WAYS)' ..." @echo "PWD = $(shell pwd)" @echo "------------------------------------------------------------------------" # Don't rely on -e working, instead we check exit return codes from sub-makes. } the reason is: 1) readline lib is not buildable on my solaris. The issue was already solved in 6.8.x branch IIRC somehow (replacing readline with different lib IIRC) 2) if [ -e $@ ], i.e. `-e' is not supported by Solaris' /bin/sh, -f works fine. My main motivation behind attempting to build it, is to give Haskell a try inside Eclipse IDE. i.e. Eclipse supports kind of Model Driven Architecture and I would like to use Haskell for models processing and transformations. Thanks! Karel

1 1

ghci debugger :trace command does not always extend trace history
by Peter Hercek 13 Jan '09

13 Jan '09

Hi, I expected ":trace expr" to always add data to the trace history but it does not do so for CAFs (which are not reduced yet). My point is that the command ":trace z" did not add anything to the trace history and I cannot check why value z is 2, because value of y is not in the trace history. Is this the expected behavior? If it is, how can I make ghci to extend the trace history when "forcing" variables? Peter. Here is the example: status:0 peter@metod [765] ~/tmp % cat a.hs test :: Int -> Int test x = let y = x+1 in let z = y+1 in z status:0 peter@metod [766] ~/tmp % ghci a.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( a.hs, interpreted ) Ok, modules loaded: Main. *Main> :break Main 5 Breakpoint 0 activated at a.hs:5:2 *Main> :trace test 0 Stopped at a.hs:5:2 _result :: Int = _ z :: Int = _ 4 let z = y+1 in 5 z 6 [a.hs:5:2] *Main> :back Logged breakpoint at a.hs:(2,0)-(5,2) _result :: Int 1 test :: Int -> Int 2 test x = 3 let y = x+1 in 4 let z = y+1 in 5 z 6 [-1: a.hs:(2,0)-(5,2)] *Main> :back no more logged breakpoints [-1: a.hs:(2,0)-(5,2)] *Main> :forward Stopped at a.hs:5:2 _result :: Int z :: Int 4 let z = y+1 in 5 z 6 [a.hs:5:2] *Main> :trace z 2 [a.hs:5:2] *Main> :back Logged breakpoint at a.hs:(2,0)-(5,2) _result :: Int 1 test :: Int -> Int 2 test x = 3 let y = x+1 in 4 let z = y+1 in 5 z 6 [-1: a.hs:(2,0)-(5,2)] *Main> y <interactive>:1:0: Not in scope: `y' [-1: a.hs:(2,0)-(5,2)] *Main> :back no more logged breakpoints [-1: a.hs:(2,0)-(5,2)] *Main> :forward Stopped at a.hs:5:2 _result :: Int z :: Int 4 let z = y+1 in 5 z 6 [a.hs:5:2] *Main> z 2 [a.hs:5:2] *Main> y <interactive>:1:0: Not in scope: `y' [a.hs:5:2] *Main> :quit Leaving GHCi. status:0 peter@metod [767] ~/tmp %

2 4

RE: [Haskell] type family vs. polymorphism
by Simon Peyton-Jones 13 Jan '09

13 Jan '09

[Redirecting to GHC users] Andres, Nice example. It's another instance of a problem that keeps coming up with type families. Details here: http://hackage.haskell.org/trac/ghc/ticket/1897#comment:10 The rest of the ticket gives other examples. It's not clear what the Right Thing to do is. Simon | -----Original Message----- | From: haskell-bounces(a)haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Andres | Loeh | Sent: 12 January 2009 21:44 | To: haskell(a)haskell.org | Subject: [Haskell] type family vs. polymorphism | | Hi. | | Here's a strange interaction of type families and higher-rank | polymorphism (tested with both ghc-6.8.3 and ghc-6.10.1): | | {-# LANGUAGE TypeFamilies, EmptyDataDecls, RankNTypes #-} | | data X (a :: *) | type family Y (a :: *) | | -- This works (datatype). | i1 :: (forall a. X a) -> X Bool | i1 x = x | | -- This works too (type family and extra arg). | i2 :: (forall a. a -> Y a) -> Y Bool | i2 x = x True | | -- This doesn't work (type family). | -- i3 :: (forall a. Y a) -> Y Bool | -- i3 x = x | | I would expect i3 to be ok as well. Note that this is a | simplified example and not really useful in its simplified | form. | | Cheers, | Andres | | -- | | Andres Loeh, Universiteit Utrecht | | mailto:andres@cs.uu.nl mailto:mail@andres-loeh.de | http://www.andres-loeh.de | _______________________________________________ | Haskell mailing list | Haskell(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell

1 0

Differences in pattern matching syntax?
by Han Joosten 13 Jan '09

13 Jan '09

Hi, I have two alternatives to specify a specific function. They both compile ok, but the first one crashes (Stack space overflow) while the second one runs fine. I use GHC 6.10.1 on windowsXP Alternative 1: antecedent :: Rule -> Expression antecedent r = case r of Ru{} -> if (rrsrt r == AlwaysExpr) then error ("(Module ADLdataDef:) illegal call to antecedent of rule "++show r) else rrant r Sg{} -> antecedent (srsig r) Gc{} -> Tm (grspe r) Fr{} -> frcmp r Alternative 2: antecedent :: Rule -> Expression antecedent r@(Ru AlwaysExpr _ _ _ _ _ _ _ _) = error ("(Module ADLdef:) illegal call to antecedent of rule "++show r) antecedent (Ru _ a _ _ _ _ _ _ _) = a antecedent (Sg _ rule _ _ _ _ _) = antecedent rule antecedent (Gc _ d _ _ _ _ _) = Tm d antecedent (Fr _ _ e _) = e Both alternatives compile, but if i use Alternative 2, then my program runs fine. If I use Alternative 1 instead, I get a stack space overflow. I would think that both alternatives would have the same semantics. So i am surprised that one runs fine, while the other one crashes. Could anyone explain what is going on? Thanks! Han Joosten ---------------------------- Might help, here is the data definition: data Rule = -- Ru c antc p cons cpu expla sgn nr pn Ru { rrsrt :: RuleType -- ^ One of the following: -- | Implication if this is an implication; -- | Equivalence if this is an equivalence; -- | AlwaysExpr if this is an ALWAYS expression. , rrant :: Expression -- ^ Antecedent , rrfps :: FilePos -- ^ Position in the ADL file , rrcon :: Expression -- ^ Consequent , r_cpu :: Expressions -- ^ This is a list of subexpressions, which must be computed. , rrxpl :: String -- ^ Explanation , rrtyp :: (Concept,Concept) -- ^ Sign of this rule , runum :: Int -- ^ Rule number , r_pat :: String -- ^ Name of pattern in which it was defined. } -- Sg p rule expla sgn nr pn signal | Sg { srfps :: FilePos -- ^ position in the ADL file , srsig :: Rule -- ^ the rule to be signalled , srxpl :: String -- ^ explanation , srtyp :: (Concept,Concept) -- ^ type , runum :: Int -- ^ rule number , r_pat :: String -- ^ name of pattern in which it was defined. , srrel :: Declaration -- ^ the signal relation } -- Gc p antc cons cpu _ _ _ | Gc { grfps :: FilePos -- ^ position in the ADL file , grspe :: Morphism -- ^ specific , grgen :: Expression -- ^ generic , r_cpu :: Expressions -- ^ This is a list of subexpressions, which must be computed. , grtyp :: (Concept,Concept) -- ^ declaration , runum :: Int -- ^ rule number , r_pat :: String -- ^ name of pattern in which it was defined. } -- Fr t d expr pn -- represents an automatic computation, such as * or +. | Fr { fraut :: AutType -- ^ the type of automatic computation , frdec :: Declaration -- ^ where the result is to be stored , frcmp :: Expression -- ^ expression to be computed , frpat :: String -- ^ name of pattern in which it was defined. } -- View this message in context: http://www.nabble.com/Differences-in-pattern-matching-syntax--tp21416338p21… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

2 1

Solaris/x86 bot failing on stage2 haddock installation.
by Karel Gardas 11 Jan '09

11 Jan '09

Hello, so it seems I'm still not lucky get head compiling well on solaris/x86 bot. This time compilation fails on stage2 at the haddock installation with following message: Installing library in /buildbot/ghc/kgardas/build/utils/haddock/install-inplace/lib/haddock-2.4.2 Installing executable(s) in /buildbot/ghc/kgardas/build/utils/haddock/install-inplace/bin Registering haddock-2.4.2... ghc-pkg: /buildbot/ghc/kgardas/build/ghc/inplace-datadir/package.conf: openFile: does not exist (No such file or directory) make[2]: *** [install-inplace] Error 1 make[2]: Leaving directory `/buildbot/ghc/kgardas/build/utils/haddock' make[1]: *** [with-stage-2] Error 2 make[1]: Leaving directory `/buildbot/ghc/kgardas/build/utils' make: *** [stage2] Error 2 see http://darcs.haskell.org/buildbot/all/builders/kgardas%20head/builds/98/ste… for more information. Do you have any idea what's going wrong this time? Is it a problem of my bot (shall I install anything else?) or is it GHC's issue? Thanks! Karel

2 3

gcc version to use on sparc/solaris
by Duncan Coutts 11 Jan '09

11 Jan '09

On Fri, 2009-01-02 at 21:06 +1100, Ben Lippmeier wrote: > I'm running into some huge compile times that I'm hoping someone will > have some suggestions about. When compiling Parser.hs the intermediate > .hc file is 4MB big, and is taking GCC 4.2.1 more than 2 hours to get > through. > > Another attempted compile of GHC 6.8.3 is stuck on > libraries/template-haskell/Language/Haskell/TH/Syntax.hs with a 4MB > intermediate .hc file. Here is what I've discovered... I built four versions of gcc and used them to build ghc-6.8.3. I selected the last point release of the last four major gcc releases: gcc-4.0.4 gcc-4.1.2 gcc-4.2.4 gcc-4.3.2 Summary: gcc-4.0.4 or gcc-4.1.2 seems to be the best choice at the moment for ghc on sparc/solaris. gcc-4.0.4 ========= This version passes all expected tests on the gcc testsuite. Using it to build ghc-6.8.3 works fine and it does not take too long. The ghc testsuite result looks like: 2128 total tests, which gave rise to 8040 test cases, of which 1 caused framework failures 1561 were skipped 6130 expected passes 281 expected failures 0 unexpected passes 48 unexpected failures Unexpected failures: 1861(normal,optc,hpc,profc,threaded1,threaded2) barton-mangler-bug(normal,hpc,threaded1) cabal01(normal) conc042(threaded2) conc043(threaded2) conc044(threaded2) conc045(threaded2) conflicting_flags(normal) enum01(hpc) ffi017(ghci) ffi019(normal,optc,hpc,profc,ghci,threaded1,threaded2) ghciprog004(normal) hClose002(normal,optc,hpc,profc,ghci,threaded1,threaded2) joao-circular(normal,optc,hpc,profc,threaded1,threaded2) num012(normal,optc,hpc,profc,ghci,threaded1,threaded2) seward-space-leak(ghci) testblockalloc(normal,threaded1) Some fail in fairly simple ways: cabal01 fails because Solaris tar does not support -C conflicting_flags fails due to a difference in output: -ghc: cannot use `-V' with `--print-libdir' +ghc-6.8.3: cannot use `-V' with `--print-libdir' hClose002 fails with a different error: -Left hClose: invalid argument (Bad file descriptor) +Left hClose: invalid argument (Bad file number) 1861 fails because ghc uses C99 INFINITY macro without using C99 and Solaris header files are more strict about standards than other systems. http://hackage.haskell.org/trac/ghc/ticket/2929 Some look a bit more scary: testblockalloc fails with "out of memory (requested 8388608 bytes)" num012 produces different output: --2147483648 +2147483647 looks like overflow, so definitely something wrong. A number of tests timeout: seward-space-leak(ghci) joao-circular(all) barton-mangler-bug(all) A few tests get bus errors: conc042, conc043, conc044, conc045 ghciprog004 ffi019(all) gcc-4.1.2 ========= This version passes all expected tests on the gcc testsuite. Using it to build ghc-6.8.3 works fine and it does not take too long. The ghc testsuite result looks like: 2128 total tests, which gave rise to 8040 test cases, of which 1 caused framework failures 1561 were skipped 6125 expected passes 281 expected failures 0 unexpected passes 49 unexpected failures Unexpected failures: 1861(normal,optc,hpc,profc,threaded1,threaded2) barton-mangler-bug(normal,optc,hpc,threaded1,threaded2) cabal01(normal) conc042(threaded2) conc043(threaded2) conc044(threaded2) conc045(threaded2) conflicting_flags(normal) ffi017(ghci) ffi019(normal,optc,hpc,profc,ghci,threaded1,threaded2) ghciprog004(normal) hClose002(normal,optc,hpc,profc,ghci,threaded1,threaded2) joao-circular(normal,optc,hpc,profc,threaded1,threaded2) num012(normal,optc,hpc,profc,ghci,threaded1,threaded2) seward-space-leak(ghci) testblockalloc(normal,threaded1) The only difference is that enum01(hpc) does not fail and barton-mangler-bug fails in two more ways (optc, threaded2) gcc-4.2.4 ========= This fails 4 tests on the gcc testsuite. This is the version that gives us massive compile times for larger .hc files (8 hours+ for Syntax.hc). I thought that using -fno-unit-at-a-time would help but ghc is already using that so no luck. It does eventually build but takes nearly 2 days. No testsuite results yet. I'm not sure I can be bothered. gcc-4.3.2 ========= This fails 50 tests on the gcc testsuite. Does not work with ghc-6.8.3 at all, presumably due to the evil mangler. This manifests itself as ./configure failing when it tries to compile and run utils/pwd/pwd: checking for path to top of build tree... /tmp/ghc15055_0/ghc15055_0.hc: In function 'sqD_ret': /tmp/ghc15055_0/ghc15055_0.hc:95:0: note: if this code is reached, the program will abort [...] /tmp/ghc15055_0/ghc15055_0.hc: In function '__stginit_Main': /tmp/ghc15055_0/ghc15055_0.hc:750:0: note: if this code is reached, the program will abort configure: error: cannot determine current directory Indeed it does abort: $ utils/pwd/pwd Illegal Instruction (core dumped) Duncan

2 3

GHC head Solaris bot failing with HsColour needed but wasn't found.
by Karel Gardas 10 Jan '09

10 Jan '09

Hello, I've noticed that my GHC head solaris bot is failing with HsColour needed but wasn't found. Set HSCOLOUR_SRCS=NO if you don't want to use it message on stage1 build since Jan 04. Please let me know what I need to install in order to make head build able again. Thanks, Karel

3 3

Build system idea
by Simon Marlow 10 Jan '09

10 Jan '09

Simon PJ and I had a talk about the build system earlier today, I thought I'd float the idea we discussed (I should admit that the idea was mine, lest Simon PJ think I'm attributing bad ideas to him :-). This is not completely thought through, but I'm pretty sure a solution exists along these lines that would improve things for us. Ok, the starting point is this: - Cabal has code to generate Makefiles. Almost nobody uses it except for the GHC build system. It essentially duplicates the build system for compiling Haskell source (but not for installation, haddocking, registration, configuration, etc.) - Cabal is a library I propose we do this: - Extract the code from Cabal that generates Makefiles, and treat it as part of the GHC build system. Rather than generating a Makefile complete with build rules, we generate a Makefile that just has the package-specific metadata (list of modules, etc.), and put the code to actually build the package in the GHC build system. This means we still get to use 'make', we still get to use the .cabal files as metadata, but the build system is more private to GHC, more extensible, and hopefully more understandable and modifiable. We can express dependencies that Cabal currently doesn't know about. It would let us avoid the current uncomfortable situation where we have to feed all kinds of configuration information from the GHC build system into Cabal - Cabal would be essentially just a mechanism for translating the .cabal file into Makefile bindings and package metadata for ghc-pkg. There will undoubtedly be some sticking points where we have to tradeoff duplicating things from Cabal against re-using parts of Cabal which might require modifying Cabal itself. For instance, we could use Cabal for installation, but that means that our build system has to leave everything in the places that Cabal's installation code expects, so it might be more feasible to do installation ourselves, but that means duplicating parts of Cabal. It will probably mean that we have a tighter dependency on Cabal, because we use it as a library rather than a black box; but hopefully we can keep our branch of Cabal more stable and not have to update it so often. Anyway, this is an idea that I think is interesting. Obviously it needs a lot more fleshing out to be a real proposal, but I'm interested in whether anyone thinks this idea is worth persuing, or whether there are better alternatives. Cheers, Simon

16 49

GADT Strangeness
by Dominic Steinitz 10 Jan '09

10 Jan '09

If I remove -XScopedTypeVariables from this http://hpaste.org/13230 then I get the following error message: > Asn1cTestNew.hs:55:27: > GADT pattern match in non-rigid context for `INTEGER' > Solution: add a type signature > In the pattern: INTEGER > In the definition of `referenceTypeAndValAux2': > referenceTypeAndValAux2 ns INTEGER x > = lhs ns <> text " = " <> text (show x) <> semi > Failed, modules loaded: Language.ASN1, ASNTYPE. At the very least the message is unhelpful. It was only by accident I decided to put in -XScopedTypeVariables. Can anyone offer an explanation as to what is happening? Dominic.

3 6

ghc 6.10.1 on freebsd 7 amd64 - ghci problems
by Markus Barenhoff 08 Jan '09

08 Jan '09

Hi! Because the ports seem not to get updated, I tried to compile ghc 6.10.1 under freebsd 7 on amd64 myself. For compiling I first used the ports ghc version (6.8.3) and then, in a second try I used the self build 6.10.1 to build it again. I added building of api docs with: $ echo "HADDOCK_DOCS = YES" >> mk/build.mk I configured it with a simple ./configure and not more options. The compiler seems to work well on both versions. But if i try to start ghci I get the following: ---- snip ---- $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: Unable to mmap() for jump islands Loading package ghc-prim ... ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for x86_64-unknown-freebsd): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ---- snip ---- It looks he has some kind of library loading problems? Any ideas? Thnx and regards Markus

3 13