- Glasgow-haskell-users

6.10.1 Bug?
by Dominic Steinitz 18 Nov '08

18 Nov '08

According to the hackage page, the Haskell Cryptography Library has a build failure. I couldn't find a bug reference when I searched for milestone 6.10.1 on trac. Should I report it? Has it been fixed? Thanks, Dominic. http://hackage.haskell.org/packages/archive/Crypto/4.1.0/logs/failure/ghc-6… > [4 of 4] Compiling Main ( SHA1Test.hs, dist/build/SHA1Test/SHA1Test-tmp/Main.o ) > ghc: panic! (the 'impossible' happened) > (GHC version 6.10.1 for i386-unknown-linux): > RegAllocLinear.getStackSlotFor: out of stack slots, try -fregs-graph > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug

3 3

Cannot escape from a black hole in ghci 6.10.1
by Ahn, Ki Yung 18 Nov '08

18 Nov '08

Dear GHC users I have both GHC 6.8.2 (debian unstable package) and GHC 6.8.10 (binary distribution from ghc homepage) installed. I was able to escape from a black hole in ghci 6.8.2 with Ctrl-C. For example, GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> let x = x + x Prelude> x ^CInterrupted. Prelude> x *** Exception: stack overflow Prelude> Interestingly, you will get a stack overflow when you try to escape from the black home for the second time. In ghci 6.10.1, I am not able to escape from a black hole with Ctrl-C. GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> let x = x + x Prelude> x ^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C ... (doesn't work) You can't escape from the black hole and ghci will start eating up your memory unless kill the ghci process. Now the black hole behaves like a real black hole :-) Is this a ticketed bug, or should we make a new ticket? -- Ahn, Ki Yung

2 1

Trouble with ghc on linux x86_64
by Bit Connor 18 Nov '08

18 Nov '08

