- Glasgow-haskell-users

RE: Problems with libgmp
by Simon Marlow 16 Nov '00

16 Nov '00

> I am maintaining the Haskell stuff at informatik.uni-muenchen.de. > (I took over the job from Sven Panne.) > > As a first exercise, I try to compile ghc-4.08.1 from scratch. > But I always run into trouble with the libgmp stuff. > IMHO, my problems are caused by several factors: > > 1. We use Suse Linux 7.0 (that provides libgmp-3.0.x). > 2. The ghc-4.08-1 distribution includes libgmp-2.x.x. > 3. libgmp-3.0.x uses prefixed names (__gnump...). Prefixed names > are generated only if the header file is included. > 4. The configure script does not recognize that libgmp is > installed (because it does not include the header file.) > 5. When linking, the linker cannot resolve symbols prefixed by mpz_ > (because the 2.x.x header file was used in compilation but the > linker uses the shared library provided by Suse Linux.) > 5. Even if informed about the local installation of libgmp > (by manually > changing config.cache), the 2.x.x header file will be used (again > resulting in unresolved bindings when linking). > > The same problems occur when bootstrapping from .hc files. > > What to do? Should I hack the Makefiles? Should I replace the libgmp > distribution included in the ghc distribution by some new 3.x.x > distribution? I'll try to clarify the situation, since it's a bit confusing. - GHC tries to detect GMP 2 on the host system during the configuration process. If it detects it, the build will go on to use the installed version. - If GMP 2 was *not* found, then we fall back to the copy of GMP in the source tree, which is build statically. - the RPMs have a dependency on the gmp2 packages. - GMP 3 is only source compatible with GMP 2, as you discovered. Furthermore, using the GMP 2 headers with the GMP 3 library aint gonna work. (if your system is set up like this, then it's broken, just like ours :-) - GHC versions post-4.08.X use GMP 3. So, I can't quite work out what went wrong in your case. If the build didn't detect GMP 2, then it should have just used the one in the tree. BTW, you can't use GMP 3 with ghc-4.08.1 (the native code generator at least will break). Hope this helps :) Cheers, Simon

3 2

Instant readFile
by George Russell 15 Nov '00

15 Nov '00

The readFile :: FilePath -> IO String action returns the contents of the associated file. This is almost what I want, but not quite, because readFile is lazy. Hence if the string is only partly read, the file is still open. What I want instead is a function which (a) opens the file; (b) slurps the complete contents compactly into an array; (c) closes the file; (d) makes the contents of the array available as a String. So instead I wrote the following: copyFileToString :: FilePath -> IO String copyFileToString file = do (addr,len) <- IOExts.slurpFile file CString.unpackCStringLenIO addr len However on further consideration this also seems to me to be unsatisfactory, because although I don't understand this issue very well, I don't think the (addr) address containing the complete file contents will ever get deallocated, because there's no way the GC can know that this particular Addr can be free'd. (Is that correct?) So please, how _should_ I write this function? For example, I could try and wrap the addr into a ForeignObj, but then how would I ensure that when the String gets gc'd, the ForeignObj does too? It all is a bit of a mystery to me how you are supposed to use Addr like things without space leaks. A little more explanation in the documentation would not perhaps be amiss . . .

2 1

The Parsec library distributed with GHC
by José Romildo Malaquias 15 Nov '00

15 Nov '00

