October 2010 - Haskell-Cafe

ANNOUNCE: Haskell XML Toolbox Version 9.0.0
by Uwe Schmidt 18 Oct '10

18 Oct '10

Haskell XML Toolbox 9.0.0 I would like to announce a new version of the Haskell XML Toolbox. HXT has grown over the years. Components for XPath, XSLT, validation with RelaxNG, picklers for conversion from/to native Haskell data, lazy parsing with tagsoup, input via curl and native Haskell HTTP and others have been added. This has led to a rather large package with a lot of dependencies. To make the toolbox more modular and to reduce the dependencies on other packages, hxt has been split into various smaller packages since this version. Information about this release, about the new packages, changes and incompatibilities to older versions can be found at HXT home: "http://www.fh-wedel.de/~si/HXmlToolbox/index.html" and on the Haskell wiki page about HXT "http://www.haskell.org/haskellwiki/HXT" The source repo has been moved to GitHub: "http://github.com/UweSchmidt/hxt" Downloads and installation is available from hackage. Please email comments, bugs, etc. to hxmltoolbox(a)fh-wedel.de or si(a)fh-wedel.de Uwe -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html

16 32

concurrency vs. I/O in GHC
by Donn Cave 18 Oct '10

18 Oct '10

As I have migrated more of my application into Haskell, I find that I/O in one thread effectively blocks other threads. That's rather the opposite of what I need - I don't care so much if Haskell threads manage to compute in parallel, but the application should continue to function, in other threads, while an I/O has one thread blocked. Is that supposed to happen, is there anything I can do about it? Specifically I'm talking about OpenSSL SSL_read(). In this case, while a file descriptor is involved, there is also (I assume) some buffering, so it isn't a simple matter of deferring SSL_read() until data arrives at the fd. I'm hoping there's something more generic, that unblocks other threads during any foreign call - as one would do in Python, for example, bracking a foreign call with C macros that release and acquire the interpreter global lock. You'd also use this with functions like open(), which may not return immediately but don't answer to select(). All the Haskell code in question is executing in callbacks, from threads started in C++. The thread that actually does the network I/O could if necessary be started in 1st generation Haskell as a special case, if that might make any difference. I disable the RTS clock itimer signals, because something in the libraries I'm using doesn't thrive under a barrage of signals. (Environment setting GHCRTS=-V0.) The consequence, according to the documentation, should be "Context switches will still happen, but deterministically and at a rate much faster than normal", and anyway I suppose that's talking about green threads, not the OS threads where context switches are an OS function. Thanks! Donn Cave, donn(a)avvanta.com

2 3

Proving stuff about IORefs
by Ben Franksen 17 Oct '10

17 Oct '10

I have a formal proof where I am stuck at a certain point. Suppose we have a function f :: IORef a -> IO b I want to prove that f r == do s1 <- readIORef r r' <- newIORef s1 x <- f r' s3 <- readIORef r' writeIORef r s3 return x What happens here is that the temporary IORef r' takes the place of the argument r, and after we apply f to it we take its content and store it in the original r. This should be the same as using r as argument to f in the first place. How can I prove this formally? Cheers Ben

7 11

Text: find
by Antoine Latter 17 Oct '10

17 Oct '10

On Sun, Oct 17, 2010 at 3:25 PM, Bryan O'Sullivan <bos(a)serpentine.com> wrote: > On Mon, Oct 11, 2010 at 1:12 PM, Malcolm Wallace <malcolm.wallace(a)me.com> > wrote: >> >> find find find (Text -> Bool) -> Text -> Maybe Text >> >> Proposal: rename Text.findBy to Text.find. > > I agree with the change of type, not so much with the naming. That's roughly > my stance in the other cases, too. > What would the definition of a function of the form: > find :: (Text -> Bool) -> Text -> Maybe Text look like? What sort of requirements would be placed on the input predicate? Maybe I have a failure of imagination, but that sounds like a tricky thing to get correct for all predicates. Antoine

3 2

Haskell Front Page Ideas
by caseyh＠istar.ca 17 Oct '10

17 Oct '10

How about a bullet list of Haskell's features (maybe pros & cons) might be better; followed by a list of a few other languages and their trade-offs. As Jon Bentley has said, "design" is usually trade-offs but when you can come up with something that is a mutual benefit; so much the better. :)

3 2

Strict Core?
by Gregory Crosswhite 17 Oct '10

17 Oct '10

Hey everyone, Out of curiosity, are there any plans for GHC to eventually use the Strict Core language described in http://www.cl.cam.ac.uk/~mb566/papers/tacc-hs09.pdf? Cheers, Greg

7 9

Heterogenous network stream
by Antoine Latter 17 Oct '10

17 Oct '10

Forwarding to list. ---------- Forwarded message ---------- From: Antoine Latter <aslatter(a)gmail.com> Date: Sun, Oct 17, 2010 at 10:48 AM Subject: Re: [Haskell-cafe] Heterogenous network stream To: Charles-Pierre Astolfi <cpa(a)crans.org> On Sun, Oct 17, 2010 at 7:31 AM, Charles-Pierre Astolfi <cpa(a)crans.org> wrote: > Hi cafe, > > I'd like to implement a toy-protocol and I'm looking for the sanest > way (for me) to do so. > > Here's what it looks like: > The server receives, in that order: > - Ascii string (4 bytes) > - 16 bits int (2 bytes) > - 8 bits int (1 byte) > - UTF8 string (128 bytes) > > I tried to use hGetBuf, but I don't know if it's the way to go and I > did not understood what to do with the buf::Ptr a argument. I'm not > very concerned about efficiency. > > I don't know how I should convert my 16 and 8 bits int (read as Chars, > I guess) to an Int. Is there something for that in the standard > library? > I recommend reading the data in as one bytestring[1] (since you have a fixed length) and then parsing it using one of the many nice bytestring parsing libraries: * binary[2] * cereal[3] Others may have other suggestions. For the UTF8 parsing, I think the text[4] package has support for decoding UTF8 from a bytestring. Antoine [1] http://hackage.haskell.org/packages/archive/bytestring/0.9.1.7/doc/html/Dat… [2] http://hackage.haskell.org/package/binary [3] http://hackage.haskell.org/package/cereal [4] http://hackage.haskell.org/package/text

1 0

Re: [Haskell-cafe] UTF-8 problems when decoding JSON data coming from Network.HTTP
by Ionut G. Stan 17 Oct '10

17 Oct '10

On 17/Oct/10 8:02 AM, Michael Snoyman wrote: > In the gist you sent, the problem is that you are reading the HTTP > response as a String. The HTTP library doesn't deal well with > non-Latin characters when doing String requests; you should be using > ByteString and then converting. It's a little tedious using the HTTP > library with ByteStrings, which is one of the reasons I wrote > http-enumerator. Here's some working code. The main point is to > convert the UTF8 octets to a String. > > You could also consider using one of the JSON libraries that support > bytestrings directly instead of strings, which will likely result in > much better performance. Contenders include JSONb[1] and > yajl-enumerator[2]. > > import Network.HTTP.Enumerator > import qualified Text.JSON as JSON > import qualified Data.ByteString.Lazy.UTF8 as BSLU > > data GithubUser = GithubUser { > name :: String, > location :: String > } deriving (Eq, Show) > > > instance JSON.JSON GithubUser where > readJSON (JSON.JSObject object) = > let (Just a) = lookupM "user" $ JSON.fromJSObject object > (JSON.JSObject b) = a > user = JSON.fromJSObject b > in do name<- lookupM "name" user>>= JSON.readJSON > location<- lookupM "location" user>>= JSON.readJSON > return $ GithubUser { > name = name, > location = location > } > > showJSON user = JSON.makeObj [ > ("name", JSON.showJSON $ name user), > ("location", JSON.showJSON $ location user) > ] > > > lookupM :: (Monad m) => String -> [(String, a)] -> m a > lookupM x xs = maybe (fail $ "No such element: " ++ x) return (lookup x xs) > > main = do jsonLbs<- simpleHttp "http://github.com/api/v2/json/user/show/igstan" > let jsonText = BSLU.toString jsonLbs > let result = JSON.decode jsonText :: JSON.Result GithubUser > showResult result > where showResult (JSON.Ok json) = putStrLn $ name json > showResult (JSON.Error e) = putStrLn e > > Michael > > [1] http://hackage.haskell.org/package/JSONb-1.0.2 > [2] http://hackage.haskell.org/package/yajl-enumerator Thanks Michael, now it works indeed. But I don't understand, is there any inherent problem with Haskell's built-in String? Should one choose ByteString when dealing with Unicode stuff? Or, is there any resource that describes in one place all the problems Haskell has with Unicode? -- Ionuț G. Stan | http://igstan.ro

3 3

Heterogenous network stream
by Charles-Pierre Astolfi 17 Oct '10

17 Oct '10

Hi cafe, I'd like to implement a toy-protocol and I'm looking for the sanest way (for me) to do so. Here's what it looks like: The server receives, in that order: - Ascii string (4 bytes) - 16 bits int (2 bytes) - 8 bits int (1 byte) - UTF8 string (128 bytes) I tried to use hGetBuf, but I don't know if it's the way to go and I did not understood what to do with the buf::Ptr a argument. I'm not very concerned about efficiency. I don't know how I should convert my 16 and 8 bits int (read as Chars, I guess) to an Int. Is there something for that in the standard library? As I also write the client, I'm looking for a conversion in both ways. Thanks, -- Charles-Pierre

1 0

Opening a gtk2hs link in default browser
by Dmitry V'yal 17 Oct '10

17 Oct '10

Hello list, I'm trying to make a clickable link in gtk2hs program. Clicking it should open an url in the default browser. Can I hope to find some portable solution in gtk2hs (it should work in linux and windows) or should I start searching platform specific ones, like /usr/bin/xdg-open or something? Can any examples be found in existing haskell software? Dmitry

2 1