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 ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire <····@enhanced.com> writes:
> 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.
I'm not a GCL user, but as much as I know it compiles to C code,
doesn't it? This might have an advantage when using CL as an
extension language, compared with the slower bytecode compilation of
CLISP, and the fact that the native code compilation of CMUCL does not
run on every platform. Maybe you could talk Stallman into replacing
Guile with GCL:-)?
Yours, Nicolas.
Greetings!
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> Camm Maguire <····@enhanced.com> writes:
>
> > 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.
>
> I'm not a GCL user, but as much as I know it compiles to C code,
> doesn't it? This might have an advantage when using CL as an
> extension language, compared with the slower bytecode compilation of
> CLISP, and the fact that the native code compilation of CMUCL does not
> run on every platform. Maybe you could talk Stallman into replacing
> Guile with GCL:-)?
>
Yes, you are correct -- this is the gcl design. I thought it a
particularly good idea too, which is why I wanted to keep it going. I
was just wondering if compiling lisp to C is still relatively unique
in the free lisp world.
Thanks for your reply!
> Yours, Nicolas.
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
I have been playing with GMP (Gnu multiple precision) with
Allegro CL, and the results suggest that replacing
multiplication (etc) with GMP may not be what you want.
If you wish to exploit GMP then you should provide
access to programs like (mpz_addmul target a b) which
does this: target <- target+a*b.
Needless to say, this is not very lisp or functional-programming-ish.
If you wish to use GMP as a substitute for all arithmetic,
you will miss out on the way-faster fixnum arithmetic
that does 99.99% of the lisp arithmetic. If you allocate
the 3-word header for gmp numbers as lisp arrays and
then finalize the GC of these arrays by telling GMP
to clear its own storage, you may find this less
work that what you were thinking about. Or maybe not;
it is not clear what you are allocating.
Incidentally, I have found it quite difficult to compile
GMP4 to make a windows dll. I am using GMP3.1 successfully,
starting with a dll kindly made by the Python people!
RJF
Richard Fateman <·······@cs.berkeley.edu> writes:
> I have been playing with GMP (Gnu multiple precision) with
> Allegro CL, and the results suggest that replacing
> multiplication (etc) with GMP may not be what you want.
What about using the library extracted from clisp by Bruno Haible?
CLN - Class Library for Numbers
http://www.ginac.de/CLN/
It's C++ and GNU GPLed (as opposed to, say, LGPL'ed),
but if you can live with that, it is designed precisely
for the use you intend: being used in a Lisp implementation.
Just my .2 mg of gold worth.
[ Fran�ois-Ren� �VB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[ TUNES project for a Free Reflective Computing System | http://tunes.org ]
/let theory guide your observations/, but till your reputation is well
established, be sparing in publishing theory. It makes persons doubt your
observations. -- Charles Darwin to a young botanist
Francois-Rene Rideau <····@tunes.org> writes:
> Richard Fateman <·······@cs.berkeley.edu> writes:
> > I have been playing with GMP (Gnu multiple precision) with
> > Allegro CL, and the results suggest that replacing
> > multiplication (etc) with GMP may not be what you want.
> What about using the library extracted from clisp by Bruno Haible?
> CLN - Class Library for Numbers
> http://www.ginac.de/CLN/
> It's C++ and GNU GPLed (as opposed to, say, LGPL'ed),
> but if you can live with that, it is designed precisely
> for the use you intend: being used in a Lisp implementation.
>
> Just my .2 mg of gold worth.
Ah, converted to the Gold Standard, have you? You must be one of
those freaks who doesn't believe in valueless money...
NIHIL EX NIHIL -- DON'T SETQ NIL
'james
--
James A. Crippen <·····@unlambda.com> ,-./-. Anchorage, Alaska,
Lambda Unlimited: Recursion 'R' Us | |/ | USA, 61.20939N, -149.767W
Y = \f.(\x.f(xx)) (\x.f(xx)) | |\ | Earth, Sol System,
Y(F) = F(Y(F)) \_,-_/ Milky Way.
On 30 May 2002 11:39:22 -0400, Camm Maguire <····@enhanced.com> wrote:
>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!
Hello! I dont know if I should be writing this. I have just started
to learn Lisp... But I have been hanging at c.l.l for some time now
and what I observe is that _most_ of the wise and the intelligent here
feel _very_ strongly about Ansi CL compliance. So maybe that should
be higher on your priority list?
>2) Ansi-common-lisp compliance
quasi
>==========================================================================
>"The earth is but one country, and mankind its citizens." -- Baha'u'llah
how true.
>>>>> "Camm" == Camm Maguire <····@enhanced.com> writes:
Camm> Greetings! I posted this to the gcl-devel mailing list, and
Camm> thought that it would be very helpful to forward here as
Camm> well to solicit useful feedback. Any comments most welcome!
Camm> Greetings! Just a few thoughts for discussion regarding the
Camm> roadmap to a 2.5.0 release. Feedback is sought on which of
Camm> these a) should be pursued at all, and b) should be
Camm> completed prior to a 2.5.0 release.
Here are some comments from an occasional user of GCL.
Camm> 1) shared external libgmp support.
I think that ecls has solved this problem, maybe you can see how they
did it?
Camm> 2) Ansi-common-lisp compliance and compile-time test suite
Camm> courtesy of clocc.
Good!
Camm> 3) ecls -- I've been looking at our sister descendant of
Camm> AKCL, and they have a number of interesting developments
Camm> which we might wish to incorporate. In fact, we really
Camm> should merge the projects, as one of the *terrible* (IMHO)
Camm> aspects about the lisp world is the system fragmentation.
Camm> a) having a shared library -llisp with all the lisp runtime
Camm> stuff needed by executables. It really seems
Camm> unconscionable, even on large memory systems, to have so
Camm> much unshared memory in lisp programs. Does anyone else
Camm> care about this, especially on multi-user systems? It would
Camm> be near impossible, AFAICT, to run a modern unix system
Camm> which was written entirely in lisp for this reason. b)
Camm> Boehm garbage collector option. They seem to already have
Camm> done the integration! We could even make this runtime
Camm> switcheable. c) several gcl-missing lisp features provided.
Camm> In fact, I'd like to know what advantages gcl currently has,
Camm> if any, over ecls. Bear in mind that I haven't used the
Camm> system.
GCL (2.4.0) builds on Solaris 2.8 (sparc), ECLS (0.4) does not.
Camm> 4) Modern/robust Makefile system based on automake.
Nice, out-of-directory build (i.e. $someplace/configure ; make) did
not work in 2.4.0.
Camm> 5) 64bit ports
Camm> 6) Incorporating Rainer's memory-integrity checking code as
Camm> a debugging option. (Haven't looked at this yet).
Camm> 7) Performance analysis, enhancement. I'd really like to
Camm> know where the bottlenecks are from those who use the system
Camm> heavily. Am already aware of gc as one.
Camm> 8) Resizing default/initial memory image size to be more
Camm> suitable for typical use.
Camm> 9) Clean builds with -Wall.
Camm> 10) Licensing -- we've added some new lisp code, which to my
Camm> understanding is all gpl compatible. But we need to double
Camm> check and document.
Camm> 11) External interfaces -- gtk bindings, blas/lapack
Camm> bindings, etc. What if any are useful?
Maybe matlisp could be used with GCL?
Camm> Any feedback on the above is much appreciated. In addition,
Camm> I'd like some frank feedback on the following:
Camm> 11) Is gcl useful? Does it still provide something which
Camm> isn't readily available in other systems? I.e., frankly, is
Camm> there a need or even desire for gcl to continue? Developing
Camm> the system is interesting, and even somewhat enjoyable, but
Camm> it seems like a waste of effort if everyone would rather use
Camm> something else. If there are unique strengths of gcl, what
Camm> are they? What should we concentrate on to truly provide a
Camm> needed service for users, rather than trying to simply
Camm> catch-up to what is available somewhere else? Please don't
Camm> get me wrong -- I don't mind working on gcl at all, but I do
Camm> want to be effective.
I think that it fills a niche due to its smaller size and better
portability w.r.t. CMUCL/SBCL and its native code compiler
w.r.t. CLISP. Merging (or at least cooperating) with ECLS would be a
good thing though.
--
best regards
Roland Kaufmann