[From nobody Fri Mar 4 23:42:48 2011 Delivered-To: mikkonecny@googlemail.com Received: by 10.220.185.141 with SMTP id co13cs78052vcb; Fri, 4 Mar 2011 13:50:03 -0800 (PST) Received: by 10.227.140.23 with SMTP id g23mr1036047wbu.46.1299275402733; Fri, 04 Mar 2011 13:50:02 -0800 (PST) Return-Path: <mik@konecny.aow.cz> Received: from mx-int-01.aston.ac.uk (mercury.aston.ac.uk [134.151.40.4]) by mx.google.com with ESMTPS id z57si4937572weq.79.2011.03.04.13.50.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2011 13:50:01 -0800 (PST) Received-SPF: neutral (google.com: 134.151.40.4 is neither permitted nor denied by best guess record for domain of mik@konecny.aow.cz) client-ip=134.151.40.4; Authentication-Results: mx.google.com; spf=neutral (google.com: 134.151.40.4 is neither permitted nor denied by best guess record for domain of mik@konecny.aow.cz) smtp.mail=mik@konecny.aow.cz Received: from [172.31.228.4] (helo=eas-mb212dnb01.aston.ac.uk) by mx-int-01.aston.ac.uk with esmtp (Exim 4.63) (envelope-from <mik@konecny.aow.cz>) id 1Pvcso-0002K7-Cf; Fri, 04 Mar 2011 21:49:58 +0000 Received: by eas-mb212dnb01.aston.ac.uk (Postfix, from userid 50092) id 621A881B85; Fri, 4 Mar 2011 21:49:20 +0000 (GMT) From: Michal =?utf-8?q?Kone=C4=8Dn=C3=BD?= <mik@konecny.aow.cz> Reply-To: mik@konecny.aow.cz Organization: home To: Daniel Peebles <pumpkingod@gmail.com> Subject: Re: [Haskell-cafe] ANN: hmpfr-0.3.2 (requires integer-simple, supports mpfr 3.0.0) Date: Fri, 4 Mar 2011 21:49:13 +0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-27-generic; KDE/4.5.1; i686; ; ) References: <201103031640.16042.mik@konecny.aow.cz> <AANLkTikxebRUPgfCTG2YyF1Xosg_yC0moW1vAYzFUWi=@mail.gmail.com> <AANLkTikC8Nwn=vGthbXRZ+7ys0mnq9PG0z+L+fxpCuuZ@mail.gmail.com> In-Reply-To: <AANLkTikC8Nwn=vGthbXRZ+7ys0mnq9PG0z+L+fxpCuuZ@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4381736.SXDXaE3lnD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201103042149.18189.mik@konecny.aow.cz> --nextPart4381736.SXDXaE3lnD Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Dan, Thank your for your suggestions. =20 I implemented the dependency on integer-simple because I need hmpfr to work= in=20 the short term. In the long term, I would like to adopt a better approach.= =20 At the moment I do not know enough about ghc internals to be able to determ= ine=20 the approach, so I welcome your pointers. I know that Ale=C5=A1, who knows= more=20 about the ghc internals, has tried various things but could not make hmpfr= =20 work with the current integer-gmp. I did not file a bug because there was a similar ghc ticket open for quite= =20 some time (#601) and it has been closed when it became possible to use=20 integer-simple instead of integer-gmp. That is why I felt that the best=20 solution to the problem at present is to use integer-simple. I am not an expert but based on what I read experts say on the topic I=20 concluded that it is close-to-impossible to make ghc+integer-gmp work with= =20 libraries such as mpfr that heavily use gmp. Of the suggested solutions we are aware of, the one that seems to me and Al= e=C5=A1=20 most promising is to create a clone of gmp that differs from the original o= nly=20 in the names of all exported symbols and distribute it as a part of ghc to = be=20 dynamically linked with all executables produced by ghc. The clone could b= e=20 produced using a script to allow easy updates with new versions of gmp. I= =20 would be interested whether someone has been trying or has plans to try to= =20 implement this approach. The reason why I like this approach than writing = cmm=20 wrappers around MPFR and prim importing them is that it is more maintainabl= e=20 and also opens the way for other libraries that depend on gmp to work with= =20 ghc. Michal On Friday 04 Mar 2011 20:27:10 you wrote: > 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. >=20 > Dan >=20 > On Fri, Mar 4, 2011 at 3:09 PM, Daniel Peebles <pumpkingod@gmail.com> > wrote: 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 integer-gmp + GHC's allocator (even if this needs to be a patch > to MPFR to talk to GHC a bit here and there). Might it help to go through > CMM like the GMP binding does, for example? >=20 > I'd really like to see libraries that use GMP work nicely with GHC, witho= ut > going and reimplementing GMP more slowly and so on. =2D-=20 |o| Michal Konecny <mikkonecny@gmail.com> |o| http://www-users.aston.ac.uk/~konecnym/ |o| office: (+42) (0)121 204 3462=20 |o| PGP key http://www-users.aston.ac.uk/~konecnym/ki.aston --nextPart4381736.SXDXaE3lnD Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAk1xXloACgkQxBHi+51on5KBcgCgrSBTNDircBlMfNTbAJ18Wqy/ 8hAAoKczKeDWm6Cy0E/xmA1k/G7OkLdQ =muHw -----END PGP SIGNATURE----- --nextPart4381736.SXDXaE3lnD-- ]