June 2004 - Glasgow-haskell-users

RE: Dynamic loading problem
by Simon Marlow 18 Feb '05

18 Feb '05

On 30 April 2004 11:26, Duncan Coutts wrote: > Could someone remind me what the remaining issues are in getting ghc > to build Haskell modules/packaged into unix .so shared libraries? > > As I recall it seems to nearly work. Andre Pang got them to load and > function but it was a bit fragile and the rts would complain after a > short while: > http://www.mail-archive.com/glasgow-haskell-users@haskell.org/msg03923.h tml It might be possible to do this, but only if you want to do dlopen()-style linking at runtime. Linking a haskell binary against Haskell .so libraries still isn't possible - I had another look at this recently, and although one of the obstacles has been removed, there are others (details available on request). Any remaining issues to do with dlopen()ing a Haskell .so library are probably to do with CAFs. The dynamically loaded code needs to call newDynCAF() instead of newCAF() in a CAF's entry code - this is normally arranged by the RTS linker, but for a .so you'll have to do it some other way, like getting the compiler to emit the different call, or doing some CPP magic (but only for -fvia-C). Any reasonable patches to implement this will be incorporated. Oh, and strictly speaking we should run the __stginit_Foo() function from each dynamically loaded module. But the RTS linker still doesn't do this. Cheers, Simon

4 3

How do I specify the source search path?
by S. Alexander Jacobson 30 Jun '04

30 Jun '04

I have the working code for my Haskell App Server Framework in "~/HAppS/HAppS.hs". If I want to start working on an app that uses this framework in e.g. "~/MyApp", how do I tell GHCi to resolve "import HAppS"? Note: The HAppS code is in active development so I don't want to put it in the system GHC lib hierarchy. I just want to use it add hoc from the command line. -Alex- _________________________________________________________________ S. Alexander Jacobson mailto:me@alexjacobson.com tel:917-770-6565 http://alexjacobson.com

4 3

Haskell module for SWIG
by Gour 30 Jun '04

30 Jun '04

Hi! I'd like to make Haskell bindings for some C library and I'm wondering if someone was/is thinking about writing Haskell support for SWIG or the present Haskell tools provide better route for such a task(s)? Sincerely, Gour -- Gour | gour(a)mail.inet.hr Registered Linux User | #278493 GPG Public Key | 8C44EDCD

4 5

RE: Socket Options
by Simon Marlow 29 Jun '04

29 Jun '04

On 26 June 2004 02:48, Glynn Clements wrote: > You can't set the send/receive timeouts using that function; it always > passes a C int (with the optlen parameter set to sizeof(int)). You > would have to re-write it with a more flexible interface, e.g.: > >> import Foreign >> import Foreign.C >> import Network.Socket hiding (setSocketOption) >> >> foreign import CALLCONV unsafe "setsockopt" >> c_setsockopt :: CInt -> CInt -> CInt -> Ptr () -> CInt -> IO CInt >> >> setSocketOption :: (Storable a) => Socket >> -> SocketOption -- Option Name >> -> a -- Option Value >> -> IO () >> setSocketOption (MkSocket s _ _ _ _) so v = do >> with v $ \ptr_v -> do >> throwErrnoIfMinus1_ "setSocketOption" $ >> c_setsockopt s (socketOptLevel so) (packSocketOption so) >> (castPtr ptr_v) (fromIntegral (sizeOf v)) return () I'm tempted to replace the current setSocketOption with this version. Would anyone object? Or perhaps we should include the new version under a different name? Cheers, Simon

5 5

RE: Socket Options
by Simon Marlow 28 Jun '04

28 Jun '04

