- Glasgow-haskell-users

Uninstall warning...
by Andre W B Furtado 24 Oct '01

24 Oct '01

I had GHC-4.08.1 installed in my computer (which runs under a Windows98 platform), and then I decided to install GHC-5.00.2 (this was its latest version at that time). It is said that GHC-5.00.2 can co-exist with other versions of GHC under a Windows platform, because it does not use cygwin anymore. At this point, everything was ok. But when I uninstalled GHC-5.00.2 (in order to install GHC-5.02), a lot of DLL files were removed from the "bin" directory of GHC-4.08.1 (ex.: HSlang.dll). I don't have any idea why this happened, but a lot of my programs that were compiled with GHC-4.08.1 became impossible to run. I had to recover the DLLs from a backup... Is this a uninstall bug? (ps: installing GHC-5.02 didn't bring my old DLLs back). -- Andre

2 1

Thread-Safety through FFI
by Ashley Yakeley 24 Oct '01

24 Oct '01

Is there a way of calling exported 'dynamic export' functions in a thread-safe manner? I have this problem in JVM-Bridge... This is what the main thread does, from Haskell: 1. starts the Java VM, which starts a bunch of other threads, including the AWT thread; 2. creates a pointer to a some IO function 'paint', using a 'dynamic export' callback-maker; 3. creates a new Java Frame (i.e. a GUI window) with the function-pointer; 4. repeatedly calls the Java Thread.yield function for 20 seconds. (the program then ends) Now, once the Java Frame has been created, the AWT thread will occasionally call the 'paint' method, which ends up calling the function-pointer. However, it seems GHC 5.02 'dynamic export' calls are not thread-safe, and sooner or later it crashes, either with a seg violation or a complaint about unknown closure types. -- Ashley Yakeley, Seattle WA

1 0

Unistall warning... again!
by Andre W B Furtado 24 Oct '01

24 Oct '01

Now things really got worse... when I try to use GHC-4.08.1, I got the following message: ghc: permission denied ghc: not found make[1]: *** [depend] Error 127 How can I use the old GHC-4.08.1 back again? I have some APIs that still need it... Thanks, -- Andre

1 0

RE: Working character by character in Haskell
by Simon Marlow 23 Oct '01

23 Oct '01

> "Simon Marlow" <simonmar(a)microsoft.com> writes: > > To really match the C program, you need to use IOExts.hGetBuf and > > IOExts.hPutBuf, and do the operations on raw characters in memory. > > Using a UArray of Word8 would be better, but there aren't any > > operations to do IO to/from a UArray yet (actually I've written > > these, but they aren't in the tree yet). > > So why don't getContents / putStr / etc. deforest cleanly to calls to > hGetBuf and hPutBuf? I'm genuinely curious; my own experience in this > direction is "The engineering is challenging". These functions are so > commonly used, though---and they're vastly easier to use, actually > portable, etc. The effort would surely be repaid. I think you're right, in that the engineering would be challenging. You could conceivably factor getContents into two functions getBlocks :: IO [Block] and a pure function to unpack the blocks into characters, which would lend itself to deforestation, but that would conflict with our attempts to re-use buffers when possible. But the gains might outweigh the slight performance loss from not re-using buffers as much - it's an interesting idea, anyway. Cheers, Simon

1 0

[nhc-bugs] confhc does not recognize ghc 5.*
by Malcolm Wallace 23 Oct '01

23 Oct '01