Hello. The Parsec library (in package text from hslibs) distributed with GHC 4.08.1 and from CVS does not work as expected. When I try the attached program, ghc gives me error messages: ================================= test.hs:6: Couldn't match `TokenParser' against `[Char]' Expected type: TokenParser Inferred type: [Char] In the first argument of `symbol', namely `"let"' In a do statement: symbol "let" test.hs:12: Ambiguous type variable(s) `a' in the constraint `Show a' arising from use of `print' at test.hs:12 In the right-hand side of an equation for `main': print (parse pLet "" "let a = 232") Compilation had errors ================================= This same program works if I use the Parsec library downloaded from the author page <http://www.cs.uu.nl/~daan> (after correcting a small bug relative to using some names from the Char module without importing them). I hope the library gets updated in the GHC CVS repository and the next GHC release corrects this problem. Regards, Romildo -- Prof. José Romildo Malaquias <romildo(a)iceb.ufop.br> Departamento de Computação Universidade Federal de Ouro Preto Brasil

1 0

Problems with libgmp
by Michael Marte 14 Nov '00

14 Nov '00

Hello, I am maintaining the Haskell stuff at informatik.uni-muenchen.de. (I took over the job from Sven Panne.) As a first exercise, I try to compile ghc-4.08.1 from scratch. But I always run into trouble with the libgmp stuff. IMHO, my problems are caused by several factors: 1. We use Suse Linux 7.0 (that provides libgmp-3.0.x). 2. The ghc-4.08-1 distribution includes libgmp-2.x.x. 3. libgmp-3.0.x uses prefixed names (__gnump...). Prefixed names are generated only if the header file is included. 4. The configure script does not recognize that libgmp is installed (because it does not include the header file.) 5. When linking, the linker cannot resolve symbols prefixed by mpz_ (because the 2.x.x header file was used in compilation but the linker uses the shared library provided by Suse Linux.) 5. Even if informed about the local installation of libgmp (by manually changing config.cache), the 2.x.x header file will be used (again resulting in unresolved bindings when linking). The same problems occur when bootstrapping from .hc files. What to do? Should I hack the Makefiles? Should I replace the libgmp distribution included in the ghc distribution by some new 3.x.x distribution? Thank you, Michael Marte

1 0

Re: Bug in GHC's Garbage Collection? (fwd) - C Strings
by Christian Lescher 13 Nov '00

13 Nov '00

Hi Simon, > > 1) How to convert the Haskell string to a C string? - There's > > a function > > > > packCString# :: [Char] -> ByteArray# > > packCString# str = case (packString str) of { ByteArray _ _ bytes -> > > bytes } > > > > in CStrings.lhs / PrelPack.lhs, which I probably have to use. > > Yes (but use packString rather than packString#). Okay, so I have use: packString :: [Char] -> ByteArray Int btw: what's the difference between packString and packCString then? > > 2) How to pass a pointer (Addr) of the converted string back > > to the outside > > world? > > You can pass the ByteArray directly to a foreign imported function (which > *must* be declared unsafe - you can't pass ByteArrays to safe ccalls). I think, here the context got lost: I want to expose a Haskell function with a string result rather than calling a C function from Haskell. > > 3) Who is responsible for freeing the memory of the string result? I > > suppose this should be done outside. But what to do that GHC's garbage > > collection doesn't free it automatically? > > The ByteArray is freed automatically by GHC's garbage collector. If you > need something more permanent, use malloc/free and the functions from > Storable to do the marshalling. For instance, how would you define a function like revstr :: String -> String revstr s = reverse s for foreign export? (The conversion of the string argument I handled like this:) strlength :: Addr -> IO Int strlength cstr = do s <- unpackCStringIO cstr return (length s) foreign export stdcall strlength :: Addr -> IO Int Cheers, Christian P.S. I think, some information on the handling of typical string conversion problems would be an interesting topic for GHC's user's manual, too.

1 0

RE: Select.hSelect & Threads
by Simon Marlow 13 Nov '00

13 Nov '00

> Will Select.hSelect block all running Haskell threads? I > assume it does. However, > the small explanation at the bottom of the documentation > seems too convoluted to > me to convey it's meaning. How about adding "Remember that > this will *block* *all* > *your* *threads*" to it? Thanks. I've rewritten this section to be clearer. It does indeed block all Haskell threads. Cheers, Simon

1 0

RE: getting type information about local bindings
by Simon Peyton-Jones 10 Nov '00

10 Nov '00

Don't try to get the type environment out. Instead, look at the syntax tree produced by the type checker. Each binder is an Id. There's a function idType :: Id -> Type that tells you the type of each binder. Quite how you present it to the user in a good way isn't clear to me, Simon | -----Original Message----- | From: Bernard James POPE [mailto:bjpop@cs.mu.OZ.AU] | Sent: 10 November 2000 05:56 | To: glasgow-haskell-users(a)haskell.org | Cc: bjpop(a)cs.mu.OZ.AU | Subject: getting type information about local bindings | | | Hi all, | | In GHC 4.09 the flag "-ddump-types" causes the type signatures of | top-level bound identifiers to be printed. | | I would really like to make use of the type-checker in GHC, | however, I would | also like to obtain the types of locally bound identifiers | (things in let expressions and where clauses). Obviously | there is going to | be some trickery regarding type variables from enclosing scopes. | | I looked in the TcModule.lhs module and noticed that the TcResults | value returned by typecheckModule contains a value | environment that only | specifies the types of top bound identifiers. | | Further investigation of the code led me to the TcBinds.lhs module | and the tcBindsAndThen function. I can see that local type | environments | are not passed upwards during type checking/inference. | | At some point I got lost in the code. Does anyone know of a | reasonable means | for obtaining this type information? I don't mind doing some | hacking, but | I wanted to get advise from the experts as to whether I might | be wasting | my time. | | Perhaps such a thing is done somewhere when generating Core code? | | As an aside I dare say that such an extension would be useful | to other | people, particularly those writing source transformation code. | | Regards, | Bernie. | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users |

1 0

getting type information about local bindings
by Bernard James POPE 10 Nov '00

10 Nov '00

Hi all, In GHC 4.09 the flag "-ddump-types" causes the type signatures of top-level bound identifiers to be printed. I would really like to make use of the type-checker in GHC, however, I would also like to obtain the types of locally bound identifiers (things in let expressions and where clauses). Obviously there is going to be some trickery regarding type variables from enclosing scopes. I looked in the TcModule.lhs module and noticed that the TcResults value returned by typecheckModule contains a value environment that only specifies the types of top bound identifiers. Further investigation of the code led me to the TcBinds.lhs module and the tcBindsAndThen function. I can see that local type environments are not passed upwards during type checking/inference. At some point I got lost in the code. Does anyone know of a reasonable means for obtaining this type information? I don't mind doing some hacking, but I wanted to get advise from the experts as to whether I might be wasting my time. Perhaps such a thing is done somewhere when generating Core code? As an aside I dare say that such an extension would be useful to other people, particularly those writing source transformation code. Regards, Bernie.

1 0

ppr for Haskell Abstract Syntax
by Kate S. Golder 07 Nov '00

07 Nov '00

Hi - I was wondering if anyone knows if there is a pretty printer for Haskell Abstract Syntax anywhere? I've been asking around, but haven't located one yet. If you know of one that I could use, it would be really helpful! Thanks in advance, *Kate ********************** Kate S. Golder Wellesley College Class of 2002 Freeman Hall Wellesley College Wellesley, Ma 02481

2 1

New InstallShield
by Reuben Thomas 06 Nov '00

06 Nov '00

Yet another improvement to the GHC 4.08.1 InstallShield. Thanks to Christian Lescher and Sigbjorn Finne, various bugs have been fixed to do with DLL building, so both static DLLs (where all the haskell stuff is linked in) and dynamic DLLs (where the DLL you build is dependent on the GHC DLLs) work rather better. Also, thanks to Martijn Schrage for pointing out that I'd omitted the net hslib from the InstallShield. It's there now. -- http://sc3d.org/rrt/ | certain, a. insufficiently analysed

1 0