[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#10519: guile and (mini-)gmp
bug#10519: guile and (mini-)gmp
Fri, 10 Aug 2012 23:51:00 +0200
Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.1 (gnu/linux)
address@hidden (Niels Möller) skribis:
> address@hidden (Ludovic Courtès) writes:
>> Reviving the discussion, as we’ve been discussing this at the GHM, and
>> some people would really like to see it happen. :-)
> Great! Any summary of the discussion, for those of us who couldn't make
> it there?
Mostly a few people reaffirmed the need for this.
> I'm attaching a patch from I tree I have around, without reading it
> carefully. I'm not sure this is the latest version I worked with. Maybe
> it's of some use.
Yes, thanks. I just tried it, and here’s the status:
- numbers.c uses ‘GMP_NUMB_BITS’, which is lacking;
- it also still uses mpq’s, as Mark noted;
- random.c uses ‘mpz_realloc2’, also lacking.
>>> 1. The header file libguile.h. As far as I understand, this is a public
>>> header file and it's use of <gmp.h> means that the public guile ABI
>>> depends on gmp.
>> The problem is that there’s a public API dealing with mpz_t:
> Exactly. To me, that seems like a potentially hairy problem to get
>> SCM_API void scm_to_mpz (SCM x, mpz_t rop);
>> SCM_API SCM scm_from_mpz (mpz_t rop);
>> So, when mini-gmp is used, a <gmp.h> header should be installed as well,
>> say under <libguile/mini-gmp.h>. WDYT?
> Maybe it would make sense with a level of indirection. User's could
> include libguile/bignum.h, which would in turn include either mini-gmp.h
> or the real gmp.h, depending on how guile was configured.
Users are only supposed to include <libguile.h>; headers under
libguile/ aren’t meant to be included directly.
Currently including <libguile.h> pulls <gmp.h>. When mini-GMP is used
instead, then <libguile/mini-gmp.h> would be pulled instead,
> Users may also need some way of figuring out if they need to link with
> -lgmp or not.
libguile-2.0.la and guile-2.0.pc would provide that info.
>>> Since mini-gmp is not binary compatible,
>> I don’t think there’s a problem, because only mpz_t objects appear in
>> the API, and they’re pointers.
> Hmm, or if you're saying that the use of mpz_t in guile's public API is
> pointers only, that that might make things a little simpler. But things
> will still break badly if the user's code is linked with gmp and guile
> uses mini-gmp, or vice versa.
Exactly, that’s the only case where it would break, AFAICS. And it’s
probably an unlikely use case: users who want to use both GMP and Guile
surely have libguile linked against GMP.
>>> 4. mini-gmp has no mp_set_memory_functions.
> That's added now, with the subtle difference that mini-gmp doesn't pass
> a valid size for the old_size argument for the free and realloc
> functions. I don't think guile depends on that feature.
No, it doesn’t.
I’m slightly concerned about mini-gmp, though. It’s almost 5000 lines,
mostly copied from GMP AIUI, but with no way to synchronize. How do you
consider the maintenance cost of this?
I understand some people want this, and I’m happy you’re helping, but
the amount of work and duplication involved would definitely be a
showstopper for me if you and Mark weren’t helping.
- bug#10519: guile and (mini-)gmp,
Ludovic Courtès <=