[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Roadmap
Re: [Gcl-devel] Roadmap
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
> 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
> 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
> 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,
> 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