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

[Camm Maguire]

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