July 2007 - Haskell-Cafe

ANNOUNCE: Haskell XML Toolbox Version 7.2
by Uwe Schmidt 09 Jul '07

09 Jul '07

Haskell XML Toolbox 7.2 I would like to announce a new version of the Haskell XML Toolbox. This is mainly a bug fix release, but there is one new module for converting data between user defined types and the HXT DOM structure. This new modules enables the simple persistent storage and retrieval of arbitrary data with XML documents. See example directory "examples/arrows/pickle" in the distribution for a none trivial example of these picklers. These functions are an adaptation of Andrew Kennedy's pickler combinators. ( http://research.microsoft.com/~akenn/fun/picklercombinators.pdf ) The darcs repo for HXT is at http://darcs.fh-wedel.de/hxt More information and download: http://www.fh-wedel.de/~si/HXmlToolbox/index.html Please email comments, bugs, etc. to hxmltoolbox(a)fh-wedel.de Uwe -- University of Applied Sciences, Wedel, Germany http://www.fh-wedel.de/~si/index.html

1 0

Re: [Haskell-cafe] Gtk2Hs, Glade, Multiple windows/dialog in one interface file.
by Brandon S. Allbery KF8NH 09 Jul '07

09 Jul '07

On Jul 8, 2007, at 16:36 , D.V. wrote: > I finally got it to work with onResponse : I traced each possible > response to see which one was fired when clicking the close button.... Great, another place where the documentation's wrong. :/ (onActivateLeaf vs. onActivateItem (and after- versions) also found to be wrong. Must submit a bug report at some point.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery(a)kf8nh.com system administrator [openafs,heimdal,too many hats] allbery(a)ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

2 1

Memoisation + unsafePerformIO
by Tony Morris 09 Jul '07

09 Jul '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello everyone, I am trying to write a generalisation of memoisation for a couple of backtracking algorithms that I wrote (which don't specify a memoisation technique), by keeping a local destructive update using unsafePerformIO and IORef - neither of which I have used before and I am struggling to figure out. I am going from the document: http://haskell.org/hawiki/GlobalMutableState I am not sure if: a) this is even possible b) if a) holds, if this is a good thing Here is some code to help demonstrate what I intend: {-# OPTIONS_GHC -fglasgow-exts #-} import Data.Ix - -- implementations must guarantee that - -- memo f k is equivalent to f k - -- but may otherwise use local destructive updates class Memo k v where memo :: (k -> v) -> k -> v instance (Ix k) => Memo k v where memo f k = error("todo: array") instance (Ord k) => Memo k v where memo f k = error("todo: binary tree") - -- Tony Morris http://tmorris.net/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGkZlFmnpgrYe6r60RArT8AJ4iFVyzmUN1pdxpMBokZpj48CiqRgCfReIe 2yZ55LMcFs24TJOVeCV4tbo= =IR5s -----END PGP SIGNATURE-----

3 2

ANNOUNCE: utf8-string-0.1
by Eric Mertens 09 Jul '07

09 Jul '07

Hello, I'd like to announce that I have posted a UTF-8 encoding/decoding library to hackage. This library also includes replacements for most of the System.IO namespace under System.IO.UTF8. This library detects overlong sequences, and replaces invalid code-points and invalid encodings with the replacement character '\xfffd'. The following file was used to ensure that the decoder was considered "safe": http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt utf8-string can be found on hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/utf8-string-0.1 source code is available via: darcs get http://code.haskell.org/utf8-string/ -- Eric Mertens

2 1

Compress and serialise data with lazy bytestrings, zlib and Data.Binary (was: Allocating enormous amounts of memory)
by dons＠cse.unsw.edu.au 08 Jul '07

08 Jul '07

