- Glasgow-haskell-users

GHC 6.8.1 on FreeBSD 7/amd64
by Brian P. O'Hanlon 17 Nov '07

17 Nov '07

Hello, all. I successfully built GHC 6.8.1 on my FreeBSD 7.0_BETA amd64 machine. I was able to bootstrap it from the GHC 6.6.1 for FreeBSD 6/amd64 which was posted to this list a while ago (and was running in FreeBSD 6 compatibility mode), as well as happy 1.15 which I compiled with that same compiler. I did have to make a minor modification; in the configure script, the machine type needed to be changed from amd64-*-freebsd* to x86_64-*-freebsd* (the same needed to be done for happy when I compiled that earlier). The C compiler was the stock gcc 4.2 compiler. GHCi does not work, but I did not really expect that it would since it did not in 6.6.1. I do not know how useful this might be to anyone else; mine is a rather esoteric setup (I am really only even using FreeBSD 7 because FreeBSD 6 does not support my video card or SATA controller), but if people are interested in binaries, I should be able to do that. -Brian -- Brian P. O'Hanlon, <brianpo+(a)cmu.edu>, 7039012836, KG4QXK Carnegie Mellon University - Math, Computer Science, and English Chairman, Spring Carnival; Station Manager, W3VC; Co-President, Math Club; Social Director, Computer Club

2 1

GHC 6.8.1 SpecConstr
by kenny lu 17 Nov '07

17 Nov '07

Hi, Recall the example from Simon's paper appearing in ICFP 2007. myLast :: [a] -> a myLast [] = error "" myLast [x] = x myLast (x:xs) = myLast xs which returns the last element in a list. Applying the idea in the paper, we should rewrite the function as follows, myLast :: [a] -> a myLast [] = error "" myLast (x:xs) = myLast' x xs where myLast' x [] = x myLast' x (y:ys) = myLast' y ys which avoids redundant pattern tests. We tried to compile the "unspecialized" version of myLast function with GHC 6.8.1 with -O2 -ddump-simpl flags and observe the core code as follows, ==================== Tidy Core ==================== lvl_r72 :: forall a_a5P. a_a5P [GlobalId] [Str: DmdType b] lvl_r72 = \ (@ a_a5P) -> GHC.Err.error @ a_a5P (GHC.Base.[] @ GHC.Base.Char) Rec { Last.$smyLast :: forall a_a5P. a_a5P -> [a_a5P] -> a_a5P [GlobalId] [Arity 2] Last.$smyLast = \ (@ a_a5P) (ipv_s6i :: a_a5P) (ipv1_s6j :: [a_a5P]) -> case ipv1_s6j of wild_X9 { [] -> ipv_s6i; : ipv2_X6p ipv3_X6r -> Last.myLast @ a_a5P wild_X9 } Last.myLast :: forall a_a5B. [a_a5B] -> a_a5B [GlobalId] [Arity 1 Str: DmdType S] Last.myLast = \ (@ a_a5P) (ds_d68 :: [a_a5P]) -> case ds_d68 of wild_B1 { [] -> lvl_r72 @ a_a5P; : x_a5I ds1_d69 -> case ds1_d69 of wild1_X9 { [] -> x_a5I; : ipv_s6i ipv1_s6j -> Last.myLast @ a_a5P wild1_X9 } } end Rec } ==================== Tidy Core Rules ==================== "SC:Last.myLast0" [0] forall {@ a_a5P ipv_s6i :: a_a5P ipv1_s6j :: [a_a5P]} Last.myLast @ a_a5P (GHC.Base.: @ a_a5P ipv_s6i ipv1_s6j) = Last.$smyLast @ a_a5P ipv_s6i ipv1_s6j It seems that $smyLast is the specialized version of myLast And the last tidy core rule says that we should replace the application (myLast (x:xs)) by ($smyLast x xs). We are surprised by the development of the second pattern of $smyLast. In the second pattern, function myLast is applied to wild_X9 which is the reference of ipv_s6j. However, according to the running example, it seems to make more sense if this application is replaced by a recursive application ($smyLast ipv_3X6r) instead. Could you guys please enlighten me? Regards, Kenny

