[armedbear-devel] New Java/Lisp stack frame distinction committed to trunk

[Mark Evenson]

I've just committed my version of Tobias' idea about including Java 
stack information in stack traces when relevant to the trunk.  The 
associated work for SLIME has been committed to SLIME HEAD.

 From the commit message of [svn 12105][1]:

Split StackFrame abstraction into Java and Lisp stack frames.

 From the original patch/idea from Tobias Rittweiler this introduces
more information of primary interest to ABCL implementers such as when
a form like (make-thread #'(lambda ())) is evaluated

All users of EXT:BACKTRACE-AS-LIST should now use SYS:BACKTRACE, the
results of which is a list of the new builtin classes JAVA_STACK_FRAME
or LISP_STACK_FRAME. The methods SYS:FRAME-TO-STRING and
SYS:FRAME-TO-LIST are defined to break these new objects into
inspectable parts. As a convenience, there is a SYS:BACKTRACE-AS-LIST
which calls SYS:FRAME-TO-LIST on each element of the computed
backtrace.

Refactorings have also occurred on the Java side: the misnamed
LispThread.backtrace() is now LispThread.printBacktrace().
LispThread.backtraceAsList() is now LispThread.backtrace() as it is
a shorter name, and more to the point.

Java stack frames only appear after a call through Lisp.error(), which
has only the top level as a restart as an option, so concerns about 
trashing the stack are not really relevant (an early concern of mine).

[1]: http://trac.common-lisp.net/armedbear/changeset/12105

-- 
"A screaming comes across the sky.  It has happened before, but there
is nothing to compare to it now."