August 2010 - Haskell-Cafe

Maintainer wanted for pappy
by Christopher Done 19 Aug '10

19 Aug '10

Hi, I thought I'd go through my uploaded Hackage packages and decide which ones I am going to maintain, which are worth others maintaining, and which are probably not worth maintaining (spoiler, most aren't). 1. Interested in and will continue maintaining: gd, higherorder, cgi-utils, fastcgi, ircbouncer For gd, cgi-utils, fastcgi, ircbouncer I'd like to write test cases and do some profiling and general proper quality assurance. For the rest... 2. Not really interested in maintaining, but in a good state and probably worth maintaining: pappy (Bryan Ford gave me permission to upload and for someone to maintain this) 3. Not interested in maintaining, but in a good state, not worth maintaining: kibro, blogination, simplesmtpclient (this has been usurped by http://hackage.haskell.org/package/hsmtpclient (same author)) 4. Not interested in maintaining, in a bad state (i.e. build failure): validate, lojban, goa, wordcloud The build failure ones and ones not worth maintaining are probably best being taken out back. What do we do with packages we're not interested in maintaining anymore? Gracenotes recommended something like changing the category to Unmaintained (and on Hackage 2.0, a tag). Good idea for now? Chars!

4 5

Re: [Haskell-cafe] ANNOUNCE: enumerator, an alternative iteratee package
by John Lato 19 Aug '10

19 Aug '10

Congratulations on this release. I notice that enumerator doesn't use any extensions, and thus should be easier to use with jhc and other Haskell compilers. This is something I would have liked to support with iteratee, but couldn't due to conflicting design goals. I'd also like to point out that the Tiff and Wave modules of iteratee are primarily meant as examples. The Wave module at least is far too slow to actually use for anything. John > From: John Millikin <jmillikin(a)gmail.com> > > Most of you have probably read Oleg's essays on using left-fold > enumerators for incremental IO. In short, by encapsulating monadic > left-folds in an "Iteratee" type, incremental pure processing is > possible without using lazy IO. Sources to read: > > Oleg: Streams and Iteratees < http://okmij.org/ftp/Streams.html > > Magnus Therning: Trying to work out iteratees < > http://therning.org/magnus/archives/735 > > cdsmith: Iteratees Step By Step (Part 1) < > http://cdsmith.wordpress.com/2010/05/23/iteratees-step-by-step-part-1/ > > > John Millikin (me): Understanding Iteratees < > http://ianen.org/articles/understanding-iteratees/ > > > Currently, the primary package for left-fold enumerators is John > Lato's "iteratee". It is based on Oleg's original code, extended to > support various forms of containers, platform-specific IO, and codecs > for the WAV and TIFF formats. > > While I appreciate Mr. Lato's development of the package, I find it > far too large, and its documentation too sparse, to effectively use. > To correct this, I've written the "enumerator" package. It is also > derived from Oleg's IterateeM.hs , but with a simplified API and > significantly reduced dependency list. > > Hackage entry: http://hackage.haskell.org/package/enumerator > Haddock docs: http://ianen.org/haskell/enumerator/api-docs/ > Source code (literate PDF): > http://ianen.org/haskell/enumerator/enumerator.pdf > > darcs get http://ianen.org/haskell/enumerator/ > > Additionally, I've included examples of using enumerators to implement > simplified versions of the "cat" and "wc" utilities. These should > serve as a useful starting point for anybody who wants to use > enumerators in their own code: > > > http://patch-tag.com/r/jmillikin/enumerator/snapshot/current/content/pretty… > > http://patch-tag.com/r/jmillikin/enumerator/snapshot/current/content/pretty… > > There are already a few libraries using the existing "iteratee" > package (snap, attoparsec-iteratee, hexpat-iteratee); I am very > interested in advice from the authors of these libraries. In > particular, are any of the removed features (ListLike, > WrappedByteString, seeking) something your libraries depend on? Are > there any useful combinators you'd like to see included? > > >

1 0

cabal, haddock, hscolour
by Johannes Waldmann 19 Aug '10

19 Aug '10