On 28 June 2004 13:17, Peter Simons wrote: > Simon Marlow writes: > > > The runtime uses non-blocking I/O and select() internally > > in order to support multi-threaded I/O. We don't have any > > direct support for timeouts [...] > > Thanks for the clarification. I understand that. > > But what would happen if I _do_ set a timeout on the socket > level nonetheless? The timeout would strike in form of a > read() or write() call returning -1 with an errno of > ETIMEDOUT, so clearly it would be noticed by the RTS. The > question is: will the RTS report the failure to me through > an asynchronous exception? > > Because if it does, then that is all the "support" I'll ever > need, it saves me from 'forkIO'ing a racer thread for every > operation that might time out. The POSIX spec says that if I/O on a socket times out, then the operation will return EAGAIN or EWOULDBLOCK (there's no ETIMEOUT). It doesn't say what happens to select() on a socket that times out, so I'm not sure what will happen if you try this in GHC. The Linux socket(7) man page seems to say that you can't set SO_RCVTIMEO or SO_SNDTIMEO on Linux (but perhaps you can with a 2.6 kernel?). Cheers, Simon

3 2

Re: Socket Options
by MR K P SCHUPKE 28 Jun '04

28 Jun '04

If you fork a thread to handle each connection the async exception is thrown to the (Haskell) thread which is performing IO on the socket when it happens. (the ignore means ignore the signal the default action is to terminate the program) Keean.

1 0

Re: Socket Options
by MR K P SCHUPKE 28 Jun '04

28 Jun '04

>What would happen if a timeout occurs in the _socket_ level? I believe a (unix) socket level problem (including remote server closing the connection unexpectedly) results in a Posix SigPIPE. Is you set the default action to ignore: installHandler sigPIPE Ignore Nothing Then it gets converted to an asynchronous exception... that means you have to be extremely careful with your 'catch' clauses so as to ensure that system resources allocated to the socket get cleaned up. Keean.

2 1

RE: Socket Options
by Simon Marlow 28 Jun '04

28 Jun '04

On 28 June 2004 13:06, Peter Simons wrote: > Glynn Clements writes: > > >> Am I even supposed to set them, or is there a better way to > >> specify general I/O timeouts than on the socket level? > > > Non-blocking I/O and select/poll; although I don't know > > how well that is supported. > > Can anyone tell me how well supported it is? What would > happen if a timeout occurs in the _socket_ level? Will an > exception be thrown? Can I count on this behavior even when > reading from a socket (read: a Handle promoted from a > Socket) with hGetContents? The runtime uses non-blocking I/O and select() internally in order to support multi-threaded I/O. We don't have any direct support for timeouts, but the usual way to do this is to fork another thread to sleep and send an exception to the original thread. Code for a timeout combinator has been posted to this list before (try Google). Cheers, Simon

2 1

RE: SPECIALIZE pragma
by Simon Peyton-Jones 28 Jun '04

28 Jun '04

There's no reason in principle. I looked into why it's not happening in practice, and there is a reason, although it's not a good one. Briefly, the way specialisation works is this: * We find all calls to 'f' in this module * We float them up to the definition of f, along with their instantiating types and dictionaries (these are called the "call instances") * We instantiate the body of 'f' with these types and dictionaries, and record the results as a RULE All this is done by a core-to-core pass called 'specialise'. All the type checker does with a SPECIALISE pragma is to create a pseudo definition foo = (f Int dInt) or whatever, where foo is unused, containing a call instance that the specialise pass will find. Problem: what if the dictionary passed at a call mentions a type variable (as in this case) GHC non-solution: discard such call instances => no specialisation. Possible alternative: abstract over such type variables. But tricky in full generality A better solution is probably for the type checker itself to create the specialised copy. Then it could do more, and deal with partial specialisation. It's also much more direct -- no danger of a requested specialisation being silently dropped as now. This would take a little work (a few hrs I guess). I'm inclined to tackle it, but only after the POPL deadline Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ross Paterson | Sent: 28 June 2004 12:28 | To: glasgow-haskell-users(a)haskell.org | Subject: Re: SPECIALIZE pragma | | On Thu, Jun 17, 2004 at 10:53:28AM +0100, I wrote: | > Digging around in the source code comments, I found a restriction that | > is biting me: | > | > > We *insist* that all overloaded type variables are specialised to ground | > > types, (and hence there can be no context inside a SPECIALIZE pragma). | > | > The latter is fine, but the former seems too restrictive. For example, | > a function with constraints (Storable a, Eq a) can't be specialized to | > Ptr b, even though b would be unconstrained. Any hope of relaxing this? | | After a bit of experimentation: if we have | | f :: (Storable a, Eq a) => T a | {-# SPECIALIZE f :: T (Ptr a) #-} | | not only do we not get the requested polymorphic specialization, but | if we use f at the ground types T (Ptr Foo) and T (Ptr Bar), we get a | specialization for each, and these are essentially the same. Is there | any reason not to generate the polymorphic one? | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

1 0

Socket Options
by Peter Simons 28 Jun '04

28 Jun '04

Hi, the Network module provides the data type SocketOption. I am particularly interested in setting the RecvTimeOut and SendTimeOut values, but I wonder how to set them. The function setSocketOption :: Socket -> SocketOption -> Int -> IO () allows me only 'Int' parameters, but the kernel expects a struct timeval here -- or more accurately, a pointer to one. Do I really have to engage in FFI pointer wizardry here, or is there a simpler way to set these values? Am I even supposed to set them, or is there a better way to specify general I/O timeouts than on the socket level? Peter

2 2