gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] General GCL quesions


From: Chris Hall
Subject: [Gcl-devel] General GCL quesions
Date: 11 Apr 2004 01:15:34 -1000
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

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.

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?

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

* 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?

* 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?

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

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

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

* 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?

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

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

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

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?

-- 
We learn from history that we do not learn from history.
-- Georg Friedrich Wilhelm Hegel





reply via email to

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