- Haskell-Cafe - Haskell.org

ANN: hmpfr-0.3.2 (requires integer-simple, supports mpfr 3.0.0)
by Michal Konečný 04 Mar '11

04 Mar '11

Dear all, I am pleased to announce hmpfr-0.3.2, a new version of Aleš Bizjak's bindings to the MPFR arbitrary precision floating point arithmetic library. The changes in this version are quite small but significant: - support for MPFR 3.0.0 as well as MPFR 2.4.* - dependency on integer-simple instead of integer-gmp The latter is most significant because unfortunately it makes it rather more difficult to install hmpfr. Currently almost all binary distributions of ghc have integer-gmp compiled in to provide the Integer type via the standard GMP library. Also haskell platform 2010.2.0.0 assumes that ghc has been compiled with integer-gmp although it makes no specific use of it. Instructions on how to compile ghc and haskell platform with integer-simple instead of integer-gmp are on: http://code.google.com/p/hmpfr/wiki/GHCWithoutGMP The rationale for this change is the fact that despite much effort hmpfr is very unreliable on ghc that includes integer-gmp due to ghc deallocating GMP data that was allocated by MPFR at unpredictable times. Aleš and I hope that hmpfr can return to using integer-gmp once the proposal http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes#BinaryDropinRepl… to replace gmp with a modified gmp in ghc is implemented and made the default. Best regards, Michal -- |o| Michal Konecny <mikkonecny(a)gmail.com> |o| http://www-users.aston.ac.uk/~konecnym/ |o| office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston

3 5

Re: [Haskell-cafe] ANN: hmpfr-0.3.2 (requires integer-simple, supports mpfr 3.0.0)
by Michal Konečný 04 Mar '11

04 Mar '11

Hi Dan, On Friday 04 Mar 2011 21:59:12 Daniel Peebles wrote: > I'm adding Ed to the conversation as he's very interested in this topic, > too. I do apologise - I was meant to post the previous email back to haskell-cafe but by mistake it went only to you. I hope you do not mind that I am taking the discussion back to the cafe. I attach my email so that other readers of the cafe can see it. > The experts were right about it being impossible to work with GHC's > GMP – until recently. "foreign import c" calls are indeed going to call GC > when you don't want it, but when they split integer-gmp out of GHC's own > RTS, Duncan Coutts (one of those experts) added the "foreign import prim" > construct so that he could do exactly what you want, and operate on GMP > integers with GHC-allocated memory without worrying about temporary > storage blowing up while you aren't looking. > > So in general, I'd lean more towards replacing all your ccall bindings to > MPFR with cmm bindings. It does require some GHC internals knowledge but > is fairly mechanical, and would solve all the problems, without requiring > a rewrite of GMP (that would be slower anyway). > > Ed is actually going to get started on a fairly simple binding to a subset > of MPFR for one of his projects, using the CMM approach based on the > structure of my natural-gmp package > (https://github.com/pumpkin/natural-gmp, which is itself based heavily on > integer-gmp, but reworked to work fine from cabal rather than depending on > GHC's build process). Once he is done with that, you might want to refer > to his implementation to make your more complete MPFR binding work with > integer-gmp (and thus make no speed sacrifices). If this is the best approach, I would welcome help with this as I will not have much time to work on it until the summer due to teaching commitments and the need to publish work done earlier. > I would also like a gmp-compatible replacement, but it's going to > necessarily be slower and would prefer to be able to have fast > computations over floating-point numbers AND integers/naturals. Eek, I made a mistake, I apologise again - the proposal I was quoting in the announcement is not what I had in mind. I was meant to refer to a mention by igloo at the very end of http://hackage.haskell.org/trac/ghc/ticket/311 which is a very different proposal from the one I linked to and the one you seem to refer to here. I was not at all thinking of writing a gmp compatible replacement. I was thinking of taking gmp sources and mechanically modify the exported names and modify integer-gmp to use those modified names. Thus there would be no difference in the speed of Integer as it would still use an exact clone of the original gmp in exactly the same way as now but not interfere with what the usual gmp code does via other libraries. Please correct me if I this approach is not feasible or if there is some advantage in using cmm over this proposal that I am missing. Michal -- |o| Michal Konecny <mikkonecny(a)gmail.com> |o| http://www-users.aston.ac.uk/~konecnym/ |o| office: (+42) (0)121 204 3462 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston

1 0

Announce: new releases of bitset and funsat
by Denis Bueno 04 Mar '11

04 Mar '11

Hello all, Just a small announcement. funsat has been bumped to 0.6.2. New in 0.6.2: works with ghc-6.12 and fixed some space leaks. http://hackage.haskell.org/package/funsat bitset has been bumped to 1.1. New in 1.1: can easily convert between the BitSet representation and the underlying Integer. http://hackage.haskell.org/package/bitset -- Denis

1 0

darcs hacking sprint #6 (1-3 April, Paris)
by Eric Kow 04 Mar '11

04 Mar '11

