- Glasgow-haskell-users

DuplexHandle finalizer fix missing...
by Keean Schupke 13 Mar '03

13 Mar '03

(appologies if this is a repeat) Hi, I have also noticed the fix for DuplexHandle finalizers is not in this release, I believe the finalizer should be attached to the write side (which is pointed to by the read side) but its still attached to the read side as in previous versions... Once again this is a critical fix, as otherwise applications keep one half of the connection open until they quit, or crash due to lack of resources. Keean.

1 0

RE: Yet another weakly defined bug report
by Simon Marlow 13 Mar '03

13 Mar '03

> You should do the counting strictly: > > Just n -> case n+1 of n1 -> addToFM f w n1 Careful - that case expression doesn't actually force n to be evaluated. It's exactly equivalent to let n1 = n+1 in addToFM f w n1 You need to use seq to force evaluation. Cheers, Simon

3 3

HTk for ghc5.04.3
by George Russell 12 Mar '03

12 Mar '03

I have created binary bundles for HTk, our Haskell interface to Tcl/Tk, for ghc5.04.3 on Linux/x86 and Windows, and put them on the download page: http://www.informatik.uni-bremen.de/htk/download/INSTALL.BINARY.html I will add FreeBSD and Solaris bundles when I can get hold of ghc5.04.3 on those platforms.

1 0

Stricness of floor etc
by Ian Lynagh 12 Mar '03

12 Mar '03

Hi all, Looking at ghc --show-iface .../ghc/lib/ghc-5.05/imports/base/GHC/Float.hi I see floor1 :: forall b. (GHC.Real.Integral b) => Double -> b __S L properFraction2 :: forall b. (GHC.Real.Integral b) => Double -> (b, Double) __S L decodeFloat2 :: Double __S U(L)m My understanding of this is that floor and properFraction of Doubles have a lazy argument while decodeFloat has a strict constructor of lazy values. It's not clear to me why the U(L) strictness isn't inherited by properFraction and then float, nor do I understand why decodeFloat is not strict in its argument when it seems to be working exclusively with unboxed values. Unfortunately decodeDouble# in PrimopWrappers.hi doesn't seem to have a strictness description so I can't see what's going on there. So I guess what I'm asking is are these strictnesses the best that can be inferred or could GHC do better? Of course a strict floor (Double to Int and Integer) is what I'm really hoping for (without having to specify it explicitly with $! in my code). Incidentally, what are 'm's in the strictness descriptions? Thanks Ian

1 0

RE: Effect of large binaries on garbage collection
by Kevin Millikin 12 Mar '03

12 Mar '03

On Tuesday, March 11, 2003 6:49 PM, Manuel M T Chakravarty [SMTP:chak@cse.unsw.edu.au] wrote: > > What is needed is a FFI tutorial (in addition to the spec); > similar to how we have the Gentle Introduction to complement > the Report. I agree completely. I've put off temporarily writing a tutorial introduction to building Win32 DLLs, but I hope to pick that up again soon, and would be willing to contribute to a broader tutorial.

1 0

RE: 5.04.2 RPM Dependencies
by Simon Marlow 11 Mar '03

11 Mar '03

> On 2003-03-10 at 20:57GMT "Dominic Steinitz" wrote: > > Can anyone help? I downloaded the latest rpm for ghc but > got the following > > errors on installation: > > > > error: failed dependencies: > > libc.so.6(GLIBC_2.3) is needed by ghc-5.04.2-1 > > libreadline.so.4 is needed by ghc-5.04.2-1 > > > > I guess I need to update libc and libreadline. Can anyone > point me at the > > rpms to do this? > > If you go to <URL: http://fr2.rpmfind.net > and type > libc.so.6 into the search box, it says there are 233 rpms > that provide it. You can constrain the search to the > distribution you are using, which would narrow things down a > bit. Upgrading libc is not something I'd recommend. Instead, get the right RPM for your distribution: we have separate RPMs for RedHat 8.0 and 7.2 these days (using the wrong one leads to strange problems). The 8.0 RPM is rumoured to work with 7.3. I'm afraid we don't do a great job of supporting non-RedHat Linux systems at the moment, except for Debian which I believe does its own packaging of GHC. We do have a .tar.bz2 "binary distribution" which *might* work for you, but it is also reliant on you having the right libraries installed. Cheers, Simon

2 1

5.04.2 RPM Dependencies
by Dominic Steinitz 11 Mar '03

11 Mar '03

