[armedbear-devel] [REVISED] Patch for including relevant java stack frames

Tobias C. Rittweiler tcr at freebits.de
Thu Jul 30 17:34:25 UTC 2009

Mark Evenson writes:

>  From what I recall this was to support the use of the :frame and 
> :inspect methods in the top-level REPL as it worked before.  One could 
> select a frame in the backtrace via ":frame n" (where n was the frame 
> you were interested in), and then issue an ":inspect *" to start walking 
> through the frame.  This should certainly be kept for the LispStackFrame 
> but maybe not for the JavaStackFrame.  I think I ran into one problem 
> that the "~S" representation of these objects was pretty opaque (i.e. 
> just "#<JAVA-STACK-FRAME>" and "#<LISP-STACK-FRAME"), but I am not quite 
> sure of my reasoning right now.  I'll revisit this in course of the 
> renamings you suggest below.

I was thinking that the opaqueness of #<JAVA-STACK-FRAME> was just a
temporary thing until introspection into Java objects would be added
which was an obvious next thing to do for ABCL. (And which Alessio just

> > b) I don't like that
> >
> >        (frame-to-list #<JAVA-STACK-FRAME>) =>  ("class.meth(file.java:NN)")
> >
> >     I think it should return ("class.meth" :file "file.java" :line NN) so
> >     higher levels can use that information. (For example `v' in SLDB.)
> Agreed.  I had a version doing plist like things as well, which makes a 
> lot more sense for tools further down the line.  I was going to make the 
> whole result a plist so as not to trip up future reorderings.  Would you 
> just have the first element of the list be a string?

I do not understand the question. Could you provide examples, please?


More information about the armedbear-devel mailing list