September 2007 - Libraries

Re: patch applied (packages/regex-base): Make setup script compileagain after recent Cabal changes
by Claus Reinke 10 Sep '07

10 Sep '07

[subject taken from cvs-libraries@; discussion directed to libraries@] does anyone else feel that there is something wrong in haskell library land? i'm picking on cabal here as one of "the usual suspects", but it seems to have become the rule that otherwise stable code has to be fixed every so often, to accomodate new compiler versions, new library dependency versions, new cabal versions, new xyz versions,.. it is almost as if everything feels free these days to evolve in non- backwards-compatible ways, following the motto "what do i care for my apis of yesterday?". with the ongoing trend towards separately evolving libraries rather than prepackaged kitchen-sink releases, this means that useful libraries die quickly, and have to be revived continuously, or they will be left behind. one symptom is "get the latest from hackage" replacing useful extra libraries kept in sync with each other (never mind that the hackage versions are no more likely to work without fixes than the in-repository versions). it is often small things ("that function/option has been renamed", "you now need to import x instead of y", "you can work around this by using 2 cabal files, then removing one depending on context", etc.), but as all dependencies keep eroding in this way, haskell projects are now built on sand rather than firm foundations, requiring constant attention just to avoid falling behind - attention that would better be focussed on development than maintenance. just a thought, claus ps. perhaps i've misunderstood, and there is in fact a haskell cabal trying to introduce as many version incompatibilities as possible, to ensure a market demand for cabal.. ?-)

11 36

Patch with new API for get/setsockopt
by Matthew Danish 09 Sep '07

09 Sep '07

Hi, Russell O'Connor pointed out the other day that it is impossible to use the getSocketOption/setSocketOption functions on options which expect or provide a non-Int value. I've concocted another API which allows values to be constructed from a specific disjoint union. This should make it possible to use options like SendTimeOut which expect a struct timeval. The attached darcs patch to the network package has the new functions setSockOpt/getSockOpt and SocketOptionValue. Whether or not those will be the final names, I am not sure. Also, I thought of some better possible interfaces, but on Ian's suggestion I stuck to Haskell'98 capabilities only. I've tested it on Linux/x86-64 and run the validate script. I'm new to GHC development, though, so I'm not sure if I should just go ahead and submit the patch. -- -- Matthew Danish -- user: mrd domain: cmu.edu -- OpenPGP public key: C24B6010 on keyring.debian.org

3 4

Re: ANNOUNCE: Cabal 1.2.0 released
by Thomas Schilling 09 Sep '07

09 Sep '07

On Thu, 2007-09-06 at 21:00 +0400, Bulat Ziganshin wrote: > Hello Thomas, > > Thursday, September 6, 2007, 8:35:19 PM, you wrote: > > We are pleased to announce that Cabal version 1.2.0 is now available. > > i suggest you to forward announce into main haskell maillist too > > major release of such important library is definitely news interesting > for many haskellers Well, I think I should have been a little clearer about the status of this release. Let me clarify. Earlier releases were preceded by release candidates before the .0 release. However, we changed it this time so that .0 basically is the release candidate and .1 will then be the first stable release. Therefore, we decided to post only to the developer mailing lists, so that the first release to the wider public (1.2.1) will, hopefully, have most issues resolved. / Thomas

3 3

darcs patch: Use CSockLen when appropriate (and 2 more)
by Lennart Kolmodin 08 Sep '07

08 Sep '07

Wed Sep 5 22:30:41 CEST 2007 Lennart Kolmodin <kolmodin(a)dtek.chalmers.se> * Use CSockLen when appropriate Thu Sep 6 06:21:13 CEST 2007 Lennart Kolmodin <kolmodin(a)dtek.chalmers.se> * alloca and poke is a 'with' Sat Sep 8 12:02:17 CEST 2007 Lennart Kolmodin <kolmodin(a)dtek.chalmers.se> * Fix abstract unix sockets Using abstract unix sockets is a bit different than regular unix sockets. Abstract unix sockets are identified with that the path starts with a zero and doesn't have the trailing zero. Thus, this patch contains the following changes: 1) Correctly count the bytes used in a unix socket address. 2) Make peekSockAddr aware the socked address length. The old implementation relied on a zero terminated path, which abstract unix sockets are not. 3) Update other functions to respect address length. 4) A bit of cleanup and use of CSockLen instead of CInt.

