RE: Problems with libgmp
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. Obviously, when linking, it did not use the one in the tree :-( Conclusion: The Linux linker does not behave like other linkers or there is a bug in some Makefile. Of late I have had problems with libgmp2 and woody-debian. I solved the problem the first time around by adding a sym link /usr/lib/libgmp2.so - /usr/lib/libgmp.so.2.0.2 Yesterday I solved the problem by installing libgmp2-dev because ld was looking for libgmp.a for some reason when trying to compile hdirect. Hacks at best. Haven't really looked for whys and wherefores. The binary distributions of 4.08.2 will come with a statically linked libgmp.a. It's up to the package maintainers (RedHat RPM, Debian etc.) to decide the best approach for those systems, i.e. whether it's better to depend on the system-supplied shared libgmp or supply one in the GHC package. On FreeBSD for example I just use the system-supplied one since it's part of the base system. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Instant readFile
George Russell writes: 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? Well, you could always free the address directly after unpacking it, since unpackCStringLenIO generates the whole string in one go. 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 . . . The alternative is to use a ByteArray to store the string. These live in the heap and so get garbage collected automatically, and should be quicker to allocate than using malloc. Check out the hGetBuf family of functions in IOExts, there are versions for reading into/out of ByteArrays, and there are variants of unpackCString that work with ByteArrays (unpackNBytesBA, for example). [ side note: ByteArrays and MutableByteArrays will eventually be replaced by UArray and STUArray/IOUArray which are functionally identical but have a nice overloaded interface in IArray/MArray. ] Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: Instant readFile
Wed, 15 Nov 2000 18:42:29 +0100, George Russell [EMAIL PROTECTED] pisze: 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. Applying foldr (\_ t - t) (return ()) to the string (and executing this application as an IO action) will force it to be read completely. If it came from readFile, the file gets closed as soon as the string is evaluated up to its end. 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 . . . Unfortunately the design of these areas (conversion between Haskell strings and C strings) is not yet complete. And Unicode in Haskell strings (already implemented in GHC development versions) will make the library more complex. -- __(" Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users