- Haskell-Cafe - Haskell.org

ANNOUNCE: darcs 2.5
by Reinier Lamers 30 Oct '10

30 Oct '10

Hi all, The darcs team is proud to announce the release of darcs 2.5. Darcs 2.5 contains many improvements over the 2.4 series. Most notable are the performance improvements in record and pull and the --bisect option for trackdown. The easiest way to install darcs 2.5 is using the Haskell Platform [1]. If you have installed the Haskell Platform or cabal-install, you can install this beta release by doing: $ cabal update $ cabal install darcs Alternatively, you can download the tarball from http://darcs.net/releases/darcs-2.5.tar.gz and build it by hand as explained in the README file. What's New ---------- A list of important changes since darcs 2.4.4: * 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 change the default repository address by default * the --edit-description option is now on by default for the send command Issues resolved since darcs 2.4.4: * 64: store metadata as UTF-8 * 121: add --ask-deps support to amend-record * 643: darcs send -o outputs remote repo email address * 1159: avoid bogus repository cache entries * 1176: caches interfere with --remote-repo flag * 1208: add trackdown --bisect * 1210: global cache gets recorded in _darcs/prefs/sources * 1232: darcs convert copies _darcs/prefs/prefs * 1250: check for newlines in setpref values * 1277: percolate repository format errors correctly * 1288: the main darcs code now compiles and runs with witnesses * 1290: support diff --index * 1337: don't show unrelated patches in darcs changes on untracked path * 1389: change predist pref to point people to use 'cabal sdist' * 1427: accept gzipped patch bundles in darcs apply * 1456: make dist write more portable archives * 1473: make annotate accept '.' as argument * 1503: prefer local caches to remote ones * 1713: shorter interactive prompts * 1716: allow mail header lines of all whitespace in test * 1719: do not back up files when no conflict markers are inserted * 1726: don't consider all files with _darcs prefix boring * 1739: make ColorPrinter handle characters > 255 * 1763: use correct filename encoding in conflictors * 1765: refuse to remove non-tracked directories recursively * 1769: add support for --match 'comment ...' * 1784: push and pull print remote address right away * 1815: work around Cabal sdist permissions issue * 1817: fix support for external merge tools * 1824: avoid PACKAGE_VERSION under Windows * 1825: do not omit important prims in unrecordedChanges w/ files * 1860: (un)applying move patches doesn't corrupt pristine * 1861: fix typo in --no-boring help * 1874: recognise network tests on cabal test command line * 1875: avoid accidentally setting default * 1879: notice unexpected commute failure on merge * 1887: add a missing newline to --list-options output * 1893: move fields of conditional builds within scope of condition * 1898: notify user when they can use set-default * 1913: sort changes in treeDiff Reporting bugs -------------- If you have an issue with darcs 2.5, you can report it via the web on http://bugs.darcs.net/ . You can also report bugs by email to bugs(a)darcs.net. Kind Regards, the darcs release manager, Reinier Lamers [1]: You can download the Haskell platform from http://hackage.haskell.org/platform/

1 0

fundata1 -- Karmic Social Capital Benchmark and Shootout
by Alexy Khrabrov 30 Oct '10

30 Oct '10

I am happy to announce fundata1 -- the largest-ever program per RAM allocation in Haskell, originally implemented in Clojure and then OCaml and Haskell for social network modeling. http://github.com/alexy/fundata1 It has now become the first large-scale social networking benchmark with a real dynamic social graph built from the actual Twitter gardenhose, with the data OK'd by Twitter and supplied along with the benchmark. I wrote three reference implementations, all on github as well. Clojure and OCaml are quite basic, while Haskell community had a chance to optimize its data structures and in fact fix a GC integer overflow while working on it. You're welcome to fork and improve all of these implementations, and supply others! There's a Google Group, http://groups.google.com/group/fundata/ to discuss the shootout. There's also a blog about it and other functional things at http://functional.tv/ Let the fun begin! -- Alexy Khrabrov firstname.lastnameATgmaildotcom

4 4

Re: Haskell-Cafe Digest, Vol 86, Issue 63
by John Lato 30 Oct '10

30 Oct '10

