Fresh svn update. Compiled with Java 1.5 on OSX File attached.
laptop:~/repos/abcl % ./abcl --noinit Armed Bear Common Lisp 0.20.0-dev Java 1.5.0_19 Apple Inc. Java HotSpot(TM) Client VM Low-level initialization completed in 0.363 seconds. Startup completed in 0.914 seconds. Type ":help" for a list of available commands. CL-USER(1): (compile-file "/Users/alanr/repos/lsw/trunk/owlapi3/patmatch.lisp") ; Compiling /Users/alanr/repos/lsw/trunk/owlapi3/patmatch.lisp ... ; (DEFUN VARIABLE-P ...) ; (DEFUN PAT-MATCH ...) ; in (DEFUN PAT-MATCH ...)
; Caught STYLE-WARNING: ; Undefined variable NO-BINDINGS assumed special
; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special
; Caught STYLE-WARNING: ; Undefined variable *OWL2-VOCABULARY-FORMS* assumed special
; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (SETF (GET # ...) ...) ; (DEFUN SEGMENT-PATTERN-P ...) ; (DEFUN SINGLE-PATTERN-P ...) ; (DEFUN SEGMENT-MATCHER ...) ; (DEFUN SINGLE-MATCHER ...) ; (DEFUN SEGMENT-MATCH-FN ...) ; (DEFUN SINGLE-MATCH-FN ...) ; (DEFUN MATCH-IS ...) ; in (DEFUN MATCH-IS ...)
; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special
; (DEFUN MATCH-AND ...) ; in (DEFUN MATCH-AND ...)
; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special
; (DEFUN MATCH-OR ...) ; in (DEFUN MATCH-OR ...)
; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special
; (DEFUN MATCH-NOT ...) ; in (DEFUN MATCH-NOT ...)
; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special
; (DEFUN SEGMENT-MATCH ...) ; in (DEFUN SEGMENT-MATCH ...)
; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special
; (DEFUN FIRST-MATCH-POS ...) ; (DEFUN SEGMENT-MATCH+ ...) ; (DEFUN SEGMENT-MATCH? ...) ; (DEFUN SEGMENT-ATOM-MATCH? ...) ; (DEFUN MATCH-OPTIONAL-ATOM ...) ; in (DEFUN MATCH-OPTIONAL-ATOM ...)
; Caught STYLE-WARNING: ; Undefined variable FAIL assumed special
; (DEFUN MATCH-IF ...)
; Compilation unit finished ; Caught 9 STYLE-WARNING conditions ; The following functions were used but not defined: ; MATCH-VARIABLE
java.lang.VerifyError: (class: org/armedbear/lisp/patmatch_19, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find integer on stack at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2357) at java.lang.Class.getConstructor0(Class.java:2671) at java.lang.Class.newInstance0(Class.java:321) at java.lang.Class.newInstance(Class.java:303) at org.armedbear.lisp.Lisp.makeCompiledFunctionFromClass(Lisp.java:1286) at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1347) at org.armedbear.lisp.Lisp.loadClassBytes(Lisp.java:1340) at org.armedbear.lisp.AutoloadedFunctionProxy.loadPreloadedFunction(AutoloadedFunctionProxy.java:224) at org.armedbear.lisp.CompiledClosure$1.execute(CompiledClosure.java:232) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_7.execute(compile-file.lisp:71) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_5.execute(compile-file.lisp:71) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_10.execute(compile-file.lisp:103) at org.armedbear.lisp.Symbol.execute(Symbol.java:799) at org.armedbear.lisp.LispThread.execute(LispThread.java:602) at org.armedbear.lisp.compile_file_40.execute(compile-file.lisp:486) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_37.execute(compile-file.lisp:486) at org.armedbear.lisp.compiler_pass2_579.execute(compiler-pass2.lisp:8685) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) at org.armedbear.lisp.Java$pf_jrun_exception_protection.execute(Java.java:1128) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.compiler_pass2_575.execute(compiler-pass2.lisp:8685) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.compile_file_35.execute(compile-file.lisp:486) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:101) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:145) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:497) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Lisp.eval(Lisp.java:460) at org.armedbear.lisp.Primitives$pf__eval.execute(Primitives.java:328) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.Lisp.evalCall(Lisp.java:497) at org.armedbear.lisp.Lisp.eval(Lisp.java:462) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Primitives$sf_block.execute(Primitives.java:3720) at org.armedbear.lisp.Lisp.eval(Lisp.java:452) at org.armedbear.lisp.Lisp.progn(Lisp.java:631) at org.armedbear.lisp.Closure.bindParametersAndExecute(Closure.java:446) at org.armedbear.lisp.Closure.execute(Closure.java:479) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.Lisp$1.execute(Lisp.java:278) at org.armedbear.lisp.Symbol.execute(Symbol.java:776) at org.armedbear.lisp.LispThread.execute(LispThread.java:568) at org.armedbear.lisp.top_level_50.execute(top-level.lisp:407) at org.armedbear.lisp.CompiledClosure.execute(CompiledClosure.java:92) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.Symbol.execute(Symbol.java:766) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) at org.armedbear.lisp.top_level_51.execute(top-level.lisp:415) at org.armedbear.lisp.AutoloadedFunctionProxy.execute(AutoloadedFunctionProxy.java:139) at org.armedbear.lisp.LispThread.execute(LispThread.java:552) at org.armedbear.lisp.Interpreter.run(Interpreter.java:319) at org.armedbear.lisp.Main$1.run(Main.java:50) at java.lang.Thread.run(Thread.java:613) #<THREAD "interpreter" {1A3492}>: Debugger invoked on condition of type ERROR Caught java.lang.VerifyError: (class: org/armedbear/lisp/patmatch_19, method: execute signature: (Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;Lorg/armedbear/lisp/LispObject;)Lorg/armedbear/lisp/LispObject;) Expecting to find integer on stack. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(2):
Hi Alan,
On Mon, Apr 26, 2010 at 7:59 AM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Fresh svn update. Compiled with Java 1.5 on OSX File attached.
Thanks for the attachment and stack trace! Alessio did some research tonight, after which I was able to fix the issue.
Could you test that the current trunk is working as it should?
Bye,
Erik.
On Mon, Apr 26, 2010 at 5:58 PM, Erik Huelsmann ehuels@gmail.com wrote:
Hi Alan,
On Mon, Apr 26, 2010 at 7:59 AM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
Fresh svn update. Compiled with Java 1.5 on OSX File attached.
Thanks for the attachment and stack trace! Alessio did some research tonight, after which I was able to fix the issue.
Could you test that the current trunk is working as it should?
It is, thanks.
Now I'm getting used to the new pathname code and other changes.
1) I used to use probe-file to test whether a thing was a file. Now, however, probe-file on an http URI will return true. Is there a recommended way to see whether a pathname is a file pathname?
2) I use a different classloader (from bsh) so as to be able to add jars to my classpath dynamically. However, if I wanted to specialize a method on a java class so obtained, I need to coerce it to one that clos knows about. I was using an internal call to do so:
(#"findJavaClass" 'org.armedbear.lisp.JavaClass class)
However this is gone in the new version. Could you suggest how I can register a java class that I've obtained from the alternative class manager so that clos knows about it?
Thanks, Alan
Bye,
Erik.
On 4/27/10 4:05 AM, Alan Ruttenberg wrote:
[…]
Now I'm getting used to the new pathname code and other changes.
- I used to use probe-file to test whether a thing was a file. Now,
however, probe-file on an http URI will return true. Is there a recommended way to see whether a pathname is a file pathname?
URL-PATHNAME and JAR-PATHNAME are now subtypes of PATHNAME, so the usual CL type machinery should be at your disposal. For convenience, we have defined predicate functions EXT:PATHNAME-URL-P and EXT:PATHNAME-JAR-P which is what I would expect one for common usage.
- I use a different classloader (from bsh) so as to be able to add
jars to my classpath dynamically. However, if I wanted to specialize a method on a java class so obtained, I need to coerce it to one that clos knows about. I was using an internal call to do so:
(#"findJavaClass" 'org.armedbear.lisp.JavaClass class)
However this is gone in the new version. Could you suggest how I can register a java class that I've obtained from the alternative class manager so that clos knows about it?
Hmmm, this should be unrelated to the URL pathname implementation.
JavaObject.java seems to still have a findJavaClass() method, and even provides a Lisp interface JAVA::%FIND-JAVA-CLASS. Maybe JSS is failing to properly invoke the method?
In any case, we should figure out what functionality you need here, and polish this up as a semi-supported interface Lisp-side for usage. The first step is figuring out where (and then why) we changed this.
On Tue, Apr 27, 2010 at 8:24 AM, Mark Evenson evenson@panix.com wrote:
On 4/27/10 4:05 AM, Alan Ruttenberg wrote:
[…]
Now I'm getting used to the new pathname code and other changes.
- I used to use probe-file to test whether a thing was a file. Now,
however, probe-file on an http URI will return true. Is there a recommended way to see whether a pathname is a file pathname?
URL-PATHNAME and JAR-PATHNAME are now subtypes of PATHNAME, so the usual CL type machinery should be at your disposal. For convenience, we have defined predicate functions EXT:PATHNAME-URL-P and EXT:PATHNAME-JAR-P which is what I would expect one for common usage.
- I use a different classloader (from bsh) so as to be able to add
jars to my classpath dynamically. However, if I wanted to specialize a method on a java class so obtained, I need to coerce it to one that clos knows about. I was using an internal call to do so:
(#"findJavaClass" 'org.armedbear.lisp.JavaClass class)
However this is gone in the new version. Could you suggest how I can register a java class that I've obtained from the alternative class manager so that clos knows about it?
Hmmm, this should be unrelated to the URL pathname implementation.
JavaObject.java seems to still have a findJavaClass() method, and even provides a Lisp interface JAVA::%FIND-JAVA-CLASS. Maybe JSS is failing to properly invoke the method?
In any case, we should figure out what functionality you need here, and polish this up as a semi-supported interface Lisp-side for usage. The first step is figuring out where (and then why) we changed this.
IIRC, I should have a local patch to make JCLASS use another classloader if you pass it to it, including in CLOS method specializers, as in (defmethod foo ((x (jclass "foo" *my-classloader*))) ...)
If that sounds sensible to you, I can adapt it to the current version of abcl and commit it, so it can be tested.
Ciao, Alessio
On Tue, Apr 27, 2010 at 2:48 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Tue, Apr 27, 2010 at 8:24 AM, Mark Evenson evenson@panix.com wrote:
On 4/27/10 4:05 AM, Alan Ruttenberg wrote:
[…]
Now I'm getting used to the new pathname code and other changes.
- I used to use probe-file to test whether a thing was a file. Now,
however, probe-file on an http URI will return true. Is there a recommended way to see whether a pathname is a file pathname?
URL-PATHNAME and JAR-PATHNAME are now subtypes of PATHNAME, so the usual CL type machinery should be at your disposal. For convenience, we have defined predicate functions EXT:PATHNAME-URL-P and EXT:PATHNAME-JAR-P which is what I would expect one for common usage.
- I use a different classloader (from bsh) so as to be able to add
jars to my classpath dynamically. However, if I wanted to specialize a method on a java class so obtained, I need to coerce it to one that clos knows about. I was using an internal call to do so:
(#"findJavaClass" 'org.armedbear.lisp.JavaClass class)
However this is gone in the new version. Could you suggest how I can register a java class that I've obtained from the alternative class manager so that clos knows about it?
Hmmm, this should be unrelated to the URL pathname implementation.
JavaObject.java seems to still have a findJavaClass() method, and even provides a Lisp interface JAVA::%FIND-JAVA-CLASS. Maybe JSS is failing to properly invoke the method?
In any case, we should figure out what functionality you need here, and polish this up as a semi-supported interface Lisp-side for usage. The first step is figuring out where (and then why) we changed this.
IIRC, I should have a local patch to make JCLASS use another classloader if you pass it to it, including in CLOS method specializers, as in (defmethod foo ((x (jclass "foo" *my-classloader*))) ...)
If that sounds sensible to you, I can adapt it to the current version of abcl and commit it, so it can be tested.
Let's give it a shot. Thanks, Alan
Ciao, Alessio
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Tue, Apr 27, 2010 at 8:54 AM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
On Tue, Apr 27, 2010 at 2:48 AM, Alessio Stalla alessiostalla@gmail.com wrote:
IIRC, I should have a local patch to make JCLASS use another classloader if you pass it to it, including in CLOS method specializers, as in (defmethod foo ((x (jclass "foo" *my-classloader*))) ...)
If that sounds sensible to you, I can adapt it to the current version of abcl and commit it, so it can be tested.
Let's give it a shot.
I finally committed the patch on trunk.
Alessio
On Sun, May 9, 2010 at 11:45 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Tue, Apr 27, 2010 at 8:54 AM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
On Tue, Apr 27, 2010 at 2:48 AM, Alessio Stalla alessiostalla@gmail.com wrote:
IIRC, I should have a local patch to make JCLASS use another classloader if you pass it to it, including in CLOS method specializers, as in (defmethod foo ((x (jclass "foo" *my-classloader*))) ...)
If that sounds sensible to you, I can adapt it to the current version of abcl and commit it, so it can be tested.
Let's give it a shot.
I finally committed the patch on trunk.
Tested, works. Thanks.
So what do you think about actually integrating the bean shell class loader into ABCL. Source is at
http://ikayzo.org/svn/beanshell (root) http://ikayzo.org/svn/beanshell/BeanShell/src/bsh/classpath (classloader) http://ikayzo.org/svn/beanshell/BeanShell/src/bsh/BshClassManager.java (classmanager)
I've been using it for about 5 years and it's pretty useful, allowing dynamic modifications to the classpath, including jars as part of asdf systems, etc.
-Alan
Alessio
On Sun, May 9, 2010 at 6:58 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
On Sun, May 9, 2010 at 11:45 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Tue, Apr 27, 2010 at 8:54 AM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
On Tue, Apr 27, 2010 at 2:48 AM, Alessio Stalla alessiostalla@gmail.com wrote:
IIRC, I should have a local patch to make JCLASS use another classloader if you pass it to it, including in CLOS method specializers, as in (defmethod foo ((x (jclass "foo" *my-classloader*))) ...)
If that sounds sensible to you, I can adapt it to the current version of abcl and commit it, so it can be tested.
Let's give it a shot.
I finally committed the patch on trunk.
Tested, works. Thanks.
So what do you think about actually integrating the bean shell class loader into ABCL. Source is at
http://ikayzo.org/svn/beanshell (root) http://ikayzo.org/svn/beanshell/BeanShell/src/bsh/classpath (classloader) http://ikayzo.org/svn/beanshell/BeanShell/src/bsh/BshClassManager.java (classmanager)
I've been using it for about 5 years and it's pretty useful, allowing dynamic modifications to the classpath, including jars as part of asdf systems, etc.
The addUrl method to dynamically add new resources to the classpath is very nice and easy to add. I'm less convinced by the other stuff, which subverts the normal classloading semantics: the bsh classloader reloads all classes from the classpath, except the core BeanShell classes, instead of delegating to the parent classloader first. I fear this may cause bugs and/or inefficiencies in the context of ABCL, and even without those concerns I see little value in adding it. Do you actually use this feature? And if yes, what for?
Also, if we expose the classloader to the user and allow him to modify the classpath, we must make sure that said classloader is used in all the relevant places. I'd prefer to postpone that to after version 0.20 is released, to avoid the risk of inadvertently introducing subtle bugs in 0.20.
Just my .02, Alessio
On Sun, May 9, 2010 at 1:32 PM, Alessio Stalla alessiostalla@gmail.com wrote:
On Sun, May 9, 2010 at 6:58 PM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
On Sun, May 9, 2010 at 11:45 AM, Alessio Stalla alessiostalla@gmail.com wrote:
On Tue, Apr 27, 2010 at 8:54 AM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
On Tue, Apr 27, 2010 at 2:48 AM, Alessio Stalla alessiostalla@gmail.com wrote:
IIRC, I should have a local patch to make JCLASS use another classloader if you pass it to it, including in CLOS method specializers, as in (defmethod foo ((x (jclass "foo" *my-classloader*))) ...)
If that sounds sensible to you, I can adapt it to the current version of abcl and commit it, so it can be tested.
Let's give it a shot.
I finally committed the patch on trunk.
Tested, works. Thanks.
So what do you think about actually integrating the bean shell class loader into ABCL. Source is at
http://ikayzo.org/svn/beanshell (root) http://ikayzo.org/svn/beanshell/BeanShell/src/bsh/classpath (classloader) http://ikayzo.org/svn/beanshell/BeanShell/src/bsh/BshClassManager.java (classmanager)
I've been using it for about 5 years and it's pretty useful, allowing dynamic modifications to the classpath, including jars as part of asdf systems, etc.
The addUrl method to dynamically add new resources to the classpath is very nice and easy to add. I'm less convinced by the other stuff, which subverts the normal classloading semantics: the bsh classloader reloads all classes from the classpath, except the core BeanShell classes, instead of delegating to the parent classloader first. I fear this may cause bugs and/or inefficiencies in the context of ABCL, and even without those concerns I see little value in adding it. Do you actually use this feature? And if yes, what for?
I've used the ability to add resources to the classpath explicitly. Via use of ClassManager I may have used the other inadvertently. I've never looked deeply at what happens behind the scenes. What I can say is that I've rarely had any issue with jss over the years I've used it within ABCL.
If you think you can preserve the desired add-to-classpath behavior with less mechanism, then I'm game to give it a try.
Also, if we expose the classloader to the user and allow him to modify the classpath, we must make sure that said classloader is used in all the relevant places. I'd prefer to postpone that to after version 0.20 is released, to avoid the risk of inadvertently introducing subtle bugs in 0.20.
Agree on this.
-Alan
On Mon, May 10, 2010 at 2:05 AM, Alan Ruttenberg alanruttenberg@gmail.com wrote:
I've used the ability to add resources to the classpath explicitly. Via use of ClassManager I may have used the other inadvertently. I've never looked deeply at what happens behind the scenes. What I can say is that I've rarely had any issue with jss over the years I've used it within ABCL.
From a quick read of ClassManager, it seems to me it's mostly a thin
layer over a classloader, which can optionally swap another classloader in to "reload" classes at will (as well as doing other stuff to support BeanShell itself). I think it can be a useful addition, but I'd keep the two things conceptually separate if possible: have a generic classloader with dynamic classpath and another, "greedy" classloader that will always load resources from its own jars first, which can be used to "reload" (or better, load different versions of) classes in a jar or set of jars. The two might actually be a single class with a boolean switch: my point is that they should be clearly distinguishable so the user can ultimately decide what to do.
If you think you can preserve the desired add-to-classpath behavior with less mechanism, then I'm game to give it a try.
It's possible, with the caveat that adding a new jar which contains a class that has already been loaded from somewhere else (in the same classloader chain) won't make the classloader use the new class. In other words, the classpath is only partially dynamic (a given class will see a static snapshot the time it is loaded). That's true for the bsh classloader as well, as far as I understand, except the bsh one will always ignore classes in the system classpath (the one specified at startup) and always load them from the jars it knows. Using "greedy" classloaders and layering them will enable to load multiple versions of a class. But as I said, I'd keep the two things separate. It would also be nice to have the "greedy" classloader optionally use a Lisp function predicate to decide whether to be greedy or not on a per-class basis.
Hope this makes sense, Alessio
armedbear-devel@common-lisp.net
-
Alan Ruttenberg -
Alessio Stalla -
Erik Huelsmann -
Mark Evenson