gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: [Maxima] GCL


From: Camm Maguire
Subject: [Gcl-devel] Re: [Maxima] GCL
Date: 14 Dec 2001 12:40:04 -0500

Greetings, and thanks for these pointers!

Tuukka Toivonen <address@hidden> writes:

> On 13 Dec 2001, Camm Maguire wrote:
> 
> >3) Dr. Schelter seems to have been reworking the gmp support in the
> >   CVS tree shortly before he passed away.  Does anyone know what he
> >   was intending to do?  Scrap gmp?  Incorporate a smaller piece?
> 
> I think you have probably already done this, but check out the
> mailing list archive at
> 
>    http://www.math.utexas.edu/pipermail/maxima/
> 
> There seems to be some messages from Mr. Schelter such as
> 
>    Date: Fri, 11 May 2001 00:48:10 -0500
>    Subject: Re: [Maxima] gmp config + propagating errors at top level compile
>    Message-Id: <address@hidden>
> 
> and
> 
>    Date: Fri, 27 Apr 2001 01:40:20 -0500
>    Message-Id: <address@hidden>
>    Subject: Re: [Maxima] 10000! (Sorry... but)
> 
> 
> I doubt that he wasn't removing the gmp code (after all, it had
> just replaced the older GP/Pari code). One of the concerns
> presented was the fact that Maxima couldn't be linked with
> existing gmp library; but the modified gmp source code had to be
> included within Maxima.
> 
> 

I think you are right in your assessment.  Some of the posts you cite
above were in response to questions I had asked him regarding
difficulties I had with the Debian maxima package.  I had forgotten
the following detail, which might provide us with a clue:


   I am afraid that change is necessary at least for the current
   implementation in GCL.  Basically it is so we can use the strategy
   for garbage collection.  I will try to convince the gmp authors to
   make the change.  Also I would like to use a relocatable space
   strategy for the bignums, but that will require some more minor
   changes to gmp.  I think I have almost made them, but there is at
   least one that is illuding me. [ (si::SET-GMP-ALLOCATE-RELOCATABLE
   t) will switch to relocatable, but some random bugs will appear if
   you compute a lot!]

This was written on 5/14, shortly after he had released 2.4.0 with the
new gmp support.  The latest cvs he has does not compile, as the gmp
stuff is in a state of flux.  He removed the configure/libtool/make
files in the gmp directory, and removed the gmp.h file defining key
gmp related function types which are necessary for gmp_big.c to
compile, for example.  Perhaps he was working on this relocatable
strategy. 

Here is what I think we should do:

1) Back port a minimal set of files from 2.4.0 to get a working CVS
   build, then tag it.
2) Understand this relocatable strategy bit, together with the bug he
   was seeing.  It will take me some time to understand how this works
   in the code, so this process could be accelerated if someone would
   please enlighten me on how lisp systems/gcl makes use of
   relocatable space and in general how it does its garbage
   collection and memory management.
3) Get a working relocatable gmp bignum build into cvs, and tag it.
4) Try to develop the gmp usage to safely use the externally supplied
   dynamically-linked gmp library.  This would especially be useful
   for distributions, as gmp can use several non-portable sets of ISA
   extensions speeding things up enormously on certain
   sub-architectures. 

Any comments/insights most appreciated!


> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah



reply via email to

[Prev in Thread] Current Thread [Next in Thread]