- Glasgow-haskell-users

type synonyms in instances...
by MR K P SCHUPKE 07 Jul '04

07 Jul '04

Is there any chance of enabling type synonyms in instance declarations. I remember a posting where is was stated that there was no technical reason for not being able to do this. Could we perhaps have a command line switch to enable this... For example, I think the following:- instance (HList e HNil) where ... is more readable as: type HSingleton e = HCons e HNil instance (HSingleton e) where ... Keean.

1 0

debian package of 6.2.1 has no ghc-pkg-$VERSION
by Johannes Waldmann 06 Jul '04

06 Jul '04

I'm not sure whose fault it is but when building HaXml-1.12, the command ghc-pkg-$VERSION is called which is not provided by the 6.2.1 debian package (from syntaxpolice.org) (of course a symlink from ghc-pkg solves this.) -- -- Johannes Waldmann, Tel/Fax: (0341) 3076 6479 / 6480 -- ------ http://www.imn.htwk-leipzig.de/~waldmann/ ---------

1 0

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