4 3

Problem with functional dependencies
by Daniel Gorín 17 Nov '07

17 Nov '07

Hi I have some code that uses MPTC + FDs + flexible and undecidable instances that was working fine until I did a trivial modification on another part of the project. Now, GHC is complaining with a very confusing (for me, at least) error message. I've been finally able to reproduce the problem using these three small modules: > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE FunctionalDependencies #-} > {-# LANGUAGE FlexibleInstances #-} > module M1 > > where > > data M n = M > data F n = F > > class C m f n | m -> n, f -> n where > c :: m -> f -> Bool > > instance C (M n) (F n) n where > c _ _ = True > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE FlexibleInstances #-} > module M2 > > where > > import M1 > > newtype F'= F' (F N) > > data N = N > > instance C m (F N) N => C m F' N where > c m (F' f) = c m f > module M3 > > where > > import M1 > import M2() > > data N' = N' > > go :: M N' -> F N' -> Bool > go m f = c m f Now, when trying to compile M3 (both in 6.6.1 and 6.8.1) I get: M3.hs:11:0: Couldn't match expected type `N'' against inferred type `M2.N' When using functional dependencies to combine C m M2.F' M2.N, arising from the instance declaration at M2.hs: 13:0 C (M N') (F N') N', arising from use of `c' at M3.hs:11:9-13 When generalising the type(s) for `go' It is worth observing that: - M2 compiles fine - No type defined in M2 is visible in M3 - if the "import M2()" is commented out from M3, it compiles fine - if, in M3, N' is placed by N (needs to be imported), everything compiles again Normally, it takes me some time to digest GHC's type-classes-related error messages, but after some reflection, I finally agree with them. This time, however, I'm totally lost. I can't see any reason why N' and M2.N would have to be unified, nor why this code should be rejected. Any help would be much appreciated! Daniel

2 3

6.8.1: source code in docs?
by Greg Fitzgerald 16 Nov '07

16 Nov '07

GHC 6.8.1's docs no longer link to the source code in the upper right-hand corner of each module. Intentional? http://haskell.org/ghc/docs/latest/html/libraries/ Thanks, Greg

1 0

State of parallel GC?
by Ravi Nanavati 16 Nov '07

16 Nov '07

I seem to recall reading in a GHC status report that there was some work going on with parallel garbage-collection. Looking at 6.8.1, it seems pretty clear that it didn't make it. Is there any update about where things are on that front? It isn't an immediately pressing need a Bluespec, but we do get asked every once in a while about parallelizing the Bluespec compiler. One of the technical reasons we're holding off on that front is that it wouldn't win as much as people expect (because garbage collection is usually a decent fraction of a typical run), so we'd be interested if the state-of-play in that area changed. Thanks, - Ravi

6 5

GHC 6.8.1 Build Failure on Mac OS X Intel 10.4.10
by Denis Bueno 15 Nov '07

15 Nov '07

Hi all, Apologies if this has already been reported, or is a symptom of something already reported. I downloaded the GHC source (http://www.haskell.org/ghc/dist/6.8.1/ghc-6.8.1-src.tar.bz2) and attempted to build as follows, bootstrapping with GHC 6.6.1: ./configure ; make -j3 (The error manifests even without `-j3'.) This eventually results in the error [1]: ghc-pkg: dependency readline doesn't exist (use --force to override) But config.log reports: configure:2809: checking for ghc-pkg matching /opt/local/bin/ghc configure:2821: result: /opt/local/bin/ghc-pkg configure:2868: checking whether ghc has readline package configure:2879: result: yes Via MacPorts I have gmp 4.2.2 and readline 5.2.007 installed; I am using XCode 2.5 and gcc 4.0.1. The failure also happens if extralibs is built alongside GHC. I've checked http://hackage.haskell.org/trac/ghc/wiki/X86OSXGhc and googled the error message, but found nothing useful. If there any more useful information I could provide, let me know. -- Denis [1] Here is more of the erroneous output: == Finished recursively making `all' for ways: p ... Registering haskell98-1.0.1.0... Reading package info from "dist/inplace-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. make stage2 make -C compiler boot stage=2 ../utils/mkdirhier/mkdirhier stage2 gcc -E -undef -traditional -P \ -DIMPORT_DIR='"/Users/Shared/incoming/ghc-6.8.1/libraries/ghc"' \ -DLIB_DIR='"/Users/Shared/incoming/ghc-6.8.1/libraries/ghc"' \ -DINCLUDE_DIR='"/Users/Shared/incoming/ghc-6.8.1/libraries/ghc/include"' \ -DDATA_DIR='"/Users/Shared/incoming/ghc-6.8.1/libraries/ghc"' \ -DHTML_DIR='"/Users/Shared/incoming/ghc-6.8.1/libraries/ghc/html"' \ -DHADDOCK_IFACE='"/Users/Shared/incoming/ghc-6.8.1/libraries/ghc/html/ghc.haddock"' \ -DFPTOOLS_TOP_ABS='"/Users/Shared/incoming/ghc-6.8.1"' \ -x c -DPKG_DEPENDS='hpc bytestring template-haskell readline unix Cabal base haskell98' -DSTAGE='"2"' -I../includes -Iinclude -DPACKAGE=ghc -DVERSION=6.8.1 -DPKG_LIBDIR='"/usr/local/lib/ghc-6.8.1"' -DPKG_DATADIR='"/usr/local/share/ghc-6.8.1"' package.conf.in | \ grep -v '^#pragma GCC' | \ sed -e 's/""//g' -e 's/:[ ]*,/: /g' >package.conf.inplace mkdir stage2 ../utils/ghc-pkg/ghc-pkg-inplace update - --force-files <package.conf.inplace for i in utils basicTypes types hsSyn prelude rename typecheck deSugar coreSyn vectorise specialise simplCore stranal stgSyn simplStg codeGen main profiling parser cprAnalysis ndpFlatten iface cmm nativeGen ghci; do \ ../utils/mkdirhier/mkdirhier stage2/$i; \ done mkdir stage2/utils mkdir stage2/basicTypes mkdir stage2/types mkdir stage2/hsSyn Reading package info from stdin ... done. ghc-pkg: dependency readline doesn't exist (use --force to override) make[2]: *** [../driver/stamp-pkg-conf-ghc] Error 1 make[2]: *** Waiting for unfinished jobs.... mkdir stage2/prelude mkdir stage2/rename mkdir stage2/typecheck mkdir stage2/deSugar mkdir stage2/coreSyn mkdir stage2/vectorise mkdir stage2/specialise mkdir stage2/simplCore mkdir stage2/stranal mkdir stage2/stgSyn mkdir stage2/simplStg mkdir stage2/codeGen mkdir stage2/main mkdir stage2/profiling mkdir stage2/parser mkdir stage2/cprAnalysis mkdir stage2/ndpFlatten mkdir stage2/iface mkdir stage2/cmm mkdir stage2/nativeGen mkdir stage2/ghci make[1]: *** [stage2] Error 2 make: *** [bootstrap2] Error 2

5 6

some links broken in 6.8.1 documentation
by Daniil Elovkov 15 Nov '07

15 Nov '07

Hello folks A quick look at the 6.8.1 user's guide reveals some broken links: 1) Obtaining code coverage, pointing to http://haskell.org/ghc/docs/6.8.1/html/users_guide/hpc.html redirects to http://projects.unsafeperformio.com/hpc.html which tells that it's not found but guesses at another location, where it is found. 2) Concurrent and parallel haskell http://haskell.org/ghc/docs/6.8.1/html/users_guide/lang-parallel.html (and possibly other pages) have links to libraries according to the pre-base-split structure, like .../base/.. instead of .../parallel/..., which results in those links being broken. Thank you -- Daniil Elovkov

