[Gcl-devel] ["D. Goel" <address@hidden>] Re: Gcl roadmap

[Camm Maguire]

Greetings!  Just forwarding this comment for discussion.  

Not to worry, I'm sure we'll clearly win out over franz in the near
future! :-)).

Take care,

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah
------- Start of forwarded message -------
To: Camm Maguire <address@hidden>
Subject: Re: Gcl roadmap
References: <address@hidden>
From: "D. Goel" <address@hidden>
Date: 02 Jun 2002 21:17:40 -0400
Message-ID: <address@hidden>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Camm

as to your last question: is it still useful?

i am extremely supportive of free software, and if i had a choice,
would use somethign that is a part of the GNU project.. i care far
less about ANSI compliance than about "GNU" compliance :)

but alas, my company has used Franz's common lisp for the past 16
years.. but i plan to change that as soon as i get a chance :).. my
dream remains to change it all to be GCL-based :)


> Greetings!  I posted this to the gcl-devel mailing list, and thought
> that it would be very helpful to forward here as well to solicit
> useful feedback.  Any comments most welcome!
> 
> Take care,
> 
> =============================================================================
> 
> 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.
> 
> 1) shared external libgmp support.
>       Its now clear how this should be done -- we'd have to define a
>       static array for bignum mallocs, like we do for the bfd struct
>       malloced on bfd open, and wrap the gmp mul calls to precede
>       them with a malloc function redirect to a function assigning
>       this static space.  Pros: relieves us of the burden of syncing
>       with gmp, can be used for other external libs calling malloc,
>       should have no noticeable performance impact, Cons: have to
>       carry a static space alloced by all executables big enough for
>       reasonable usage, and failing if exceeded.  We already have a
>       number of static stacks which cause an abort if filled, so
>       this won't be terribly different.  But we really need to
>       consolidate them into one big static area, instead of having
>       many separate abort conditions on single function arrays.
>       R. Toy mentioned, if I understood correctly, that CMULISP has
>       a large such area for external function memory access which is
>       kept separate from the lisp heap.  I still don't understand
>       what the big issue is about *access*, if one can temporarily
>       shut off gc, but this seems ideal/essential for external
>       *mallocs*. 
> 
> 2) Ansi-common-lisp compliance and compile-time test suite courtesy of
>    clocc.
> 
> 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.
> 
> 4) Modern/robust Makefile system based on automake.
> 
> 5) 64bit ports
> 
> 6) Incorporating Rainer's memory-integrity checking code as a
>    debugging option. (Haven't looked at this yet).
> 
> 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.
> 
> 8) Resizing default/initial memory image size to be more suitable for
>    typical use.
> 
> 9) Clean builds with -Wall.
> 
> 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.
> 
> 11) External interfaces -- gtk bindings, blas/lapack bindings, etc.
>     What if any are useful?
> 
> 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?  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.
> 
> Take care,
> 
> -- 
> Camm Maguire                                          address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah



DG                                 <http://www.glue.umd.edu/~deego/>
-- 
Seen on slashdot (Mignon)
Microsoft - "Where do you want to go today?"
Translation - "Let us take you for a ride." 


------- End of forwarded message -------