Hi Arnaud, > From: Arnaud Bailly <arnaud.oqube(a)gmail.com> > > Hello, > I am trying to wrap my head around the concept of Iteratee reading the > article by John Lato in Monad Reader issue 16 > (http://themonadreader.files.wordpress.com/2010/05/issue16.pdf) I > followed the "advice" on page 34: > > "I have frequently heard reports from Haskellers (including highly-talented > and > experienced users) that the only way they could understand > enumeration-based > I/O was by re-implementing it themselves." > > and so reimplemented this code in Java which is, for better and worse, > my current professional language (and there really is no point in > writing my own 50th iteratee code...). > > I have a question about iteratees composition and their behaviour. I > tried to use the throbber code to display progress while writing a > file, without using enumeratees which are introduced later on in the > article, but failed. I can bind the two iteratees together, but the > writer iteratee consumes the stream of characters to write before > handing over the control to the throbber iteratee which has nothing to > count. Did I miss something ? > This is the expected behavior. When iteratees are composed with bind, the first will consume as much of the stream as it needs to calculate its result, and only then will it pass the remaining stream to the next iteratee in the composition. Since "streamToFile" and "throbber" both consume an entire stream, they won't complete until EOF, and then will pass just that EOF to the next iteratee in the composition. The behavior you want is pretty common, and it can be accomplished by writing either throbber or streamToFile as an enumeratee. Then the enumeratee version would do the work it's supposed to but also pass the stream along to another iteratee. You could write a library function with type (following the types from the article) iterToEnum :: Monad m => Iteratee el m () -> EnumerateeM el el m a which would do this for any data-sink type iteratee. A very similar approach is used in the "iteratee" package to define the "enumPair" function, enumPair :: Monad m => Iteratee s m a -> Iteratee s m b -> Iteratee s m (a,b) I consider "enumPair" to be one of the most powerful functions supplied in iteratee. Since you use Java, you may be interested in an iteratee implementation in Scala, http://apocalisp.wordpress.com/2010/10/17/scalaz-tutorial-enumeration-based… Best, John

2 1

Haddock API and .haddock interface files questions
by Claus Reinke 30 Oct '10

30 Oct '10

Some questions about Haddock usage: 1. Haddock executable and library are a single hackage package, but GHC seems to include only the former (haddock does not even appear as a hidden package anymore). Is that intended? 2. Naively, I'd expect Haddock processing to involve three stages: 1. extract information for each file/package 2. mix and match information batches for crosslinking 3. generate output for each file/package I would then expect .haddock interface files to repesent the complete per-package information extracted in step 1, so that packages with source can be used interchangeably with packages with .haddock files. However, I can't seem to use 'haddock --hoogle', say, with only .haddock interface files as input ("No input file(s)."). 3. It would be nice if the Haddock executable was just a thin wrapper over the Haddock API, if only to test that the API exposes sufficient functionality for implementing everything Haddock can do. Instead, there is an awful lot of useful code in Haddock's Main.hs, which is not available via the API. So when coding against the API, for instance, to extract information from .haddock files, one has to copy much of that code. Also, some inportant functionality isn't exported (e.g., the standard form of constructing URLs), so it has to be copied and kept in synch with the in-Haddock version of the code. It might also be useful to think about the representation of the output of stage 2 above: currently, Haddock directly generates indices in XHtml form, even though much of the index computation should be shareable accross backends. That is, current "backends" seem to do both stage 2 and stage 3, with little reuse of code for stage 2. It seems that exposing sufficient information in the API, and allowing .haddock interface files as first-class inputs, there should be less need for hardcoding external tools into Haddock (such as --hoogle, or haddock-leksah). Instead, clients should be able to code alternative backends separately, using Haddock to extract information from sources into .haddock files, and the API for processing those .haddock files. Are these expectations reasonable, or am I misreading the intent behind API and .haddock files? Is there any documentation about the role and usage of these two Haddock features, as well as the plans for their development? Claus

2 1

Haskellers.com idea: strike forces
by Michael Snoyman 30 Oct '10

30 Oct '10

Hey all, In the recent discussion about the status of email support in Haskell, the idea of strike forces to tackle these big problems came up. I think one dilemma people face when trying to coordinate such a venture is the logistics: where to organize, how to advertise it, where to have discussions that can be publicly accessible. This may be something that the Haskellers website can help address. Here's an idea, please give me any feedback you have (especially the negative kind): * Anyone can create a "strike force", by specifying a name for the strike force and giving a description. That person will automatically be the administrator for the strike force. * Anyone on Haskellers can watch a strike force; this will contribute to its popularity. The most popular strike forces will be shown at the top of the listings, to give an idea of what projects are active and which are dead. * People must apply to be members of a strike force, and be approved by a strike force admin. Strike force admins also have the right to add new admins/remove current admins. * Admins can add links to other websites, list Hackage packages that are part of this strike force's scope, etc. Ideas on this are welcome. * There will be some kind of discussion forum. The only thing I know for certain about this is we want to have a news feed to give updates on what's happening. I'm open to suggestions on what to implement here, but some ideas: ** A request/bug tracker. ** Free-form message boards. Possibly requires moderation for non-members. ** I'm not certain if it should just be a single thread, multi discussion threads, hierarchical discussions like Reddit, etc. Please let me know what you think. And if you think this is a foolish idea that won't help the community out, please let me know that too. Michael

3 5

State & nested structures
by Dupont Corentin 29 Oct '10

29 Oct '10

Hello the list, I have another silly question. In my software I have a very common pattern: --in file A.hs module A where data A = A {b :: B, i :: Int} type SA x = State A x -- many functions with SA x --in file B.hs data B = B {r :: Int} type SB x = State B x -- many functions with SB x Of course in module A I'm calling some functions of module B. I'd like to know if it's possible, in a function of type SA, to call a function of type SB, without actually executing the State SB. I just wanna tell him "Hey look, you can construct a SA from a SB like this!" For now I have this: bToA:: (B -> B) -> A -> A bToA bb = (λa -> a{b = bb (b a)}) useB :: SB () -> SA () useB = modify . bToA . execState Can I get rid of the execState? Also, I can't manage to write the more generic function SB x -> SA x. Cheers, Corentin

4 6

libffi mystery
by Conor McBride 29 Oct '10

29 Oct '10

Hi again This is what happens when you write actual for-users for-running programs, I guess. It's been a while... I've been writing some software with Network.CGI etc, which we run on the deparmental web server for my students to use. But we just had a bit of an upgrade on the system, and now (once cabal was properly installed) everything compiles again but nothing works. The reason appears to be that the executables now depend on a dynamic library libffi.so.5 which is not (and I am told cannot become) available on our web server. The current workaround is to compile with 6.8.2, which is survivable and will hopefully get me through the semester, but not ideal. Is there some way I can get some more static linking to happen? I did poke about online a bit and found some remarks to the effect that GHC got so much more portable after switching to the dynamic libffi. That sounds great, but tough luck for me. So, being both powerless and clueless, I can only ask: how hosed am I? I'd be grateful for any glimmers of light. Thanks Conor

3 4

Does it deserve to be a hackage package?
by Dmitry V'yal 28 Oct '10

28 Oct '10

Hello haskellers, While ago I had a question about opening the url in the default browser from haskell program. I didn't get any immediate answers so I wrote my own solution. On Linux it uses xdg-open and on Windows - ShellExecute Api. Later I received a letter saying what similar functionality was recently implemented in trunk version of gtk2hs but is currently unavailable as binary package. Code I wrote works quite well for my purposes and I copied it into several my programs. In order to make maintenance easier I recently thought about uploading it to hackage. But given a wast amount of half-dead packages with intersecting functionality there I'd like to ask the opinion of community. Does such library look helpful to you? Dmitry

4 5

If Python now has a good email library; how challenging is it to call Python from Haskell?
by caseyh＠istar.ca 28 Oct '10

28 Oct '10

:)

8 7

New repo location for the network package
by Johan Tibell 28 Oct '10

28 Oct '10

Hi all, To ease my maintenance burden, I've moved the network package repo to: http://github.com/haskell/network Patches are accepted either in the git mbox format, as normal (diff) patch files, or as GitHub pull requests. P.S. If you want to get added to the haskell GitHub organization, just drop me an email. Johan

3 6