3 4

Re: ANNOUNCE: GHC version 6.8.1
by Philip K.F. Hölzenspies 14 Nov '07

14 Nov '07

Dear Ian, all, Even in the current release, I'm still having trouble building GHC on my linux machine. The error is still about DerivedConstants.h. I'm sorry for not following up on my last report, but I'll try and make things right with this one. curl http://www.haskell.org/ghc/dist/6.8.1/ghc-6.8.1-src.tar.bz2 | tar -xj curl http://www.haskell.org/ghc/dist/6.8.1/ghc-6.8.1-src.tar.bz2 | tar -xj cd ghc-6.8.1 sh boot ./configure &> configure.output make &> make.output The outputs are attached to this e-mail. I just wanted to note some of the highlights: The boot script still warns about underquoting (and I still don't know whether this is relevant at all): Booting . Booting libraries/base Booting libraries/directory /usr/share/aclocal/progsreiserfs.m4:13: warning: underquoted definition of AC_CHECK_LIBREISERFS run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal Booting libraries/old-time Booting libraries/process Booting libraries/readline Booting libraries/unix The make still fails on the absence of (a rule for) DerivedConstants.h: /usr/local/bin/ghc -H16m -O -istage1/utils -istage1/basicTypes -istage1/types -istage1/hsSyn -istage1/prelude -istage1/rename -istage1/typecheck -istage1/deSugar -istage1/coreSyn -istage1/vectorise -istage1/specialise -istage1/simplCore -istage1/stranal -istage1/stgSyn -istage1/simplStg -istage1/codeGen -istage1/main -istage1/profiling -istage1/parser -istage1/cprAnalysis -istage1/ndpFlatten -istage1/iface -istage1/cmm -istage1/nativeGen -Wall -fno-warn-name-shadowing -fno-warn-orphans -Istage1 -cpp -fglasgow-exts -fno-generics -Rghc-timing -I. -Iparser -package unix -ignore-package lang -recomp -Rghc-timing -H16M '-#include "cutils.h"' -DUSING_COMPAT -i../compat -ignore-package Cabal -c codeGen/CgPrimOp.hs -o stage1/codeGen/CgPrimOp.o -ohi stage1/codeGen/CgPrimOp.hi make[1]: *** No rule to make target `../includes/DerivedConstants.h', needed by `stage1/codeGen/CgProf.o'. Stop. make[1]: Leaving directory `/local/holzensp/src/ghc-6.8.1/compiler' make: *** [stage1] Error 1 Somewhere near the beginning of make's output, where the output for "make boot" is logged, it does seem to have created DerivedConstants.h: ../utils/mkdependC/mkdependC -f .depend -- -O -DTABLES_NEXT_TO_CODE -I. -I../rts -- mkDerivedConstants.c rm -f mkDerivedConstants.o gcc -O -DTABLES_NEXT_TO_CODE -I. -I../rts -c mkDerivedConstants.c -o mkDerivedConstants.o gcc -o mkDerivedConstantsHdr -O -DTABLES_NEXT_TO_CODE -I. -I../rts mkDerivedConstants.o ./mkDerivedConstantsHdr >DerivedConstants.h gcc -o mkGHCConstants.o -O -DTABLES_NEXT_TO_CODE -I. -I../rts -c mkDerivedConstants.c -DGEN_HASKELL gcc -o mkGHCConstants -O -DTABLES_NEXT_TO_CODE -I. -I../rts mkGHCConstants.o ./mkGHCConstants >GHCConstants.h Later in the "make all" phase, there is another mention of DerivedConstants: rm -f mkDerivedConstants.o gcc -O -DTABLES_NEXT_TO_CODE -I. -I../rts -c mkDerivedConstants.c -o mkDerivedConstants.o gcc -o mkDerivedConstantsHdr -O -DTABLES_NEXT_TO_CODE -I. -I../rts mkDerivedConstants.o ./mkDerivedConstantsHdr >DerivedConstants.h gcc -o mkGHCConstants.o -O -DTABLES_NEXT_TO_CODE -I. -I../rts -c mkDerivedConstants.c -DGEN_HASKELL gcc -o mkGHCConstants -O -DTABLES_NEXT_TO_CODE -I. -I../rts mkGHCConstants.o ./mkGHCConstants >GHCConstants.h I don't see the header file being removed anywhere, but it does indeed not show up in the includes directory. When I cheat and, after this failed build, do the following: cd includes make cd .. make the build runs until [42 of 42] and fails, saying: Configuring base-3.0.0.0... Setup: Cannot find ghc at ../../compiler/stage1/ghc-inplace or on the path rm -f base/GNUmakefile cp Makefile.local base if ifBuildable/ifBuildable base; then \ cd base && setup/Setup makefile -f GNUmakefile; \ fi Setup: error reading dist/setup-config; run "setup configure" command? This is where I currently am with trying to build GHC. I hope this serves as a decent bug report. Regards, Philip

