Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0

[Gregory Wright]

Hi Camm,

Thanks for giving this a close reading. I'll get back to working on the
autoconf system and source tree layout as soon as I get past an
especially nasty device driver problem at work.

Best Wishes,
Greg


On Sun, 2002-08-25 at 23:15, Camm Maguire wrote:
> 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
-- 

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