- Haskell-Cafe - Haskell.org

Array bug?
by Andrew Coppin 03 Nov '08

03 Nov '08

Consider the following GHCi session: GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m Data.Array.IO Prelude Data.Array.IO> t <- newArray ((0,0),(5,4)) 0 :: IO (IOUArray (Int,Int) Int) Loading package array-0.1.0.0 ... linking ... done. Prelude Data.Array.IO> getBounds t ((0,0),(5,4)) Prelude Data.Array.IO> writeArray t (10,10) 5 *** Exception: Error in array index Prelude Data.Array.IO> writeArray t (7,3) 5 *** Exception: Error in array index Prelude Data.Array.IO> writeArray t (3,7) 5 Prelude Data.Array.IO> So the array has 0 <= x <= 5 and 0 <= y <= 4, and writing to (10,10) or (7,3) throws an exception. However, writing to (3,7) triggers no exception - despite being clearly out of range. Judging by the behaviour of the large, complex program I was debugging when I stumbled upon this, the coordinates "wrap round" to the next column. (!!) Obviously, writing to non-existent coordinates and not getting an exception is a Very Bad Thing. I was counting on writeArray (and readArray) to detect out-of-range coordinates so I could fix my code. But as you can see, it doesn't actually work as advertised. You have *no idea* how long I spent trying to track this bug down! >_< Is this a known bug? Is it likely to be fixed any time soon? (I'm guessing the bug is as simple is converting indicies to integers and then checking the integers are in-range, rather than the underlying index type.)

9 14

Re: [Haskell] ANNOUNCE: RefSerialize-0.2.1
by Alberto G. Corona 03 Nov '08

03 Nov '08

I uploadad RefSerialize<http://hackage.haskell.org/cgi-bin/hackage-scripts/package/RefSerialize> to Hackage . Read, Show and Data.Binary do not check for repeated references to the same data address. As a result, the data is serialized multiple times when serialized. This is a waste of space in the filesystem and also a waste of serialization time. but the worst consequence is that, when the serialized data is read, it allocates multiple copies in memory for the same object referenced multiple times. Because multiple referenced data is very typical in a pure language such is Haskell, this means that the resulting data loose the beatiful economy of space and processing time that referential transparency permits. This package allows the serialization and deserialization of large data structures without duplication of data, with the result of optimized performance and memory usage. It is also useful for debugging purposes. There are automatic derived instances for instances of Read/Show, lists and strings. the deserializer contains a almos complete set of Parsec.Token parsers for deserialization. Every instance of Show/Read is also a instance of Data.RefSerialize The serialized string has the form "expr( var1, ...varn) where var1=value1,..valn=valueN " so that the string can ve EVALuated. See demo.hs and tutorial. I presumably will add a entry in haskell-web.blogspot.com To develop: -derived instances for Data.Binary -serialization to/from ByteStings I wrote this module because I needed to serialize lists of verisions of the same data with slight modifications between each version. This is a short tutorial (in tutorial.txt) runW applies showp, the serialization parser of the instance Int for the RefSerialize class Data.RefSerialize>let x= 5 :: Int Data.RefSerialize>runW $ showp x "5" every instance of Read and Show is an instance of RefSerialize. rshowp is derived from showp, it labels the serialized data with a variable name Data.RefSerialize>runW $ rshowp x " v8 where {v8= 5; }" Data.RefSerialize>runW $ rshowp [2::Int,3::Int] " v6 where {v6= [ v9, v10]; v9= 2; v10= 3; }" while showp does a normal show serialization Data.RefSerialize>runW $ showp [x,x] "[5, 5]" rshowp variables are serialized memory references: no piece of data that point to the same addrees is serialized but one time Data.RefSerialize>runW $ rshowp [x,x] " v9 where {v6= 5; v9= [ v6, v6]; }" This happens recursively Data.RefSerialize>let xs= [x,x] in str = runW $ rshowp [xs,xs] Data.RefSerialize>str " v8 where {v8= [ v10, v10]; v9= 5; v10= [ v9, v9]; }" the rshowp serialized data is read with rreadp. The showp serialized data is read by readp Data.RefSerialize>let xss= runR rreadp str :: [[Int]] Data.RefSerialize>print xss [[5,5],[5,5]] this is the deserialized data the deserialized data keep the references!! pointers are restored! That is the whole point! Data.RefSerialize>varName xss !! 0 == varName xss !! 1 True rShow= runW rshowp rRead= runR rreadp Data.RefSerialize>rShow x " v11 where {v11= 5; }" In the definition of a referencing parser non referencing parsers can be used and viceversa. Use a referencing parser when the piece of data is being referenced many times inside the serialized data. by default the referencing parser is constructed by: rshowp= insertVar showp rreadp= readVar readp but this can be redefined. See for example the instance of [] in RefSerialize.hs This is an example of a showp parser for a simple data structure. data S= S Int Int deriving ( Show, Eq) instance Serialize S where showp (S x y)= do xs <- rshowp x -- rshowp parsers can be inside showp parser ys <- rshowp y return $ "S "++xs++" "++ys readp = do symbol "S" -- I included a (almost) complete Parsec for deserialization x <- rreadp y <- rreadp return $ S x y there is a mix between referencing and no referencing parser here: Data.RefSerialize>putStrLn $ runW $ showp $ S x x S v23 v23 where {v23= 5; } (I corrected some errors in this file here)

