- Libraries - Haskell.org

[PATCH] [rfc] Network.Socket: Add recvBuf
by Simon Horman 09 Jan '11

09 Jan '11

recently I have been looking into a latency-gap between the C and Haskell implementations of a TCP-echo One issue that has come up is that recvBufFrom calls getpeername() for each successful recvfrom(). This is unnecessary in the context of the code that I am working with as the result is discarded. My proposed solution to this is to implement recvBuf. I apologise in advance for my rudimentary Haskell skills. --- Network/Socket.hsc | 57 ++++++++++++++++++++++++++++++++++----------------- 1 files changed, 38 insertions(+), 19 deletions(-) diff --git a/Network/Socket.hsc b/Network/Socket.hsc index 21d83ac..13a94c2 100644 --- a/Network/Socket.hsc +++ b/Network/Socket.hsc @@ -81,6 +81,7 @@ module Network.Socket -- ** Sending and receiving -- $sendrecv , recv + , recvBuf , recvBufFrom , recvFrom , recvLen @@ -662,16 +663,10 @@ recvFrom sock nbytes = str <- peekCStringLen (ptr, len) return (str, len, sockaddr) --- | Receive data from the socket, writing it into buffer instead of --- creating a new string. The socket need not be in a connected --- state. Returns @(nbytes, address)@ where @nbytes@ is the number of --- bytes received and @address@ is a 'SockAddr' representing the --- address of the sending socket. --- -- NOTE: blocking on Windows unless you compile with -threaded (see -- GHC ticket #1129) -recvBufFrom :: Socket -> Ptr a -> Int -> IO (Int, SockAddr) -recvBufFrom sock@(MkSocket s family _stype _protocol _status) ptr nbytes +recvBufFrom' :: Socket -> Ptr a -> Int -> IO (Int, Ptr SockAddr) +recvBufFrom' sock@(MkSocket s family _stype _protocol _status) ptr nbytes | nbytes <= 0 = ioError (mkInvalidRecvArgError "Network.Socket.recvFrom") | otherwise = withNewSockAddr family $ \ptr_addr sz -> do @@ -687,17 +682,41 @@ recvBufFrom sock@(MkSocket s family _stype _protocol _status) ptr nbytes let len' = fromIntegral len if len' == 0 then ioError (mkEOFError "Network.Socket.recvFrom") - else do - flg <- sIsConnected sock - -- For at least one implementation (WinSock 2), recvfrom() ignores - -- filling in the sockaddr for connected TCP sockets. Cope with - -- this by using getPeerName instead. - sockaddr <- - if flg then - getPeerName sock - else - peekSockAddr ptr_addr - return (len', sockaddr) + else return (len', ptr_addr) + +-- | Receive data from the socket, writing it into buffer instead of +-- creating a new string. The socket need not be in a connected +-- state. Returns @(nbytes, address)@ where @nbytes@ is the number of +-- bytes received and @address@ is a 'SockAddr' representing the +-- address of the sending socket. +-- +-- NOTE: blocking on Windows unless you compile with -threaded (see +-- GHC ticket #1129) +recvBufFrom :: Socket -> Ptr a -> Int -> IO (Int, SockAddr) +recvBufFrom sock ptr nbytes = do + (len, ptr_addr) <- recvBufFrom' sock ptr nbytes + flg <- sIsConnected sock + -- For at least one implementation (WinSock 2), recvfrom() ignores + -- filling in the sockaddr for connected TCP sockets. Cope with + -- this by using getPeerName instead. + sockaddr <- + if flg then + getPeerName sock + else + peekSockAddr ptr_addr + return (len, sockaddr) + +-- | Receive data from the socket, writing it into buffer instead of +-- creating a new string. The socket need not be in a connected +-- state. Returns @(nbytes)@ where @nbytes@ is the number of +-- bytes received. +-- +-- NOTE: blocking on Windows unless you compile with -threaded (see +-- GHC ticket #1129) +recvBuf :: Socket -> Ptr a -> Int -> IO Int +recvBuf sock ptr nbytes = do + (len, ptr_addr) <- recvBufFrom' sock ptr nbytes + return len ----------------------------------------------------------------------------- -- send & recv -- 1.7.2.3

2 2

Data.Monoid.First and Data.Monoid.Last
by Louis Wasserman 09 Jan '11

09 Jan '11

Is there a reason that Data.Monoid.First and Data.Monoid.Last aren't also instances of Functor, Applicative, Alternative, Monad, MonadPlus? I find those instances quite useful. Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

2 1

Proposal: Add Control.Exception.allowInterrupt
by Simon Marlow 08 Jan '11

08 Jan '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/4857 This proposal is to add the following function to Control.Exception: -- | When invoked inside 'mask', this function allows a blocked -- asynchronous exception to be raised, if one exists. It is -- equivalent to performing an interruptible operation (see -- #interruptible#), but does not involve any actual blocking. -- -- When called outside 'mask', or inside 'uninterruptibleMask', this -- function has no effect. allowInterrupt :: IO () allowInterrupt = unsafeUnmask $ return () The above is almost the entire implementation modulo imports, so I didn't bother attaching a patch to the ticket. unsafeUnmask is not exported by Control.Exception, it is an internal function from GHC.IO. Some discussion leading up to this can be found in http://hackage.haskell.org/trac/ghc/ticket/3837. Discussion period: 3 weeks (until 12 Jan 2011) Cheers, Simon

3 4

Re: Proposal: Change to library proposal process
by Howard B. Golden 08 Jan '11

08 Jan '11

On 06 Jan 2011 11:32:45 +0000, Simon Marlow <marlowsd(a)gmail.com> wrote: > The changes being proposed by Greg and Johan, as I understand it, would > amount to the following. I'm willing to give it a try; we can always go > back if it doesn't work out. > > - maintainers are empowered to make API changes. > > - no formal review process for API changes, although there is an > expectation that non-trivial changes would still be discussed on > the list beforehand. >From my experience upgrading Gentoo's Haskell distribution, I would like to suggest a bit more structure than this. API changes can wreak havoc with many packages. Therefore, I believe that we should _strongly_encourage_ upward compatibility in API changes. This doesn't require that APIs remain static, nor need it cause a lot of difficulty for maintainers, if we _encourage_ smooth migration to the new API. One possible approach would be to add conditional compilation directives so the new and old APIs can co-exist initially. This would provide an easy workaround for packages that depend on the old API. There may be better methods than this, but this is always an option. Alternatively, we should try to develop adapter libraries (e.g., old-time and old-locale) so old code can still be compiled with minimal modification. There are still many packages that depend on base-3 and the switch to ghc-7.0 and base-4.3 breaks them. From the perspective of an enterprise developer the current situation is a show-stopper. In order to gain more enterprise penetration we need to make upgrades less painful. Cheers, Howard

3 3

Help understanding a dependency conflict
by tsuraan 07 Jan '11

07 Jan '11

I have a program that's using both json (0.4.4) and hslogger (1.1.0). During the "cabal configure" stage of compiling my program, I get this error message: Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package json-0.4.4 requires mtl-1.1.0.2 package hslogger-1.1.0 requires mtl-2.0.1.0 Looking at the .cabal files for json and hslogger, they both have dependencies on "mtl", but neither package gives a version for it. I only have mtl 2.0.1.0 installed, so installing json didn't bring in an old version of the library when it was installed. My program compiles and runs without any errors. Can anybody tell my why cabal thinks json needs mtl 1.1.0.2, and what I can do to make the message go away?

3 7

Proposal: Add instances for Functor, Monad, Applicative to Data.Monoid.First, Last
by Sterling Clover 06 Jan '11

06 Jan '11

Ticket: http://hackage.haskell.org/trac/ghc/ticket/4880 This proposal adds missing instances for the two newtype wrappers for Maybe in Data.Monoid. A patch is attached to the ticket. Both the motivation and implementation are straightforward. Discussion period: 2 weeks (until 20 Jan 2011). Cheers, Sterl

3 2

Proposal: Deprecate and remove Prelude.catch and System.IO.Error.{catch,try}
by Ian Lynagh 05 Jan '11

05 Jan '11

Hi all, Deprecate and remove Prelude.catch and System.IO.Error.{catch,try} http://hackage.haskell.org/trac/ghc/ticket/4865 Prelude and System.IO.Error both export an old version of catch, which only catches IOError's, and System.IO.Error additionally exports try with the same problem. These exports are annoying for people who want to use the modern exception handling functions in Control.Exception, as you need to explicitly either import the Prelude with catch hidden, or give the module of the function you want to use. They may also be confusing for beginners, who may not expect to have to use anything other than the catch function in the default scope to catch all exceptions. I believe these functions are only there for historical reasons, and are old cruft that we should tidy up, so I propose that in the base package that comes with GHC 7.2 we deprecate these old functions, and in 7.4 we remove them. Suggested deadline: 24 Jan 2011. Thanks Ian

11 24

MVar/Chan Ord instance
by Mitar 05 Jan '11

05 Jan '11

Hi! Is it possible to derive Ord for MVar (and based on that also for Chan)? Currently Eq is defined as reference equality (so each MVar is different from each other, independently from the content), at least as I understand it. But it would be useful to have also Ord defined in a such way (Ord of references). So without any semantic meaning of this ordering, but so that MVars (and Chans) can be used in set data types so that it is possible to define O(log n) isMember operation. I see that Eq is defined with internal function sameMVar#, so probably there would be also ordMVar# needed for this? Is there a way to get MVar internal references somehow (so that what sameMVar# is using)? Mitar

2 1

Suggested new function for System.Process - robustReadProcessWithExitCode
by Andrew Miller 05 Jan '11

05 Jan '11

Hi, I include my proposal for a new function, for System.Process , robustReadProcessWithExitCode, below. Best wishes, Andrew Miller Motivation for change: using readProcessWithExitCode risks terminating the program due to uncaught IOException (ResourceExhausted) if the input string is not read entirely by the new process before the new process exits, because readProcessWithExitCode will attempt to write to a process that doesn't exist. Often, it is the exit code and standard input and standard error that matters to a programmer, and not whether a process read all the input. There is therefore a case for a function like readProcessWithExitCode which is robust to the new process exiting before all input is read. Suggested implementation: {- | robustReadProcessWithExitCode creates an external process, reads its standard output and standard error strictly, waits until the process terminates, and then returns the 'ExitCode' of the process, the standard output, and the standard error. 'robustReadProcessWithExitCode' is a fairly simple wrapper around 'createProcess'. Constructing variants of these functions is quite easy: follow the link to the source code to see how 'robustReadProcessWithExitCode' is implemented. 'robustReadProcessWithExitCode' differs from 'readProcessWithExitCode' because it ignores IOExceptions encountered when writing the input to the new process. This can be useful if you don't know if the process reads all your input, but you want to get the output and exit code even if it exits before reading all input. -} robustReadProcessWithExitCode :: FilePath -- ^ command to run -> [String] -- ^ any arguments -> String -- ^ standard input -> IO (ExitCode,String,String) -- ^ exitcode, stdout, stderr robustReadProcessWithExitCode cmd args input = do (Just inh, Just outh, Just errh, pid) <- createProcess (proc cmd args){ std_in = CreatePipe, std_out = CreatePipe, std_err = CreatePipe } outMVar <- newEmptyMVar -- fork off a thread to start consuming stdout out <- hGetContents outh _ <- forkIO $ C.evaluate (length out) >> putMVar outMVar () -- fork off a thread to start consuming stderr err <- hGetContents errh _ <- forkIO $ C.evaluate (length err) >> putMVar outMVar () -- now write and flush any input, ignoring errors when (not (null input)) $ C.handle ((\e -> return ()) :: (C.IOException -> IO ())) $ do hPutStr inh input; hFlush inh hClose inh -- done with stdin -- wait on the output takeMVar outMVar takeMVar outMVar hClose outh -- wait on the process ex <- waitForProcess pid return (ex, out, err)