The system is a xen virtual machine: Linux 2.6.24-19 SMP x86_64 Dual-Core AMD Opteron(tm) Processor 2212 AuthenticAMD GNU/Linux With GHC version 6.8.2, ghci gives the error: $ ghci GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help ghc-6.8.2: internal error: R_X86_64_32S relocation out of range: (noname) = 0x7f10a29e56d0 (GHC version 6.8.2 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted GHC version 6.10.1 gives a similar error: $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: internal error: mmap() returned memory outside 2Gb (GHC version 6.10.1 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted These same 2 results happen on 2 different distros that I've tried. With both GHC versions, compiling haskell programs sometimes works, but sometimes hangs during the linking stage. The results are the same using the distro provided packages and with the binaries from the ghc website. I also actually managed to compile ghc version 6.10.1 using ghc 6.8.2, but not completely, "make" got froze during haddock generation for ghc-6.10.1. There was however a "ghc" binary that was produced in the directory ghc/dist-stage2/build/ghc/ghc. Running this binary as --interactive gave the exact same 6.10.1 error above. Any ideas? Thanks, Bit

2 3

problem with echo prompting in ghci (visible in emacs)
by Conal Elliott 17 Nov '08

17 Nov '08

ghci echoes all of my input in emacs, when run via haskell-mode or via "M-x shell", which then confuses various useful haskell-mode features. I built it from sources. At the time I didn't have libedit-dev, so today I installed libedit-dev (version 2.11~20080614 on ubuntu), did a clean make & install, and I get exactly the same behavior. Does anyone have experience in getting through this problem? Willing to help me out? Thanks, - Conal

2 3

more libedit.so.0 issues
by James Swaine 17 Nov '08

17 Nov '08

We've had unbelievable problems getting past this ridiculous 'unable to load object file or shared library libedit.so.0' error when attempting to build the 6.10.1 source tree. We initially just built editline in a user directory and attempted to manipulate environment variables to help the linker (e.g. setting LIBRARY_PATH, LD_LIBRARY_PATH, and CPATH) - but this did no good. We then just installed the editline package so it's available globally and the libraries (specifically libedit.so.0) live in /usr/local/lib, so it should be found with no problem. Not so for ghc - same error. We're running this on Red Hat. I'm part of a research group at Northwestern University that is exploring the use of ghc and associated libraries for some upcoming projects. It's a shame that this is so difficult to even compile/install, and nobody seems to be able to figure out what's wrong.

6 13

extra libraries vs. cabal libraries (ghc-6.10.1)
by Christian Maeder 16 Nov '08

16 Nov '08

Hi, the documentation of extra libraries is listed under share/doc/ghc/libraries/ 1. Is it possible to add cabal packages in the same way? How? 2. It would be nice if the cabal-install (i.e. the binary cabal) came with ghc. Currently zlib, HTTP and cabal-install have to be (awkwardly) installed via Setup before being able to "cabal install". Cheers Christian

3 2

editline in ghc-6.10.1 under Solaris
by Christian Maeder 16 Nov '08

16 Nov '08

Hallo Judah, I've build http://www.thrysoee.dk/editline/libedit-20080712-2.11.tar.gz and it was linked against libcurses: -bash-3.1$ ldd /usr/local/lib/libedit.so.0 libcurses.so.1 => /lib/libcurses.so.1 libc.so.1 => /lib/libc.so.1 libgcc_s.so.1 => /usr/local/lang/lib/gcc/i386-pc-solaris2.10/4.2.2/libgcc_s.so.1 libm.so.2 => /lib/libm.so.2 When building ghc-6.10.1 your configure script prefers ncurses over curses, therefore I get an additional dependency for ghc: libncurses.so.5 => /usr/local/lib/libncurses.so.5 For (the usual) dynamic linking just "-ledit" is enough, only for static linking "-lcurses" or "-lncurses" is needed, otherwise "term.o" is the "Undefined symbol". (By chance, I've only libncurses.a and no libcurses.a for static linking.) I'm not sure which dependency to prefer. configure of libedit-20080712-2.1 prefers curses over ncurses. Cheers Christian P.S. While relinking the stage2 compiler I'll noticed that also haddock depends on libedit which I think should be avoided (by splitting the ghc package)! Which other ghc-6.10.1 binaries depend on libedit? P.P.S My PC binary distribution is here: http://www.dfki.de/sks/hets/pc-solaris/ghcs/ghc-6.10.1-i386-unknown-solaris… I did not succeed to build ghc-6.10.1 for a Sparc http://hackage.haskell.org/trac/ghc/ticket/2692

2 1

RPM for 6.10.1 on Fedora?
by Colin Paul Adams 16 Nov '08

16 Nov '08

I have 6.8.2 installed here (Fedora 9 x86_64). Doing a yum update says no update available. Does this mean I have yum wrongly configured, or is it just the case that the 6.10.1 roms haven't been built yet? -- Colin Adams Preston Lancashire

1 0

Re: "A lazy (~) pattern cannot bind existential type variables"?
by Conal Elliott 16 Nov '08

16 Nov '08

> > > data HasShow = forall a. Show a => HasShow a > > weird ~(HasShow x) = HasShow x > > Now, what Show context is referred to by the result of "weird undefined"? > I'd expect bottom, just as with matching ~(x,y) against bottom. The lambda is not the same as the "where" clause. Let's desugar a few > of the code snippets you gave me: [...] > Thanks. I get it now, and I see that the only version that makes it through the type-checker is the one that defeats laziness and therefore generally breaks these nice morphism properties. That algebraic failure seems reason enough to try fixing ghc. - Conal On Sun, Nov 16, 2008 at 2:18 AM, Ryan Ingram <ryani.spam(a)gmail.com> wrote: > > My brain just exploded. > > Best compiler error message ever. > > I think that existential quantification with lazy matches can do some > crazy things to the type system. > > > lazyPair ~(a,b) = (a,b). > > So, lazyPair undefined = (undefined, undefined); it makes any pair > "more defined". But what does this do when you have an existential > context? > > > data HasShow = forall a. Show a => HasShow a > > weird ~(HasShow x) = HasShow x > > Now, what Show context is referred to by the result of "weird undefined"? > > > useShow (HasShow x) = show x > > broken = useShow (weird undefined) > > It's likely that there is a way to solve this; you need to force the > pattern match to take place anywhere that the existential type gets > applied (in the System F sense). But I think that doing so is a lot > more difficult for the compiler author, and it's an edge case in the > language. > > The lambda is not the same as the "where" clause. Let's desugar a few > of the code snippets you gave me: > > > fmap g ~(WC f k) = WC f (fmap g k) > => fmap = \g wc -> let (WC f k) = wc in WC f (fmap g k) > > > fmap g wc = WC f (fmap g k) > > where WC f k = wc > => fmap = \g wc -> let (WC f k) = wc in WC f (fmap g k) > (same as above) > > > fmap g = \ (WC f k) -> WC f (fmap g k) > => fmap = \g wc -> case wc of (WC f k) -> WC f (fmap g k) > (i.e. the same as not using a lazy pattern at all) > > I'll think about this and see if I can come up with a workaround. I'm > not sure it's possible in GHC. > > -- ryan > > > On Sat, Nov 15, 2008 at 10:33 PM, Conal Elliott <conal(a)conal.net> wrote: > > What is the reasoning behind the ghc restriction that "A lazy (~) pattern > > cannot bind existential type variables"? > > > > This error came up for me in the following code: > > > > -- | Add a continuation. > > data WithCont h b c = forall a. WC (h b a) (a -> c) > > > > instance Functor (WithCont h b) where > > fmap g ~(WC f k) = WC f (fmap g k) > > > > The error message: > > > > A lazy (~) pattern cannot bind existential type variables > > `a' is a rigid type variable bound by > > the constructor `WC' at Data/Zip/FoldL.hs:66:11 > > In the pattern: ~(WC f k) > > > > I also tried this variation: > > > > instance Functor (WithCont h b) where > > fmap g wc = WC f (fmap g k) > > where WC f k = wc > > > > and got this message: > > > > My brain just exploded. > > I can't handle pattern bindings for existentially-quantified > > constructors. > > Instead, use a case-expression, or do-notation, to unpack the > > constructor. > > In the binding group for > > WC f k > > In a pattern binding: WC f k = wc > > > > I can work around these limitations by using a lambda: > > > > instance Functor (WithCont h b) where > > fmap g = \ (WC f k) -> WC f (fmap g k) > > > > which I believe is equivalent. Please correct me if I'm wrong here. > > > > For infix definitions like (<*>), however, this work-around is less > > pleasant. > > For instance, > > > > (<*>) = \ (WC hf hk) (WC xf xk) -> > > WC (hf `zip` xf) (\ (a,a') -> (hk a) (xk a')) > > > > instead of the prettier but forbidden > > > > ~(WC hf hk) <*> ~(WC xf xk) = > > WC (hf `zip` xf) (\ (a,a') -> (hk a) (xk a')) > > > > > > If you're curious what these definitions are about, see > > http://conal.net/blog/posts/enhancing-a-zip/ . > > > > Thanks, - Conal > > > > >

1 0

GHC on powerpc (OS X): segmentation fault
by Chris Kuklewicz 16 Nov '08

16 Nov '08

I am having trouble compiling GHC using mac ports on powerpc OS X (10.5.5) (using XCode 3.1). I have also opened a ticket at http://trac.macports.org/ticket/17184 which has the full build log attached. The build starts with > nice port -c upgrade ghc > ---> Staging gmp into destroot > ---> Packaging tgz archive for gmp 4.2.4_0 > ---> Deactivating gmp 4.2.3_0 > ---> Installing gmp 4.2.4_0 > ---> Activating gmp 4.2.4_0 > ---> Cleaning gmp > ---> Fetching ghc > ---> Attempting to fetch ghc-6.10.1-src.tar.bz2 from http://haskell.org/ghc/dist/stable/dist/ > ---> Attempting to fetch ghc-6.10.1-src-extralibs.tar.bz2 from http://haskell.org/ghc/dist/stable/dist/ > ---> Attempting to fetch ghc-6.8.2-darwin-ppc-leopard-bootstrap.tar.bz2 from http://haskell.org/ghc/dist/6.8.2/ > ---> Verifying checksum(s) for ghc > ---> Extracting ghc > ---> Applying patches to ghc > ---> Configuring ghc > ---> Building ghc with target all > Error: Target org.macports.build returned: shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1 && env DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib make" returned error 2 > Command output: /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc -optc-O -optc-I/opt/local/include -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I/opt/local/include -optc-I../gmp/gmpbuild -optc-I../libffi/build/include -optc-fno-strict-aliasing -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c parallel/GranSim.c -o parallel/GranSim.o Eventually the build fails with > /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc -optc-O -optc-I/opt/local/include -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I/opt/local/include -optc-I../gmp/gmpbuild -optc-I../libffi/build/include -optc-fno-strict-aliasing -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c sm/Sweep.c -o sm/Sweep.o > /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c Apply.cmm -o Apply.o > make[1]: *** [Apply.o] Segmentation fault > make: *** [stage1] Error 2 Does anyone have a clue how to proceed?

5 9