How is the "cabal" magic that would run hscolour? I am using "cabal haddock --executables --hyperlink-source" and this generates the API docs for all modules, and all have source links, but the actual html-ized source is only generated for the main module, and missing for all others. Thanks - J.W. cabal --version cabal-install version 0.8.2 using version 1.8.0.6 of the Cabal library haddock --version Haddock version 2.7.2, (c) Simon Marlow 2006 Ported to use the GHC API by David Waern 2006-2008 HsColour --version HsColour 1.17 ghc --version The Glorious Glasgow Haskell Compilation System, version 6.12.3

4 8

ANNOUNCE: darcs 2.5 beta 3
by Reinier Lamers 19 Aug '10

19 Aug '10

Hi all, The darcs team would like to announce the immediate availability of darcs 2.5 beta 3 (also known as darcs 2.4.98.3 due to Cabal restrictions). Important changes since darcs 2.4.4 are: * trackdown can now do binary search with the --bisect option * darcs always stores patch metadata encoded with UTF-8 * diff now supports the --index option * amend-record now supports the --ask-deps option * apply now supports the --match option * amend-record has a new --keep-date option * inventory-changing commands (like record and pull) now operate in constant time with respect to the number of patches in the repository * the push, pull, send and fetch commands no longer set the default repository by default * the --edit-description option is now on by default for the send command You may notice that a line "obliterate has a -o flag to save obliterated patch" was removed from this list of changes since the darcs 2.5 beta 2 announcement. We have postponed this feature because we discovered some problems with it, and we want to take the time to fix them adequately. On the other hand, a line "diff now supports the --index option" was added since the last beta :) If you have installed the Haskell Platform or cabal-install, you can install this beta release by doing: $ cabal update $ cabal install darcs-beta Alternatively, you can download the tarball from http://darcs.net/releases/darcs-2.4.98.3.tar.gz and build it by hand as explained in the README file. (You may notice that the Unix permissions in this tarball are weird - all files are 0600. That is because of Cabal bug #627: http://hackage.haskell.org/trac/hackage/ticket/627. It will be fixed in the final release.) Kind Regards, the darcs release manager, Reinier Lamers

5 5

gtk2hs with old gtk2
by Johannes Waldmann 19 Aug '10

19 Aug '10

I'm trying to build gtk2hs on debian/lenny, that is, with gtk2 v. 2.12 if I understand this correctly. I got the gtk2hs sources from darcs (I guess it's 0.11.0) and http://www.haskell.org/gtk2hs/ says "You need to specify -f-gtk_2_20 for Gtk+ 2.18 etc." I would love to, but where exactly? (When bootstrap.sh) Thanks - J.W.

3 6

Handling absent maintainers
by Mark Wotton 19 Aug '10

19 Aug '10

Hello all, I've recently had problems with haskell-src-meta. While it's a great package, it doesn't currently compile on GHC 6.12, and Matt Morrow doesn't seem to be around to push the version that does to Hackage. Our "one-world" approach with cabal seems to discourage forking as a casual act, so when a package that others rely on goes AWOL, it's very awkward to fix it. I can think of a few ways to get around my current problems: 1. upload haskell-src-meta-placeholder, or haskell-src-meta-mwotton, or something similar - this could be said to pollute the namespace, but would solve my immediate problem. I'd have to similarly specialise the chain of packages up to the one I actually want to use as well, though. 2. run my own hackage server and tell my users to use that instead. 3. ... profit? Ideally, I'd like to be able to say something like "cabal install my-hacked-package --as original-package" - are there fundamental reasons that wouldn't be possible, or a bad idea? mark

10 23

ANNOUNCE: haskell-src-meta 0.1.0
by Ben Millwood 19 Aug '10

19 Aug '10