Hi everybody, Following up on my last message, the date and venue for the sixth Darcs Hacking sprint has been confirmed. Get out your berets everybody, because we're going to Paris! Here are three things to know 1. Everybody is welcome to join us. We'd love to have you, whatever your Haskell or Darcs hacking experience. Also, if you've got a wacky idea for the future of version control, or a cool use for the Darcs library, you should join us too :-) 2. Please let us know if you're attending. Just add your name to http://wiki.darcs.net/Sprints/2011-04 and you're good to go. You can also send us an email. 3. We can reimburse travel costs (within reason!). Let us know if you'd like a reimbursement, and save your receipts. Many thanks to everybody who participated in our fundraising drives or who gave money on the side. Thanks also to the Software Freedom Conservancy for making fundraising and reimbursements so painless! If you can't join us in person, but you'd like to cheer us on, say hello at http://darcs.net/donations.html! Looking forward to seeing you! Eric PS. Berets optional. -- Eric Kow <http://www.nltg.brighton.ac.uk/home/Eric.Kow> For a faster response, try +44 (0)1273 64 2905 or xmpp:kowey@jabber.fr (Jabber or Google Talk only)

1 0

A practical Haskell puzzle
by Yitzchak Gale 04 Mar '11

04 Mar '11

You have written a large software system in Haskell. Wishing to play to Haskell's strength, you have structured your system as a series of composable layers. So you have data types Layer1, Layer2, ... and functions layer2 :: Layer1 -> Layer2 layer3 :: Layer2 -> Layer3 ... etc. Of course you'll want to be able to run any range of the layers separately, at least for testing and debugging purposes if not for the functionality itself. So your UI module (command line or whatever) that launches your application provides a data type data Layers = Layers Int Int that indicates which layers to run, and functions deserialize1 :: L.ByteString -> Layer1 deserialize2 :: L.ByteString -> Layer2 ... serialize1 :: Layer1 -> L.ByteString serialize2 :: Layer2 -> L.ByteString ... etc. Now you need a function runLayers :: Layers -> L.ByteString -> L.ByteString so that the effect is for example runLayers (Layers 4 6) = serialize6 . layer6 . layer5 . deserialize4 Typically there could be 20 or 30 layers, so writing out each case could result in hundred of boilerplate definitions for runLayers. Scripting the generation of all that boilerplate, e.g. using TH, doesn't seem very attractive either. On the other hand, it seems silly to have to use super-advanced type olegery for such a trivially simple yet centrally important component of the system. What is the best way to write runLayers? Feel free to change the details of the above design, as long as it meets the functionality requirements expressed. Regards, Yitz

7 16

ANN: Haskell XML Toolbox Version 9.1
by Uwe Schmidt 04 Mar '11

04 Mar '11

Haskell XML Toolbox 9.1 I would like to announce an update hxt-9.1 of the Haskell XML Toolbox. Main changes compared to hxt-9.0 are * space optimization of DOM tree for better performance for lager XML documents * optimization of space used during parsing in native XML and HTML parsers * a binding to the expat parser via hexpat Cheers, Uwe

1 0

Getting started with http-enumerator
by C K Kashyap 04 Mar '11

04 Mar '11

Hi, I'd like to use http-enumerator for things that I've been using perl/Lwp for. I tried looking but was not able to find good documentation for it. Could someone please point me to simple examples? Like posting a form, dealing with cookies etc. Regards, Kashyap

1 0

Project structure
by Hauschild, Klaus (EXT) 04 Mar '11

04 Mar '11

Hi Haskellers, is there a recommended structure for Haskell projects. I like the Maven way (http://maven.apache.org/guides/introduction/introduction-to-the-standard-di…) for Java projects. How to separate productive from test code, how to separate source code from other resources? Thanks Klaus

2 1

ANN: cabal-dev-0.7.4.0
by Rogan Creswick 04 Mar '11

04 Mar '11

We're happy to announce that cabal-dev-0.7.4.0 is now on hackage. We strongly suggest that everyone upgrade to this release, since this release specifically addresses changes in Cabal-1.10 and newer, which the latest cabal-install now uses. The ticket for the bug is here, for anyone interested: https://github.com/creswick/cabal-dev/issues/2 --Rogan

1 0

ANN: Version 0.14 of dataenc, version 0.5 of omnicodec
by Magnus Therning 03 Mar '11

03 Mar '11

I've just uploaded a new version of dataenc to hackage[1]. It contains a large change to the API. The old, rather simplistic, lazy API has been removed. It has been replaced by an API based on incremental encoding/decoding. This should make the library easier to use together with left-fold enumerators such as enumerator[2] and iteratee[3]. It's accompanied by a release of omnicodec[4] which makes use of the modified API of dataenc. /M [1] http://hackage.haskell.org/package/dataenc [2] http://hackage.haskell.org/package/enumerator [3] http://hackage.haskell.org/package/iteratee [4] http://hackage.haskell.org/package/omnicodec -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus(a)therning.org jabber: magnus(a)therning.org twitter: magthe http://therning.org/magnus Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. -- Alan Kay

1 0