- Glasgow-haskell-users

RE: ghci - relocation error : libreadline
by Simon Marlow 29 Jun '05

29 Jun '05

On 29 June 2005 14:35, alexandre wrote: > Simon Marlow wrote: > >My guess is that libreadline.so.5 is depending on a later (or > earlier?) >version of libc than the one you have. > > Ok. Then i would need 2 versions of readline and 2 versions of libc > on my system... i'm afraid it's too complex for me to achieve this. > > So i will uninstall readline 5, read the bootstrapping section of the > "building from source" document and try to compile GHC myself. You might find that an earlier version of GHC will work on your system, in which case you can use that to compile up version 6.4. This is much easier than bootstrapping. Cheers, Simon

1 0

RE: ghci - relocation error : libreadline
by Simon Marlow 29 Jun '05

29 Jun '05

On 28 June 2005 16:09, alexandre wrote: > I just installed GHC 6.4 from RPM on a Linux/Mandriva 10.1. > When i try to start GHCI i get the following error message : > ************************************************************************ > GHC Interactive, version 6.4, for Haskell 98. > Loading package base-1.0 ... linking ... done. > /usr/lib/ghc-6.4/ghc-6.4: relocation error: /usr/lib/libreadline.so.5: > symbol __sprintf_chk, version GLIBC_2.3.4 not defined in file > libc.so.6 with link time reference > ************************************************************************ > Could someone help me solve this problem ? For the GHC RPM > installation, i had to install readline 5 first, so i now have two > version of readline on my system : 4.3 and 5 (... and a lot of > application depending on 4.3). Did that error message result from a plain 'ghci' command, or were there any other options? My guess is that libreadline.so.5 is depending on a later (or earlier?) version of libc than the one you have. Cheers, Simon

2 1

RE: ANNOUNCE: GHC survey results
by Simon Peyton-Jones 29 Jun '05

29 Jun '05

| That's fair. I just hope the implicit parameter implementation is | orthogonal enough that it's worth keeping around. It's only *linear* implicit parameters (always regarded as highly experimental) that we might nuke, not implicit parameters themselves. Does anyone out there actually find linear IPs useful? (not all survey results were signed) Simon

1 0

Feedback on Error messages in ghc.
by Peter A Jonsson 29 Jun '05

29 Jun '05

Hello, I read the summary of the survey and noticed you wanted feedback on where error messages could be improved. I looked up some (simple) examples of type errors and ran them through ghc. I do not make any claims to be an HCI expert, just a mere mortal with an opinion. Code: 1 module Test2 where 2 3 fib n = if (3 > n) then 1 else (fib (n - 1) + fib (n - 2)) 4 k = fib 's' Error message: Test2.hs:4: No instance for (Num Char) arising from use of `fib' at Test2.hs:4 In the definition of `k': k = fib 's' This isn't a bad error message in my humble opinion, it does pinpoint that I'm doing something wrong in line 4, and that there isn't an instance for Num Char doesn't come as a surprise. However I think it could have been more helpful by telling me that I tried to pass a Char to a function which expected an (Ord a, Num a) => a as its parameter. Code: 1 module Test4 where 2 3 k :: Int -> Int 4 k l = 2.0*l Error message: Test4.hs:4: No instance for (Fractional Int) arising from the literal `2.0' at Test4.hs:4 In the first argument of `(*)', namely `2.0' In the definition of `k': k l = 2.0 * l One reason this kind of error could happen is an inexperienced user declaring the wrong type for his function, or not knowing that 2.0 would be interpreted as a Fractional. Code: 1 module Test7 where 2 3 len' xs = head (xs) + (length xs) 4 o = len' "GH" Error message: Test7.hs:4: Couldn't match `Int' against `Char' Expected type: [Int] Inferred type: [Char] In the first argument of `len'', namely `"GH"' In the definition of `o': o = len' "GH" I ran this through Hugs version November 2002 and got this error message: ERROR "Test7.hs":4 - Type error in application *** Expression : len' "GH" *** Term : "GH" *** Type : String *** Does not match : [Int] I find the Hugs message more clear, but that might be my background. Code: 1 module Test8 where 2 3 f = head 3 Error message: Test8.hs:3: No instance for (Num [a]) arising from the literal `3' at Test8.hs:3 Possible cause: the monomorphism restriction applied to the following: f :: a (bound at Test8.hs:3) Probable fix: give these definition(s) an explicit type signature In the first argument of `head', namely `3' In the definition of `f': f = head 3 This one I find outright scary. For "wrong = div 3 8 + 1/2" it gives an error message that somewhat helps me guess the error, but the above doesn't even come close to helping me. / Peter

5 5

ANNOUNCE: GHC survey results
by Simon Marlow 29 Jun '05

29 Jun '05

We've finally digested the results of the GHC survey, and you can find our analysis here: http://www.haskell.org/ghc/survey2005-summary.html There's a lot to take in, but it's an interesting read. Enjoy! -- The GHC Team.

7 7

RE: state of GHC-6.4 on Solaris?
by Simon Marlow 29 Jun '05

29 Jun '05

[ forwarding to glasgow-haskell-useres(a)haskell.org ] On 28 June 2005 13:13, Christian Maeder wrote: > I've copied a fresh binary distribution (from June 27th) of ghc-6.4.1 > for solaris to: > > http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/ hets/solaris/ghc-6.4.1-sparc-sun-solaris2.tar.bz2 > > It was configured with: > > ./configure --disable-opengl --disable-glut --disable-openal > > and compiled using gcc_3.4.4 > > ghci (and thus template haskell) does not work! The error shows up as: > > Loading package mtl-1.0 ... > > GHCi runtime linker: fatal error: I found a duplicate definition for > symbol _module_registered I've uploaded this distribution to haskell.org, here: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.4.1-sparc-sun-solaris2 .tar.bz2 Cheers, Simon

