Re: [Kawa-commonlisp-dev] [GSoC] Status

[Jamison Hope]

On Aug 10, 2012, at 1:59 PM, Charles Turner wrote:

> So I appear to succeed with --module-static-run, but only if I compile
> the two files separately, that is, instead of
>
> $ ... -C primitives.lisp defmacro.lisp
>
> I run
>
> $ ... -C primitives.lisp
> $ ... -C defmacro.lisp
>
> For the case of them both on the same line, I receive this:
>
> (compiling defmacro.lisp)
> defmacro.lisp:244:1: exception loading 'COMMON-LISP:DEFMACRO' - no
> such class: gnu.commonlisp.lisp.primitives
> defmacro.lisp:256:1: exception loading 'COMMON-LISP:DEFMACRO' - no
> such class: gnu.commonlisp.lisp.primitives
> defmacro.lisp:599:1: exception loading 'COMMON-LISP:DEFMACRO' - no
> such class: gnu.commonlisp.lisp.primitives
>
> Which doesn't make a lot of sense to me.

If you look at kawa.repl#compileFiles, notice that there are two
for-loops -- in the first, all the listed files are read and compiled,
and in the second, the resultant class files are written to disk.

So, when it's compiling defmacro.lisp, the file primitives.class
does not exist yet. And since it's loading the symbol COMMON- 
LISP:DEFMACRO
via the def*StFld() stuff in CommonLisp.java which says to look for it
in that class file, it doesn't find it and throws the exception.

The good news, though, is that it only goes through that lookup
mechanism if the symbol isn't loaded yet, so if we explicitly load
it by putting

(require class::|gnu.commonlisp.lisp.primitives|)

at the top of defmacro.lisp, then we're good to go:

Making all in lisp
java -classpath "../../..:./../../..:$CLASSPATH" kawa.repl -d ../../..  
-P `echo gnu-commonlisp-lisp|sed -e s/-/./g`. --module-static-run -- 
clisp -C primitives.lisp defmacro.lisp
(compiling primitives.lisp to gnu.commonlisp.lisp.primitives)
(compiling defmacro.lisp to gnu.commonlisp.lisp.defmacro)
(+ 0 1)
(+ 1 1)
(+ 2 1)
(+ 3 1)
defmacro.lisp:572:38: warning - no declaration seen for COMMON- 
LISP:FUN-NAME-BLOCK-NAME
[etc]

> Given the Makefile setup of using clisp-classes.stamp, it seems like
> such "all-at-once" compilation is the way to go, I'm not sure what the
> best of way of changing it to build them one at a time is, though, and
> whether I should actually do that...

Stick to all-at-once, just if you're compiling several files and some  
depend
on others, then put explicit require declarations as needed (even if  
it's
for symbols that will be automatically available at the REPL).

[Note that kawa/lib/std_syntax.scm REQUIREs kawa.lib.prim_syntax for  
this
reason.]

> Sidenote: When I change a Makefile, I run aclocal && automake &&
> ./configure ... This means that when I commit my working set, *lots*
> of Makefile.in changes are sent to the repository. I don't recall ever
> seeing this using Per's repository, and I'm sure Makefile's have
> changed in the time I've been here, am I doing something wrong?

Those happen occasionally, but I think Per just doesn't re-run automake
all that often. But look at r7241, it's almost entirely Makefile.{am,in}
changes. You aren't doing anything wrong.


Jamie

--
Jamison Hope
The PTR Group
www.theptrgroup.com