July 2008 - Glasgow-haskell-users

GHC 6.6 GADT type unification vs GHC 6.8
by Jason Dagit 29 Jul '08

29 Jul '08

Hello, I was wresting with the problem of converting our type witness code in darcs to work with ghc 6.8 and it occurred to me that someone has probably document the change somewhere. In particular, I'm seeing this error message a lot, but 6.6 doesn't give this message: GADT pattern match in non-rigid context for `NilRL' Tell GHC HQ if you'd like this to unify the context The main difference I have observed is that 6.6 infers types in case statements fully, but 6.8 seems to skip them and expects type signatures. Sometimes I'm at a loss to figure out where to add the type signature to satisfy 6.8 and the process becomes tedious and time consuming. I'm using 6.8.2 and I did see this thread: http://www.haskell.org/pipermail/glasgow-haskell-users/2007-December/013952… What version of GHC do I need to see the improved diagnostics mentioned in that thread? Will the GADT unification in 6.10 be compatible with 6.6? If so, maybe I shouldn't convert the code to work for 6.8. Also, can someone point me to a discussion of the difference or a paper about it? Thanks, Jason

2 4

Re: ghc 6.8.3 build error with __DISCARD__ linking problem, please help!
by Yu Di 26 Jul '08

26 Jul '08

Thanks! I installed 6.8.2 binary and that successfully compiled 6.8.3 source with gcc 4.1.1. (I am still not sure why a direct 6.8.3. binary installation did not work for me, but now I think everything is good). Thanks very much again! Di, Yu 7.26 ----- Original Message ---- From: Simon Marlow <marlowsd(a)gmail.com> To: Yu Di <diyu60607(a)yahoo.com> Cc: glasgow-haskell-users(a)haskell.org Sent: Friday, July 25, 2008 3:52:01 AM Subject: Re: ghc 6.8.3 build error with __DISCARD__ linking problem, please help! Yu Di wrote: > Hi, I am trying to build ghc 6.8.3 from source release, my currently > installed version is ghc 6.4.2 (x86 linux binary release version), and I > got: > > /usr/local/ghc/bin/ghc -o ghc-pkg.bin -H16m -O -cpp -Wall > -fno-warn-name-shadowing -fno-warn-unused-matches -DUSING_COMPAT > -i../../compat -ignore-package Cabal -Rghc-timing -package unix > -L../../compat -lghccompat Main.o Version.o CRT_noglob.o > Main.o: In function `__stginit_ZCMain': > ghc13533.hc:(.text+0x4): undefined reference to `__DISCARD__' > ghc13533.hc:(.text+0x9): undefined reference to `__DISCARD__' > Main.o: In function `__stginit_Main': > ghc13533.hc:(.text+0x18): undefined reference to `__DISCARD__' > ghc13533.hc:(.text+0x1d): undefined reference to `__DISCARD__' > Main.o: In function `__stginit_Main_': > ghc13533.hc:(.text+0x2c): undefined reference to `__DISCARD__' > Main.o:ghc13533.hc:(.text+0x3d): more undefined references to > `__DISCARD__' follow > collect2: ld returned 1 exit status > <<ghc: 13726704 bytes, 3 GCs, 105428/105428 avg/max bytes residency (1 > samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (1.98 elapsed), > 0.01 GC (0.03 elapsed) :ghc>> > > Do you know how I can fix this problem? My ghc and gcc versions are: > > The Glorious Glasgow Haskell Compilation System, version 6.4.2 > gcc (GCC) 4.1.1 20060724 (prerelease) (4.1.1-4pclos2007) > > (I also tried ghc 6.2.0 and gcc 3.3.6, but all combinations resulted in > the same error message) The error is coming from your installed 6.4.2, and I strongly suspect that it is incompatible with the gcc version you have installed. You could try downgrading gcc, but your best bet is to just install a recent GHC binary distribution. Cheers, Simon

1 0

ghc 6.8.3 build error with __DISCARD__ linking problem, please help!
by Yu Di 25 Jul '08

25 Jul '08

Hi, I am trying to build ghc 6.8.3 from source release, my currently installed version is ghc 6.4.2 (x86 linux binary release version), and I got: /usr/local/ghc/bin/ghc -o ghc-pkg.bin -H16m -O -cpp -Wall -fno-warn-name-shadowing -fno-warn-unused-matches -DUSING_COMPAT -i../../compat -ignore-package Cabal -Rghc-timing -package unix -L../../compat -lghccompat Main.o Version.o CRT_noglob.o Main.o: In function `__stginit_ZCMain': ghc13533.hc:(.text+0x4): undefined reference to `__DISCARD__' ghc13533.hc:(.text+0x9): undefined reference to `__DISCARD__' Main.o: In function `__stginit_Main': ghc13533.hc:(.text+0x18): undefined reference to `__DISCARD__' ghc13533.hc:(.text+0x1d): undefined reference to `__DISCARD__' Main.o: In function `__stginit_Main_': ghc13533.hc:(.text+0x2c): undefined reference to `__DISCARD__' Main.o:ghc13533.hc:(.text+0x3d): more undefined references to `__DISCARD__' follow collect2: ld returned 1 exit status <<ghc: 13726704 bytes, 3 GCs, 105428/105428 avg/max bytes residency (1 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.01 MUT (1.98 elapsed), 0.01 GC (0.03 elapsed) :ghc>> Do you know how I can fix this problem? My ghc and gcc versions are: The Glorious Glasgow Haskell Compilation System, version 6.4.2 gcc (GCC) 4.1.1 20060724 (prerelease) (4.1.1-4pclos2007) (I also tried ghc 6.2.0 and gcc 3.3.6, but all combinations resulted in the same error message) Thanks!

2 1

Advice sought for 6.9 and Arrow/Category
by Conal Elliott 22 Jul '08

22 Jul '08

I want to use ghc-6.9 for improved support of type families, but I see that the change to the Arrow interface breaks some of my libraries (since (>>>) is no longer a method of Arrow). Will this change really be in ghc-6.9? Does anyone have coping strategies for keeping libraries working in 6.8 *and* 6.9, particularly ones that define instances of Arrow? Thanks, - Conal

5 6

Building libraries with ticky-ticky
by Andrew Hunter 21 Jul '08

21 Jul '08

Hi, I have some code I want to use ticky-ticky profiling on (if it matters, I want some of the data ticky-ticky collects about frequency of updates and related matters.) However, I'm specifically interested in the code running with some modificiations I've made to the RTS, so I need to build GHC with ticky-ticky. That in itself isn't hard--the documentation said to just run "make way=t" in rts/, which seemed to work; but the documentation also said that to get meaningful numbers, I should make sure to build the libraries with ticky-ticky (which makes sense--I'm interested in the same data whether or not the updates happen in a function from List or one I wrote, &c.) The documentation does *not*, however, say (anywhere I can find) how to do this! My natural guess was to go into mk/build.mk, and add -ticky to GhcLibHcOpts, but that didn't work (regardless of whether I had previously built a ticky rts, this produced a multitude of linker errors.) I also tried, on a lark, adding "t" to GhcLibWays, and this didn't die, but I'm unclear if it...did anything at all, really. I see no way to really tell one way or another. So, any help or advice on how to tell the GHC build system to build a set of libraries with ticky-ticky profiling enabled would be greatly appreciated. (FWIW, I'm not distributing anything, so it'd be more than adequate for stuff to be broken for non ticky use, I just need to build some test executables and be sure they're logging the right data.) Thanks, AHH

2 3

GHC Error: "FATAL:Symbol _XJv_srt already defined."
by Ron Alford 21 Jul '08

21 Jul '08

I posted this to Haskell-Cafe, but it's more GHC specific. Anyone know what this is about? Removing parts makes problem go away, but it's not clear what parts to remove! (that, and I wrote those parts for a reason!). bash-3.2$ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.8.3 bash-3.2$ uname -a Darwin silverback-wired.home 9.4.0 Darwin Kernel Version 9.4.0: Mon Jun 9 19:30:53 PDT 2008; root:xnu-1228.5.20~1/RELEASE_I386 i386 $ rm -f DerivingError.o DerivingError.hi; ghc --make DerivingError.hs [1 of 1] Compiling DerivingError ( DerivingError.hs, DerivingError.o ) /var/folders/C0/C0SledGV2RaxbU+8ZLDnVU+++TI/-Tmp-//ghc27223_0/ghc27223_0.s:6080:0: FATAL:Symbol _XxG_srt already defined. -Ron Alford

1 0

problem submitting ghc bug in trac
by Conal Elliott 17 Jul '08

17 Jul '08

I logged onto the ghc trac, am trying to submit a ghc bug report, and I get "TICKET_CREATE privileges are required to perform this operation". How do I get TICKET_CREATE privileges? I do see "logged in as conal". - Conal

1 0

Bug in type equality constraints?
by Conal Elliott 16 Jul '08

16 Jul '08

I'm converting some code from functionally dependencies to associated types, and I've run into a problem with equality constraints and subclasses. The classes: class AdditiveGroup v => VectorSpace v where type Scalar v :: * (*^) :: Scalar v -> v -> v class VectorSpace v => InnerSpace v where (<.>) :: v -> v -> Scalar v Products of vector spaces are vector spaces *if* over the same scalar field. Hence: instance ( VectorSpace u,VectorSpace v , Scalar u ~ Scalar v ) => VectorSpace (u,v) where type Scalar (u,v) = Scalar u s *^ (u,v) = (s*^u,s*^v) Similarly for inner product spaces: instance ( InnerSpace u,InnerSpace v, Scalar u ~ Scalar v , AdditiveGroup (Scalar v) ) => InnerSpace (u,v) where (u,v) <.> (u',v') = (u <.> u') ^+^ (v <.> v') But here's where ghc-6.9.20080622 balks: Data\VectorSpace.hs:106:0: Couldn't match expected type `Scalar v' against inferred type `Scalar u' When checking the super-classes of an instance declaration In the instance declaration for `InnerSpace (u, v)' Any ideas? - Conal

2 1

Re: [Haskell-cafe] Mutually recursive modules and google protocol-buffers
by Chris Kuklewicz 16 Jul '08

16 Jul '08

Thanks Roberto! Roberto Zunino wrote: > Chris Kuklewicz wrote: >> There is no way to create a "A.hs-boot" file that has all of >> (1) Allows A.hs-boot to be compiled without compiling B.hs first >> (2) Allows B.hs (with a {-# SOURCE #-} pragma) to be compiled after >> A.hs-boot >> (3) Allows A.hs to compiled after A.hs-boot with a consistent interface > > I thought the following A.hs-boot would suffice: > > module A(A) where > data A > > There's no need to provide the data constructors for type A. Does this > violate any of the goals above? > > Regards, > Zun. I tried that experiment. The failure is complicated, and triggers be a ghc bug. Hmmm... the bug for > module A(A) where > data A > deriving Show using "ghc -c -XGeneralizedNewtypeDeriving A.hs-boot" is > A.hs-boot:2:0:ghc-6.8.3: panic! (the 'impossible' happened) > (GHC version 6.8.3 for powerpc-apple-darwin): > newTyConEtadRhs main:A.A{tc r5z} > > Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Is this a known bug? But now I see that > module A(A(..)) where > import B(B) > data A = A B | End > deriving Show > does work. And avoids the bug! -- Chris

2 1

ghc.exe: panic! (the 'impossible' happened)
by Peter Hercek 12 Jul '08

12 Jul '08

Hi, I was advised to report it here ... and maybe somebody who knows ghc better can reproduce it or knows what is the problem. I uninstalled all ghc, gtk, and gtk2hs packages then installed ghc 6.8.3 and then gtk2hs 0.9.13 on Windows XP 32bit. This should not be because of some stalled files from previous ghc as it was suggested to me. And I was told there is nothing strange in gtk2hs 0.9.13 to cause this. A version of gtk2hs 0.9.12.1 I compiled myself works with ghc 6.8.3. I did not try to compile 0.9.13. Any ideas? Peter. status:0 peter@dwarf [764] /c/tools/Gtk2Hs/demos/hello % ls Makefile World.hs status:0 peter@dwarf [765] /c/tools/Gtk2Hs/demos/hello % ghcii.sh World.hs GHCi, version 6.8.3: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling Main ( World.hs, interpreted ) Ok, modules loaded: Main. *Main> main Loading package array-0.1.0.0 ... linking ... done. Loading package bytestring-0.9.0.1.1 ... linking ... done. Loading package mtl-1.1.0.1 ... linking ... done. Loading package glib-0.9.13 ... <interactive>: Unknown PEi386 section name `.reloc' (while processing: C:/tools/Gtk2Hs/HSglib.o) ghc.exe: panic! (the 'impossible' happened) (GHC version 6.8.3 for i386-unknown-mingw32): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug *Main> :quit Leaving GHCi. status:0 peter@dwarf [766] /c/tools/Gtk2Hs/demos/hello %

1 0