[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
24 May 2002 18:37:26 -0400
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
2) Ansi-common-lisp compliance and compile-time test suite courtesy of
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
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.
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
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
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.
Camm Maguire address@hidden
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
- [Gcl-devel] Roadmap,
Camm Maguire <=