[Top][All Lists]

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

Re: [Gcl-devel] Re: Status of GCL?

From: Jeff Dalton
Subject: Re: [Gcl-devel] Re: Status of GCL?
Date: Fri, 09 Apr 2004 01:26:17 +0100 (BST)
User-agent: IMP/PHP IMAP webmail program 2.2.8

Quoting Camm Maguire <address@hidden>:

> The following message is a courtesy copy of an article
> that has been posted to comp.lang.lisp as well.
> Greetings!  GCL has seen a lot of development over the past three
> years or so.  You can follow the progress at address@hidden

Thanks for the reply!  I added myself to the gcl-devel list
the other day but ended up asking my question in comp.lang.lisp

> faslink has not been enabled yet because no one has asked for it.
> It would appear to be straightforward given GCL's other linking
> options.  If you would like to explore enabling it and have some
> specific examples, please let us know. The docs state that faslink is
> a rather unportable option, and recommend an alternate method based on
> the makefiles.  We've simplified the latter option quite a lot, so
> that the build tree and makefiles are no longer necessary to link in C
> libraries and code, rather the user can use (compiler::link...) from
> within GCL proper.  Again, if you have a specific example, I can show
> you how to link your new image with this function, or you can just
> check the docs.

> Of course, native compiled lisp object loading is still supported as
> always, with dumping via si::save-system preserving these loads on 6
> out of 12 Debian platforms (i386 sparc arm m68k ppc s390) and xBSD.
> As you probably know, one can insert arbitrary C code into these
> modules via (clines ...).

Yes, clines is what I usually do.  I find the KCL approach
much nicer than the foreign function interface in other Lisps.

The problem is when the C code refers to something in a C
library that isn't in GCL.  si:faslink handled that case.
When it stopped being supported, I had to manually build
in the desired routines by writing some C code that referred
to them and then rebuilding GCL with the .o file included.

It sounds like the "alternate method based on the makefiles"
that you mentioned was similar.

Perhaps (compiler::link...) will do the job.

I've done a lot of work with KCL/AKCL/GCL over the years
(including porting it a couple of times), and I'd like to
start using it again if it's being actively supported,
which it sounds like it is.

In fact, I still use it for one thing (the O-Plan AI planning
system).  Unfortunately, due to Linux and FreeBSD changes over
the years, the GCLs I'm using no longer work well enough for
me to load compiled code.

Since O-Plan isn't being actively developed these days, I've
been able to get by with an old image and non-compiled files
loaded at run-time(!).

But several things have recently come up that I'd like to do
with O-Plan, and it would be much easier if I had a properly
working GCL.

-- Jeff

reply via email to

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