Re: [Gcl-devel] General GCL quesions

[Camm Maguire]

Greetings, and thanks for your interest in GCL.

Chris Hall <address@hidden> writes:

> I'm new to lisp - so new that I haven't settled on a 'primary' lisp
> yet - though I *have* decided on lisp over scheme.  If languages can
> be said to have attitudes, I think I like lisp's 'attitude' better
> than any other language in all my years of programming.
> 
> But I am truly beginning to appreciate why everybody on c.l.lisp seems
> to keep several 'flavors' around and to be fairly proficient in at
> least two: each implementation of lisp seems to be better at some
> things than at others.  This is probably actually a good thing for the
> community, but I think it tends to be bit frustrating at times (as I
> am sure most lispers have experienced), and confusing at best for us
> newbs.
> 
> I run Debian Woody, and believe strongly in free (as in speech)
> software.  I've got CMUCL 18e, SBCL 0.8.9, and the Debian stable CLISP
> 2.2.7 and GCL (2.5.0+cvs) packages.  I have also downloaded asdf,
> cl-sql, portable aserve, CL-HTTP, McCLIM, Garnet plus a few others,
> and gotten them all to work under at least one distribution.  I've
> learned in the process the rudiments of current practices/methods in
> packaging, distributing, configuring, building and installing lisp
> libraries/systems/whatevers.
> 
> I prefer PostgreSQL for my database (Python stored procedures!).
> 
> My primary interest these days is in developing web-facing
> applications - my colleagues seem to have this focus as well.  Most
> recently, I used Python (the language) for this, but I've decided on
> lisp for this use, for a lot of reasons.
> 
> With that said, I have for some reason been particulary drawn to GCL,
> even after having read a *lot* of the (historical) posts on c.l.lisp
> where GCL is discussed.  To be honest, my attraction to GCL is against
> my better judgement - if I were to emphasize practicality, I think I
> would have to settle on CMUCL - it seems to be by far the most widely
> supported implementation, though it is 'only' 'free as in beer'.  And
> if it weren't for GCL's stated intention of gaining ANSI compliance,
> I'd be in a real pickle since CLISP - the only other 'free as in
> speech' lisp of which I am aware - doesn't compile to native code,
> which is a 'must' for me.
> 

My rudimentary understanding of the history of lisp evolution with
regards to GCL is that GCL was one of the first 'free as in speech',
widely portable, natively compiling lisp systems with good performance
that still exists today.  real people used it for real products,
mostly in AI, and at a time when the ansi standard was not completed,
perhaps not even started.  Then the ANSI spec solidified a major
revision in the definition of the language, one including major
components such as the object system which were either new or formerly
optional add-ons.  To my knowledge, no end-user open-source
application has yet been built on this newer specification -- all
existing self-contained open-source user lisp apps use and perhaps
even require the older standard, known as CLtL1.  Here I'm thinking of
maxima, acl2, axiom, nqthm1992, and pc-nqthm1992.

GCL has therefore decided to support both standards, supplying
traditional/CLtL1 and ANSI images, the latter of which is a work in
progress.   Each Debian GCL package has both images, the toggling of
which is achieved through setting the environment variable GCL_ANSI to
any non-empty string.  In recent GCL, the flavor will appear in the
splash statement.

GCL also has a stable branch of development, currently labeled at
2.6.x, and an unstable branch, 2.7.x.  In brief, for heavy AnSI work I
recommend the ansi image of the unstable branch.  I've packaged this
separately for Debian as gclcvs.  This can be installed simultaneously
with gcl.

I would very much recommend in either case compiling the source from
Debian unstable to your stable system, make a .deb and install it.
Are released Debian packages with very few exceptions always represent
an improvement and have been fairly well tested before Debian release.

apt-get -q -b source {gcl,gclcvs}

> So - to my questions:
> 
> * Is there no GCL users' newsgroup/mailing list?  I couldn't find one.
>   It seems such a group or list is de rigeur, so I'm curious about
>   this.  Is there a MAXIMA group where people discuss GCL?
> 

So far we're using gcl-devel for everyone, though we could easily make
such a list if there is interest.

> * Apparently the Debian versions of GCL are non-ANSI?  'Apropos' shows
>   nothing for 'ansi.
> 

See above.  GCL_ANSI=t gcl, or GCL_ANSI=t gclcvs.

