March 2011 - Haskell-Cafe

Hexpat: Lazy I/O problem with huge input files
by Aleksandar Dimitrov 10 Dec '11

10 Dec '11

Hello Haskell Cafe, I really hope this is the right list for this sort of question. I've bugged the folks in #haskell, they say go here, so I'm turning to you. I want to use Hexpat to read in some humongous XML files (linguistic corpora,) since it's the only Haskell XML library (I could find) that takes ByteStrings as input. I stumbled on a problem when using one of the examples from the docs of Text.XML.Expat.Tree. The "cookbook recipe" there suggests *first* processing the data, and only then looking into the parser error to see if there has been an error. I understand this should prevent the parse tree from being fully evaluated before use. Unfortunately, that is not what happens on my system (ghc 6.12.1, if that's of importance.) This is the code from the docs, that I modified to read files: > import Text.XML.Expat.Tree > import System.Environment (getArgs) > import Control.Monad (liftM) > import qualified Data.ByteString.Lazy as C >· > -- This is the recommended way to handle errors in lazy parses > main = do > f <- liftM head getArgs >>= C.readFile > let (tree, mError) = parse defaultParseOptions f > print (tree :: UNode String) >· > -- Note: We check the error _after_ we have finished our processing > -- on the tree. > case mError of > Just err -> putStrLn $ "It failed : "++show err > Nothing -> putStrLn "Success!" Given a 42M test file, an invocation like this: % ghc --make -O2 Hexpat.hs % ./Hexpat input.xml > dump.xml will gobble up some 2Gigs of RAM (at least. I usually kill it before it starts thrashing the swap space, since that almost crashes my entire machine.) If I remove the last 3 lines: > import Text.XML.Expat.Tree > import System.Environment (getArgs) > import Control.Monad (liftM) > import qualified Data.ByteString.Lazy as C > > main = do > f <- liftM head getArgs >>= C.readFile > let (tree, mError) = parse defaultParseOptions f > print (tree :: UNode String) the same invocation and input file barely uses a megabyte or two of RAM and finishes really quickly. Why is that? Is this a mistake in the Hexpat docs, or am I doing something wrong? Lazy IO has always been a little bit of a mystery to me, and just when I thought I had it... Thanks for any help on the matter! Aleks

3 3

Parsing Haskell in Parsec
by Alex Rozenshteyn 16 Jun '11

16 Jun '11

I'm trying to write a parser for a small functional language in Parsec, as part of a larger project of porting this<http://www.cs.jhu.edu/%7Escott/pl/book/dist/>from ocaml to Haskell. I was wondering if there was a parser for Haskell written in Parsec that I could use as a reference. -- Alex R

4 5

Re: [Haskell-cafe] Re: Functional dependencies and Peano numbers (and hoogle-bug?)
by Oscar Finnsson 03 May '11

03 May '11

Thanks for the great feedback. The bijective example was especially interesting. While reading "Fun with Type Functions" I notices GNum as an interesting alternative to the Num type class but I couldn't find any such package on hackagedb. Do anyone know if there is anything like GNum on hackagedb? On an unrelated note: I hoogled "to" (i.e. http://haskell.org/hoogle/?hoogle=to) and just got a blank page. Nothing. Nil (not even <html>...</html>). Is this a bug or a "feature"? :) The reason I hoogled it was because I'm searching for something like explicit casting found in many other languages, something similar to > class To f t where > to :: f -> t > > instance To a a where > to x = x > > instance (Real a, Fractional b) => To a b where > to = realToFrac > > instance (Read a) => To String (Maybe a) where > to = maybeRead -- not from cgi :) so I can write something like > ("23.2" `to`) :: Maybe Double or > ((42 :: Integer) `to`) :: Float Anyone made a module/package that solves this problem already? I cannot be the first that needs generic type safe conversion... . -- Oscar

3 2

Trouble installing FileManipCompat
by Tony Miller 28 Apr '11

28 Apr '11

