gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Roadmap


From: Mike Thomas
Subject: [Gcl-devel] Roadmap
Date: Sat, 25 May 2002 12:53:45 +1000

Hi Camm.

In general I think that 2.5 should really just be driven by the Maxima
release - ie if it builds a usable version of Maxima at the point that the
new version of Maxima is released, GCL should also be tagged and released.

I say this because I suspect that the only use GCL has is to support Maxima
(at present), and a stable version is critical for that.

I also think that 2.5 should be regarded as a simple
stabilization/consolidation of GCL post Bill Schelter's death where all the
old functionality has been restored on all relevant platforms.  It is then a
stable jump off point for some of the changes you propose.


>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.

Post 2.5 unless it is easy to do on all platforms.  Remember that shared
libraries on Unix are different from DLL's on Windows.  Don't know enough
about whether this is needed or not.

>2) Ansi-common-lisp compliance and compile-time test suite courtesy of
>   clocc.

No need before 2.5 I think.

>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.

Agreed, but leave until post 2.5.

> 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.

Once again the DLL vs shared lib issue could be a big problem

> b) Boehm garbage collector option.  They seem to already have
>    done the integration!  We could even make this runtime
>    switcheable.

I don't know enough to comment other than to say that we need to know what
is unique and good about each system to make a comparison.  My experience
with Boehm GC is that it is a Good Thing.

> c) several gcl-missing lisp features provided.

Very important for building third party libraries but post 2.5.


> 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.

I looked at ECLS a few months ago and could not get a quick build under
Cygwin on Windows, let alone a native Win32 port eg Mingw32.

I also believe (but may be wrong) that ECLS does not have dynamic
compilation and loading of native object code as GCL has.  I think that this
feature is very important.


> 4) Modern/robust Makefile system based on automake.

Very important but leave until after 2.5


> 5) 64bit ports

Not relevant to me.


>6) Incorporating Rainer's memory-integrity checking code as a
>   debugging option. (Haven't looked at this yet).

Don't know what this is.


>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.

Very important, but post 2.5


>8) Resizing default/initial memory image size to be more suitable for
>   typical use.

Should be done before 2.5 is released.


>9) Clean builds with -Wall.

Should be done before 2.5 is released


>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.

Before 2.5


>11) External interfaces -- gtk bindings, blas/lapack bindings, etc.
>    What if any are useful?

There is also a binding to PVM which would be really good I think.  GTK I
don't care about.  BLAS/LAPACK/FFTW would be 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.

I thought a lot about this one myself before working on the Mingw32 port.  I
personally don't use Common Lisp as I prefer Haskell/SML.  My main interest
apart from Maxima is that AKCL/GCL is an important historical part of Common
Lisp and I get a nice feeling using it with the following major exception:

I find it frustrating that we can't build things like the PDF library
recently release because there is no CLOS or defsystem, and my own mucking
around at home has been to investigate this area, but I don't have the
expertise to do it properly.

To catch up with the latest CL spec is a daunting task requiring a lot of
expertise and person power (or a brilliant hacker).

On the other hand, the dynamic native object compilation and loading feature
of GCL potentially opens up the possibility of building a completely self
contained development system (source and everything for compilers IDE etc)
in the same vein as a Smalltalk system.

That is a great strength, but once again, who is going to do it?

I fully endorse your proposal that the good bits from GCL and ECLS be
combined if possible.

Cheers

Mike Thomas.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]