3 2

SampleVar semantics
by Eric Stansifer 02 Jan '11

02 Jan '11

Hi, I didn't get a response to my question on haskell-cafe, perhaps libraries is a more appropriate place to ask. doc: http://www.haskell.org/ghc/docs/7.0-latest/html/libraries/base-4.3.0.0/Cont… source: http://www.haskell.org/ghc/docs/7.0-latest/html/libraries/base-4.3.0.0/src/… The isEmptySampleVar function, isEmptySampleVar :: SampleVar a -> IO Bool isEmptySampleVar (SampleVar svar) = do (readers, _) <- readMVar svar return (readers == 0) returns False whenever readers < 0. However, readers < 0 occurs when there are threads waiting on an empty SampleVar. The documentation on SampleVar is a bit sparse on explaining the intended behavior; I wouldn't have expected this behavior if I hadn't read the source. Can someone clarify the semantics of SampleVar? For a contrived example, consider do_something = threadDelay 100000 -- 100 ms produce, consume :: SampleVar Int -> IO () produce svar = do do_something b <- isEmptySampleVar svar if b then randomIO >>= writeSampleVar svar else return () produce svar consume svar = do x <- readSampleVar svar print x consume svar main = do svar <- newEmptySampleVar forkIO $ produce svar forkIO $ consume svar threadDelay 1000000 -- one second This code deadlocks instead of printing random numbers. Thanks, Eric

3 4