- Libraries - Haskell.org

[network] #9: Race/Async Exception issue in Network.Socket.connect
by network 12 May '09

12 May '09

#9: Race/Async Exception issue in Network.Socket.connect ---------------------+------------------------------------------------------ Reporter: sclv | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | ---------------------+------------------------------------------------------ Submitted here as well: http://hackage.haskell.org/trac/ghc/ticket/3225 {{{ import Control.Concurrent import Control.Monad import Network.Socket import Control.Exception as C import System.Timeout import Network.BSD(hostAddresses, getHostByName) import System.IO.Error import Data.Maybe -- someHostName should be replaced by a real host that gives -- "connection refused" errors on connection to ports in the range. -- The latter ip is a junk one that should cause connections to -- hang indefinitely. -- More hostnames with either characteristic can be added to taste -- if that helps to reproduce the bug. servers = [ "someHostName", "126.255.255.255"] ports = [9001..9099] :: [Int] conns = [(h,p) | h <- servers, p <- ports] connectSock :: Integral a => String -> a -> IO Socket connectSock host port = do hn <- maybe (ioError . mkIOError doesNotExistErrorType "No Host Address" Nothing $ Just host) return . listToMaybe . hostAddresses =<< getHostByName host sk <- socket AF_INET Stream 6 connect sk (SockAddrInet (fromIntegral port) hn) `C.onException` sClose sk return sk pMapM f xs = mapM (\x -> forkIO $ f x) xs mapM' f xs = mapM (\x -> (C.try :: IO a -> IO (Either C.SomeException a)) (f x)) xs main = do -- This is the canary thread in the bugmine forkIO $ forever $ putStrLn "chirp" >> threadDelay 100000 -- This is the bug thread forever $ pMapM (\(h,p) -> timeout 1000000 (connectSock h p) >> return ()) conns >> threadDelay 2000000 }}} The above code, compiled with the threaded runtime, causes a race condition. After roughly one to two cycles of the bug thread, the canary thread stops running, indicating that the program has become somehow trashed. (The bug thread stops running as well). In experiments, this race condition is best triggered with at least two servers, one of which yields "connection refused" on connection, and the other of which simply hangs -- the nonsense ip address provided above works for the latter. If the pMapM is replaced by mapM' (i.e. we switch from parallel to serial connection) then the bug does not appear to be triggered. Wrapping the call to sClose in a mutex didn't seem to help, so it seems the race condition is in the connect call. -- Ticket URL: <http://trac.haskell.org/network/ticket/9> network <http://projects.haskell.org/network/> Networking-related facilities

1 0

Proposal: add System.Posix.fdReadBuf/fdWriteBuf
by Simon Marlow 12 May '09

12 May '09

http://hackage.haskell.org/trac/ghc/ticket/3218 From the ticket: Functions for reading/writing actual arrays of bytes in memory. At the moment, `System.Posix` only provides {{{ fdRead :: Fd -> ByteCount -- ^How many bytes to read -> IO (String, ByteCount) -- ^The bytes read, how many bytes were read. fdWrite :: Fd -> String -> IO ByteCount }}} which are not only wrong (`String`?), but too slow for many purposes. I propose {{{ Mon May 11 16:21:02 BST 2009 Simon Marlow <marlowsd(a)gmail.com> * add fdReadBuf, fdWriteBuf -- | Read data from an 'Fd' into memory. This is exactly equivalent -- to the POSIX @read@ function. fdReadBuf :: Fd -> Ptr Word8 -- ^ Memory in which to put the data -> ByteCount -- ^ Maximum number of bytes to read -> IO Bytecount -- ^ Number of bytes read (zero for EOF) -- | Write data from memory to an 'Fd'. This is exactly equivalent -- to the POSIX @write@ function. fdWriteBuf :: Fd -> Ptr Word8 -- ^ Memory containing the data to write -> ByteCount -- ^ Maximum number of bytes to write -> IO ByteCount -- ^ Number of bytes written }}} darcs patches are attached to the ticket. Discussion: 2 weeks (ends 25 May) Cheers, Simon

2 1

Haskell Platform universe
by Bulat Ziganshin 11 May '09

11 May '09

it seems that i should forward here my letter from Haskell Platform list: i just installed Windows Haskell Platform RC. it have created "Start Menu\Haskell Platform\GHC 6.10.2" item, that forced me to think deeper about HP universe yes, we decided that HP will include up-to-date GHC and some set of libraries. but how different HP versions will coexist? one model is that every HP is separate universe, with its own GHC and libs carried - this case menu item (and disk directory) should be called something like "Start Menu\Haskell Platform\2009.0.0" another model is that each HP release updates HP universe already existing on user's box. i.e. it comes with some versions of GHC and libs while this universe may already contain this and previous GHC versions and some libraries so HP should be carefully installed in order to not lose old contents (such as ghc-pkg database) i fear that currently this topic was not considered and we don't support any model at all. i.e. every next HP release will just overwrite universe with fresh GHC installation making it suitable only for beginners well, the good news is that we can make a *first* release that does clean installation and add "update" feature only staring from the second one (well, as far as users will not install first release attop of later ones :) -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com

1 0

Haskell Platform tasks for the June 1 2009.2.1 minor release
by Don Stewart 10 May '09

10 May '09

There's a minor revision (i.e. versioning/API compatible) release of the Haskell Platform coming up on June 1. http://trac.haskell.org/haskell-platform/wiki/ReleaseProcess Tasks currently listed for this release are available here: http://trac.haskell.org/haskell-platform/query?status=new&status=assigned&s… In particular, note: * Mac OS X installer is planned (currently will block the release) * Decide if we upgrade to 6.10.3 And we need to decide on the fate of some packages that may have compat. upgrades: * GLUT * OpenGL * network * happy Finally, there are a few remaining infrastructure tasks: * Unified haddocks Please consult the tickets if you can help or have thoughts. -- Don