Jefferson Heard write: > I'm using the Data.AltBinary package to read in a list of 4.8 million > floats and 1.6 million ints. Doing so caused the memory footprint to > blow up to more than 2gb, which on my laptop simply causes the program > to crash. I can do it on my workstation, but I'd really rather not, > because I want my program to be fairly portable. > > The file that I wrote out in packing the data structure was only 28MB, > so I assume I'm just using the wrong data structure, or I'm using full > laziness somewhere I shouldn't be. Here's a quick example of how to efficient read and write such a structure to disk, compressing and decompressing on the fly. $ time ./A Wrote 4800000 floats, and 1600000 ints Read 4800000 floats, and 1600000 ints ./A 0.93s user 0.06s system 89% cpu 1.106 total It uses Data.Binary to provide quick serialisation, and the zlib library to compress the resulting stream. It builds the tables in memory, writes and compresses the result to disk, reads them back in, and checks we read the right amount of CFloats and CInts. You'd then pass the CFloats over to your C library that needs them. Compressing with zlib is a flourish, but cheap and simple, so we may as well do it. With zlib and Data.Binary, the core code just becomes: encodeFile "/tmp/table.gz" table table' <- decodeFile "/tmp/table.gz" Which transparently streams the data through zlib, and onto the disk, and back. Simple and efficient. -- Don Here's the code: -- some imports import Text.Printf import Data.Binary import Codec.Compression.Zlib import Control.Monad import qualified Data.ByteString.Lazy as L import qualified Data.ByteString.Base as B import Foreign import Foreign.C.Types -- A simple table type for the arrays, that will be easy to manipulate data Table = Table { floats :: L.ByteString , ints :: L.ByteString } -- Serialise this data in gzip-compressed form: a gzipping Binary instance. instance Binary Table where put t = do put (compress (floats t)) put (compress (ints t)) get = liftM2 Table (decompress `liftM` get) (decompress `liftM` get) -- Default sizes floatSize = 4800000 intSize = 1600000 -- Build a new empty table newTable :: IO Table newTable = do f <- mallocArray floatSize :: IO (Ptr CFloat) i <- mallocArray intSize :: IO (Ptr CInt) -- fill them with data here -- -- convert to bytestrings. bf <- B.packCStringFinalizer (castPtr f) (floatSize * sizeOf (undefined :: CFloat)) (return ()) bi <- B.packCStringFinalizer (castPtr i) (intSize * sizeOf (undefined :: CInt)) (return ()) return $ Table (L.fromChunks [bf]) (L.fromChunks [bi]) -- Now just build the table, serialise it, read it back in, and print the result main = do table <- newTable -- write the data to disk, compressed with gzip as we go. encodeFile "/tmp/table.gz" table draw "Wrote" table -- load it back in, decompressing on the fly table' <- decodeFile "/tmp/table.gz" draw "Read" table' -- now use 'floats' as a Ptr to pass back to C. where draw s v = printf "%s %d floats, and %d ints\n" s (fromIntegral (lengthFloats v) `div` sizeOf (undefined :: CFloat)) (fromIntegral (lengthInts v ) `div` sizeOf (undefined :: CInt)) lengthFloats = L.length . floats lengthInts = L.length . ints

1 1

Re: practicality of typeful programming
by oleg＠pobox.com 08 Jul '07

08 Jul '07

Daniil Elovkov wrote: > I've recently asked some questions here about some little type hackery > implementing an embedded dsl. But now I wonder if it's worth the > effort at all... Yes it is. Typed embedded DSL are quite useful and widely used. For example, Lava (high-level hardware description language) uses phantom types to prevent the designer from building meaningless circuits (e.g., connecting a Bool and an Int wires). http://citeseer.ist.psu.edu/69503.html There are other such hardware design languages which profitably use types (which ought to be popularized more). Using types can decrease the amount of error checking in the implementation. I highly recommend the following _very_ good thesis on this topic: Morten Rhiger Higher-Order Program Generation http://www.brics.dk/DS/01/4/index.html

3 7

Re: [Haskell-cafe] Gtk2Hs, Glade, Multiple windows/dialog in one interface file.
by D.V. 08 Jul '07

08 Jul '07

I finally got it to work with onResponse : I traced each possible response to see which one was fired when clicking the close button.... onResponse aboutdialog $ \resp -> do putStrLn "onResponse!!!" case resp of ResponseNone -> putStrLn "ResponseNone" ResponseReject -> putStrLn "ResponseReject" ResponseAccept -> putStrLn "ResponseAccept" ResponseDeleteEvent -> putStrLn "ResponseDeleteEvent" ResponseOk -> putStrLn "ResponseOk" ResponseCancel -> putStrLn "ResponseCancel" >> widgetHide aboutdialog ResponseClose -> putStrLn "ResponseClose" ResponseYes -> putStrLn "ResponseYes" ResponseNo -> putStrLn "ResponseNo" ResponseApply -> putStrLn "ResponseApply" ResponseHelp -> putStrLn "ResponseHelp" ResponseUser n -> putStrLn ("ResponseUser "++ show n)

1 0

Gtk2Hs, Glade, Multiple windows/dialog in one interface file.
by D.V. 08 Jul '07

08 Jul '07

Is it possible to have multiple windows in a glade file, and display only one when the program starts, then show/hide the others as the need arises ? I can't find how... I have a main window with a menu. One entry shows the about dialog which is also defined in the glade file : aboutmenu <- xmlGetWidget xml castToMenuItem "apropos1" onActivateLeaf aboutmenu $ do widgetShowAll aboutdialog My problems are multiple : 1) how do I handle the close button that is automatically generated ? I tried doing this ... aboutdialog <- xmlGetWidget xml castToAboutDialog "aboutdialog1" onDestroy aboutdialog $ do widgetHide aboutdialog But the Close button doesn't work, and if I close the about dialog by the upper right cross button, it does disappear, but if I select again the menuitem, then a tiny empty dialog opens, as if the about dialog has been stripped out of all his inner components. And I get this line : (<interactive>:10852): Gtk-CRITICAL **: gtk_container_foreach: assertion `GTK_IS_CONTAINER (container)' failed I tried looking at the demos, but it doesn't help. The closest that could have helped uses an about dialog it creates, instead of reading from a glade file.

2 5

A very nontrivial parser
by Andrew Coppin 08 Jul '07

08 Jul '07

Well, I eventually got it to work correctly... (!) My goal is to be able to stack multiple parsers one on top of the other - but be able to *change* the stack half way through parsing if needed. This I eventually succeeded in doing. The external interface is fairly simple, but the type signatures are NOT. (!!) My basic idea was to abstract the data source that a parser gets its data from: class Source s where empty :: s x -> Bool fetch :: s x -> (x, s x) instance Source [] where -- Nice syntax... :-S empty = null fetch xs = (head xs, tail xs) Now I can define a parser type. But... uh... there's a slight glitch. What I *want* to say is Parser state in out = ... But what I ended up with is newtype Parser state src x y = Parser ((state, src x) -> (state, src x, y)) I then make Parser a monad, write some functions to get/set the state parameter, and token_get :: (Source src) => Parser state src x x token_get = Parser (\(state, tokens) -> let (t,ts) = fetch tokens in (state, ts, t)) Anyway, all of that more or less works. Then I begin the utterly psychopathic stuff: data Stack state0 src0 t0 t1 = ... instance Source (Stack state0 src0 t0) where ... stacked :: st0 -> Parser st0 src0 t0 [t1] -> st1 -> Parser st1 (Stack st0 src0 t0) t1 x -> Parser st9 src0 t0 x By this point, my brain is in total agony! >_< But, almost unbelievably, all this psychotic code actually *works*... (Well, there were a few bugs, they're fixed now.) Essentially, I have the "stacked" function, where if I do x <- stacked foo parser1 bar parser2 y <- parser3 then it runs parser2, but it uses parser1 to transform the data first. Which is what I actually wanted in the first place... Most critically, when parser2 *stops* demanding tokens, parser3 is run, picking up from where parser1 left off. (Confused yet? Wait til you see the code to implement this insanity!) One problem remains... That pesky source type. Every time I mention a parser, I have to say what kind of course object it reads from - even though all parsers work with *any* source object! (That's the whole point of the Source class.) I really want to get rid of this. (See, for example, the type signature for "stacked". Yuck!) Also, every time I write a simple parser, I get a compile-time error saying something about a "monomorphism restriction" or something... If I add an explicit type it goes away, but it's very annoying to keep typing things like test7 :: (Source src) => Parser state src Int Int and so forth. And I can't help thinking if I could just get *rid* of that stupid source type in the signature, there wouldn't be a problem... Anybody have a solution to this?

21 89

Language semantics
by Andrew Coppin 08 Jul '07

08 Jul '07

I have a tricky little question... Suppose I write a function like this: foo pattern1 | gard1 = ... | gard2 = ... foo pattern2 | gard3 = ... | gard4 = ... According to one tutorial I read, if pattern1 matches, pattern2 will never be tried, even if both guard1 and guard2 fail. And according to another tutorial I read, if pattern1 matches but all guards fail, pattern2 *will* be tried. Can somebody comfirm which one is actually correct?

10 25