clisp-list

Hi,
did anybody use the Screamer package with clisp>2.33.2?
I have from Ubuntu/Debian on Linux/386 the packages cl-screamer =
3.24.2-1 and clisp-2.33.2
Screamer loads fine with these.
However, when I use the clisp I built from CVS, I get an error message
"special-operator-p (setf variable-value) is not a symbol"
which cleary shows that Screamer does not recognize clisp's special
((setf foo) zot bar) syntax as a result of
(macroexpand '(setf (foo bar) zot))
Which is somewhat surprising, since this "(setf foo) is a function name =
in all aspects in CLISP" behaviour is not new to version >2.33.2. It's =
quite old in CLISP.
What maybe new is that it's only in clisp>2.33.2 that the above =
expansion takes place as shown above. In an older one (2.33.2), =
macroexpand is less clever, and one gets
(let ((#:g123 bar)) ((setf foo) zot #:g123))
[for more complex situations, e.g. (setf (foo (bar)) (zot)), one still =
gets that form -- order of evaluation is not broken]
Maybe that change is enough to cause Screamer to fail -- still it's =
surprising that it did not fail before.
Probably Screamer need be taught about how to handle (setf foo), like I =
had to do for the Iterate package (I haven't yet found the =
corresponding place in the code).
Regards,
J=C3=B6rg H=C3=B6hle.

I have created a new system for building custom CLISP memory images and
executables, similar to the functionality of ``clisp-link
add-module-set''.
I didn't write it in Lisp, sorry!
The new system comes in the form of a single GNU make include file,
which handles everything through proper dependencies and very little
shell script hacking.
No symbolic links are used anywhere: all compiling and linking is done
using full and relative paths.
Proper dependencies are set up between all the pieces.
The rules handle invoking the compiler to get the FFI definitions
translated, compiling all the .lisp files to .fas (the ones going into
the lispinit.mem).
Two-step memory image boostrapping is supported, analogous to the
TO_PRELOAD mechanism in clisp-link, so call-in references to packaged
functions can be handled.
Libraries and CFLAGS are pulled out of the makevars file in the
source linking set, and converted into a proper make include file, in
which they appear as target-specific variable assignments.
The makefile is namespace-clean: multiple, independent instantiations
of the rules in the same make process should be possible.
So now, it's super easy to add a custom CLISP to an exiting
makefile-based project. No special directory structure to set up. No
symbolic links. No awkward scripts to invoke, nothing. Plus if you mess
with anything, the dependencies take care of rebuilding what is needed.
Just set up a bunch of variables in your makefile, include clink.mk,
hook the targets into your dependencies and you're done.
What is not done: the output is not a complete CLISP linking set that can
be used as an input to create more linking sets. It doesn't contain a
makevars, and it doesn't contain the archives that it was built from. Just
the lisp.run and lispinit.mem! (But in practice, people usually just care
about doing one step: take the stock thing and add the FFI stuff for their
application).
Get it now: http://users.footprints.net/~kaz/clink-0.1.tar.gz
This archive includes the clink.mk as part of a tiny working sample
project.
Please try, discuss, change, improve ...
--
Meta-CVS: the working replacement for CVS that has been stable since
2002. It versions the directory structure, symbolic links and execute
permissions. It figures out renaming on import. Plus it babysits the kids
and does light housekeeping! http://freshmeat.net/projects/mcvs