I have added to our inspector the ability to look into Java classes, showing the values of fields and allowing them to be further inspected. Here's an example interaction:
CL-USER(1): (setq obj (jnew (jconstructor "java.util.ArrayList"))) #<JAVA-OBJECT java.util.ArrayList {98062F}> CL-USER(2): (inspect obj) #<JAVA-OBJECT java.util.ArrayList {98062F}> is an object of type JAVA-OBJECT. The wrapped Java object is an instance of java.util.ArrayList: "[]" 0 java-class -------> #<JAVA-OBJECT java.lang.Class {1FB7CBB}> 1 fields -----------> (("serialVersionUID" 8683452581122892189 ...) ("elementData" # ...) ...) [1i] CL-USER(3): :istep 1 A proper list with 4 elements at #x385715 0-> ("serialVersionUID" 8683452581122892189 ...) 1-> ("elementData" #(NIL NIL ...) ...) 2-> ("size" 0 ...) 3-> ("modCount" 0 ...) [1i] CL-USER(4): :istep 1 A proper list with 3 elements at #xDD23CF 0-> "elementData" 1-> #(NIL NIL ...) 2-> #<JAVA-OBJECT java.lang.reflect.Field {5A25F3}> [1i] CL-USER(5):
As you can see, fields are triplets: the field name, the value, and the Field metaobject. I chose to represent them as simple lists to avoid having a class just for that purpose.
NB: since the field values are read when the object is first inspected, and then translated to Lisp objects, the inspector will NOT reflect the current state of the object should it be altered (e.g. by another thread, or interactively by the user while inspecting). This is important especially wrt. inner objects: if A contains B and later C, inspecting A at a certain time will show me B, and inspecting B will, unsurprisingly, show me B, not C - even if A contains C now. I don't know if our inspector behaves like this for other objects too or not, but I don't see any (easy) way to change this fact.
Next I'd like to show methods as well, and maybe even allow one to easily call them interactively (e.g. by making a method be a shown as triplet as well - the signature as a string, the java.lang.reflect.Method metaobject, and a closure which, when invoked, calls the method on the inspected object with the given parameters).
I'm also working on a graphical inspector, but that's a bit more in the works ;)
Thoughts?
Ale
Alessio Stalla writes:
I have added to our inspector the ability to look into Java classes, showing the values of fields and allowing them to be further inspected.
Cool!
NB: since the field values are read when the object is first inspected, and then translated to Lisp objects,
Is the translation cached?
the inspector will NOT reflect the current state of the object should it be altered (e.g. by another thread, or interactively by the user while inspecting). This is important especially wrt. inner objects: if A contains B and later C, inspecting A at a certain time will show me B, and inspecting B will, unsurprisingly, show me B, not C - even if A contains C now. I don't know if our inspector behaves like this for other objects too or not, but I don't see any (easy) way to change this fact.
If the translation is not cached, reinspection of A results in correctly showing C, right?
At least in the Slime Inspector, objects are reinspected on navigating back from an inner object. I.e. in your example above: you'd start with A, would go down to B, and when going back to A, A is reinspected and hence will now show C instead of B.
-T.
Alessio Stalla writes:
I have added to our inspector the ability to look into Java classes, showing the values of fields and allowing them to be further inspected.
Cool!
NB: since the field values are read when the object is first inspected, and then translated to Lisp objects,
Is the translation cached?
the inspector will NOT reflect the current state of the object should it be altered (e.g. by another thread, or interactively by the user while inspecting). This is important especially wrt. inner objects: if A contains B and later C, inspecting A at a certain time will show me B, and inspecting B will, unsurprisingly, show me B, not C - even if A contains C now. I don't know if our inspector behaves like this for other objects too or not, but I don't see any (easy) way to change this fact.
If the translation is not cached, reinspection of A results in correctly showing C, right?
At least in the Slime Inspector, objects are reinspected on navigating back from an inner object. I.e. in your example above: you'd start with A, would go down to B, and when going back to A, A is reinspected and hence will now show C instead of B.
-T.
On Tue, Jul 28, 2009 at 10:58 PM, Tobias C. Rittweilertcr@freebits.de wrote:
Alessio Stalla writes:
I have added to our inspector the ability to look into Java classes, showing the values of fields and allowing them to be further inspected.
Cool!
NB: since the field values are read when the object is first inspected, and then translated to Lisp objects,
Is the translation cached?
Yes, but not by my code. The abcl inspector expects the objects it's showing are the actual objects, not representations of them, so it has no concept of "refreshing" an object.
the inspector will NOT reflect the current state of the object should it be altered (e.g. by another thread, or interactively by the user while inspecting). This is important especially wrt. inner objects: if A contains B and later C, inspecting A at a certain time will show me B, and inspecting B will, unsurprisingly, show me B, not C - even if A contains C now. I don't know if our inspector behaves like this for other objects too or not, but I don't see any (easy) way to change this fact.
If the translation is not cached, reinspection of A results in correctly showing C, right?
At least in the Slime Inspector, objects are reinspected on navigating back from an inner object. I.e. in your example above: you'd start with A, would go down to B, and when going back to A, A is reinspected and hence will now show C instead of B.
Sure, I think the abcl inspector does this too. However, with Lisp objects B is B itself; with Java objects, B is a representation of object B' in a certain state. If B' changes, B remains the same.
Example: A contains a field which is an array B of 10 ints, all zeros. When I inspect B, I'll see a Lisp array of 10 Fixnums, all zeros. I can inspect one of them, and see it's zero; then I change B to contain all 42s, and return to the previous inspected object: I'll still see a Lisp array of 10 zeroed Fixnums. If I reinspect A, I'll see of course the new state. This is because the Java array has been translated to Lisp, and the Lisp object has been inspected instead. Also if I modify the inspected array, the original one won't get modified.
However, I understand now that I can change that easily - I can return the raw untranslated Java object - you'll see all fields have a value of #<JAVA-OBJECT foo.bar.Class>, even for numbers, arrays, strings and other simple types; but that will always reflect the current object, and you'll still be able to inspect it to see what it is, so I think it's a sensible thing to do.
Bye, Alessio
Alessio Stalla writes:
Sure, I think the abcl inspector does this too. However, with Lisp objects B is B itself; with Java objects, B is a representation of object B' in a certain state. If B' changes, B remains the same.
Where and why does that translation take place? I can see the need for to wrap "native" Java objects into an LispObject so you can pass it to Lisp functions, right? But why the deep wrapping?
However, I understand now that I can change that easily - I can return the raw untranslated Java object - you'll see all fields have a value of #<JAVA-OBJECT foo.bar.Class>, even for numbers, arrays, strings and other simple types; but that will always reflect the current object, and you'll still be able to inspect it to see what it is, so I think it's a sensible thing to do.
Yes, it's what I'd expect.
-T.
On Tue, Jul 28, 2009 at 11:48 PM, Tobias C. Rittweilertcr@freebits.de wrote:
Alessio Stalla writes:
Sure, I think the abcl inspector does this too. However, with Lisp objects B is B itself; with Java objects, B is a representation of object B' in a certain state. If B' changes, B remains the same.
Where and why does that translation take place? I can see the need for to wrap "native" Java objects into an LispObject so you can pass it to Lisp functions, right? But why the deep wrapping?
Poor design by my part ;)
However, I understand now that I can change that easily - I can return the raw untranslated Java object - you'll see all fields have a value of #<JAVA-OBJECT foo.bar.Class>, even for numbers, arrays, strings and other simple types; but that will always reflect the current object, and you'll still be able to inspect it to see what it is, so I think it's a sensible thing to do.
Yes, it's what I'd expect.
-T.
Ok, here's the new & improved patch :)
Bye, Ale
Just fyi - Michael Travers wrote the beginnings of swing based inspector for java that I use in LSW for productive work. Anyone is welcome to grab it and improve it or just steal ideas or code. It's at:
http://mumble.net:8080/svn/lsw/trunk/inspect/
-Alan
On Tue, Jul 28, 2009 at 5:59 PM, Alessio Stallaalessiostalla@gmail.com wrote:
On Tue, Jul 28, 2009 at 11:48 PM, Tobias C. Rittweilertcr@freebits.de wrote:
Alessio Stalla writes:
Sure, I think the abcl inspector does this too. However, with Lisp objects B is B itself; with Java objects, B is a representation of object B' in a certain state. If B' changes, B remains the same.
Where and why does that translation take place? I can see the need for to wrap "native" Java objects into an LispObject so you can pass it to Lisp functions, right? But why the deep wrapping?
Poor design by my part ;)
However, I understand now that I can change that easily - I can return the raw untranslated Java object - you'll see all fields have a value of #<JAVA-OBJECT foo.bar.Class>, even for numbers, arrays, strings and other simple types; but that will always reflect the current object, and you'll still be able to inspect it to see what it is, so I think it's a sensible thing to do.
Yes, it's what I'd expect.
-T.
Ok, here's the new & improved patch :)
Bye, Ale
armedbear-devel mailing list armedbear-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
On Wed, Jul 29, 2009 at 12:40 AM, Alan Ruttenbergalanruttenberg@gmail.com wrote:
Just fyi - Michael Travers wrote the beginnings of swing based inspector for java that I use in LSW for productive work. Anyone is welcome to grab it and improve it or just steal ideas or code. It's at:
Very interesting! Actually the inspector I have begun working on is more of a sample/test for the Swing library I'm coding. It mostly re-uses what's already in abcl and just packages it in a GUI. It seems Mike's is more powerful, as it also knows about rdf, and maybe more (I've just given it a quick look). I also see that he wrote his own little Swing abstraction for the inspector: is LSW itself a GUI application, or just the inspector? (just curious - I'd like to see as many abcl+Swing applications as possible in order to improve my library). In any case, I'll consider stealing some code :) I have defined a little object-description abstraction, so I'm not tied to abcl's own inspector infrastructure only, and I can easily plug in new types of objects to be inspected. And of course, I'll share my code - it's not published yet, but I plan to set up a common-lisp.net project soon, even if the library is still not much more than a sketch.
Bye, Alessio
On Wed, Jul 29, 2009 at 3:43 AM, Alessio Stallaalessiostalla@gmail.com wrote:
On Wed, Jul 29, 2009 at 12:40 AM, Alan Ruttenbergalanruttenberg@gmail.com wrote:
Just fyi - Michael Travers wrote the beginnings of swing based inspector for java that I use in LSW for productive work. Anyone is welcome to grab it and improve it or just steal ideas or code. It's at:
Very interesting! Actually the inspector I have begun working on is more of a sample/test for the Swing library I'm coding. It mostly re-uses what's already in abcl and just packages it in a GUI. It seems Mike's is more powerful, as it also knows about rdf, and maybe more (I've just given it a quick look). I also see that he wrote his own little Swing abstraction for the inspector: is LSW itself a GUI application, or just the inspector?
LSW is my tools for manipulating OWL and using various semantic web technologies in abcl. It does a bunch of stuff, but does have, as one component, an ontology browser based on the prefuse (http://prefuse.org) package (see pretty picture here: http://esw.w3.org/topic/LSW) and another graphical tools for debugging reasoner performance based on some of the tools that Mike wrote (which in turn use some of the prefuse base)
The ontology browser is very much written for *me* and is the typical agglomeration of functionality without coherent design. It could use a serious re-engineer, but might have snippets of use to you. See http://mumble.net:8080/svn/lsw/trunk/owl/graph.lisp
The bit for the other tool is in http://mumble.net:8080/svn/lsw/trunk/owl/abox.lisp
(just curious - I'd like to see as many abcl+Swing applications as possible in order to improve my library). In any case, I'll consider stealing some code :) I have defined a little object-description abstraction, so I'm not tied to abcl's own inspector infrastructure only, and I can easily plug in new types of objects to be inspected. And of course, I'll share my code - it's not published yet, but I plan to set up a common-lisp.net project soon, even if the library is still not much more than a sketch.
Looking forward to seeing (and using/stealing from it ;-)
Regards, Alan
Bye, Alessio
I created some slime patches to improve inspector functionality for abcl.
I submitted that patch to the slime mailing list, but it was never applied. I didn't have the inclination to push it any farther, but you might find the code interesting / helpful.
-russ
----- Original Message ----
From: Alessio Stalla alessiostalla@gmail.com To: armedbear-devel@common-lisp.net Sent: Tuesday, July 28, 2009 3:30:00 PM Subject: [armedbear-devel] Proposed patch for ticket #58 (inspection of Java objects)
I have added to our inspector the ability to look into Java classes, showing the values of fields and allowing them to be further inspected. Here's an example interaction:
CL-USER(1): (setq obj (jnew (jconstructor "java.util.ArrayList"))) # CL-USER(2): (inspect obj) #is an object of type JAVA-OBJECT. The wrapped Java object is an instance of java.util.ArrayList: "[]" 0 java-class -------> # 1 fields -----------> (("serialVersionUID" 8683452581122892189 ...) ("elementData" # ...) ...) [1i] CL-USER(3): :istep 1 A proper list with 4 elements at #x385715 0-> ("serialVersionUID" 8683452581122892189 ...) 1-> ("elementData" #(NIL NIL ...) ...) 2-> ("size" 0 ...) 3-> ("modCount" 0 ...) [1i] CL-USER(4): :istep 1 A proper list with 3 elements at #xDD23CF 0-> "elementData" 1-> #(NIL NIL ...) 2-> # [1i] CL-USER(5):
As you can see, fields are triplets: the field name, the value, and the Field metaobject. I chose to represent them as simple lists to avoid having a class just for that purpose.
NB: since the field values are read when the object is first inspected, and then translated to Lisp objects, the inspector will NOT reflect the current state of the object should it be altered (e.g. by another thread, or interactively by the user while inspecting). This is important especially wrt. inner objects: if A contains B and later C, inspecting A at a certain time will show me B, and inspecting B will, unsurprisingly, show me B, not C - even if A contains C now. I don't know if our inspector behaves like this for other objects too or not, but I don't see any (easy) way to change this fact.
Next I'd like to show methods as well, and maybe even allow one to easily call them interactively (e.g. by making a method be a shown as triplet as well - the signature as a string, the java.lang.reflect.Method metaobject, and a closure which, when invoked, calls the method on the inspected object with the given parameters).
I'm also working on a graphical inspector, but that's a bit more in the works ;)
Thoughts?
Ale
Russell McManus writes:
I created some slime patches to improve inspector functionality for abcl.
I submitted that patch to the slime mailing list, but it was never applied. I didn't have the inclination to push it any farther, but you might find the code interesting / helpful.
I'll take a look at it next week, and will also see how to leverage Alessio's work. In general people from implementations themselves are responsible for their swank backends. I don't think anyone of the ABCL team has commit right yet, though.
Mark Evenson seems like a good candidate. Mark, do you have a c-l.net account?
-T.
On 7/29/09 8:27 AM, Tobias C. Rittweiler wrote: […]
Mark Evenson seems like a good candidate. Mark, do you have a c-l.net account?
Yep (mevenson)! I'd be happy to accept SLIME commit rights on behalf of ABCL.
Mark
armedbear-devel@common-lisp.net
-
Alan Ruttenberg -
Alessio Stalla -
Mark Evenson -
Russell McManus -
Tobias C. Rittweiler