[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0
From: |
Camm Maguire |
Subject: |
Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0 |
Date: |
25 Aug 2002 23:15:57 -0400 |
Greetings, and thanks very much for your helpful input here!
Gregory Wright <address@hidden> writes:
> Hi Camm,
>
>
> I guess my point is here that beyond a roadmap, we need a release
> engineering policy. It doesn't have to be fancy, just, "After we finish
<snip>
This is exactly right! Thanks for the proposal below. I've edited
and rearranged slightly, and integrated with the 'roadmap' document we
were putting together last May. Comments welcome. Perhaps we could
use this as a working release policy. I've added tentative goal dates
-- these could be greatly accelerated as far as I'm concerned if
anyone has a pressing need for a gcl release. CVS currently looks
fine to me :-). New items are labelled with n?) -- I hope to solicit
opinions about where these should go if anywhere. And some old items
we're deciding not to do -- I'll list these first:
Never:
=============================================================================
3) ecls -- I've been looking at our sister descendant of AKCL, and
they have a number of interesting developments which we might wish
to incorporate. In fact, we really should merge the projects, as
one of the *terrible* (IMHO) aspects about the lisp world is the
system fragmentation.
Status -- I received an email back from the ecls maintainer.
He doesn't feel a merge is viable.
6) Incorporating Rainer's memory-integrity checking code as a
debugging option. (Haven't looked at this yet).
Status -- not done. See below.
n9) Boehm conservative gc option
Status -- not done. In the course of working on gcl, I've
become convinced of the existing gc's correctness and
superiority for the task at hand.
2.5.0-alpha: (hopeful target -- 10/1?)
=============================================================================
1) shared external libgmp support.
Status -- done. (configure --enable-dynsysgmp)
5) 64bit ports.
Status -- done. Remaining issues on hppa are not 64bit
related. Code should now be 64bit clean. Confirmed on alpha
and ia64.
9) Clean builds with -Wall.
Status -- basically done. I need to trap -Wall output from
the compiler generated in maxima/acl2 builds to completely
verify.
n1) Eliminate void argument function prototypes, e.g. int foo().
These pass potential errors.
Status -- partially done.
n2) Make static all functions not used outside file of definition.
Status -- not done.
n3) Consolidate header files
Status -- not done.
n4) Working gcl/maxima (5.6 and 5.9) builds on all Debian architectures, sparc
solaris and mingw.
Status -- all but hppa last time checked.
n8) Ship -lgcl and gcl.h for ease of building when BFD relocations are
(temporarily) not available.
Status -- not done. In other words, we need to be able to
build maxima 5.9 on mips for example without having to
duplicate the entire gcl build tree as was previously
customary.
8) Resizing default/initial memory image size to be more suitable for
typical use.
Status -- invocation stack alone resized.
n13) autoloading policy
Status -- not done. We need to decide what will be an
irreducible gcl core, and what objects will be autoloaded on
demand, as readline is now for example. This should enable
maxima and acl2 users to retain a small footprint when we add
in ansi pcl support. We need to consider a size/speed
tradeoff here.
2.5.0-beta -- code freeze save bugs.
=============================================================================
10) Licensing -- we've added some new lisp code, which to my
understanding is all gpl compatible. But we need to double check
and document.
Status -- not done.
2.5.0-release -- code freeze save bugs.
=============================================================================
n10) gcl.info compiled from gcl.texi in distro.
Status -- not done.
n12) Documentation update.
Status -- not done.
2.6.0-alpha (hopeful target -- 1/1?)
=============================================================================
n5) BFD relocations everywhere, enabling save-system to retain loaded
objects.
Status -- all but Windows, alpha, ia64, and mips(el).
n6) Working gcl/acl2 builds on all Debian architectures, sparc
solaris and mingw.
Status -- Debian i386 verified.
n7) ANSI C vararg functions and prototypes.
Status -- not done. This will entail adding dummy arguments
to functions with no explicit arguments at present.
4) Modern/robust Makefile system based on automake.
Status -- more configuration items determined automatically by
configure. Eventually, we should not need .h/.defs by
default, i.e. barring extraordinary circumstances. We should
leave the possibility for such files in the build
indefinitely, to allow the user to override configure easily
if necessary.
7) Performance analysis, enhancement. I'd really like to know where
the bottlenecks are from those who use the system heavily. Am
already aware of gc as one.
Status -- not done.
n15) Improve random number/hashing support
Status -- not done. I like the Cokus generator, which we
could modify to use mmx if we wish. How important is hash
lookup to lisp performance? Are all symbol to function
mappings handled this way?
3.0-alpha (Hopeful target -- 6/1?)
=============================================================================
2) Ansi-common-lisp compliance and compile-time test suite courtesy of
clocc.
Status -- Some progress made. This should be handled as Greg
outlines below, with skeleton support preceding full support.
11) External interfaces -- gtk bindings, blas/lapack bindings, etc.
What if any are useful?
Status -- not done.
n11) Compile floating point loops to blas calls.
Status -- not done.
n14) merge gcc frontend tree in preparation for submission of gcl as
official lisp compiler of the gcc family.
Status -- not done.
n16) Multi-threading/parallel processing
Status -- not done.
I'd love to hear any thoughts on this. I'm very flexible regarding
the details, but I think that Greg is right in saying we need *some*
policy, whatever it may be. So lets consider this our "working
policy", by which I mean I'll be happy to alter over the next few days
in response to any well-reasoned arguments.
Take care,
> Here's a proposal, based on the roadmap discussion from May. I welcome
> discussion and the best way to get it going is to propose something
> specific.
>
> 1. For 2.5.0-alpha:
>
> Clean build on all debian platforms with -Wall.
> libbfd issues resolved on all platforms (even if that
> means libbfd won't be supported on that platform).
>
> We define a regression test that all builds must pass
> (build maxima and ACL2 + tests cleanly on all platforms?)
>
> When we get the cvs HEAD to a 2.5.0-alpha state, we open a 2.5 branch.
>
> 2. For 2.5.0-beta:
>
> Licensing checks
> Make sure bignum arithmetic works on all platforms.
> Code freeze on this branch except for bugfixes.
>
> 3. For 2.5.0-release_candidate:
>
> Everything done but documentation (this is sour chance to sync
> up the documentation with all the work that has gone before).
>
> 4. Release 2.5.0
>
> Release with documentation.
> 2.4.x will be deprecated; users urged to upgrade to 2.5.x.
>
> 5. Fix the obvious 2.5 bug that releasing roots out.
>
> 6. HEAD starts toward 3.0, ANSI compliant GCL
>
> Define which ANSI tests we will require GCL pass (really,
> this means understand the test suites).
>
> 7. Intermediate goal: COMMON-LISP skeleton complete
>
> Every symbol in the COMMON-LISP package has skeleton
> support (the right arguments) even if it doesn't work yet.
>
> 8. Intermediate goal: COMMON-LISP core complete
>
> Almost everything in COMMON-LISP almost works.
>
>
> 9. Intermediate goal: Modernize the build system
>
> Use modern automake/autoconf setup. May break compatibility
> with autoconf-2.13 and earlier (but 2.5.x should still build
> with older autoconfs).
>
> 10. 3.0-alpha release
>
> Feature complete.
> branch the cvs
>
>
>
> When we see how that's going we could set specific goal dates for alpha,
> beta and release_candidate builds.
>
> Naturally, a plan like this gets fuzzier as it extrapolates into the
> future. Items 7, 8 and 9 involve a lot of parallel work.
>
> Goals and especially release target dates are good because they help us
> decide what has to be done and what can wait. If we can get this plan
> into good shape, we can start asking what dates could go onto items 1, 2
> and 3.
>
> >
> > > I'm certainly trying to encourage us all to look at what we can possibly
> > > avoid doing. Our company's software team is about the same size as
> > > gcl's. We have to be pretty ruthless in deciding what really needs to be
> > > done. Ars longa, vita brevis!
> > >
> >
> > I agree whole-heartedly and love this new phrase!
> >
>
> Best Wishes,
> Greg
>
>
> --
>
> Gregory Wright
> Chief Technical Officer
> PacketStorm Communications, Inc.
> 20 Meridian Road
> Eatontown, New Jersey 07724
>
> 1 732 544-2434 ext. 206
> 1 732 544-2437 [fax]
> address@hidden
>
>
>
>
> _______________________________________________
> 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
- Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0, (continued)
- Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0, Camm Maguire, 2002/08/10
- Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0, Matt Kaufmann, 2002/08/10
- Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0, Camm Maguire, 2002/08/14
- Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0, Camm Maguire, 2002/08/10
- Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0, Gregory Wright, 2002/08/10
- Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0, Camm Maguire, 2002/08/14
- Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0, Gregory Wright, 2002/08/15
- Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0,
Camm Maguire <=
- Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0, Gregory Wright, 2002/08/27
- Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0, Vadim V. Zhytnikov, 2002/08/12
- Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0, Gregory Wright, 2002/08/12
Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0, Camm Maguire, 2002/08/23