Hello cafe, The haskell-src-meta package was originally written by Matt Morrow, to provide a translation from the syntax tree parsed from String by the haskell-src-exts package to Template Haskell's representation of Haskell source code, making possible a variety of interesting quasiquoters and metaprogramming. However, while the package was still fairly embryonic and incomplete, Matt disappeared from the haskell community, and his work no longer compiles with the latest versions of template haskell and GHC. Many people still had use for it, so there was some discussion about its future in a haskell-cafe thread [1] resulting in a fork [2]. After I and at least one other person duplicated the work of updating haskell-src-meta, ignorant of the fork, it was decided that maintaining forks was a less-than-ideal solution, so I volunteered to take up maintainership of a package that had by now been untouched for some ten months. Hence, haskell-src-meta-0.1.0, from a new maintainer (hello!). The functionality changes in this release are minimal, but nonzero: its primary purpose is to let the original work be used with updated TH. However, there have been some changes and additions since 0.0.6: * The previously somewhat lengthy Language.Haskell.TH.Instances.Lift is now mostly generated with template haskell using the th-lift package. * Contexts, kinds, bang patterns, unboxed word literals, newly supported in template-haskell-2.4.0.0, are used where necessary. * Use of haskell-src-exts is brought in line with newer versions. * Thanks to a patch by Jonas Duregard, a new ToDecs class has been added to handle cases where more than one Dec must be returned. I don't have any big plans for future releases: there is a lot that could do with tidying up, and some small aspects of the syntax conversion that aren't covered, but I mostly just intend to ensure it keeps building and that anyone with patches to contribute has a prompt response. How You Can Help: the easiest way is to tell me that I've put the version constraints too tightly on some dependency or other -- I have erred on the conservative side. Any other comments on the package in general are appreciated too, since this is the first time I've ever uploaded anything to Hackage. There is a github repository at http://github.com/benmachine/haskell-src-meta if you want to submit patches. Yours sincerely, Ben Millwood [1] http://www.haskell.org/pipermail/haskell-cafe/2010-July/080390.html [2] http://hackage.haskell.org/package/haskell-src-meta-mwotton

2 1

String vs ByteString
by Erik de Castro Lopo 19 Aug '10

19 Aug '10

Hi all, I'm using Tagsoup to strip data out of some rather large XML files. Since the files are large I'm using ByteString, but that leads me to wonder what is the best way to handle clashes between Prelude functions like putStrLn and the ByteString versions? Anyone have any suggestions for doing this as neatly as possible? Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

38 160

building ghc on opensolaris
by Günther Schmidt 19 Aug '10

19 Aug '10

Hi, does anybody know why --with-gcc= ... has no effect when passed to ./configure? This is under OpenSolaris only, under Mac OS X for instances it takes. Günther

2 2

Specific to General to Specific
by Edward Z. Yang 19 Aug '10

19 Aug '10

Imagine that I have the following type-class: class (Monad (m n)) => NetworkMonad m n data NT n a instance NetworkMonad NT n data NQ n a instance NetworkMonad NQ n monadicValue :: NetworkMonad m n => m n () It defines some family of phantom monads, in this case NT n and NQ n, and permits some values to inhabit either monad (resolved by the surrounding code). Suppose, however, that there are multiple possible implementations for the pair (NT, NQ). Then we might like to generalize this typeclass with an associated type. (Suppose that our old implementation was g = Int.) {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE FlexibleContexts #-} class Network g where data GNT g :: * -> * -> * data GNQ g :: * -> * -> * class (Monad (m g n)) => GenericNetworkMonad g m n type NT n a = GNT Int n a type NQ n a = GNQ Int n a genericMonadicValue :: GenericNetworkMonad g m n => m g n () genericMonadicValue = undefined monadicValue :: GenericNetworkMonad Int m n => m Int n () monadicValue = undefined My question is, how can I write a specialized typeclass NetworkMonad that recaptures the original simple interface? monadicValue' :: NetworkMonad m n => m n () monadicValue' = undefined I've tried something like this: type family GetM (x :: * -> * -> *) :: (* -> * -> * -> *) type instance GetM (m g) = m type family GetG (x :: * -> * -> *) :: * type instance GetG (m g) = g class (GenericNetworkMonad (GetG mg) (GetM mg) n) => NetworkMonad mg n where But this doesn't seem to be enough information to do inference with: monadicValue'' :: NetworkMonad m n => m n () monadicValue'' = genericMonadicValue gives the type error: Test.hs:28:17: Could not deduce (GenericNetworkMonad g m n) from the context (NetworkMonad m1 n) arising from a use of `genericMonadicValue' at Test.hs:28:17-35 Possible fix: add (GenericNetworkMonad g m n) to the context of the type signature for `monadicValue''' In the expression: genericMonadicValue In the definition of `monadicValue''': monadicValue'' = genericMonadicValue Test.hs:28:17: Couldn't match expected type `m1' against inferred type `m g' `m1' is a rigid type variable bound by the type signature for `monadicValue''' at Test.hs:27:31 In the expression: genericMonadicValue In the definition of `monadicValue''': monadicValue'' = genericMonadicValu Am I out of luck without superclass equality constraints? Cheers, Edward

2 1