[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: |
Gregory Wright |
Subject: |
Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0 |
Date: |
27 Aug 2002 11:44:19 -0400 |
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
- 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, Matt Kaufmann, 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/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, 2002/08/25
- Re: [Gcl-devel] Re: "COMMON-LISP" package in GCL 2.5.0,
Gregory Wright <=
- 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