Have you submitted a bug report to GHC of why it can't work with the current
integer-gmp binding? I know that GHC's collector is collecting MPFR's
temporary data, but maybe it'd be good to get a discussion going on what can
be done to stop it from doing this even in the context of the existing
According to Duncan Coutts (whom I asked about this issue in #ghc), the
solution here is to use the new foreign import prim machinery to talk to
MPFR. This prevents GC from occurring during the MPFR calls and will make
everything work nicely without reimplementing GMP.
Dan
On Fri, Mar 4, 2011 at
I'd be more than willing to tackle flipping things over to use foreign
prims, so that I have something I can build on top without requiring the
contortions to get a ghc build with integer-simple.
Dan has a cabal buildable library with foreign prims to use as a model.
Is the google code
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
On Friday 04 Mar 2011 21:06:45 Edward Kmett wrote:
I'd be more than willing to tackle flipping things over to use foreign
prims, so that I have something I can build on top without requiring the
contortions to get a ghc build with integer-simple.
Dan has a cabal buildable library with
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
Woohoo!
I tried to fix up the hmpfr bindings myself before the
integer-simple/integer-gmp split was done, but it was impossible given the
way GHC hooks into the gmp allocator. The main issue appears to be the fact
that as mpfr has matured it has come to do more internal allocation to
handle