3 4

Proposal: Add sequenceWhile and SequenceWhile_ to Control.Monad
by Dominic Steinitz 09 May '09

09 May '09

I'm not sure of the protocol for adding things to existing libraries but I'd like to propose the addition of these two functions to Control.Monad. sequenceWhile_ :: Monad m => (a -> Bool) -> [m a] -> m () sequenceWhile_ _ [] = return () sequenceWhile_ p (x:xs) = x >>= \c -> if (p c) then sequenceWhile_ p xs else return () sequenceWhile :: Monad m => (a -> Bool) -> [m a] -> m [a] sequenceWhile _ [] = return [] sequenceWhile p (x:xs) = do y <- x if (p y) then do ys <- sequenceWhile p xs return (y:ys) else return [y]

3 4

[libraries@haskell.org: Re: [network] #1: unpackFamily on Windows fails match]
by Don Stewart 09 May '09

09 May '09

We need someone on Windows to construct a patch for getHostByName on windows. See http://trac.haskell.org/network/ticket/1 ----- Forwarded message from network <libraries(a)haskell.org> ----- Date: Sat, 09 May 2009 07:44:28 -0000 From: network <libraries(a)haskell.org> Cc: libraries(a)haskell.org Subject: Re: [network] #1: unpackFamily on Windows fails match #1: unpackFamily on Windows fails match ----------------------+----------------------------------------------------- Reporter: igloo | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Resolution: | Keywords: ----------------------+----------------------------------------------------- Comment (by tibbe): I have limited access to Windows machines. If someone could come up with a rough patch that addresses this bug I'd be happy to review it. -- Ticket URL: <http://trac.haskell.org/network/ticket/1#comment:4> network <http://projects.haskell.org/network/> Networking-related facilities _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://www.haskell.org/mailman/listinfo/libraries ----- End forwarded message -----

1 0

Re: [Haskell-cafe] Re: ANNOUNCE: The Haskell Platform
by Don Stewart 07 May '09

07 May '09

kyagrd: > Thanks for this great effort! > > Are we going to have a meta-package on hackage as well? > (which makes it able to build it through cabal-install) Yes, this ticket tracks that stuff: http://trac.haskell.org/haskell-platform/ticket/15

1 0

problem with readline (mac os x)
by brian 07 May '09

07 May '09

Here's the relevant bits : checking for readline in -lreadline... yes checking for rl_readline_version... yes checking for rl_begin_undo_group... no configure: error: readline not found, so this package cannot be built Looks like it found readline, and then decided it didn't ? I'm having fairly consisten problems with cabal packages needing symlinks in /usr/local to work properly, i.e. it can't seem to find libraries in /sw/lib where fink puts them. Is that a cabal problem or a ghc issue ? Brian

2 3

ANNOUNCE: The Haskell Platform
by Don Stewart 06 May '09

06 May '09

We're pleased to announce the first release of the Haskell Platform: a single, standard Haskell distribution for every system. Download the Haskell Platform 2009.2.0 installers and specification: http://hackage.haskell.org/platform/ The Haskell Platform is a blessed library and tool suite for Haskell culled from Hackage, along with installers for a wide variety of systems. It saves developers work picking and choosing the best Haskell libraries and tools to use for a task. What you get: http://hackage.haskell.org/platform/contents.html With regular time-based releases, we expect the platform will grow into a rich, indispensable development environment for all Haskell projects. Distro maintainers that support the Haskell Platform can be confident they're fully supporting Haskell as the developers intend it. Developers targetting the platform can be confident they have a trusted base of code to work with. *Please note that this is a beta release*. We do not expect all the installers to work perfectly, nor every developer need met, and we would appreciate feedback. You can help out by packaging the platform for your distro, or reporting bugs and feature requests, or installing Haskell onto your friends' machines. The process for adding new tools and libraries will be outlined in coming weeks. The Haskell Platform would not have been possible without the hard work of the Cabal development team, the Hackage developers and maintainers, the individual compiler, tool and library authors who contributed to the suite, and the distro maintainers who build and distribute the Haskell Platform. Thanks! -- The Platform Infrastructure Team

1 0

[network] #8: Evaluating addrFlags from use of Network.Socket.getAddrInfo causes exception
by network 05 May '09

05 May '09

#8: Evaluating addrFlags from use of Network.Socket.getAddrInfo causes exception -------------------------------------------+-------------------------------- Reporter: semanticphilosopher(a)gmail.com | Owner: Type: defect | Status: new Priority: major | Milestone: Component: network | Version: Keywords: | -------------------------------------------+-------------------------------- Using GHC 6.10.2 under Mac OS X 10.5.6 it does not appear that you can access the 'addrFlags' returned by getAddrInfo, you get the exception: *** Exception: unpackBits: unhandled bits set: 8 {{{ GHCi, version 6.10.2: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Prelude> :m Network.Socket Prelude Network.Socket> getAddrInfo Nothing (Just "localhost") Nothing Loading package syb ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package parsec-2.1.0.1 ... linking ... done. Loading package network-2.2.1 ... linking ... done. [AddrInfo {addrFlags = *** Exception: unpackBits: unhandled bits set: 8 Prelude Network.Socket> }}} -- Ticket URL: <http://trac.haskell.org/network/ticket/8> network <http://projects.haskell.org/network/> Networking-related facilities

1 4