June 2010 - Haskell-Cafe

Efficient string construction
by Kevin Jardine 04 Jun '10

04 Jun '10

(I've done a basic Google search on this with no results. Apologies if this has been asked before.) I am coding a web application in which the content is a Unicode string built up over multiple functions and maintained in a State structure. I gather that the String module is inefficient and that Data.Text would be a better choice. Is it more efficient to build up a list of Text objects over time and combine them together with a single Data.Text.concat for the final output or to run Data.Text.append for each new string so that I am maintaining a single Text object rather than a list? As Data.Text.append requires copying both strings each time, my gut feeling is that concat would be much more efficient, but Haskell has surprised me before, so I wanted to check. Kevin

5 7

ICFP Programming Contest
by Wouter Swierstra 04 Jun '10

04 Jun '10

This year's ICFP Programming Contest will begin on June 18th (12:00 Noon GMT) and will run till June 21st (12:00 Noon GMT). As in the previous editions, this is your chance to show that your favorite programming language is better than all others! The problem statement and further information will become available at: http://icfpcontest.org/2010/ Feel free to contact ifcpcont at imn dot htwk-leipzig dot de for further questions. Good luck! Wouter

1 0

Simplest reference for how to build GHC head + get it running w/ cabal/haskell-platform?
by Ryan Newton 03 Jun '10

03 Jun '10

What's the easiest reference for how to build GHC head and get it up and running with cabal/haskell-platform? I simply installed 6.12 + haskell-platform then built ghc-6.13.xx and rebuilt only the packages I needed with "cabal install --reinstall". Perhaps this is not the recommended way. Indeed, something must be wrong because I can't build certain packages. (I have problems with "base" dependencies.) For example: $ cabal install QuickCheck Resolving dependencies... cabal: cannot configure QuickCheck-1.2.0.0. It requires base ==3.* For the dependency on base ==3.* there are these packages: base-3.0.3.1 and base-3.0.3.2. However none of them are available. base-3.0.3.1 was excluded because of the top level dependency base -any base-3.0.3.2 was excluded because of the top level dependency base -any Thanks! -Ryan

2 1

Re: [Haskell-cafe] Weird socket problem on Mac OS X
by Antoine Latter 03 Jun '10

03 Jun '10

Hi Arnaud, One thing you might want to try is to stop using the PortNumber data constructor, and instead rely on 'fromInteger' to do the right thing. The data constructor assumes that it's argument is in network byte order, which won't always be the case. It's not obvious that the constructor should be avoided - this is the second time today I've seen this! Take care, Antoine On Jun 3, 2010 5:13 PM, "Arnaud Bailly" <arnaud.oqube(a)gmail.com> wrote: Hello, I have the following code which works ok on Linux and Windows XP, but fails on Mac OS X with error message: Connect: does not exist (connection refused) The server: doStartstate = do pr <- liftIO $ runProcess ... liftIO $ threadDelay 500000 st <- get put st { slimHandle = Just pr } The client: fetchAnswers st msgs = liftIO $! do let port = PortNumber $ fromInteger $ port $ config st cnx <- connectTo "localhost" port Help most welcome, thanks Arnaud _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Language Shootout reverse-complement benchmark
by Louis Wasserman 03 Jun '10

03 Jun '10

Hey, I was looking at the reverse-complement benchmark on the Language Shootout, and among other things, I noticed that the Haskell implementation was using (filter (/= '\n')) on ByteStrings, and also using lists as queues. I had a few improvements which using -fasm seem to yield about a 19% improvement in speed, and a 35% reduction in allocation, on my computer. (If both programs are compiled with -fllvm -- I'm not sure whether or not that's fair game on the Shootout -- my implementation is 35% faster, and does 10% less allocation.) I've checked my code on the Shootout's test input, as well. Mostly, the improvement comes from a tightly specialized version of (filter (/= '\n')), although eliminating an intermediate list entirely (and one used in a queuelike fashion) didn't seem to hurt. I managed to cut the program to a point where the program size is about the same as before. The code is at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=25865; the previous implementation is at http://shootout.alioth.debian.org/u32/program.php?test=revcomp&lang=ghc&id=2 . Let the arguing begin? Louis Wasserman wasserman.louis(a)gmail.com http://profiles.google.com/wasserman.louis

5 5

Data.ByteString.Lazy.hPut and timeouts?
by Jeremy Shaw 03 Jun '10

03 Jun '10

Hello, I am using Data.ByteString.Lazy.hPut to write data to a network socket. Is there any portable way to have hPut timeout if no data has been sent after some time period (say 120s?). I know that some OSes provide a per socket timeout that I can set in my application code (instead of a system-wide timeout that can only be set by root). But that does not seem like a very portable solution. My only other thought so far is to modify hPut to take a timeout. The standard definition looks like this: hPut :: Handle -> ByteString -> IO () hPut h cs = foldrChunks (\c rest -> S.hPut h c >> rest) (return ()) cs Seems like it should be easy to modify it so that it forks another thread to act as a watch dog. After every S.hPut it can tickle the timer. Since chunks are 16k, I think this should be sufficiently ok. If it is taking longer than 120s to send 16k, then we might want to consider the connection dead, even if it is making painfully slow progress.. Once all the chunks have been sent, we can kill the watch dog thread.. But, I am wondering if I am missing a better solution ? (Or an existing implementation of this solution?) Thank you for your insights! - jeremy p.s. At this point, using lazy ByteStrings is a requirement. Though I believe I would still have a very similar question if I was using iteratees anyway.

2 1

Weird socket problem on Mac OS X
by Arnaud Bailly 03 Jun '10

03 Jun '10

Hello, I have the following code which works ok on Linux and Windows XP, but fails on Mac OS X with error message: Connect: does not exist (connection refused) The server: doStartstate = do pr <- liftIO $ runProcess ... liftIO $ threadDelay 500000 st <- get put st { slimHandle = Just pr } The client: fetchAnswers st msgs = liftIO $! do let port = PortNumber $ fromInteger $ port $ config st cnx <- connectTo "localhost" port Help most welcome, thanks Arnaud

1 0

Process priority
by Andrew Coppin 03 Jun '10

03 Jun '10

I've had a hunt around in System.Process, but I can't discover any way to adjust the priority of the process you just spawned. Am I missing something, or has this just not been implemented yet? (I must confess, I don't know whether Windows and Unix both have the same ideas about priority numbers...)

2 1

Sockets get bound to wrong port on Windows
by Matthias Reisner 03 Jun '10

03 Jun '10

Hi, there's something wrong with port numbers in the Network.Socket module of package network. Printing values gives: *Main> PortNum 8888 47138 *Main> PortNum 47138 8888 So I thought it's just an error in the show instance of PortNumber, which shows the bytes flipped. But if I use the following code snippet sock <- socket AF_INET Datagram 0 bindSocket sock $ SockAddrInet (PortNum 8888) iNADDR_ANY to bind a socket to port 8888, netstat and TCPView reveal that the socket is actually bound to the wrong port 47138. I'm using network-2.2.1.7 on Windows XP. Is that a bug or am I doing something wrong here? Regards, Matthias

5 7

The state of Hackage: what are we doing about it?
by Don Stewart 03 Jun '10

03 Jun '10

I see fairly regular complaints about too many Haskell libraries, bewildering choice of difficult-to-determine quality. I've tried to summarize the state of Hackage, and what projects are active to make it easier to find high quality libraries: http://tinyurl.com/2cqw9sb Thoughts? -- Don

10 17