[Gcl-devel] Re: gcl

[Camm Maguire]

Greetings!

Gene Michael Stover <address@hidden> writes:

> Hi Camm,
> 
> Robert read said you still haven't received my reply message.
> Here's another copy.
> In case it matters, I usually send e-mail from "address@hidden".
> 

Please accept my apologies if I've misplaced your earlier mail.

> --- forwarded message ---Date: Fri, 28 Dec 2001 18:04:36 -0800
> From: Gene Michael Stover <address@hidden>
> To: Camm Maguire <address@hidden>
> Subject: Re: gcl
> 
> Hey Camm,
> 
>  > Certainly!  If you would, please register as a user at
>  > savannah --
> 
> Done.  I'm "gstover".

Great!  I've added you on the site.  Welcome to the project!

> 
>  > Then maybe we can talk about
>  > what you'd like to work on.  What is your background?=3D20
> 
> I'm a software engineer with 10+ years experience, mostly
> with C/C++ on Unix in the wireless telecomm industry.  I've
> done Lisp as a language of choice off & on since university,
> but I've been serious about Lisp for only about two years
> when I learned it specifically because it was different from
> C, C++, Java, & everything else I had used, and I wanted to
> expand the ways in which I was able to think about
> algorithms.  If you want to see my professional resume, it's
> 
> at (http://gms.freeshell.org/resume.html).  Basically, I
> have a firm grounding in theory, including compilers, and
> extensive experience in Unix, C, C++ application
> development, but it's been over 10 years since I wrote a
> line of assembly or toggled address lines, so if we get into
> stuff where we map the OS's virtual memory / pager into
> Lisp's memory manager, then I'll have some learning to do
> first.

Wonderful!  Sounds like you have valuable experience which will be
very helpful!

> 
> I'll be happy to help in whatever way is needed--even baking
> cookies, if that's what was needed--but if I were to suggest

Hmm, cookies sound nice :-)!

> something specific: The last I tried installing GCL was
> about November.  At that time, as the previous few times, it
> didn't build & install.  I'd like to give the installation
> system a revamp so it works easily.  So that even if someone
> builds & installs a GCL that's missing some features or has
> a bug, at least they get a GCL without having to gnash their
> teeth. (You might notice on my resume that an interest &
> common task for me is to manage the build & installation
> systems & the "portability framework".  And I have a lot of
> experience with getting the installation system to solve
> portability issues so that the app's code doesn't need to
> worry about it--doesn't even need to use conditionalcompilation.)
> 

This is important to me too.  We've made a number of changes in cvs to
enable clean compilation without tcl/tk, and without emacs, but these
need testing.  Your comments are most welcome.  I think we also need
to take a hard look at issues arising from compiling on one box and
running on another.  This shouldn't be harder than adding some options
to the configure script, like --with-gmp-subarch, --with-linux-kernel
(if necessary), etc.  Then we will have to make sure that to the
extent the gcl needs to run on the compiling box, which it does, that
it can do so with sane default options.  I put together an atlas
package for Debian with similar issues.  There, all the particular
stuff was isolated into small shared libs, and the compilation was run
with LD_LIBRARY_PATH set to the default lib version.

Personally, though, I think the project will benefit most from getting
the following as quickly as possible

1) stable Linux i386 builds in all flavors
2) stable cygwin i386 builds
3) the most annoying non-ansi-ness removable with a runtime switch
   -ansi. 

The above are what make gcl unpopular at present.

The long term natural strengths of gcl should be its
portability/performance combination.  For this to be demonstrated, we
should also get

4) stable builds on all non-x86 Linux arches  (to this end, I'ma about
   to commit a 2.5.0 which uses the external bfd library for
   (hopefully portable) relocations.  I'd greatly appreciate feedback
   when this happens!)
5) stable builds on Mac OS X, the BSD'es, and hopefully True64 Alpha &
   OpenVMS 
6) stable interfaces to third party high quality high performance
   packages where feasible, e.g. the gmp currently in the tree, and
   the pari stubs in the code, etc.  Other thoughts are external
   garbage collectors, and perhaps interfaces to optimized linear
   algebra libs, though it would appear that most people don't use
   lisp for strictly numerical stuff.  We should *externalize* these
   facilities and make them options as much as possible.  I.e., link
   them in as 3rd party shared libs.  Again, the gmp shows us that gcl
   should be able to do this relatively easily.  I've built the gmp
   sub tree as a shared lib, and it does work.

Anything we can do on the above will bring maxima at least to a wider
audience.  This is perhaps the most useful open-source CAS package
available.  The more users, the more helpers!

And then my wish list:

7) Clean the code!  No errors with -Wall, comment, etc.
8) dlopen instead of fasload.
9) look into the Boehm conservative garbage collector.  Can we do
   without a garbage collector, and just 'free' at the appropriate
   time? 
10) Remove all the macro cruft.  Many are vestiges, and do nothing.  I
    think that we should eliminate all the arch.h and arch.defs files,
    have these determined by configure, and use Makefile.in's

All these priorities are certainly open to discussion.  Please
contribute your thoughts!

Right now, we have a relatively small "beachhead" on i386 Linux, and
even this is not completely reliable.  GCL still makes the best maxima
(performance wise) by a long shot, but the developers there are moving
toward lisp agnosticism, as they should.  So we have a window of time
here to quickly demonstrate gcl's strengths.  I'm very happy with the
level of interest expressed thus far!  If we succeed, I expect this
will continue to grow.

In sum, with your background, I'd be most appreciative if you could
help with tracking down this bug on the latest Linux systems.  I'd be
ready to pronounce it stable when it can run maxima's make test on all
Linux versions, can run with GET_FAULT_ADDRESS and SGC commented out,
gcc 3.0 and gcc 2.95, kernel 2.2.x and kernel 2.4.x, and with a range
of optimization flags.  In this effort, I think it will help us
greatly to make use of the DEBUG macro presently in the code
(i.e. maxima's make test should produce no debugging warnings), and
getting a stand-alone sfasl loader to exactly match the output of ld. 

But above all, please feel free to work on what *you* feel is
important.  That is probably what other users want too!

Take care,

> But like I said, I'd like to help with anything that's
> needed.
> 
>  > My only request
>  > is that if you ever get to the point where you would like to commit
>  > something to the cvs tree instead of submitting a patch, that we
>  > discuss it first at least the first time around, so we can work on
>  > some sane policy to keep us from interfering with one
>  > another.
> 
> Goes without saying.  To quote Geddy Lee on the /Great White
> North/ album: "Hey, I'm a professional". ;-)
> --- end forwarded message ---
> 
> -- 
> Gene Michael Stover (address@hidden)
> God, how I love Lisp.
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah