[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Release proposal
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] Release proposal |
Date: |
09 Feb 2003 17:16:29 -0500 |
Greetings!
Am checking in 3) now. Bye bye varargs, hello gcc 3.3 and higher.
Please let me know if anything breaks. Self-compilation, test-suite,
maxima and acl2 all appear to work as before.
Take care,
Camm Maguire <address@hidden> writes:
> Greetings! I'd like to do the following if feasible:
>
> 1) release 2.5.0 on or about 2/15
> 2) possible minor bugfix if necessary release by 2/25
> 3) be largely unavailable for GCL work from 3/1 - 6/1
>
> The question now is what should go in this release. Unfortunately,
> even if we do ship an ansi binary, it will be considerably incomplete.
> It still may be worth doing, but we have to find a way to clearly
> indicate to the user that ansi support is still a work in progress,
> lest (s)he become disenchanted :-). Here is the most ambitious plan,
> which may be doable:
>
> 1) rework the ansi build to load the pcl and clcs modules in the .text
> section, as is currently done with modules in the lsp and cmpnew
> directories. This will enable people wanting to do a (si::link
> ...) build of, say, maxima with the ansi image should they desire.
>
> 2) Ship both images, and have the shell wrapper toggle with the -ansi
> switch.
>
> 3) Eliminate varargs, and verify that GCL will consequently build with
> gcc 3.3
>
> Unfortunately, it looks as if the following will have to wait, though
> this is now my preferred long term solution to the image size
> question:
>
> 4) Load as many modules as possible via the autoload mechanism
> currently used for readline.o.
>
> I'd also like to run the test suite as part of the build, and compare
> against a known failures list. It seems that there are a few
> very minor issues remaining accounting for a large majority of the
> failures. It would be nice to get a small list of simple fixes which
> would reduce the failure number as much as possible. For example,
> (typep <vector object> <array-class>) is nil. but (typep <vector
> object> <vector-class>) is t. I thought typep was not supposed to
> traverse the class-precedence list (unlike subtypep)? I can't see
> from the spec where the existing behavior is wrong.
>
> Take care,
>
> --
> Camm Maguire address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens." -- Baha'u'llah
>
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
>
>
--
Camm Maguire address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah