ANNOUNCE: zlib and bzlib 0.4 releases

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 in these releases is that the packages work with a wider range of systems and versions of dependent packages. In particular: * Works "out of the box" on Windows It uses a bundled copy of the zlib C library (version 1.2.3) on Windows and uses the system zlib on all other platforms. * Works with ghc-6.4, 6.6, 6.8 * Works with new bytestring versions * Works with older versions of zlib (eg zlib 1.1 on MacOS X) They require Cabal-1.2.1 (which is also available on hackage and works with all ghc versions). The zlib and bzlib packages provide functions for compression and decompression in the gzip 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 <- fmap GZip.decompress (ByteString.readFile file)
Both packages are bindings to the corresponding C libs, so they depend on those C libraries. Fortunately both zlib and bzlib2 are available on every OS. It also means that the compression speed is as you would expect since it's the C lib that is doing all the work. The zlib package is now being used in cabal-install to work with .tar.gz files. So it has actually been tested on Windows. The development versions have new homes on code.haskell.org. I'm very happy to get feedback on the API, the documentation or of course any bug reports. Duncan

On Tue, 2007-10-23 at 16:34 +0200, Yitzchak Gale wrote:
Duncan Coutts wrote:
I'm very happy to get feedback on the API, the documentation or of course any bug reports.
It would be nice if the API could be the same for all character and data codecs.
Hmm, though the inputs and outputs are different types in general. With compression we're working with uninterpreted streams of bytes. For character encoding/decoding we're converting between internal Unicode representations and external representations as sequences of bytes. That is, (de)compression does not fit into encode :: [Word8] -> String decode :: String -> [Word8] If we parametrise over the input and output types we get something far too general. Also, from my point of view there's nothing wrong with giving (de)compression a different function name from character encoding. In my opinion it is easier to read: content <- return . decode . decompress =<< readFile file than content <- return . decode . decode =<< readFile file Where I mean to read a compressed unicode text file. Names are good! :-) Am I missing something or just being curmudgeonly? :-) Duncan
participants (2)
-
Duncan Coutts
-
Yitzchak Gale