From: Peter G. <pe...@ar...> - 2005-10-30 10:27:45
|
On Sat, 29 Oct 2005 at 02:30:05 +0200, Andras Simon wrote: > [Sorry for the late reply; my adsl modem gave up the ghost after a > power outage, and it took two days to get a replacement.] Ouch! > On Thu, 27 Oct 2005, Peter Graves wrote: > > > Suppose (for the sake of argument) you do: > > > > (define-condition throwable (java-exception) ()) > > (register-java-exception "java.lang.Throwable" 'throwable) > > > > And then some call to Java throws a NullPointerException (for example). > > > > Now, you haven't registered "java.lang.NullPointerException". But from > > Java's point of view, a NullPointerException _is_ a Throwable, so the > > condition registered for "java.lang.Throwable" should arguably be > > signalled. > > > > You can't accomplish this with a simple hashtable lookup of > > "java.lang.NullPointerException". You'd have to walk the list of > > registered exceptions and check to see if the class of the exception at > > hand is either identical to, or a subclass of, one of the registered > > exception classes. And the order in which you walked the list would > > matter, in exactly the same way the order of catch clauses matters > > after a try block in Java code. > > How about walking the list of superclasses of the exception thrown > (starting with itself of course), and stop at the first that is > registered? That seems reasonable, but of course I haven't actually tried it. As far as I can see, by the way, jFli itself doesn't have any concept analogous to REGISTER-JAVA-EXCEPTION. -Peter |
From: Andras S. <as...@ma...> - 2005-10-30 10:58:56
|
On Sun, 30 Oct 2005, Peter Graves wrote: > As far as I can see, by the way, jFli itself doesn't have any concept > analogous to REGISTER-JAVA-EXCEPTION. Perhaps this is because jFLI was abandoned (or rather, transformed into Foil and then to Clojure) before something like it could get in. Also, doing stuff like this is so much easier with ABCL. Andras |
From: Peter G. <pe...@ar...> - 2005-10-30 11:11:33
|
On Sun, 30 Oct 2005 at 11:58:49 +0100, Andras Simon wrote: > On Sun, 30 Oct 2005, Peter Graves wrote: > > > As far as I can see, by the way, jFli itself doesn't have any concept > > analogous to REGISTER-JAVA-EXCEPTION. > > Perhaps this is because jFLI was abandoned (or rather, transformed > into Foil and then to Clojure) before something like it could get in. Hmmm... Somehow I failed to recognized that jFli was abandoned. (I think I would have just called it "quiescent".) For that matter, Clojure seems fairly quiescent at this point, too (no commits since June). I guess we're on our own... ;) > Also, doing stuff like this is so much easier with ABCL. Yeah. -Peter |
From: Andras S. <as...@ma...> - 2005-10-30 11:35:03
|
On Sun, 30 Oct 2005, Peter Graves wrote: > On Sun, 30 Oct 2005 at 11:58:49 +0100, Andras Simon wrote: >> On Sun, 30 Oct 2005, Peter Graves wrote: >> >>> As far as I can see, by the way, jFli itself doesn't have any concept >>> analogous to REGISTER-JAVA-EXCEPTION. >> >> Perhaps this is because jFLI was abandoned (or rather, transformed >> into Foil and then to Clojure) before something like it could get in. > > Hmmm... > > Somehow I failed to recognized that jFli was abandoned. (I think I > would have just called it "quiescent".) > > For that matter, Clojure seems fairly quiescent at this point, too (no > commits since June). I hope Rich will tell us more about the status of Clojure these days. > > I guess we're on our own... ;) I thought so, too. But now I checked http://www.weitz.de/rdnzl/ and http://www.weitz.de/rdnzl/#exceptions in particular, and I think we needn't feel too isolated :) Andras |
From: Rich H. <ri...@ri...> - 2005-10-30 16:59:04
|
On Oct 30, 2005, at 6:34 AM, Andras Simon wrote: > > > On Sun, 30 Oct 2005, Peter Graves wrote: > > >> On Sun, 30 Oct 2005 at 11:58:49 +0100, Andras Simon wrote: >> >>> On Sun, 30 Oct 2005, Peter Graves wrote: >>> >>> >>>> As far as I can see, by the way, jFli itself doesn't have any >>>> concept >>>> analogous to REGISTER-JAVA-EXCEPTION. >>>> >>> >>> Perhaps this is because jFLI was abandoned (or rather, transformed >>> into Foil and then to Clojure) before something like it could get >>> in. >>> >> >> Hmmm... >> >> Somehow I failed to recognized that jFli was abandoned. (I think I >> would have just called it "quiescent".) >> >> For that matter, Clojure seems fairly quiescent at this point, too >> (no >> commits since June). >> > > I hope Rich will tell us more about the status of Clojure these days. Well, nothing has been 'abandoned', but being one person with a limited amount of spare time (none currently) I have to focus my effort. None of my projects has seen significant interest or input, and I would characterize the number of people in the CL community who care about Java integration as very small - perhaps they are all working on/with ABCL :) Nevertheless, I am still actively engaged in how best to integrate Lisp and the JVM/CLR and intend to continue to contribute to this area when I have time. Re: Clojure - I have reached the point where I am planning support for defining Java/CLR classes etc and have realized that this is something I should have implemented first. While I only have a small amount of Java runtime lib code, if Clojure itself were capable of generating decent Java classes and calls, ideally I should have none (bootstrap issues aside). I am always surprised at the inordinate amount of Java code in Lisp-in-Java implementations and I think this is because they, too, added this later in the game. Otherwise, why write so much Java? - the whole reason we do these things is so at the end of the day we won't have to. I am also questioning whether or not I can get the level of integration that I desire, and that is expected by the not-already-CL- users community, and remain CL compatible. I've only attempted a very small subset of CL in Clojure, but still encounter thorny issues esp. as relates to unifying the type systems. The conversions and wrappers of jFli are convenient and fun, and as long as you are using reflection the performance overhead is a non-issue, but when you are compiling it's a different story. Some of the things I am contending with in Clojure are: Should aref work on Java arrays? When calling a Java function that returns a string, do you get a Lisp string or a Java string? Should the non-mutating string library functions be made to work on Java strings? Should the generic function system be able to dispatch on Java types (i.e. not wrappers)? Can (some of) the sequence functions be made to work on Java collections? How does conditional logic handle Java null? Java booleans? etc. The fact is that CL has 'closed-over' much of its type system and is not really extensible in many areas. Which leaves all CL-compatible approaches having to deal with Java via an FFI such as jFli or jLinker, and thus a lot of jthis and jthat, conversions, wrappers etc. I had hoped to avoid much of that in Clojure, but I'm not sure I can and remain a proper CL subset that supports interactive development via Foil. So, I'm thinking, thus the quiescence. I am not interested in re-inventing wheels, and with its license change, I am happy to see ABCL dominate the CL-in-Java space. I would be very excited to see it adopt some Java calling primitives it would guarantee would compile into efficient direct Java calls, as well as compile-time Java class definition syntax (at which point I might become a serious user). I think ABCL is stunning in it's level of CL conformance, and is the logical home for the (hopefully compilable) future of jFli. Rich |
From: Peter G. <pe...@ar...> - 2005-10-30 18:17:53
|
On Sun, 30 Oct 2005 at 11:58:55 -0500, Rich Hickey wrote: > Well, nothing has been 'abandoned', but being one person with a > limited amount of spare time (none currently) I have to focus my > effort. None of my projects has seen significant interest or input, > and I would characterize the number of people in the CL community who > care about Java integration as very small - perhaps they are all > working on/with ABCL :) > > Nevertheless, I am still actively engaged in how best to integrate > Lisp and the JVM/CLR and intend to continue to contribute to this > area when I have time. Excellent! > Re: Clojure - I have reached the point where I am planning support > for defining Java/CLR classes etc and have realized that this is > something I should have implemented first. While I only have a small > amount of Java runtime lib code, if Clojure itself were capable of > generating decent Java classes and calls, ideally I should have none > (bootstrap issues aside). I am always surprised at the inordinate > amount of Java code in Lisp-in-Java implementations and I think this > is because they, too, added this later in the game. Otherwise, why > write so much Java? - the whole reason we do these things is so at > the end of the day we won't have to. The bootstrap issues can be formidable. My experience has been that it has proved very useful during ABCL's development to have its core written in pure Java, even though it's a bit annoying to have to deal with such a large body of Java code. > I am also questioning whether or not I can get the level of > integration that I desire, and that is expected by the not-already-CL- > users community, and remain CL compatible. I've only attempted a very > small subset of CL in Clojure, but still encounter thorny issues esp. > as relates to unifying the type systems. The conversions and wrappers > of jFli are convenient and fun, and as long as you are using > reflection the performance overhead is a non-issue, but when you are > compiling it's a different story. > > Some of the things I am contending with in Clojure are: > > Should aref work on Java arrays? > When calling a Java function that returns a string, do you get a Lisp > string or a Java string? > Should the non-mutating string library functions be made to work on > Java strings? > Should the generic function system be able to dispatch on Java types > (i.e. not wrappers)? > Can (some of) the sequence functions be made to work on Java > collections? > How does conditional logic handle Java null? Java booleans? > etc. > > The fact is that CL has 'closed-over' much of its type system and is > not really extensible in many areas. Which leaves all CL-compatible > approaches having to deal with Java via an FFI such as jFli or > jLinker, and thus a lot of jthis and jthat, conversions, wrappers > etc. I had hoped to avoid much of that in Clojure, but I'm not sure I > can and remain a proper CL subset that supports interactive > development via Foil. So, I'm thinking, thus the quiescence. > > I am not interested in re-inventing wheels, and with its license > change, I am happy to see ABCL dominate the CL-in-Java space. I would > be very excited to see it adopt some Java calling primitives it would > guarantee would compile into efficient direct Java calls, as well as > compile-time Java class definition syntax (at which point I might > become a serious user). I think ABCL is stunning in it's level of CL > conformance, and is the logical home for the (hopefully compilable) > future of jFli. I can certainly see reasons why one would want to call Java code from Lisp (the obvious one being to be able to use library code that would otherwise not be available), but not being much of a Java programmer, I have a harder time imagining why one would want to write a non-trivial Java class in Lisp when Lisp code can be compiled to efficient JVM bytecode directly. Of course you'd want to be able to implement an interface and be able to do callbacks and handle events, but it seems like these things can be done with relatively simple wrappers. Maybe I'm wrong about that. (And I'm probably ignoring some large class of applications that have totally different requirements.) In any event, my bias made a lot of decisions easy. ABCL is a full Common Lisp and uses the CL type system, for better or worse; the Java type system is not visible to Lisp. A LispObject is not identical to a java.lang.Object. Strings are mutable. The Lisp side sees only LispObjects, never a Java null or a Java boolean or a Java array or a Java collection. One of the design goals is that a user seeing just the repl should not even be aware that ABCL is implemented in Java. I've just started to look at the issue of having ABCL's compiler generate efficient direct Java calls, using the JCALL/JMETHOD stuff. I still don't think it's much of a problem, but I have no proof of that yet either. On the other hand, it's clear that there will always be at least a little overhead when you cross the Lisp/Java boundary, in either direction. That doesn't bother me; I don't cross it much. In the event that I actually need to define a real Java class, I'll probably just do it in Java. That shouldn't be taken to mean that ABCL won't ever provide some way of defining a real Java class. I do want to get rid of the ASM dependency in JNEW-RUNTIME-CLASS and friends, and a class definition syntax (is it really a syntax?) may fall out of that work. -Peter |
From: Peter G. <pe...@ar...> - 2005-10-30 10:31:14
|
On Sat, 29 Oct 2005 at 12:24:23 +0200, Andras Simon wrote: > On Fri, 28 Oct 2005, Peter Graves wrote: > > For example: > > > > CL-USER(1): (jnew (jconstructor "java.lang.String" "java.lang.String") > > (make-immediate-object nil :ref)) > > Debugger invoked on condition of type JAVA-EXCEPTION: > > java.lang.reflect.InvocationTargetException > > Since this exception is an artifact of our using reflection behind the > scenes, I think it would make sense to get the real cause (by > getCause()) and present that to the user (and also to check that on > the registered exceptions list). Then we'd have > > CL-USER(5): (jnew (jconstructor "java.lang.String" "java.lang.String") > (make-immediate-object nil :ref)) > Debugger invoked on condition of type JAVA-EXCEPTION: > java.lang.NullPointerException > at java.lang.String.<init>(String.java:144) > ... > > [1] CL-USER(7): (inspect *debug-condition*) > 0 LAYOUT -----------> #<SYSTEM:LAYOUT {176ED77}> > 1 FORMAT-CONTROL ---> NIL > 2 FORMAT-ARGUMENTS -> NIL > 3 CAUSE ------------> #<JAVA-OBJECT java.lang.NullPointerException {E02FC4}> > > and > > CL-USER(9): (jnew (jconstructor "java.lang.String" "java.lang.String") 23) > Debugger invoked on condition of type JAVA-EXCEPTION: > java.lang.IllegalArgumentException: argument type mismatch > > [1] CL-USER(10): (inspect *debug-condition*) > 0 LAYOUT -----------> #<SYSTEM:LAYOUT {176ED77}> > 1 FORMAT-CONTROL ---> NIL > 2 FORMAT-ARGUMENTS -> NIL > 3 CAUSE ------------> #<JAVA-OBJECT java.lang.IllegalArgumentException {600A08}> > > Perhaps a good rule of thumb is that exceptions that are in the > java.lang.reflect package should be replaced with their causes, and > all other exceptions should be left alone. > > One possible problem with this is if the user is doing her own > reflection. For what it's worth, jFli only does this for exceptions of class java.lang.reflect.InvocationTargetException. From jni.lisp: (defun handle-exception () (let ((e (exception-occurred))) (when (not (fli:null-pointer-p e)) ;allow for safe calling in non-exceptional state (exception-clear) ;if the exception occurs in the reflection target, we really want that (when (is-instance-of e (jni-find-class "java/lang/reflect/InvocationTargetException")) (setf e (invocationtargetexception.gettargetexception e))) (error "~A" (with-output-to-string (s) (format s "~A~%" (object.tostring e)) (do-jarray (x (throwable.getstacktrace e)) (format s "~A~%" (object.tostring x)))))))) Makes sense to me. -Peter |
From: Andras S. <as...@ma...> - 2005-10-30 10:44:31
|
On Sun, 30 Oct 2005, Peter Graves wrote: > On Sat, 29 Oct 2005 at 12:24:23 +0200, Andras Simon wrote: >> Perhaps a good rule of thumb is that exceptions that are in the >> java.lang.reflect package should be replaced with their causes, and >> all other exceptions should be left alone. >> >> One possible problem with this is if the user is doing her own >> reflection. > > For what it's worth, jFli only does this for exceptions of class > java.lang.reflect.InvocationTargetException. From jni.lisp: I only checked this for JNEW, but there InvocationTargetException is the only exception that is in the java.lang.reflect package. I put in getCause() there yesterday. I didn't do this unwrapping for JCALL, JSTATIC etc. because I haven't encountered InvocationTargetExceptions there yet. But perhaps it should be done anyway. Andras |
From: Russell M. <rus...@ya...> - 2005-10-31 11:42:48
|
Rich Hickey <ri...@ri...> writes: > Should aref work on Java arrays? > When calling a Java function that returns a string, do you get a Lisp > string or a Java string? > Should the non-mutating string library functions be made to work on > Java strings? > Should the generic function system be able to dispatch on Java types > (i.e. not wrappers)? > Can (some of) the sequence functions be made to work on Java > collections? > How does conditional logic handle Java null? Java booleans? > etc. $0.02 One approach that might work in these areas is to use CLOS liberally. aref could be a generic function. position, find, etc. could be a generic functions. If you've got this, then it's pretty easy to slip java types in there. And it's cool. So I am saying yes, the generic function function system should be able to dispatch on Java types. -russ |
From: Peter G. <pe...@ar...> - 2005-11-04 20:52:50
|
On Fri, 4 Nov 2005 at 21:30:36 +0100, Andras Simon wrote: > But I get this while doing a full compile: > > Primitives.java:3913: cannot find symbol > symbol : constructor > TypeError(org.armedbear.lisp.LispObject,java.lang.String) location: > class org.armedbear.lisp.TypeError > return signal(new TypeError(arg, "output stream")); > ^ > Closure.java:1166: cannot find symbol > symbol : constructor > TypeError(org.armedbear.lisp.LispObject,java.lang.String) location: > class org.armedbear.lisp.TypeError > return signal(new TypeError(arg, "closure")); > ^ > Note: Some input files use unchecked or unsafe operations. > Note: Recompile with -Xlint:unchecked for details. > 2 errors > Build failed. Looks like I forgot to check in Primitives.java (and Closure.java). Should be fixed now. Sorry! -Peter |
From: Andras S. <as...@ma...> - 2005-11-04 21:40:13
|
On Fri, 4 Nov 2005, Peter Graves wrote: > > Looks like I forgot to check in Primitives.java (and Closure.java). > > Should be fixed now. It is. Thanks, Andras |
From: Peter G. <pe...@ar...> - 2005-11-06 20:50:18
|
On Sun, 6 Nov 2005 at 19:52:00 +0100, Andras Simon wrote: > On Fri, 4 Nov 2005, Peter Graves wrote: > > There's a fundamental (and, I think, necessary) schizophrenia in ABCL's > > condition system: conditions defined in the *.java source files are > > instanceof Condition, but conditions defined by DEFINE-CONDITION are > > normal STANDARD-OBJECTs. > > > > Is this the reason for the following? > > CL-USER(1): (define-condition throwable (java-exception) ()) > THROWABLE > CL-USER(2): (register-java-exception "java.lang.Throwable" 'throwable) > T > CL-USER(3): (handler-case > (jnew (jconstructor "java.lang.String" "java.lang.String") > (make-immediate-object nil :ref)) > (throwable (c) c)) > #<THROWABLE {F1CDFB}> > CL-USER(4): (java-exception-cause *) > Debugger invoked on condition of type TYPE-ERROR: > The value #<THROWABLE {F1CDFB}> is not of type JAVA-EXCEPTION. > Restarts: > 0: TOP-LEVEL Return to top level. > [1] CL-USER(5): :res > CL-USER(6): (typep * 'java-exception) > T > CL-USER(7): > > That there is an error is fine, since I haven't updated Java.java. (I > plan to do that soon, by the way.) But the message is quite > misleading. Yes, JAVA-EXCEPTION-CAUSE was expecting its argument to be instanceof Condition, but a THROWABLE is just a STANDARD-OBJECT. Fixing that bug exposed a printing bug with UNBOUND-SLOT conditions, which I've also fixed. So now it works (or at least signals a plausible error): CL-USER(1): (define-condition throwable (java-exception) ()) THROWABLE CL-USER(2): (register-java-exception "java.lang.Throwable" 'throwable) T CL-USER(3): (handler-case (jnew (jconstructor "java.lang.String" "java.lang.String") (make-immediate-object nil :ref)) (throwable (c) c)) #<THROWABLE {1ABA308}> CL-USER(4): (java-exception-cause *) Debugger invoked on condition of type UNBOUND-SLOT: The slot SYSTEM::CAUSE is unbound in the object #<THROWABLE {1ABA308}>. Restarts: 0: TOP-LEVEL Return to top level. [1] CL-USER(5): There are probably more bugs like this lurking in the condition system, pending the completion of a thorough cleanup pass. -Peter |
From: Andras S. <as...@ma...> - 2005-11-06 22:28:42
|
On Sun, 6 Nov 2005, Peter Graves wrote: > > Yes, JAVA-EXCEPTION-CAUSE was expecting its argument to be instanceof > Condition, but a THROWABLE is just a STANDARD-OBJECT. > > Fixing that bug exposed a printing bug with UNBOUND-SLOT conditions, > which I've also fixed. > > So now it works (or at least signals a plausible error): > > CL-USER(1): (define-condition throwable (java-exception) ()) > THROWABLE > CL-USER(2): (register-java-exception "java.lang.Throwable" 'throwable) > T > CL-USER(3): (handler-case > (jnew (jconstructor "java.lang.String" "java.lang.String") > (make-immediate-object nil :ref)) > (throwable (c) c)) > #<THROWABLE {1ABA308}> > CL-USER(4): (java-exception-cause *) > Debugger invoked on condition of type UNBOUND-SLOT: > The slot SYSTEM::CAUSE is unbound in the object #<THROWABLE {1ABA308}>. > Restarts: > 0: TOP-LEVEL Return to top level. > [1] CL-USER(5): > Perfect! > There are probably more bugs like this lurking in the condition system, > pending the completion of a thorough cleanup pass. Is this one of them? CL-USER> (define-condition throwable (java-exception) ()) THROWABLE CL-USER> (register-java-exception "java.lang.Throwable" 'throwable) T CL-USER> (handler-case (jnew (jconstructor "java.lang.String" "java.lang.String") (make-immediate-object nil :ref)) (throwable (c) c)) #<THROWABLE {1F72D0}> CL-USER> (typep * 'simple-condition) NIL CL-USER> (simple-condition-format-control **) "java.lang.NullPointerException" [I've just committed the changes you suggested two days ago, that's how "java.lang.NullPointerException" got in the FORMAT-CONTROL slot.] In other words: should conditions that inherit from JAVA-EXCEPTION be SIMPLE-CONDITIONs? Andras |
From: Andras S. <as...@ma...> - 2005-11-06 22:59:29
|
On Sun, 6 Nov 2005, Andras Simon wrote: > > > On Sun, 6 Nov 2005, Peter Graves wrote: > >> >> Yes, JAVA-EXCEPTION-CAUSE was expecting its argument to be instanceof >> Condition, but a THROWABLE is just a STANDARD-OBJECT. >> >> Fixing that bug exposed a printing bug with UNBOUND-SLOT conditions, >> which I've also fixed. >> >> So now it works (or at least signals a plausible error): >> >> CL-USER(1): (define-condition throwable (java-exception) ()) >> THROWABLE >> CL-USER(2): (register-java-exception "java.lang.Throwable" 'throwable) >> T >> CL-USER(3): (handler-case >> (jnew (jconstructor "java.lang.String" >> "java.lang.String") >> (make-immediate-object nil :ref)) >> (throwable (c) c)) >> #<THROWABLE {1ABA308}> >> CL-USER(4): (java-exception-cause *) >> Debugger invoked on condition of type UNBOUND-SLOT: >> The slot SYSTEM::CAUSE is unbound in the object #<THROWABLE >> {1ABA308}>. >> Restarts: >> 0: TOP-LEVEL Return to top level. >> [1] CL-USER(5): >> > > Perfect! > >> There are probably more bugs like this lurking in the condition system, >> pending the completion of a thorough cleanup pass. > > Is this one of them? > > CL-USER> (define-condition throwable (java-exception) ()) > THROWABLE > CL-USER> (register-java-exception "java.lang.Throwable" 'throwable) > T > CL-USER> (handler-case > (jnew (jconstructor "java.lang.String" "java.lang.String") > (make-immediate-object nil :ref)) > (throwable (c) c)) > #<THROWABLE {1F72D0}> > CL-USER> (typep * 'simple-condition) > NIL > CL-USER> (simple-condition-format-control **) > "java.lang.NullPointerException" > > [I've just committed the changes you suggested two days ago, that's > how "java.lang.NullPointerException" got in the FORMAT-CONTROL slot.] > > In other words: should conditions that inherit from JAVA-EXCEPTION be > SIMPLE-CONDITIONs? I've just noticed that you wrote in the same mail I referred to above | I've fixed signal() at Lisp.java:303 to use the :FORMAT-CONTROL | initarg, which ABCL (like Allegro) supports for CONDITIONs as well as | SIMPLE-CONDITIONs: Sorry for the noise! Andras |
From: Peter G. <pe...@ar...> - 2005-11-08 05:42:36
|
On Mon, 7 Nov 2005 at 18:45:57 +0100, Andras Simon wrote: > The code that does the checking isn't very pretty. Some excuses: > - I'm sure there is a standard way to check (in Java) whether one > (Lisp) class is a subclass of another, but I couldn't find it. Before this evening, it wasn't easy to find, but now it is: private static boolean isJavaException(LispClass lc) { return lc.subclassp(LispClass.findClass(Symbol.JAVA_EXCEPTION)); } > - NIL is not a Cons, and that makes going down a list a bit harder > than usual. > - I would've liked to have a > > private static final LispClass java_exception = > LispClass.findClass(Symbol.JAVA_EXCEPTION); > > to compare the superclasses of the condition to be signaled with, but > it got initialized too early (?) and ended up being null. I've moved Java.class to the very end of the loadClass() list at the bottom of Lisp.java, so maybe that will work correctly now. StandardClass.JAVA_EXCEPTION might work too. > So now java_exception is a local variable in isJavaException [a > misleading name, by the way]. Maybe it would be simpler to check the > name of these classes against Symbol.JAVA_EXCEPTION, but that would > mean slightly more work at runtime. > > > > > Once again, completely untested... :) > > ... but working :) Great! -Peter |
From: Andras S. <as...@ma...> - 2005-11-08 12:40:52
|
On Mon, 7 Nov 2005, Peter Graves wrote: > On Mon, 7 Nov 2005 at 18:45:57 +0100, Andras Simon wrote: >> The code that does the checking isn't very pretty. Some excuses: >> - I'm sure there is a standard way to check (in Java) whether one >> (Lisp) class is a subclass of another, but I couldn't find it. > > Before this evening, it wasn't easy to find, but now it is: > > private static boolean isJavaException(LispClass lc) > { > return lc.subclassp(LispClass.findClass(Symbol.JAVA_EXCEPTION)); > } Much friendlier! >> private static final LispClass java_exception = >> LispClass.findClass(Symbol.JAVA_EXCEPTION); >> >> to compare the superclasses of the condition to be signaled with, but >> it got initialized too early (?) and ended up being null. > > I've moved Java.class to the very end of the loadClass() list at the > bottom of Lisp.java, so maybe that will work correctly now. It does. Thanks. I think it's now time to actually use this stuff. Andras |