I haven't been watching this stuff very carefully
because I have been waiting for it to settle down
and then
(a) downloading a new xmaxima for windows
and
(b) downloading the source and seeing if it
can be trivially compiled for Allegro CL.
(as was true in the past).
But I thought I'd mention that I had this problem
with xmaxima and timing out when I was using
it with a windows NT 200Mhz system, and Bill Schelter
and I went back and forth over this; he ended up
waiting a lot longer. For my part, I switched
to Windows 2000 and a 933Mhz machine, and the
problem went away. Obviously this was some time
before the latest flurry of activity.
It seems to me it would be nice to try to maintain
any hooks from xmaxima to other systems (whether the
hooks are attached or not...) as long as they are
not problematical.
Also I have some experience with GMP. It is not
obvious that this will make GCL/maxima faster "on average"
though GMP is going to win substantially on numbers
that are more than a few words in length. There is,
as has already been mentioned, a need to figure out
how to configure GMP for some reasonable lowest-common-denominator
machine, since it has many optimizations that cannot
be run everywhere. Putting ALL of GMP up-front as
accessible to Maxima might be neat. It is not just
a bignum package.
RJF
Camm Maguire wrote:
> Greetings!
>
> C Y <smustudent1@yahoo.com> writes:
>
>
>>--- James Amundson <amundson@fnal.gov> wrote:
>>
>>>Here is what I think the criteria should be for release candidate 2:
>>>
>>>1) Show-stopping bugs in rc1 fixed.
>>> -Done, or nearly so. The worrying thing lately is with the
>>>socket problems recently observed under windows. I would really like
>>>to hear if the same problem appears using clisp. Is anyone doing
>>>windows builds with clisp?
>>>
>>Jim, what's the ultimate goal there for Windows? Do we go with
>>whichever Lisp gives us a fully operational build more quickly, or do
>>we want the speed gcl can give?
>>
>>
>
> Just a note here -- if anyone finds a *gcl* issue on Windows
> preventing a successful maxima build, please so report on
> gcl-devel@gnu.org. To my understanding, there are none currently.
> While I don't use Windows myself, there are a number of developers who
> do, and we want to ensure that gcl is supported there.
>
>
>>>2) Camm's alternative gcl linking procedure added.
>>> -Mostly done. Needs more (some!) testing.
>>>
>>What procedures would we do to test that?
>>
>>
>
> With the additional Makefile.am patch I sent James recently, I've
> verified the build in a preliminary fashion on i386 Linux. Typically,
> I'd wait until the maxima release to put together the 5.9 Debian
> maxima package, which would effectively test the build on now more
> that 11 architectures simultaneously. I might be persuaded to put the
> package together before release, if that would assist in shaking out
> bugs.
>
>
>>>3) Binary packages for RedHat Linux (and other rpm-based
>>>distributions)
>>>and Windows.
>>> -Linux: Nearly done. (Sample packages are building as I
>>>speak.)
>>> -Windows: Great progress has been made. I hope we will have
>>>solid packages soon.
>>>
>>I know this probably isn't strictly relevant to this release, but is
>>the Debian package maintainer still active? Also, has anyone thought
>>
>
> That would be me :-). Maxima 5.6 binaries are available on 10 out of
> the 11 Debian architectures, all based on current GCL cvs. I'm not
> planning to support any other lisps for maxima on Debian, as Debian
> packages need to be very portable, and clisp and cmulisp don't nearly
> have the coverage of Debian architectures that GCL has at present.
>
> Take care,
>
>
>