gcl-devel
[Top][All Lists]
Advanced

[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




reply via email to

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