March 2011 - Libraries

Uncatchable error (fwd)
by Henning Thielemann 11 Mar '11

11 Mar '11

I like to forward this message from Haskell-Cafe: ---------- Forwarded message ---------- Date: Fri, 11 Mar 2011 17:04:16 +0100 (CET) From: Daniel Díaz <danieldiaz(a)asofilak.es> To: haskell-cafe(a)haskell.org Subject: [Haskell-cafe] Uncatchable error Hi, cafe, I'm working in a program where I use many connections with Network.HTTP. Sometimes, connections are closed while my program is reading them, and an error appears: <socket: XXX>: Data.ByteString.hGetLine: invalid argument (Bad file descriptor) All I need is to handle this error. The function 'catch' doesn't work. I guess this error comes from a call to 'error' function, or something similar. What I can do? Thanks in advance, Daniel Díaz _______________________________________________ It sounds to me that this is not a particular problem of Network.HTTP or Data.ByteString.hGetLine. It would certainly also happen for System.IO.hGetLine applied to a HTTP stream. So how can exceptions about closed HTTP connections be caught and where is it documented? The System.IO functions only mention EOF as possible exception.

1 0

Proposal: Generalize maybeNew
by Bas van Dijk 08 Mar '11

08 Mar '11

Hi, This is a tiny proposal to generalize Foreign.Marshal.Utils.maybeNew[1] from: maybeNew :: ( a -> IO (Ptr a)) -> (Maybe a -> IO (Ptr a)) to: maybeNew :: ( a -> IO (Ptr b)) -> (Maybe a -> IO (Ptr b)) so that it becomes consistent with maybeWith: maybeWith :: ( a -> (Ptr b -> IO c) -> IO c) -> (Maybe a -> (Ptr b -> IO c) -> IO c) Discussion period: 2 weeks. Bas [1] http://hackage.haskell.org/packages/archive/base/latest/doc/html/Foreign-Ma…

1 0

Proposal: add ByteString support to unix:System.Posix.IO API
by wren ng thornton 07 Mar '11

07 Mar '11

Hello all, I've written variants of the System.Posix.IO API for strict and lazy ByteStrings which are currently lingering in their own unpublished package[1]. It's silly to have a separate package for just four functions, so I'd like to see it combined into the unix package. I don't have access to create a new ticket with the patch, but it's available at [2]. Discussion time: 2 weeks. [1] darcs: http://community.haskell.org/~wren/bytestring-unix haddock: http://community.haskell.org/~wren/bytestring-unix/dist/doc/html/bytestring… [2] Darcs patch: http://community.haskell.org/~wren/bytestring-unix/bytestring-unix-0.1.0.dp… -- Live well, ~wren

6 15

darcs patch: Fix #4970 (time002 and time004 test failures on darwin)
by gwright＠antiope.com 04 Mar '11

04 Mar '11

1 patch for repository http://darcs.haskell.org/ghc-7.0/packages/old-time: Fri Mar 4 13:05:00 EST 2011 gwright(a)antiope.com * Fix #4970 (time002 and time004 test failures on darwin) This patch fixes #4970. The tv_usec field of struct timeval has type __int32_t, but getClockTime treats it as 64 bits. Because allocaBytes doesn't zero its memory, garbage can end up in the upper 32 bits. This causes a "picoseconds out of range" error in test002 and test004. The fix is to change the cast of (#peek struct timeval,tv_usec) p_timeval from "IO CTime" to "IO CInt" on darwin. The usec value is then handled correctly. I have no idea why this is only seen when the tests are run interactively but not in compiled code.

1 0

ByteString version of Text.Regex?
by Kathleen Fisher 04 Mar '11

04 Mar '11

I want a version of the Text.Regex library where the input is a character-based ByteString instead of a String. I haven't found one on hackage, although I'm not convinced I've looked exhaustively. (Every time I try to explore the regular expression libraries on Hackage, I end up in a maze of documentation, never sure precisely where I am or where I should be going.) It would be really helpful if there were a few English paragraphs somewhere explaining the high-level model provided by the various modules! I ended up taking a version of Text.Regex and making changes to produce a library that works for lazy character ByteStrings. Is that a reasonable thing to do? I'm going to make my software public soon, so I'll either need to release this modified library or swap my version out for a more standard one. Any suggestions on the best way to proceed? Kathleen

4 4

Re: Proposal: add ByteString support to unix:System.Posix.IO API
by wren ng thornton 04 Mar '11

04 Mar '11

On 2/28/11 12:28 PM, Johan Tibell wrote: > On Mon, Feb 28, 2011 at 9:20 AM, Bryan O'Sullivan<bos(a)serpentine.com> wrote: >> On Sun, Feb 27, 2011 at 9:18 PM, wren ng thornton<wren(a)freegeek.org> wrote: >>> >>> I've written variants of the System.Posix.IO API for strict and lazy >>> ByteStrings which are currently lingering in their own unpublished >>> package[1]. It's silly to have a separate package for just four functions, >>> so I'd like to see it combined into the unix package. I don't have access to >>> create a new ticket with the patch, but it's available at [2]. >> >> I think that the strict bytestring version should just replace the current >> function in System.Posix.IO, and the lazy version should not go in at all. >> This is the approach taken by the network package, and it's cleanest. > > Thanks for working on this Wren. > > I agree with Bryan's point. So then what would become of the string variants? Backwards compatibility and all... not _everyone_ uses ByteStrings yet. Also, FWIW, the real impetus behind writing these was to deal with lazy ByteStrings, since that's what one of my dependencies uses[1]. It seems like a common enough situation that it should be handled directly. Forcing people to call (BS.concat . BL.toChunks) first muddies up the code and introduces additional copying, whereas making people use (mapM_ fdWrite . BL.toChunks) is still rather messy and it's buggy in the face of partial writes. For network usage I agree that the strict-only approach is clean and effective. For general purpose writing to Fds, I'm not so sure. [1] http://hackage.haskell.org/packages/archive/protocol-buffers/1.8.0/doc/html… -- Live well, ~wren

11 22

ANN: Version 0.14 of dataenc, version 0.5 of omnicodec
by Magnus Therning 03 Mar '11

03 Mar '11

I've just uploaded a new version of dataenc to hackage[1]. It contains a large change to the API. The old, rather simplistic, lazy API has been removed. It has been replaced by an API based on incremental encoding/decoding. This should make the library easier to use together with left-fold enumerators such as enumerator[2] and iteratee[3]. It's accompanied by a release of omnicodec[4] which makes use of the modified API of dataenc. /M [1] http://hackage.haskell.org/package/dataenc [2] http://hackage.haskell.org/package/enumerator [3] http://hackage.haskell.org/package/iteratee [4] http://hackage.haskell.org/package/omnicodec -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

1 0

union in Data.Map
by Ross Paterson 01 Mar '11

01 Mar '11

[sidetracking from the discussion of unordered-containers] On Thu, Feb 24, 2011 at 12:36:42PM +0000, Ross Paterson wrote: > On Wed, Feb 23, 2011 at 08:45:47AM +0000, Max Bolingbroke wrote: > > 3. Some map combining algorithms work more efficiently when one of > > their two arguments are smaller. For example, Data.Map.union is most > > efficient for (bigmap `union` smallmap). If you don't care about which > > of the two input maps wins when they contain the same keys, you can > > improve constant factors by testing the size of the map input to size > > (in O(1)) and flipping the arguments if you got (smallmap `union` > > bigmap) instead of the desirable way round. > > This is a most unfortunate feature of Data.Map, forcing users to bend the > logic of their application to suit the library. On closer inspection, I think the documentation is underselling the code here. From experiments adding 1000 trees of size 10 to a tree of size 1000, it seems that the best order varies with the distribution of keys, but on average they come out about even. (Maybe small U big is slightly faster.) Also, I believe the hedge algorithm does achieve the asymptotic optimum, namely O(m log(n/m)), where m and n are the sizes of the smaller and larger trees respectively. It does do more comparisons than necessary, but these can be avoided, e.g. by altering hedgeUnionL to hedgeUnionL :: Ord a => MaybeS a -> MaybeS a -> Map a b -> Map a b -> Map a b hedgeUnionL _ _ t1 Tip = t1 hedgeUnionL blo bhi Tip (Bin _ kx x l r) = join kx x (filterGt blo l) (filterLt bhi r) hedgeUnionL blo bhi (Bin _ k1 x1 l1 r1) t2@(Bin _ k2 _ l2 r2) = case compare k1 k2 of LT -> join k1 x1 (hedgeUnionL blo bmi l1 (trim blo bmi l2)) (hedgeUnionL bmi bhi r1 t2) EQ -> join k1 x1 (hedgeUnionL blo NothingS l1 (trim blo NothingS l2)) (hedgeUnionL NothingS bhi r1 (trim NothingS bhi r2)) GT -> join k1 x1 (hedgeUnionL blo bmi l1 t2) (hedgeUnionL bmi bhi r1 (trim bmi bhi r2)) where bmi = JustS k1 and similarly for difference. The extra lookup in the With versions seems harder to avoid, though.

1 0

add Data.Bool.ifThenElse
by Henning Thielemann 01 Mar '11

01 Mar '11

If I activate RebindableSyntax in GHC-7.0, I have to provide a function named ifThenElse. How about a default implementation in Data.Bool that is equivalent to classical if-then-else? So far, I only use RebindableSyntax for overloaded number literals.

3 3