August 2004 - Glasgow-haskell-users

RE: isEmptyChan, System.Posix.Signals
by MR K P SCHUPKE 16 Aug '04

16 Aug '04

I thought NT and more recent was Posix compliant... Surely it should support posix signals? Keean.

1 0

RE: main thread GC'd on ^C
by Simon Marlow 16 Aug '04

16 Aug '04

On 13 August 2004 17:46, Hal Daume III wrote: > When I Control-C to stop a running program, I get: > > recomputeLambdaProb: internal error: main thread has been GC'd > Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, > or http://www.sourceforge.net/projects/ghc/ > > which I understand, but is a bit odd...IIRC this is new...is there any > reason it doesn't just exit gracefully, or print "Control-C caught" or > something like that? Known problem, will be fixed in 6.2.2. Thanks for the report. Cheers, Simon

1 0

RE: isEmptyChan, System.Posix.Signals
by Simon Marlow 16 Aug '04

16 Aug '04

On 14 August 2004 16:00, ariep(a)xs4all.nl wrote: > 2. System.Posix.Signals does not export anything on my windows > installation: > > Prelude System.Posix.Signals> :b System.Posix.Signals > > Prelude System.Posix.Signals> > > I wanted to include 'installHandler sigPIPE Ignore Nothing' (as > mentioned in the documentation of the Network module) in my program > to make it more portable. Perhaps 'installHandler' could be set to a > constant 'return ()' on windows? The System.Posix.Signals interface doesn't make any sense on Windows. We could duplicate the whole interface with "do nothing" functionality, but it's not clear that this is the right thing to do (the interface is quite a bit more than just installHandler). You want something like this: #if __GLASGOW_HASKELL__ < 603 #include "config.h" #else #include "ghcconfig.h" #endif #ifdef mingw32_TARGET_OS ignorePipeSignal = return () #else import System.Posix ignorePipeSignal = installHandler sigPIPE Ignore Nothing #endif Maybe it would make sense to include this in a library somewhere. Cheers, Simon

1 0

isEmptyChan, System.Posix.Signals
by ariep＠xs4all.nl 15 Aug '04

15 Aug '04

Hello, Two independent questions/remarks: 1. 'isEmptyChan x' blocks if x is empty and some other thread is waiting to read from x: Prelude Control.Concurrent> x <- newChan Prelude Control.Concurrent> forkIO $ readChan x Prelude Control.Concurrent> empty <- isEmptyChan x *** Exception: thread blocked indefinitely Is that the intended behaviour? Is it possible to make a non-blocking version? 2. System.Posix.Signals does not export anything on my windows installation: Prelude System.Posix.Signals> :b System.Posix.Signals Prelude System.Posix.Signals> I wanted to include 'installHandler sigPIPE Ignore Nothing' (as mentioned in the documentation of the Network module) in my program to make it more portable. Perhaps 'installHandler' could be set to a constant 'return ()' on windows? My GHC version is 6.2. (Please let me apologise in advance in case (some of) these issues have changed since 6.2.) Regards, Arie Peterson

2 1

RE: Network, sClose
by Simon Marlow 14 Aug '04

14 Aug '04

On 11 August 2004 14:19, Glynn Clements wrote: > Right. If listenOn and accept are in Network, sClose should be in > there too. That would at least provide an API which is usable for the > simplest programs. Sounds reasonable. I'll add it. > OTOH, the core problem with Network.recvFrom is essentially that it > appears to be a misguided attempt to provide a symmetric counterpart > to Network.sendTo. While the low-level sendTo/recvFrom functions may > be roughly symmetric, at a higher level, the client and server ends of > a connection aren't at all symmetric. Yes, I'm sure that's the reason for it. Proposals for a replacement are welcome... Cheers, Simon

3 2

GHC CVS build...
by MR K P SCHUPKE 13 Aug '04

13 Aug '04

just checked out the CVS ghc to play with instance resolution - however: fptools/mk/config.h.in seems to be missing and nothing can be built. Keean.

2 1

main thread GC'd on ^C
by Hal Daume III 13 Aug '04

13 Aug '04

When I Control-C to stop a running program, I get: recomputeLambdaProb: internal error: main thread has been GC'd Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ which I understand, but is a bit odd...IIRC this is new...is there any reason it doesn't just exit gracefully, or print "Control-C caught" or something like that? (9:38am strontium:ACE/ ghc --version The Glorious Glasgow Haskell Compilation System, version 6.2.1) - Hal -- Hal Daume III | hdaume(a)isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

1 0

RE: GHCI/FFI/GMP/Me madness
by Simon Marlow 13 Aug '04

13 Aug '04

On 13 August 2004 14:04, Remi Turk wrote: >> How do you arrange to free a GMP integer when it is no longer >> referenced from the heap? You'd need finalizers, and that way lies >> madness. The memory allocation tricks we play with GMP are all to >> support GC of Integers. > > Errr, I guess I'll have to start looking for a straitjacket then ;) > Finalisers where exactly what I was thinking about, and though > below implementation without doubt contains a bunch of bugs, > perhaps even show-stoppers, the following code _does_ print True: > > import Mpz > > main= print $ show (z::Integer) == show (z::Mpz) > where > -- some random calculations > x, y, z :: Blub a => a > x = 2^64 - sum (take 100 $ iterate (63*) 3) > y = 3^200 * 234233432 - (34 `pow` 38) + sum [1,87..20000] > z = fac 5000 * (x + y) `div` (2^100) > > Or are finalisers simply going to be too slow to take seriously > for this? You can't use mallocForeignPtr (because GMP needs to allocate its own memory), so you have to use full-blown ForeignPtrs with malloc/free and finalizers. Yes, these are very slow compared to using GC'd memory. Cheers, Simon

1 0

RE: GHCI/FFI/GMP/Me madness
by Simon Marlow 13 Aug '04

13 Aug '04

On 11 August 2004 20:45, Remi Turk wrote: > But as long as GMP doesn't mind about being abused the way my > most recent util.c does, I can get away with the > mp_set_memory_functions-trick, can't I? Not really. You can't let GMP realloc() a memory block that was allocated using one method, with a different method. Also, GMP must not try to free() a block that was allocated using a different method. > ("*Be sure to call `mp_set_memory_functions' only when there are no > active GMP objects allocated using the previous memory functions! > Usually that means calling it before any other GMP function.*", > and using undocumented features) > > And with this trick and a ffi GMP-binding implement a working Mpz > datatype. > > And when (if?) this is done, drop in a "type Mpz = Integer", rip > out all Integer-primops, remove the mp_set_memory_functions-trick > and start benchmarking? > (Conveniently forgetting that "fromInteger :: Integer -> Integer" > most certainly has to stay a primop anyway...) How do you arrange to free a GMP integer when it is no longer referenced from the heap? You'd need finalizers, and that way lies madness. The memory allocation tricks we play with GMP are all to support GC of Integers. > Or is the rts using Integers in such a way that any (standard > malloc) allocations are forbidden while e.g. "(*) :: Integer -> > Integer -> Integer" is running? Not sure what you mean here - malloc() can always be used. Cheers, Simon

2 1

RE: Closed Classes...
by MR K P SCHUPKE 13 Aug '04

13 Aug '04

If I wanted to experiment with instance selection, which part of GHC do I want to be looking at? Keean

1 0