Mieszko Lis <elf(a)sandburst.com> writes: > i ran into a compiler-detection bug in building nhc98 (the 1.10 tarball, > but the same bug seems to be in cvs and earlier versions): the build > process fails to detect the default ghc 5.02 installation on my debian > linux machine as well as the ghc 5.00.2 installation on a redhat 7.1 box > nearby. > > the problem turns out to be that script/confhc looks through the ghc > executable for the wrong stuff (at least in the installations i > mentioned above). i attached a patch (against the cvs tree) to fix > this at least on these debian and redhat installations. Here is the essential part of the patch: - GHCDIR=`grep '^libdir' ${whichGHC} | head -1 | sed 's/^libdir=.$.*$./\1/'` + GHCDIR=`grep '^TOPDIROPT' ${whichGHC} | head -1 | sed 's/^TOPDIROPT="*-B$[^";]*$.*/\1/'` However, this does not work on my (Slackware Linux) machine. In the driver script for ghc-5.02, I see the following two lines: libdir='/usr/malcolm/local/lib/ghc-5.02' TOPDIROPT="-B$libdir"; which means that the original confhc gives the correct path (/usr/malcolm/local/lib/ghc-5.02), but the patched confhc gives an incorrect path symbol ($libdir). Can someone at ghc central confirm whether this part of the ghc-5.02 driver script differs, depending on package and platform? And if so, what is the best way to detect which variation applies? Regards, Malcolm

2 1

RE: Blocking IO in module Socket
by Simon Marlow 22 Oct '01

22 Oct '01

> Why doesn't Socket.accept call threadWaitRead before entering the > C-call (which will block the entire RTS when used in conjunction > with Concurrent)? Is there any design decision involved? The call doesn't block, because the socket is set to non-blocking mode. Or have you perhaps observed different behaviour? It works here. Cheers, Simon

2 1

Blocking IO in module Socket
by Volker Stolz 22 Oct '01

22 Oct '01

Why doesn't Socket.accept call threadWaitRead before entering the C-call (which will block the entire RTS when used in conjunction with Concurrent)? Is there any design decision involved? -- Volker Stolz * vs(a)foldr.org * PGP + S/MIME

1 0

5.02 MonadError Broke My Code
by Ashley Yakeley 22 Oct '01

22 Oct '01

MonadError seems to have been redefined in 5.02 to have a fundep: 5.00.2: class (Monad m) => MonadError e m 5.02: class (Monad m) => MonadError e m | m -> e Why? Perhaps the IO Monad can have only one kind or level of error, but why can't other Monads have more? Anyway, because of GHC's naive instance overlapping checking, it broke my code: instance (JVMMonad m) => MonadError ThrowableRef m where { throwError = jvmThrow; catchError = jvmCatch; }; because GHC thinks it might overlap with the Prelude's instance MonadError Exception IO -- Ashley Yakeley, Seattle WA

1 0

Strict functions
by Ian Lynagh 21 Oct '01

21 Oct '01

Hi all I've been reading the GHC docs and they say that strict functions are good for space and time. Section 6.2 goes on to explain how to read the .hi files to determine the strictness of a function. However, it doesn't explain all the cases I am seeing. Example of the ones I've noticed are: V S(L)V AAAb m C(V)L What do these mean? And more importantly, how good are they? Also, the prelude definition of zipWith has LVL whereas the following definition has LVV. Why is something like the following not used? > zipWith :: (a->b->c) -> [a] -> [b] -> [c] > zipWith f (a:as) (b:bs) = f a b : zipWith f as bs > zipWith _ _ [] = [] > zipWith _ _ _ = [] Thanks Ian

3 3

Re: Multi-parameter OOP
by Ashley Yakeley 19 Oct '01

19 Oct '01

At 2001-10-19 08:02, George Russell wrote: >a naive user (like me a month ago) might expect that this to work, so that >toBool (WrappedA a) (WrappedB b) will return False unless a is an A1, and >b a B1, in which case it returns True. I think existential types are arranged so that Haskell never needs to store type information in them at run-time. So you'll never be able to do dynamic OOP with them. One possible extension to Haskell for dynamic OOP, which I never tire of suggesting, is the extensible datatype, for instance: module P data BaseType = B1 | B2 | _ module Q data DerivedType = D1 | D2 data BaseType |= BD DerivedType -- Ashley Yakeley, Seattle WA

1 0