Re: [Gcl-devel] Roadmap

[Vadim V. Zhytnikov]

Camm Maguire wrote:

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

We have very large number of missing features to add, very ...
So, lets do it step by step.  The good thing is that probably
many of such missing items could be borrower from other
free CL implementation.

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

I'm not so sure about merging gcl with ecls but at least
we can make use some of ecls' results.

>
> 4) Modern/robust Makefile system based on automake.
>
> 5) 64bit ports
>

I think that 4 and 5 are welcomed but could wait a bit.

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

I'm ashamed  but I know nothing about this.

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

Well, one bottleneck is known already - GC and memory management.

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

The way like GCL compiles lisp code using system's C compiler
seems to be unique among other CL implementations.  And it works
quite well.  Potentially GCL is very fast.  With some improvements
it can be even faster than CMUCL. At least it already beats it on
some my tests.  In addition GCL, unlike CMUCL, is quite portable.
It seems that presently thisis the only free CL which run on Win32.

>
> Take care,
>
> --
> Camm Maguire                                            address@hidden
> ==========================================================================
> "The earth is but one country, and mankind its citizens."  --  Baha'u'llah
>
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel

--
     Vadim V. Zhytnikov

      <address@hidden>
    <address@hidden>
     <address@hidden>