Alan Ruttenberg writes:

Can anyone summarize what kinds of source information are recorded? Is source location for generic function methods recorded? Variables? Constants? Stuctures?

I'd like to extend source recording for functions defined interactively in slime as well, if I can understand what needs to be done on the abcl side.

I could hunt around the source but figured I'd ask in case someone has thought of this recently.

I'm losing in slime most of the time I meta-point things.

Losing in what way exactly? Getting an error message in the minibuffer, or getting to the wrong place?

On another debugging front, is it possible to get local variables for functions that are interpreted, in the context of an exception? I understand it's more difficult for compiled functions.

I'm changing Slime so backends can provide even more information than just local lexical variables.

For example, see

http://paste.lisp.org/display/95598

on how the backend for the ECL implementations reports locally bound specials, and even restarts next to local lexical variables!

I'm saying this for the brave hero who tackles this problem so he knows that the more information he can press out of a stack frame the better.

-T.

On Mar 3, 2010, at 4:27 AM, Alan Ruttenberg wrote:

Can anyone summarize what kinds of source information are recorded? Is source location for generic function methods recorded? Variables? Constants? Stuctures?

Unfortunately, only source locations for normal function definitions are recorded. Some DEFMETHOD forms seem to record a source location, but the implementation seems a bit wonky here: it sometimes identifies the correct file without the correct position. I'm still trying understand our behavior.

I'd like to extend source recording for functions defined interactively in slime as well, if I can understand what needs to be done on the abcl side.

Function source locations are stored on the property list of the symbol corresponding to the function definition. The plist key is the symbol SYSTEM::%SOURCE with the value being a cons whose car is the pathname of the file and whose cdr is the character location in the file.

An example of such a plist would be (SYSTEM::%SOURCE (#P"/Users/evenson/work/misc/source-location.lisp" . 212)).

"All" you would have to do would be to set this plist after the function compilation, which should be relatively easy, as long as you have a corresponding file location.

I could hunt around the source but figured I'd ask in case someone has thought of this recently.

[…]

On another debugging front, is it possible to get local variables for functions that are interpreted, in the context of an exception? I understand it's more difficult for compiled functions.

Erik has claimed it would be fairly easy to implement such things for interpreted code, but I have yet to understand how to get this working easily. When we have time, I'll try to understand the approach he has in mind, and see if we can come up with an implementation strategy. It would certainly seem like a decent tradeoff to get such information in debugging code, modulo the parts of ABCL where our interpreted v. compiled semantics differ (which are bugs anyways).

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