1 1

Proposal: Test.HUnit documentation (#1632)
by Leif Frenzel 07 Sep '07

07 Sep '07

Hi everybody, I have recently written a tutorial for using HUnit and noticed that there was no Haddock library documentation yet, so I thought I might contribute some :-) As described on http://haskell.org/haskellwiki/Library_submissions I have created a trac ticket (#1632). Please let me know if anything else needs to be done to make this fit for the library :-) Thanks && ciao, Leif

2 3

ByteString I/O Performance
by Peter Simons 07 Sep '07

07 Sep '07

> import System.IO > import Foreign ( allocaBytes ) > import qualified Data.ByteString as Str > bufsize :: Int > bufsize = 4 * 1024 In order to determine I/O performance, a random 512 MB file is copied from standard input to standard output. All test programs have been compiled with GHC 6.6.1 using "-O2 -funbox-strict-fields" for optimization. The time to beat for this test comes from /bin/cat: $ dd if=/dev/urandom of=test.data bs=1M count=512 $ time /bin/cat <test.data >/dev/null real 0m2.097s 0m2.135s 0m2.100s user 0m0.036s 0m0.028s 0m0.024s sys 0m2.060s 0m2.108s 0m2.076s The first entry is implemented using static buffer I/O: > catBuf :: Handle -> Handle -> IO () > catBuf hIn hOut = allocaBytes bufsize input > where > input ptr = hGetBuf hIn ptr bufsize >>= output ptr > output _ 0 = return () > output ptr n = hPutBuf hOut ptr n >> input ptr real 0m2.747s 0m2.737s 0m2.758s user 0m0.524s 0m0.416s 0m0.632s sys 0m2.224s 0m2.304s 0m2.124s The second entry is implemented with ByteString: > catString :: Handle -> Handle -> IO () > catString hIn hOut = Str.hGet hIn bufsize >>= loop > where > loop buf | Str.null buf = return () > | otherwise = Str.hPut hOut buf >> catString hIn hOut real 0m7.852s 0m7.817s 0m7.887s user 0m4.764s 0m4.800s 0m4.748s sys 0m3.080s 0m3.000s 0m3.108s When Data.ByteString.Char8 is used instead, the program produces almost identical results. Data.ByteString.Lazy, however, came out differently: real 0m8.184s 0m8.086s 0m8.067s user 0m5.104s 0m5.252s 0m4.948s sys 0m2.940s 0m2.808s 0m3.120s ByteString turns out to be more than two times slower than ordinary buffer I/O. This result comes as a surprise because ByteString _is_ an ordinary memory buffer, so it feels reasonable to expected it to perform about the same. The reason why ByteString cannot compete with hGetBuf appears to be Data.ByteString.Base.createAndTrim. That function allocates space with malloc(), reads data into that buffer, allocates a new buffer, and then copies the data it has just read from the old buffer into the new one before returning it. This approach is quite inefficient for reading large amounts of data. It is particularly odd that Data.ByteString.readFile relies on the same mechanism. The required buffer size is known in advance. There is no point in reading data into a temporary buffer. I may have misread the implementation, but my impression is that readFile currently requires 2*n bytes of memory to read a file of size n. It feels like there is plenty of room for optimization. :-) > main :: IO () > main = do > mapM_ (\h -> hSetBuffering h NoBuffering) [ stdin, stdout ] > catString stdin stdout

13 32

ANNOUNCE: Cabal 1.2.0 released
by Thomas Schilling 06 Sep '07

06 Sep '07

The Haskell Cabal The Common Architecture for Building Applications and Libraries. <http://www.haskell.org/cabal> We are pleased to announce that Cabal version 1.2.0 is now available. Changes: The major new feature in this release is support for Cabal configurations. This allows package authors to more easily adopt their package descriptions to different system parameters such as operating system, architecture, or compiler. In addition, some optional features may be enabled or disabled explicitly by the package user. Many other new features and tool support has been added, among others: - Support for hscolour (haddock links to coloured source code). - Support for pkg-config (allows specifying dependencies on many C libraries). - Specification of build-tool dependencies. - Better default installation paths on Windows. - Seperate "includes" and "install-includes" fields - Install paths can be specified relative to each other. - Many more new small features, command line flags and bugfixes. For a more exhaustive list, see http://www.haskell.org/cabal/release/rc/changelog Please note that this is a .0 release, so we would appreciate any feedback or bug reports. Note also, that the hooks API changed, so it's quite likely that many non-trivial Setup.[l]hs files will break. We hope, however, that much of those files' functionality can now be expressed using configurations. This version (or a bug fix update) will be included in GHC version 6.8.1. For other Haskell implementations or older versions of GHC you can install it separately: Download: http://www.haskell.org/cabal/download.html http://haskell.org/cabal/release/rc/cabal-1.2.0.tar.gz Documentation: http://www.haskell.org/cabal/release/rc/doc/users-guide/ http://www.haskell.org/cabal/release/rc/doc/API/Cabal See both the README file and the changelog for interface changes: http://www.haskell.org/cabal/release/rc/changelog Bugs: Report bugs using our bug tracker: http://hackage.haskell.org/trac/hackage/newticket or at the libraries(a)haskell.org (please CC to cabal-devel(a)haskell.org) mailing list (note that this is subscriber only).

5 5

darcs patch: Link against GNUreadline.framework, if it's available.
by Judah Jacobson 06 Sep '07

06 Sep '07

I noticed that the HEAD readline package wasn't linking against the GNUreadline framework (as distributed for Mac OS X on the ghc-6.6.1 downloads page). The following patch fixes that. I've tested it on OS X (both with and without the framework), but someone should probably double-check that it works fine on non-Mac systems. Also note that for this to work correctly, it requires a bugfix that I just sent to cvs-ghc: http://permalink.gmane.org/gmane.comp.lang.haskell.cvs.ghc/23055 Thank, -Judah * Link against GNUreadline.framework, if it's available. This can be overridden by setting --with-readline-includes or --with-readline-libraries. M ./HsReadline_cbits.c -2 +1 M ./configure.ac -20 +39 M ./include/HsReadline.h -1 +7 M ./readline.buildinfo.in +1

3 2

Request for code review - Knuth Morris Pratt for Data.Sequence
by Justin Bailey 04 Sep '07

04 Sep '07

Using the code developed for ByteStrings by myself, Christ Kuklewicz and Daniel Fischer, I've implemented Knuth-Morris-Pratt substring searching on Data.Sequence "Seq" values. Attached you'll find the library in kmp.zip.safe. The algorithm is implemented in the module Data.Sequence.KMP. At the root, SpeedTest.hs can be compiled on Windows with the "prof_compile.bat" file included (you'll need to install the "regex-dfa" and "regex-base" packages from Hackage to build). SpeedTest searches for a known value in the 7 MB file "endo.dna" (which can be downloaded from http://www.icfpcontest.org/endo.zip) using several different algorithms and methods: strict and lazy bytestrings, regular expressions, and the KMP algorithm for "Seq" values. SpeedTest is pretty fast but I worry about its space usage. It may just be the nature of Seq values, but I cannot get it to run in constant space when I think it should be. I'm especially interested in help here. All comments and feedback are welcome. Since the zip file includes a darcs context file, feel free to send patches. Justin

1 0

Adding IdentityT to mtl
by dons＠cse.unsw.edu.au 03 Sep '07

03 Sep '07

I wanted an IdentityT today, for extending xmonad. (The idea is to allower user-defined monad transformers, so users can plug in their own semantics easily). By default it would use IdentityT, which I note is not in mtl! Here's roughly what it would be: ----------------------------------------------------------------------------- -- | -- Module : Identity.hs -- License : BSD3-style (see LICENSE) -- module IdentityT where import Control.Monad.Trans -- -- IdentityT , a parameterisable identity monad, with an inner monad -- The user's default monad transformer -- newtype IdentityT m a = IdentityT { runIdentityT :: m a } instance (Functor m, Monad m) => Functor (IdentityT m) where fmap f = IdentityT . fmap f . runIdentityT instance (Monad m) => Monad (IdentityT m) where return = IdentityT . return m >>= k = IdentityT $ runIdentityT . k =<< runIdentityT m fail msg = IdentityT $ fail msg instance (MonadIO m) => MonadIO (IdentityT m) where liftIO = IdentityT . liftIO Any reasons why this shouldn't be in mtl? -- Don

3 5