> * How may one determine the status of ANSI compliance, for example for
>   version 2.5.0+cvs, the current Debian stable version?  This would be
>   *extremely* useful in determining debugging strategies when trying
>   to load generally available packages.
> 
>   As an example, I just tried to load the asdf package, so that I
>   could try to load clsql.  GCL 2.5.0+cvs had DEFPACKAGE loaded by
>   default, but it appeared broken.  From c.l.lisp older postings, I
>   saw something about how the symbol 'option' in loop invocation
>   shouldn't be in parentheses (and indeed I got a 'invalid as a
>   function' error) - so I grabbed the DEFPACKAGE listing from the
>   posting, changed it, re-loaded and tried asdf again.  Nope.  Ah! Get
>   'ansi-loop.lisp' from CMU, load it, *then* load the 'fixed'
>   DEFPACKAGE, and now, I am getting:
> 
>    (:EXPORT #:DEFSYSTEM #:OOS ...) is not a valid DEFPACKAGE option
> 
>   Does this mean that GCL DEFPACKAGE in non-ANSI compliant?
> 

All such issues as these have been significant;y improved since the
version you are using.  We still have ansi issues, but there is a
substantial likelihood that your problem has already been address in
GCL_ANSI=t gclcvs.  Each Debian package has the results of an ANSI
compliance test suite run at build time in
/usr/share/doc/{gcl,gclcvs}/test_results.gz.

> * Is there a way to display the source for forms when interacting with
>   the break repl?  Is this done via the GDB?  Is this documented
>   somewhere?

There is an emacs mode called dbl which allows one to set break points
in source files, etc. in much the same way as is done with C debugging
in gdb.  It was designed for the CLtL1 image and likely needs some
minor modifications for ANSI.  We've held off on this, as everyone
appears to be converging on SLIME, a gcl mode for which can in
principal be easily constructed.  But in general, no, the source for
the forms is not stored separately in GCL itself.  The most useful
features of the break repl at present IMHO are :bl, :bt, :fr, (si::loc
n), and then any other lisp one wishes to type in and evaluate at that
point in the stack.  I'd like to improve debugging substantially and
integrate with gdb if possible.  Typically I'll have the source in
another emacs window, insert (break "foo") where I want, C-M-A to go t
the top of the form, C-M-space to mark it, M-w to copy, C-x o to the
lisp window, C-Y and enter to evaluate it, repeated M-p to pull up
previous commands, etc.

> 
> * While I appreciate having the information I need to define a new
>   'break option' available interactively, would it be possible to make
>   this itself an option, rather than filling up my screen and leaving
>   the 'interesting' stuff scrolled past the top of the screen?  It
>   gets old *real* fast when working from an xterm, or even in ILISP.
> 

This is only when one requests it with :h, no?

> * How much of GCL is written in lisp?  Would it be worth it for me to
>   get the lisp sources?
> 

The compiler itself and much of the lisp library functions are written
in lisp and compiled from source at build time.

> * Why is there no 2.5.3 Debian package available for i386 in
>   ftp://ftp.gnu.org/pub/gnu/gcl/cvs/?  All other architectures, but
>   not i386?  There *is* 2.6.0 i386, but Debian testing/unstable has
>   2.6.1-33/36 (see next item).
> 
>   I considered upgrading to testing/unstable, but that would mean
>   upgrading libc6, tcl8.3 and tk8.3, and that makes me a bit nervous -
>   libc because it is so central to the system, tcl/tk because IIRC,
>   they trigger a bunch of other dependencies.
> 

gnu.org had an ftp compromise and was down for some time.  We are just
about to release the next stable 2.6.2, at which time we'll update
ftp.gnu.org. 

> * Is GCL meant to be a niche product - MAXIMA/ACL2 support + Tcl/Tk?
>   If so, shouldn't that be stated somewhere?  Or are the GCL
>   developers intending on making GCL more broadly usable?  What is
>   being done in this respect?
> 

We'd like GCL to be as useful to as many people as are interested,
more especially if they are also interested in helping improve GCL
itself.

> * What lisp would the GCL developers recommend for Debian users who
>   would like to write web apps (at *least* to access postgres
>   databases) in a truly free lisp?  Please keep in mind that this, for
>   me at least, requires some sort of multi-processing - I'm fine with
>   select-based stuff for the web side, in fact I prefer it, but
>   databases usually require full-on threads - and AFAIK, neither GCL
>   or CLISP seems to do either type of multi-processing.
> 

As a first shot, you could try calling fork() directly in your lisp
function via the (clines ... macro).  Any C code can be interspersed
with lisp in this and other ways.  fork() as opposed to threads will
guarantee that there are no GBC difficulties, while also making use of
Linux's efficient copy-on-write pages.  This having said, we'd like to
do threads at some point, but this is challenging for any lisp, to my
understanding. 

> * Does anyone know of reasonably decent web server running under GCL?
>   Anyone using mod_lisp to talk to a GCL?
> 

I do not know of anything here.

> * Does anyone know of anyone running clsql under GCL?  CLSQL uses
>   connection pooling, I presume this means it can be done in a
>   separate thread.
> 

sockets in general, yes, clsql unknown -- perhaps you could be our
guru in this area!

> To anyone who has read this far - I realize that this a long post, but
> for me these are practical, 'real world' issues the resolutions of
> which are crucial in choosing a tool.  And these issues seem to be
> very common needs these days.
> 
> Am I wrong in thinking that neither of the truly free lisps is going
> to be really suitable for such common tasks any time soon?  Or are
> people going to suggest that I write/port threading, a web server and
> postgres support?
> 

I think it is fair to say that GCL will need some considerable work to
be maximally efficient at multithreaded we/database stuff.  this
having been said, GCL is based on C, and can do anything C can do,
including call C libraries.  So its really a question of interest and
time, both of which, alas, are in too short supply these days.

Take care,

> -- 
> We learn from history that we do not learn from history.
> -- Georg Friedrich Wilhelm Hegel
> 
> 
> 
> _______________________________________________
> Gcl-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gcl-devel
> 
> 
> 

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