From: Peter G. <pe...@ar...> - 2004-04-16 21:19:10
|
There's no new snapshot today, but I've checked in a new implementation of COMPILE-FILE that really does compile the file. In the current scheme of things, given a source file foo.lisp, COMPILE- FILE generates (by default) foo.fasl in the same directory, plus some number of files named foo-1.cls, foo-2.cls, etc., one for each compiled function in that file. The .fasl file is just a .lisp file in disguise; the .cls files are Java .class files with a different extension. Once things are sufficiently debugged and stable, it will probably make sense to wrap up foo.fasl and foo-*.cls into foo.jar, but I haven't done that yet, since it's still handy to have the individual output files around for debugging purposes at this point. (They don't eat much.) You can try all of this out at home by firing up ABCL (after rebuilding it from the latest CVS sources) and evaluating the form: (compile-system) For COMPILE-SYSTEM to work, *LISP-HOME* must be set to the full pathname of the directory containing the Lisp source files (which is normally /.../src/org/armedbear/lisp). If you build ABCL (or j) from source on Linux, *LISP-HOME* should be set correctly on startup. If, for some reason, that turns out not to be the case, COMPILE-SYSTEM will signal a continuable error, and you should do: (setq *lisp-home* #p"/my/path/to/src/org/armedbear/lisp/") (your actual path may vary) and then select the CONTINUE restart. Note that the final backslash in #p"/my/path/to/src/org/armedbear/lisp/" is REQUIRED. On my main development system, an Athlon XP 2100+, COMPILE-SYSTEM takes 2-3 minutes from a standing start. I haven't tried any of this on Windows. In principle, there's no reason why it shouldn't work, but at a minimum *LISP-HOME* won't be set for you automatically, so some assembly will be required. 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. Thanks for your support. -Peter |
From: <as...@ma...> - 2004-04-17 15:44:27
|
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@3b100c 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 |
From: Peter G. <pe...@ar...> - 2004-04-17 21:22:10
|
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@3b100c 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 |
From: <as...@ma...> - 2004-04-17 23:29:18
|
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 |
From: Peter G. <pe...@ar...> - 2004-04-18 19:26:54
|
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 |
From: <as...@ma...> - 2004-04-18 23:12:34
|
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 |
From: Peter G. <pe...@ar...> - 2004-04-19 00:23:32
|
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 |
From: <as...@ma...> - 2004-04-19 05:13:34
|
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 |