Can anyone help? I downloaded the latest rpm for ghc but got the following errors on installation: error: failed dependencies: libc.so.6(GLIBC_2.3) is needed by ghc-5.04.2-1 libreadline.so.4 is needed by ghc-5.04.2-1 I guess I need to update libc and libreadline. Can anyone point me at the rpms to do this? By the way I didn't have this problem with 5.04.1. Dominic Steinitz

2 1

Type classes problem: Could not deduce ...
by dirk.buehler＠student.uni-tuebingen.de 10 Mar '03

10 Mar '03

Hello, trying to compile the following program class ClassA a where foo :: a -> Int class ClassA a => ClassB b a where toA :: b -> a test :: (ClassB b a) => b -> Int test x = let y = toA x in let z = foo y in z I get a compilation error: TestTypeClasses.hs:12: Could not deduce (ClassB b a1) from the context (ClassB b a) Probable fix: Add (ClassB b a1) to the type signature(s) for `test' arising from use of `toA' at TestTypeClasses.hs:12 In a pattern binding: toA x Can anybody explain the problem to me or suggest workarounds? Adding (ClassB b a1) to the context does not solve the problem, it just generates an error of the same sort. Any hints are appreciated. Cheers, dirk ______________________________________________________________________________ Werden Sie kreativ! Bei WEB.DE FreeMail heisst es jetzt nicht nur schreiben, sondern auch gestalten. http://freemail.web.de/features/?mc=021142

2 1

RE: Effect of large binaries on garbage collection
by Simon Marlow 10 Mar '03

10 Mar '03

> > Thanks, looks like it's option (1) then. Could you tell me what > > Haskell type I have to use be able to pass a pointer to this binary > > to C land (genuine address, not StablePtr). I don't think > > the standard FFI allows this at all but, IIRC, the old ghc libraries > > allowed you to do this with a mutable byte array. > > Does anybody know the answer to this? please.. pretty please..:-) > > Sorry if this is a case of me failing to RTFM, but I don't > think it is. Paragraph 8.1.1 of the users guide says.. > > "The types ByteArray and MutableByteArray may be used as basic > foreign types (see FFI Addendum, Section 3.2). In C land, > they map to (char *)." This is still true for 5.04.x: the ByteArray and MutableArray libs in hslibs (package lang) provide these types, but they are deprecated and will be removed at some point. The functionality which allows ByteArray and MutableByteArrays to be passed to FFI functions has already been removed in CVS. In the current CVS GHC, undoubtedly the right thing to use is Foreign.mallocForeignPtr. Internally these are implemented as MutableByteArray#, so you get fast allocation and GC, but from the programmer's point of view it's a normal ForeignPtr. If you don't mind the not-so-great performance, you can use ForeignPtr with malloc/free in 5.04.x and convert to mallocForeignPtr when the next major release of GHC comes along. Or you can use ByteArray/MutableByteArray for the time being (note that you can only pass one of these to an "unsafe" FFI function, BTW). Cheers, Simon

1 0

RE: Effect of large binaries on garbage collection
by Simon Peyton-Jones 10 Mar '03

10 Mar '03

GHC does not copy big objects, so don't worry about the copying cost. (Instead of copying, it allocates big objects to (a contiguous series of) heap blocks, with no other objects in those blocks. Then the object can "move" simply by swizzling the heap-block descriptor.) Simon | -----Original Message----- | From: Adrian Hey [mailto:ahey@iee.org] | Sent: 04 March 2003 11:05 | To: glasgow-haskell-users(a)haskell.org | Subject: Effect of large binaries on garbage collection | | Hello, | | I'm writing a library which will require many blocks of binary data | of various sizes (some very large) to be stored in the heap. I'm a | little worried about the effect this will have on the efficiency of | garbage collection. I'm not sure how ghc gc works these days, but | I seem to remember it's a copying collector by default. If so it seems | a pity to waste time copying 10's of MBytes of binaries at each | collection. | | The options I'm considering are.. | | (1) Use Haskell heap space | Pros: Easy for me | Cons: May slow down gc | AFAICS I can't use anything like realloc | Current FFI proposals seem to prevent me from directly | accessing Haskell heap objects from C land (or have I | misunderstood?). | | (2) Use C heap space | Pros: Easy(ish) to use from C and Haskell ffi | Cons: Unless C heaps have improved a lot since I last looked | (which I doubt), it seems likely I will suffer from slow | allocation and fragmentation problems. | | (3) Write my own "sliding" heap manager and use finalisers for | garbage collection. | Pros: Can tailor it to work exactly the way I want. | Cons: More work for me, especially if I want the | result to be portable across OS's. | Might be a complete waste of time if my worries | about ghc heap management are groundless :-) | | Any advice? | | Thanks | -- | Adrian Hey | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 2