2 2

Fwd: [Haskell-cafe] Re: [Haskell] ANNOUNCE: RefSerialize-0.2.1
by Alberto G. Corona 03 Nov '08

03 Nov '08

I forgot to cc to haskell-cafe: ---------- Forwarded message ---------- From: Alberto G. Corona <agocorona(a)gmail.com> Date: 2008/11/2 Subject: Re: [Haskell-cafe] Re: [Haskell] ANNOUNCE: RefSerialize-0.2.1 To: Bulat Ziganshin <Bulat.Ziganshin(a)gmail.com> * SerTH is a binary serialization library for Haskell. It supports serializing cyclic datatypes in a fast binary format. SerTH uses template haskell for deriving the serializing interface for new datatypes. *Too bad...I did not know it. Not even many people in the #haskell channel, where i discussed about how badly a functionality such that is needed. It restores the references when data is deserialized?. My package is text oriented and the serialization is readable and eval-uable, so can be used also for debugging purposes. I use System.Mem.StableName. for it. 2008/11/2 Bulat Ziganshin <bulat.ziganshin(a)gmail.com> Hello Alberto, > > Sunday, November 2, 2008, 5:02:10 PM, you wrote: > > Read, Show and Data.Binary do not check for repeated references to > > the same data address. > > afair, SerTH does it, using GHC's internal address compare function > > what way to check for copies you use? > > > -- > Best regards, > Bulat mailto:Bulat.Ziganshin@gmail.com > >

1 0

Cairo build fail on OS X Leapord
by Jefferson Heard 03 Nov '08

03 Nov '08