1 0

RE: References to the Rts in unregisterised first build of ghc 6.4
by Simon Marlow 29 Jun '05

29 Jun '05

On 29 June 2005 04:47, Ian Lynagh wrote: > On Tue, Jun 28, 2005 at 12:14:08PM +0100, Simon Marlow wrote: >> On 27 June 2005 17:53, Michiel Buddingh' wrote: >> >>> Commented out: >>> >>> #if alpha_TARGET_ARCH >>> checkFEDArgs arg_tys >>> = check (integral_args <= 32) err >>> where >>> integral_args = sum [ machRepByteWidth rep >>> | (rep,hint) <- map typeMachRepRep arg_tys, >>> hint /= FloatHint ] >>> err = ptext SLIT("On Alpha, I can only handle 4 >>> non-floating-point arguments to foreign export dynamic") >>> >>> from TcForeign.lhs. typeMachRepRep was nowhere to be found (not in >>> ghc-6.4, or any earlier released version), and I wasn't able to >>> figure out what, exactly, it does. It seemed like an RTS thing, so >>> I decided to comment it out, and the build proceded. Not sure if >>> that was such a wise idea now. >> >> That looks like a sanity check that has bitrotted. You can ignore it >> until you need to get 'foreign import "wrapper"' working. > > This works (or at least compiles!) on Linux/Alpha: Committed, thanks. Simon

1 0

RE: References to the Rts in unregisterised first build of ghc 6.4
by Simon Marlow 29 Jun '05

29 Jun '05

On 27 June 2005 17:53, Michiel Buddingh' wrote: > On Mon, Jun 27, 2005 at 01:00:01PM +0100, Simon Marlow wrote: >> On 26 June 2005 18:28, Michiel Buddingh' wrote: >>> I was able to generate a set of .hc files on a linux-i386 host, but >>> (as was expected) the rtc failed to build. >> >> Where exactly did the RTS build fail? Can you post the error >> message? We do need the .hc files generated from the RTS .cmm source >> files. > > Adjustor.c:106:27: machine/pal.h: No such file or directory > Adjustor.c: In function createAdjustor': > Adjustor.c:403: error: PAL_imb' undeclared (first use in this > function) Adjustor.c:403: error: (Each undeclared identifier is > reported only once Adjustor.c:403: error: for each function it > appears in.) > > I didn't take a look at this before, but I suspect machine/pal.h > might even be specific to OSF/1. Ok, I suggest you do a 'make -k' in ghc/rts. The .cmm files should at least generate .hc files, that you can take to the target machine. > Other alterations (in reverse order) > > Edited out the -mieee gcc flag from /ghc/compiler/main/DriverFlags.hs > (gcc-i386 doesn't understand it, and even on Alpha, removing it > probably wouldn't break the build process itself) Ok, I assume you'll discover in due course whether you need this on Alpha or not. > Commented out: > > #if alpha_TARGET_ARCH > checkFEDArgs arg_tys > = check (integral_args <= 32) err > where > integral_args = sum [ machRepByteWidth rep > | (rep,hint) <- map typeMachRepRep arg_tys, > hint /= FloatHint ] > err = ptext SLIT("On Alpha, I can only handle 4 non-floating-point > arguments > to foreign export dynamic") > > from TcForeign.lhs. typeMachRepRep was nowhere to be found (not in > ghc-6.4, or any earlier released version), and I wasn't able to > figure out what, exactly, it does. It seemed like an RTS thing, so I > decided to comment it out, and the build proceded. Not sure if that > was such a wise idea now. That looks like a sanity check that has bitrotted. You can ignore it until you need to get 'foreign import "wrapper"' working. > Commented out: > > import PrimRep ( getPrimRepSize, isFloatingRep ) > > from the same file. The file isn't included with ghc > anymore, and the imported functions weren't used. More bitrot. Please send us patches when you've got the compiler bootstrapped. Cheers, SImon

2 1

Re: [Haskell] ANNOUNCE: GHC survey results
by John Meacham 28 Jun '05

28 Jun '05

On Tue, Jun 28, 2005 at 01:27:39PM +0100, Thomas Davie wrote: > On 28 Jun 2005, at 10:58, Simon Marlow wrote: > > >We've finally digested the results of the GHC survey, and you can find > >our analysis here: > > > > http://www.haskell.org/ghc/survey2005-summary.html > > > >There's a lot to take in, but it's an interesting read. Enjoy! > I feel compelled to point out that for all those people wanting a > debugger, Hat is there, it's under active development, and it isn't > going away for a while. It even sports a forward tracer as people > seem to want (hat-anim). > > http://www.haskell.org/hat Unfortunatly hat suffers from the same problem that pretty much every non-trivial preprocessor does, as soon as you start using ghc's special or experimental features that have not been added to hat yet, they stop working. Big complicated programs tend to be the ones you want to debug and also are the ones where you most likely needed to use a new extension... I am not sure what the general solution would be. perhaps hat being integrated with ghc? or better yet would be a standard interface for ghc to call a preprocessor but at some intermediate level where most of the extensions have been sugared away but most of the original source structure still exists... the nice thing about a standard interface would be that jhc and other compilers could support it too. It wouldn't even need to be a plugin based thing, but rather an executable that ghc can run and pass commands to it on stdin and read results on stdout. Being able to just work on any unmodified program the compiler supports is a huge feature. John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

6.4.1?
by John Meacham 28 Jun '05

28 Jun '05

Any word on 6.4.1? The major FFI bug in 6.4 is holding back some projects of mine. John -- John Meacham - ⑆repetae.net⑆john⑈

4 6