[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gcl-devel] ["D. Goel" <address@hidden>] Re: Gcl roadmap
From: |
Camm Maguire |
Subject: |
[Gcl-devel] ["D. Goel" <address@hidden>] Re: Gcl roadmap |
Date: |
03 Jun 2002 18:14:03 -0400 |
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 -------
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gcl-devel] ["D. Goel" <address@hidden>] Re: Gcl roadmap,
Camm Maguire <=