[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gcl-devel] Roadmap

From: C Y
Subject: Re: [Gcl-devel] Roadmap
Date: Fri, 24 May 2002 16:15:21 -0700 (PDT)

--- Camm Maguire <address@hidden> wrote:
> Greetings!  Just a few thoughts for discussion regarding the roadmap
> to a 2.5.0 release.  Feedback is sought on which of these a) should
> be
> pursued at all, and b) should be completed prior to a 2.5.0 release.

OK, but keep in mind this is just my opinion, and not tremendously
informed opinion at that. 

> 2) Ansi-common-lisp compliance and compile-time test suite courtesy
> of clocc.

Would be very nice if this were completed before the 2.5.0 release.

> 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.  
>       a) having a shared library -llisp with all the lisp runtime
>          stuff needed by executables.  It really seems
>          unconscionable, even on large memory systems, to have so
>          much unshared memory in lisp programs.  Does anyone else
>          care about this, especially on multi-user systems?  It would
>          be near impossible, AFAICT, to run a modern unix system
>          which was written entirely in lisp for this reason.
>       b) Boehm garbage collector option.  They seem to already have
>          done the integration!  We could even make this runtime
>          switcheable.         
>       c) several gcl-missing lisp features provided.
> In fact, I'd like to know what advantages gcl currently has, if any,
> over ecls.  Bear in mind that I haven't used the system.

Have you had any discussions with the ecls folks about a merge?  The
proposal is worth making, if nothing else.
> 4) Modern/robust Makefile system based on automake.

I don't think this is critical before 2.5, but would be much
appreciated ;-)

> 5) 64bit ports

Would be nice, but I would say they probably aren't highest priority
unless someone else knows of a compelling reason.
> 6) Incorporating Rainer's memory-integrity checking code as a
>    debugging option. (Haven't looked at this yet).

Helpful, probably desirable as a step toward 2.5?

> 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.

This can probably be done post 2.5.

> 8) Resizing default/initial memory image size to be more suitable for
>    typical use.

Definitely needs to be done for 2.5.
> 9) Clean builds with -Wall.

Should be done for 2.5
> 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.

Needs to be done before 2.5.
> 11) External interfaces -- gtk bindings, blas/lapack bindings, etc.
>     What if any are useful?

I think this is a post 2.5 issue - gtk bindings exist for other lisps,
but to the best of my knowledge aren't terribly robust or well
maintained.  blas/lapack is both, but is not critical to the basic 2.5
gcl package, imho.  Ditto for the Garnet toolkit.
> Any feedback on the above is much appreciated.  In addition, I'd like
> some frank feedback on the following:
> 11) Is gcl useful?  Does it still provide something which isn't
>     readily available in other systems?  

Well, a straight compile with gcc (something CMUCL can't do) and better
speed than clisp would seem to make it unique.

>    I.e., frankly, is there a
>    need or even desire for gcl to continue?  Developing the system is
>     interesting, and even somewhat enjoyable, but it seems like a
>     waste of effort if everyone would rather use something else.  If
>     there are unique strengths of gcl, what are they?  What should we
>     concentrate on to truly provide a needed service for users,
> rather
>     than trying to simply catch-up to what is available somewhere
>     else?   Please don't get me wrong -- I don't mind working on gcl
>     at all, but I do want to be effective.

Not really qualified to address this one, beyond the points mentioned


Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience

reply via email to

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