October 2001 - Glasgow-haskell-users

RE: Socket library
by Simon Marlow 25 Oct '01

25 Oct '01

> I just wanted to play a bit with the Socket library comming > with Haskell. However, whatever I try to do, I get the following > runtime error, eg in ghci: > > Socket> connectTo "pcsep" (PortNumber 80) > *** Exception: does not exist > Action: getProtocolByName > Reason: no such protocol entry > > > Seems that I am doing something wrong here? Which platform are you on? (there is a bug in 5.02's networking library which means that Socket.conncetTo might not work - but I haven't seen it produce the error that you quote above). Simon

3 2

gtk+hs and libgmp
by Gérard Milmeister 25 Oct '01

25 Oct '01

When trying to compile the examples in gtk+hs, I get the following link errors: /opt/ghc/lib/ghc-5.02/libHSstd.a(PrelFloat__413.o): In function `shP2_2_alt': PrelFloat__413.o(.text+0x2b0): undefined reference to `__gmpz_cmp_si' etc.. When linking simple programs, this doesn't occur. I have the following gmp's installing: /usr/lib/libgmp.so.2.0.2 /usr/local/lib/libgmp.so.3.1.1 /opt/ghc/lib/ghc-5.02/libgmp.a It seems that the programs only link with the version in /usr/local/lib. I tried putting this path in 'library_dirs' for package 'gmp' in 'package.conf', but to no avail. Only when I explicitly put '/usr/local/lib/libgmp.so' in 'extra_ld_opts' for package 'gmp' did it work. -- Gérard Milmeister Tannenrauchstr. 35 8038 Zürich gemi(a)bluewin.ch

1 0

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

24 Oct '01

At 2001-10-24 02:52, Simon Marlow wrote: >If you're talking about OS threads (eg. POSIX threads), Yes >then GHC's RTS certainly isn't thread safe. Good. This means I know why it's crashing... >It isn't safe to call foreign exported >functions from more that one OS thread simultaneously. OK, can I call a foreign exported function from some other thread while the main thread is in 'foreign import' native code? I could have calls to the foreign exported function block until the main thread called a special foreign imported 'yield' function. The alternative is to have all Haskell in one thread, which means other threads would have to queue up calls to foreign exported functions, which would get executed by the main thread whenever it called 'yield'. -- Ashley Yakeley, Seattle WA

1 0

Re: 5.02 MonadError Broke My Code
by Marcin 'Qrczak' Kowalczyk 24 Oct '01

24 Oct '01

Sun, 21 Oct 2001 19:38:55 -0700, Ashley Yakeley <ashley(a)semantic.org> pisze: > 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? It allows some practical functions which would be awkward to write without the fundep. For example: data ParseError = ... class HasParseError e where inject :: ParseError -> e parseInteger :: (MonadError m e, HasParseError e) => m Integer -- This type is ambiguous without the fundep because the main part of -- the type doesn't mention e. You could argue that we should write this instead: parseString :: MonadError m ParseError => String -> m () but this style isn't always feasible. It would force to have a concrete error type in all places where the error type is not directly visible in the type of the whole function. I don't want to commit to a particular error type in generic parsing library for example - the library only specifies properties of the error type using classes and gives several choices for it; details of the error type are specific to places where the library is used. Also a constraint like 'MonadError m ParseError' which mentions a concrete type can't be put in an instance context without -fallow-undecidable-instances. I have an example where putting this in an instance context is useful: there is a large set of constraints (six) which is used in many functions, so they are packed in a subclass with no methods which serves as a "class synonym". > Anyway, because of GHC's naive instance overlapping checking, it broke my > code: > > instance (JVMMonad m) => MonadError ThrowableRef m where Sorry about that. A single MonadError class can't simultaneously allow both ways of associating error types with monads. I guess you can move 'MonadError ThrowableRef m' to superclasses of JVMMonad and make MonadError instances for all types in this class separately. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0

Socket library
by Sven Eric Panitz 24 Oct '01

24 Oct '01

I just wanted to play a bit with the Socket library comming with Haskell. However, whatever I try to do, I get the following runtime error, eg in ghci: Socket> connectTo "pcsep" (PortNumber 80) *** Exception: does not exist Action: getProtocolByName Reason: no such protocol entry Seems that I am doing something wrong here? Sven Eric

1 0

RE: Thread-Safety through FFI
by Simon Marlow 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. If you're talking about OS threads (eg. POSIX threads), then GHC's RTS certainly isn't thread safe. It isn't safe to call foreign exported functions from more that one OS thread simultaneously. We have some partially working thread support, but it has been on the back burner for some time now. Cheers, Simon

1 0

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