6 9

Unpacking across modules
by Scott Dillard 14 Nov '07

14 Nov '07

Hello, What is the interaction between the UNPACK pragma and modules? I've attached a small test case where a datatype is unpacked when it and its associated functions are defined in the same file in which they are used, but it is not unpacked if the definitions are given in another module. There are two versions of the data type, a monomorphic one, defined by: > data Vec3 = Vec3 Double Double Double and a polymorphic, recursive one, defined by > data C a b = C a b With the following typedef to make them equivalent > type Vec3 = C Double (C Double (C Double () )) In the actual file, they're both appropriately annotated with bangs and UNPACK pragmas. The mono datatype is successfully unpacked in both cases, when it is defined in the same file and in a different file. The poly datatype is only unpacked when it is defined in the same file. To see the behavior, compile the attached files with -DMONO_SAME, -DMONO_OTHER, -DPOLY_SAME and -DPOLY_OTHER. In all cases except POLY_OTHER, the program runs in constant space, and in time that is quite competitive with C. (Nice work guys!) However, for POLY_OTHER you will likely have to kill it. The only other flag I used is -O2. Please let me know there's something I'm missing here. Is there a reason why this data type cannot be unboxed across modules? Or is this a bug? Thanks, Scott PS: Also, when the INLINE pragma is used with the Storable instance for the polymorphic data type, it causes heap explosion, even in the same file. Any thoughts here?

