On 12/31/10 4:30 AM, Alan Ruttenberg wrote: […]
b) If you are going to be doing thinking about compiler architecture I would very much like to see some thought going into debuggability. My current impression is that the trend is downward with more and more cases of not even being able to see function call arguments in slime. For example, at this point in ABCL's development, I think having a compiler option that pays performance for the ability to view local variables in the debugger should be an increasing priority. Other's mileage may vary, but in my case, where the bulk of time is spent in java libraries of various sorts, improving lisp performance is a distinctly lower priority than improving developer productivity by making it easier to debug.
Improving the ability to debug code is the main point is one of my main concerns as well. It is indeed good to know that this point of view is shared within the ABCL user community, and rest assured that I will continue to advocate/promote this line of thought in the development discussions on #abcl.
Steps in the direction of better debug facilities for ABCL that I have in mind would be 1) the ability to inspect local variables from a given stack frame (probably by implementing EVAL with respect to a given frame, 2) implementing STEP, 3) the ability to restart computation at a given frame, and 4) better integration with source location information like the necessary hooks to support XREF. I have no concrete plans for implementation yet, as I am just trying to analyze what would be involved. Any others out there on private wishlists?
Currently I am investigating how to do these things in interpreted mode as it seems to be the easier path, and being able to do debug things would greatly assist the construction of a corresponding compiler. The one exception to the observation that we should try to do these debug implementation in interpreted mode first, is it might be possible to implement STEP in compiled code via "native" JVM breakpoints, but this would entail outfitting the compiler with a much better mapping of source to object code (and might involve using one JVM to instrument a second one via JVMTI). This "source to object" mapping in the compiler seems to be needed in general, as it would allow (eventually) things like finding the value of a local variable in compiled mode and to debug the compiler behavior as was needed in the current problem with ticket #117 that I asked Erik to help out with in order to get callbacks working in JNA.
I have fought hard to prevent regressions in information present in SLIME. Are you observing the complete lack of all function call arguments in the SLIME debugger presentation? If so, we should debug your installation details a bit, as SLIME HEAD with ABCL trunk always should work as it's what I test with. In order to prevent the pretty printer's elision of frame arguments, I often have to set *PRINT-RIGHT-MARGIN* to some large finite value, but I assume you would have recognized this. The compiler also often optimizes away stack frames that can be restored quickly by interpreting the given form at the current point in SLIME via M-x slime-eval-defun. Please provide some more details when you get the chance.
ABCL: arming bears since 1997!