ArmedBear / J

On Fri, 16 Apr 2004, Peter Graves wrote:

> Once you've successfully compiled the system, ABCL should start up
> much faster, and it will run faster, too, since it will be able to use
> compiled versions of most (but not all) of the functions that have in
> previous versions been loaded from .lisp files.

Indeed, it is much faster now! Even loading files takes less than half
the time it did before. (This is important for me, because I usually
load a bunch of jparse generated files from .ablrc.) Great job!

There's one small problem though. After compiling and loading a file with

(define-symbol-macro sm 1)
(defun test () (print (+ 3 sm)))

in it, I get

CL-USER(111): (test)
Debugger invoked on condition of type TYPE-ERROR:
  The value org.armedbear.lisp.SymbolMacro@... is not of type number.
Restarts:
  0: TOP-LEVEL Return to top level.
[1] CL-USER(112):

This came up when I was trying to use JNEW-RUNTIME-CLASS (which
should probably use DEFCONSTANTs instead of DEFINE-SYMBOL-MACROs).

Also, while compiling runtime-class.lisp, which has

(defmethod initialize-instance :after ((b jboolean) &key &allow-other-keys)
  (setf (slot-value b 'java-instance) (make-immediate-object (java-instance b) :boolean)))

in it, I get

Error: COMPILE-FUNCTION: unsupported case: #'(SETF SLOT-VALUE)

but the file compilation continues.

Andras

On Sat, 17 Apr 2004 at 17:44:21 +0200, Andr=E1s_Simon wrote:
> Indeed, it is much faster now! Even loading files takes less than
> half the time it did before. (This is important for me, because I
> usually load a bunch of jparse generated files from .ablrc.) Great
> job!
>
> There's one small problem though. After compiling and loading a file
> with
>
> (define-symbol-macro sm 1)
> (defun test () (print (+ 3 sm)))
>
> in it, I get
>
> CL-USER(111): (test)
> Debugger invoked on condition of type TYPE-ERROR:
>   The value org.armedbear.lisp.SymbolMacro@... is not of type number=
=2E
> Restarts:
>   0: TOP-LEVEL Return to top level.
> [1] CL-USER(112):
>
> This came up when I was trying to use JNEW-RUNTIME-CLASS (which
> should probably use DEFCONSTANTs instead of DEFINE-SYMBOL-MACROs).

Right. File compilation clearly isn't up to DEFINE-SYMBOL-MACRO yet,
but DEFCONSTANT should work OK.

File compilation is far from 100% correct at this point. The test suite
doesn't really test file compilation yet, so I'm working on the problem
by trying to use ABCL to build SBCL. This project has revealed a number
of issues (some now solved, some not). On a good day I get a bit further.=

Stay tuned.

> Also, while compiling runtime-class.lisp, which has
>
> (defmethod initialize-instance :after ((b jboolean) &key &allow-other-k=
eys)
>   (setf (slot-value b 'java-instance) (make-immediate-object (java-inst=
ance b) :boolean)))
>
> in it, I get
>
> Error: COMPILE-FUNCTION: unsupported case: #'(SETF SLOT-VALUE)
>
> but the file compilation continues.

That message is benign and can be ignored. The compiler can't compile
everything, and when it encounters something it knows it can't compile,
it prints a message such as the one you've quoted (so the problem won't
be totally forgotten) and leaves things in a state where the function
in question should still be callable interpretively: no harm, no foul.

-Peter

On Sat, 17 Apr 2004, Peter Graves wrote:

>
> Right. File compilation clearly isn't up to DEFINE-SYMBOL-MACRO yet,
> but DEFCONSTANT should work OK.

It does. So JNEW-RUNTIME-CLASS works again.

> File compilation is far from 100% correct at this point. The test suite
> doesn't really test file compilation yet, so I'm working on the problem
> by trying to use ABCL to build SBCL. This project has revealed a number
> of issues (some now solved, some not). On a good day I get a bit further.=
>
> Stay tuned.

Sure, I will :-)

> That message is benign and can be ignored. The compiler can't compile
> everything, and when it encounters something it knows it can't compile,
> it prints a message such as the one you've quoted (so the problem won't
> be totally forgotten) and leaves things in a state where the function
> in question should still be callable interpretively: no harm, no foul.

Then perhaps a warning would be more appropriate (would scare users
less)? But it's not that important.

Andras

On Sun, 18 Apr 2004 at 01:29:15 +0200, Andr=E1s_Simon wrote:
> On Sat, 17 Apr 2004, Peter Graves wrote:
> > Right. File compilation clearly isn't up to DEFINE-SYMBOL-MACRO yet,
> > but DEFCONSTANT should work OK.
>
> It does. So JNEW-RUNTIME-CLASS works again.

Maybe, but I'm not sure.

The new version of runtime-class.lisp contains code like this:

    (defconstant constants.ifnonnull
                 #.(jfield "org.objectweb.asm.Constants" "IFNONNULL"))

which evaluates the (jfield ...) form at read time. This doesn't work
for me, since I don't have the org.objectweb.asm package installed, so
I can't compile runtime-class.lisp.

And even if I could, it seems like the .fasl would end up with a line
in it like this:

    (DEFCONSTANT CONSTANTS.IFNONNULL #<JAVAOBJECT ... >)

which would cause the attempt to load runtime-lisp.fasl to fail, since
the Lisp reader would choke on "#<JAVAOBJECT ... >". Note that file
compilation, in its current state, doesn't serialize Java objects.

Now, it might work if you let the JFIELD call happen at .fasl load time:

    (defconstant constants.ifnonnull
                 (jfield "org.objectweb.asm.Constants" "IFNONNULL"))

i.e. without the "#." in the source, but I don't know for sure since I
still don't have org.objectweb.asm (or, for that matter, any test cases
for the code in runtime-class.lisp).

For the time being I've taken runtime-class.lisp out of the list of
classes in compile-system.lisp, to avoid having the aforementioned
problem kill the build. You can always build it by hand:

    (compile-file "runtime-class.lisp")

Subsequently you should do

    (load "runtime-class.fasl")

or

    :ld runtime-class.fasl

i.e. explicitly giving the .fasl extension, when you want to load the
=2Efasl as opposed to the source file. If you just do

    :ld runtime-class

you'll get the .lisp file.

-Peter

On Sun, 18 Apr 2004, Peter Graves wrote:

> On Sun, 18 Apr 2004 at 01:29:15 +0200, Andr=E1s_Simon wrote:
> > On Sat, 17 Apr 2004, Peter Graves wrote:
> > > Right. File compilation clearly isn't up to DEFINE-SYMBOL-MACRO yet,
> > > but DEFCONSTANT should work OK.
> >
> > It does. So JNEW-RUNTIME-CLASS works again.
>
> Maybe, but I'm not sure.
>
> The new version of runtime-class.lisp contains code like this:
>
>     (defconstant constants.ifnonnull
>                  #.(jfield "org.objectweb.asm.Constants" "IFNONNULL"))
>
> which evaluates the (jfield ...) form at read time. This doesn't work
> for me, since I don't have the org.objectweb.asm package installed, so
> I can't compile runtime-class.lisp.

You're right: it works for me (the .fasl file has (DEFCONSTANT
CONSTANTS.IFNONNULL 199) etc.) only because I have asm in the
CLASSPATH. It didn't occur to me that, unlike with autoloading, people
who don't care about JNEW-RUNTIME-CLASS will have runtime-class.lisp
compiled. It was a bad idea (a textbook example of premature
optimization), sorry!

>
> Now, it might work if you let the JFIELD call happen at .fasl load time:
>
>     (defconstant constants.ifnonnull
>                  (jfield "org.objectweb.asm.Constants" "IFNONNULL"))
>
> i.e. without the "#." in the source, but I don't know for sure since I
> still don't have org.objectweb.asm (or, for that matter, any test cases
> for the code in runtime-class.lisp).

I'd think it should work as well as loading the .lisp file. But I
can't check now whether it does, because I've run into the following:

;  Loading file:/home/simon/java/j/lisp.jar!/org/armedbear/lisp/format.lisp ...
Error in #P"file:/home/simon/java/j/lisp.jar!/org/armedbear/lisp/format.lisp" at line 36 (offset 1401).
Debugger invoked on condition of type UNBOUND-VARIABLE:
  The variable ARMEDBEAR is unbound.

Andras

On Mon, 19 Apr 2004 at 01:12:25 +0200, Andr=E1s_Simon wrote:
> I'd think it should work as well as loading the .lisp file. But I
> can't check now whether it does, because I've run into the following:
>
> ;  Loading
> file:/home/simon/java/j/lisp.jar!/org/armedbear/lisp/format.lisp ...
> Error in
> #P"file:/home/simon/java/j/lisp.jar!/org/armedbear/lisp/format.lisp"
> at line 36 (offset 1401). Debugger invoked on condition of type
> UNBOUND-VARIABLE:
>   The variable ARMEDBEAR is unbound.

That's odd, since format.lisp hasn't changed in the last two weeks, and
the error occurs while loading the .lisp file. Like runtime-class.lisp,
format.lisp is not included in the list of files in compile-system.lisp.
(There are several commented-out files in compile-system.lisp that have
unresolved issues that I need to look into.)

The relevant area of format.lisp is a read-time conditional:

    #+armedbear
    (ext:resolve 'write-string)

Read-time conditionalization is implemented in boot.lisp, line 87 and
following, so one thing to try would be to delete boot.fasl and restart
ABCL (thus forcing it to use boot.lisp instead, to rule out miscompila-
tion of the read-time conditionalization code).

The next thing to try would be to start from scratch, i.e.

    rm *.fasl *.cls *.class

in the src/org/armedbear/lisp directory followed by rebuilding the
=2Ejava source files, restarting ABCL and doing

    (compile-system)

then restarting ABCL again to pick up the compiled .fasl's.

One of the next things on my list is fasl versioning, but that's not
implemented at this point, so the first order of business if a
mysterious failure is encountered after CVS updating should be to start
from scratch, as above. Trying to load old .fasl's in a system
containing newer code elsewhere is likely not to work, but until fasl
versioning is implemented you won't be informed of the problem in a
coherent way. (Another problem is that currently LOAD-SYSTEM-FILE will
use the .fasl version of a file, if it exists, even if the .lisp
version is newer.)

Sorry for the inconvenience. I'll try to make all of this more robust
over the next few days.

-Peter

On Sun, 18 Apr 2004, Peter Graves wrote:

>
> The next thing to try would be to start from scratch, i.e.
>
>     rm *.fasl *.cls *.class
>
> in the src/org/armedbear/lisp directory followed by rebuilding the
> =2Ejava source files, restarting ABCL and doing
>
>     (compile-system)
>
> then restarting ABCL again to pick up the compiled .fasl's.
>

This did the trick. Thanks!
Andras