2 2

RE: Build failures making GHC 6.8.1 on PPC Mac Os X 10.5
by Corey O'Connor 13 Nov '07

13 Nov '07

(Sorry I couldn't reply to the existing thread; wasn't on the mailing list till recently) I'm also having build problems trying to make GHC 6.8.1 on Mac OS X 10.5 on PPC. Specifically: ../../compiler/stage1/ghc-inplace -package-name parsec-2.1.0.0-hide-all-packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.0.0 -O -XExistentialQuantification -XPolymorphicComponents -idist/build -H16m -O -O -Rghc-timing -fgenerics -c Text/ParserCombinators/Parsec/Token.hs -o dist/build/Text/ParserCombinators/Parsec/Token.o -ohi dist/build/Text/ParserCombinators/Parsec/Token.hi collect2: ld terminated with signal 10 [Bus error] <<ghc: 335847016 bytes, 43 GCs, 3796398/5983044 avg/max bytes residency (3 samples), 19M in use, 0.00 INIT (0.01 elapsed), 3.07 MUT (23.06 elapsed), 0.54 GC (1.29 elapsed) :ghc>> make[2]: *** [dist/build/Text/ParserCombinators/Parsec/Token.o] Error 1 make[1]: *** [make.library.parsec] Error 2 make: *** [stage1] Error 2 This is on a dual G5 not a PowerBook G4 as previous reports seamed to be from. Anytime I see the linker crash I get nervous. Any clues on where to start debugging? -- -Corey O'Connor

5 5