Installing gtk2hs from MacPorts on a clean mac: 2 -I/usr/X11R6/include svgcairo/Graphics/Rendering/Cairo/SVG.chs:201:2: Couldn't match expected type `()' against inferred type `CInt' Expected type: Render () Inferred type: Render CInt In the expression: liftIO $ (\ (SVG arg1) (Cairo arg2) -> withForeignPtr arg1 $ \ argPtr1 -> rsvg_handle_render_cairo argPtr1 arg2) svg cr In the expression: do cr <- ask liftIO $ (\ (SVG arg1) (Cairo arg2) -> withForeignPtr arg1 $ \ argPtr1 -> rsvg_handle_render_cairo argPtr1 arg2) svg cr make[1]: *** [svgcairo/Graphics/Rendering/Cairo/SVG.o] Error 1 rm svgcairo/Graphics/Rendering/Cairo/SVG.hs make: *** [all] Error 2 Error: Status 1 encountered during processing. -- I try to take things like a crow; war and chaos don't always ruin a picnic, they just mean you have to be careful what you swallow. -- Jessica Edwards

2 3

Arch Haskell News: Nov 02 2008
by Don Stewart 03 Nov '08

03 Nov '08

News about the Haskell packages for Arch Linux. Highlights, * 672 Haskell packages now supported in Arch Linux, up 33 from two weeks ago. Noteworthy, * haskell-tcache-0.5.3: “A Transactional data cache with configurable persistence” * haskell-yampa-0.9.2.3: “Library for programming hybrid systems.” * haskell-network-bytestring-0.1.1.3: “Fast and memory efficient low-level networking” * haskell-checkers-0.1.1: “Check properties on standard classes and data structures.” * haskell-coreerlang-0.0.1: “Facilities for manipulating Core Erlang source code: an abstract syntax, parser and pretty-printer.” Full update list, http://archhaskell.wordpress.com/2008/11/03/arch-haskell-news-nov-02-2008/ -- Don How's your favourite distro doing? If its not up to scratch, talk to someone.

1 0

Re: [Haskell-cafe] ANNOUNCE: Graphalyze-0.5 and SourceGraph-0.3
by Ivan Lazar Miljenovic 03 Nov '08

03 Nov '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 2 Nov 2008 22:43:27 -0500 "Gwern Branwen" <gwern0(a)gmail.com> wrote: > Darn! I was really hoping to analyze my XMonadContrib modules which use > CPP. :( > > Come now, is it really so intractable? Why not try a dumb, but simple > and understandable approach - like dropping everything inside CPP > sections, and analysing the remainder? If it's clearly stated in the > docs, I don't think any user could really blame you. If they insist, > you could always add a flag like --strict-cpp ('So you prefer no > results to somewhat wrong results? FINE.') The main reason I haven't is due to lack of time... as it was, these last few fix-ups were only done last-minute whilst I was waiting for my supervisor to read through my draft (and mainly fixed what I perceived as _real_ bugs, not just adding functionality). Though, to be honest I didn't think about performing sanitizing in that fashion... Of course, if you really want that functionality you can add it ;-) - -- Ivan Lazar Miljenovic Ivan.Miljenovic(a)gmail.com IvanMiljenovic.wordpress.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkkOdBkACgkQfEfFJ9JhvyhjYgCggEcRquF+BmZSCkVpxt3dY1sT pI4AnjV5em0zVrTxHQtdf2J6ibOZ121d =qd3I -----END PGP SIGNATURE-----

1 0

ANNOUNCE: zlib and bzlib 0.5 releases
by Duncan Coutts 02 Nov '08

02 Nov '08

I'm pleased to announce updates to the zlib and bzlib packages. The releases are on Hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/zlib http://hackage.haskell.org/cgi-bin/hackage-scripts/package/bzlib What's new ========== What's new in these releases is that the extended API is slightly nicer. The simple API that most packages use is unchanged. In particular, these functions have different types: compressWith :: CompressParams -> ByteString -> ByteString decompressWith :: DecompressParams -> ByteString -> ByteString The CompressParams and DecompressParams types are records of compression/decompression parameters. The functions are used like so: compressWith defaultCompressParams { ... } decompressWith defaultDecompressParams { ... } There is also a new parameter to control the size of the first output buffer. This lets applications save memory when they happen to have a good estimate of the output size (some apps like darcs know this exactly). By getting a good estimate and (de)compressing into a single-chunk lazy bytestring this lets apps convert to a strict bytestring with no extra copying cost. Future directions ================= The simple API is very unlikely to change. The current error handling for decompression is not ideal. It just throws exceptions for failures like bad format or unexpected end of stream. This is a tricky area because error streaming behaviour does not mix easily with error handling. On option which I use in the iconv library is to have a data type describe the real error conditions, something like: data DataStream = Chunk Strict.ByteString Checksum DataStream | Error Error -- for some suitable error type | End Checksum With suitable fold functions and functions to convert to a lazy ByteString. Then people who care about error handling and streaming behaviour can use that type directly. For example it should be trivial to convert to an iterator style. People have also asked for a continuation style api to give more control over dynamic behaviour like flushing the compression state (eg in a http server). Unfortunately this does not look easy. The zlib state is mutable and while this can be hidden in a lazy list, it cannot be hidden if we provide access to intermediate continuations. That is because those continuations can be re-run whereas a lazy list evaluates each element at most once (and with suitable internal locking this is even true for SMP). Background ========== The zlib and bzlib packages provide functions for compression and decompression in the gzip, zlib and bzip2 formats. Both provide pure functions on streams of data represented by lazy ByteStrings: compress, decompress :: ByteString -> ByteString This makes it easy to use either in memory or with disk or network IO. For example a simple gzip compression program is just: > import qualified Data.ByteString.Lazy as ByteString > import qualified Codec.Compression.GZip as GZip > > main = ByteString.interact GZip.compress Or you could lazily read in and decompress .gz file using: > content <- GZip.decompress <$> ByteString.readFile file General ======= Both packages are bindings to the corresponding C libs, so they depend on those external C libraries (except on Windows where we build a bundled copy of the C lib source code). The compression speed is as you would expect since it's the C lib that is doing all the work. The zlib package is used in cabal-install to work with .tar.gz files. So it has actually been tested on Windows. It works with all versions of ghc since 6.4 (though it requires Cabal-1.2). The darcs repos for the development versions live on code.haskell.org. I'm very happy to get feedback on the API, the documentation or of course any bug reports. Duncan

3 3

Poll: Do you need to be able to build darcs from source on GHC 6.6?
by Jason Dagit 02 Nov '08

02 Nov '08

Hello, I would like to find out if any darcs users who build from the source are still using ghc 6.6? If you are such a user, please let me know. Thanks, Jason

11 25

Re: [Haskell-cafe] number of references to a variable
by wren ng thornton 02 Nov '08

02 Nov '08

Alberto G. Corona wrote: > * "Certainly a worthy research goal, but probably not what you had in mind > :)" > > *Not at all, My interest on that was on to improve RefSerialize. Although > the Clean people has done a superb job on optimization. By the way, I'm not > sure if uniqueness is the cause of his performance. I tested Haskell code > generated using Maybe with and without monad instance and the monad does not > impose any overhead at all. Oh, I wasn't saying that monads impose any overhead. Rather, the Clean folks aren't fans of monads and so they use uniqueness typing in order to provide the same kind of solution to IO while retaining functional purity. GHC's implementation of IO is actually very similar under the hood to what Clean does, though that's not necessarily true of other monads. Even though they seem to intersect at IO, the ideas of monads and linear logics are orthogonal. The big optimization trick with linear logic is, since you know when some object is uniquely referenced, you know when it's safe to destructively update it in situ. For example, you can reverse a spine-unique list in linear time with zero space (modulo registers) by just inverting the spine pointers as you traverse it. Since it's uniquely referenced, noone else will notice so referential transparency is preserved. Doing it this way saves on allocation costs and on garbage collection. There are certainly other ways to use the information that some object is held only by a single reference, but Clean's optimizations are the first that leap to my mind. -- Live well, ~wren

1 0

is there a way to pretty print a module?
by Anatoly Yakovenko 02 Nov '08

02 Nov '08

is there a way to pretty print a module? like: module Main where import Language.Haskell.TH main = do print $ pprint Main

6 8