[Top][All Lists]

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

[Gcl-devel] Re: (Summary view of above)

From: Chris Hall
Subject: [Gcl-devel] Re: (Summary view of above)
Date: 17 Apr 2004 04:03:43 -1000
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2

Thanks for the taking the time for your detailed response!

Dennis Decker Jensen <address@hidden> writes:

>       Chris Hall wrote on 16 Apr 2004 04:07:54 -1000:
>       Build process: it seems to me, as a new 'customer'
>       of GCL, that it might make sense to --enable-ansi by
> I think it is already.  What version of Debian are you using?

I'm on Debian Woody.  The stable GCL is 2.5.0 according to my dselect.
The saved_gcl is less than 3MB, and the GCL_ANSI=t doesn't seem to
have any effect - no ANSI-CL feature is present, and the initial
default package is USER rather than COMMON-LISP-USER.

This point is moot for me now, thanks, though - I have built from
source 2.6.1-36 and 2.7.0-20.  I mentioned it more for anyone else new
to GCL who might have similar confusion, e.g., problems in using ILISP
w/GCL, since apparently one needs the ANSI support to do that.

I think I might need to be clearer as to _why_ I mention things - I'll
try to improve that.

> On startup GCL will run `init.lsp' if there is one.

Umm, should this be in $HOME/?  Have I missed this in the docs?

>       Does anyone know of a workaround for the SETF
> Camm has asked me to remind him to do something about logical
> as well as physical pathnames in 2.7.0; in 2.6.2 coming soon
> there will still be CLtL1 like pathnames that are incompatible
> with ANSI.  This also prevents use of DEFSYSTEM and a number
> of packages (dpkg) for common-lisp implementations made available
> through common-lisp-controller (dpkg).  The jury is still out
> on wheither how important this is for GCL.

Speaking as a budding user of GCL, I can say that having it would make
it a *lot* easier to use/port code from other distros, and allow me to
write code in GCL that I could easily install in other distros.  I
personally would find both capabilities very attractive indeed, e.g.,

Of course, I also understand the need in any development effort to
prioritize tasks.  But I would suggest considering it in that it might
broaden the general appeal of GCL by making other code more easily

> Congratulations on getting ILISP to work with GCL!  Have you
> tried SLIME?  GCL has a dbl-mode for debugging you might be
> interested to play with and that needs a loving hand from
> somebody knowing both elisp as well as GCL.

I like SLIME a lot - I've used it with CMUCL, SBCL and (I think)

I've got dbl.el for my EMacs - is that dbl-mode you are referring to?
I haven't a clue as to how to use it at present, since the comments in
the file didn't mean a whole lot to me, and I haven't really needed
such a thing yet.  I'd appreciate any links/docs you can point me at,
though - I expect to need it C-level debugging in the near future.

Part of my 'road to lisp' was elisp in Emacs, and though I'm not
anywhere near what I'd call proficient in any lisp at present, I am
doing what I can to change that.  That said, I'd be happy to do
whatever I can in support of the GCL effort, albeit at this point it
would probably have to be something in an admin/support role.

> Dennis Decker Jensen
> Good judgement comes from experience.
> Experience comes from bad judgement.
>  -- The Murphy's Law Calendar, ~1987

I like your .sig!  We seem to have gotten it from different sources,
though.  (And it was time for me to change mone, anyway. :-D)


Good judgment comes from experience. Experience comes from bad
- Jim Horning

reply via email to

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