Hi, I'm trying to install FileManipCompat(well, really HStringTemplateHelpers, but the error is from FileManipCompat) and I'm getting this error: [1 of 1] Compiling System.FilePath.FindCompat ( System/FilePath/FindCompat.hs, dist/build/System/FilePath/FindCompat.o ) System/FilePath/FindCompat.hs:175:20: Not in scope: data constructor `State' I've attached the complete output of `cabal --verbose install HStringTemplateHelpers`.

3 4

how to optmize this code?
by Gilberto Garcia 11 Apr '11

11 Apr '11

Hi Haskellers, I was solving this problem from project euler to study haskell. I came up whit the following solution and I was wondering if there is a more optimized and concise solution. fkSum :: Int -> [Int] -> Int fkSum a [] = 0 fkSum a (b) = foldl (+) 0 (filter (\x -> isMultiple x b) [1..a]) isMultiple :: Int -> [Int] -> Bool isMultiple a [] = False isMultiple a (x:xs) = if (mod a x == 0) then True else isMultiple a xs Thanks in advance ggarcia

8 12

DSL for task dependencies
by Serge Le Huitouze 07 Apr '11

07 Apr '11

Hi Haskellers! I think I remember reading a blog post or web page describing a EDSL to describe tasks and their dependencies "a la" make. Can anyone point me to such published material? Thanks in advance. --serge

8 7

ANN: Google Summer of Code student application period opens today
by Johan Tibell 05 Apr '11

05 Apr '11

Hi, The Google Summer of Code student application period starts today at 19:00 UTC. If you're a student and like to get paid to work on a Haskell project this summer I recommend you go find an interesting project [1] and start working on your application. You can find more information on the wiki [2]. Cheers, Johan 1. http://hackage.haskell.org/trac/summer-of-code/report/1 2. http://hackage.haskell.org/trac/summer-of-code/wiki/Soc2011

4 5

why is ghci trying to load hsc file ??
by briand＠aracnet.com 04 Apr '11

04 Apr '11

Howdy, I worked out a small hdf5 binding using cabal and bindings-DSL and sqlite3 as my example. Time to try it ! ghci -idist/build/ dist/build/Bindings/HDF5.o -lhdf5 -lhdf5_hl hdf5_pkg_test.hs GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static) dist/build/Bindings/HDF5.o ... done Loading object (dynamic) hdf5 ... done Loading object (dynamic) hdf5_hl ... done final link ... done [1 of 2] Compiling Bindings.HDF5 ( dist/build/Bindings/HDF5.hs, interpreted ) src/Bindings/HDF5.hsc:49:8: parse error on input `import' Failed, modules loaded: none. Huh ? Why is it trying to read HDF5.hsc ?? What's even more interesting is that line 49 of that file doesn't have an import on it, so something is fubar. No idea how this could be happening. I've included a copy of my cabal file. BTW. I have to specify the hdf5 libraries, i.e. libhdf5 and libhdf5_hl on the command line. It seems like the build process should have taken care of that in some way, maybe... ? Certainly when I use something like sqlite3, I'm not specifying libsqlite3 on the command line. Thanks, Brian

7 11

Unboxing CFloat and GLfloat
by Jason Dagit 03 Apr '11

03 Apr '11

First a bit of background. Sometimes I would like to be able to create unboxed arrays of CFloats and GLfloats. Both of these are defined as newtypes around types that can be unboxed (e.g., Float). I'm assuming GHC here. As far as I can tell, the newtyping is there to help programmers pick a representation that matches the C compiler's representation on their platform without having to use CPP in their Haskell code. Would it be possible to add instances like these? instance MArray (STUArray s) GLfloat (ST s) instance MArray IOUArray GLfloat IO instance MArray (STUArray s) CFloat (ST s) instance MArray IOUArray CFloat IO I would also want instances for the other C types that map to Haskell types that are unboxed and the other GL types too. For example, in my program I imported all the right libraries and added this instance as an experiment: instance MArray (STUArray s) GLfloat (ST s) where {-# INLINE getBounds #-} getBounds (STUArray l u _ _) = return (l,u) {-# INLINE getNumElements #-} getNumElements (STUArray _ _ n _) = return n {-# INLINE unsafeNewArray_ #-} unsafeNewArray_ (l,u) = unsafeNewArraySTUArray_ (l,u) fLOAT_SCALE {-# INLINE newArray_ #-} newArray_ arrBounds = newArray arrBounds 0 {-# INLINE unsafeRead #-} unsafeRead (STUArray _ _ _ marr#) (I# i#) = ST $ \s1# -> case readFloatArray# marr# i# s1# of { (# s2#, e# #) -> (# s2#, unsafeCoerce (F# e#) #) } {-# INLINE unsafeWrite #-} unsafeWrite (STUArray _ _ _ marr#) (I# i#) e = ST $ \s1# -> let F# e# = unsafeCoerce e in case writeFloatArray# marr# i# e# s1# of { s2# -> (# s2#, () #) } I had to use an unsafeCoerce because the constructor for GLfloat is not exposed, and realToFrac has terrible performance because the following rules (suggested by Andy Gill) are missing from the OpenGL bindings: {-# RULES "realToFrac/a->GLfloat" realToFrac = \x -> GLfloat (realToFrac x) #-} {-# RULES "realToFrac/GLfloat->a" realToFrac = \(GLfloat x) -> realToFrac x #-} Even if I had those rules, I would still need to get access to the underlying representation (the e#) to have the right kind. GLfloat is defined in terms of CFloat which is defined in terms of other things. On my machine, CFloat happens to correspond to Float, although in general this need not be the case. So to do this instance correctly I would need to know, in general, what the underlying type is for CFloat. I think that means I would need to use the same macros as GHC, although I don't think that requires this instance to appear in base. I could just borrow the macros once I figure out the corresponding instance for CFloat. While the GLfloat instances don't need to be in base, the CFloat instance probably should be in base. Is this something I should make a library proposal for and submit patches? Is there an easier way to get these instances? Has someone already done this? Thanks, Jason

2 1

pool, persistent, persistent-sqlite: Space leak
by Ertugrul Soeylemez 02 Apr '11

02 Apr '11

Hello Michael, hello fellow Haskellers, there seems to be a space leak in either 'pool', 'persistent' or 'persistent-sqlite'. From the behaviour I suspect the bug to be in 'pool'. When I run a transaction in an infinite loop, my program keeps eating more and more memory, even if the transaction itself doesn't do anything: forever $ runSqlPool (return ()) pool This doesn't happen for non-pooled connections, i.e. the following code runs in constant space as expected: forever $ runSqlConn (return ()) conn Versions are pool-0.0.1, persistent-0.4.2, persistent-sqlite-0.4.0. It happens for both file and in-memory databases. Greets, Ertugrul -- nightmare = unsafePerformIO (getWrongWife >>= sex) http://ertes.de/

2 2