Onay onayu@gmx.net writes:
I wonder if there is a possibility to implement the mentioned feature since, at least IMO, it would be VERY MUCH appreciated. Often, files are loaded which do contain errors and the sldb just shows some info about the form. But then, it is quite a search to find the right place (file + line).
- does CLISP provide source file+line debug info when compiling/loading?
The last time I checked, a year ago, the situation was like this: compile time: COMPILE-FILE yes, COMPILE no load time: no runtime: no
- if yes, is it possible to benefit from this whithin slime?
I think compiler errors are annotated reasonably well in the source buffer. At least swank-clisp.lisp has some hacks for compiler to do that.
The most obvious problem with CLISP support are the poor backtraces in the SLIME debugger for compiled code. It basically means that you can't compile the code, if you want to see something the backtrace. CLISP's own debugger produces better backtraces, but many of the relevant bits are written in C and cannot be used easily for SLIME, e.g. CLISP's debugger prints the bracktrace directly to a stream while SLIME wants to have a list/vector of frame objects.
The situation for interpreted code is a bit better, at least we can display something. What still lacks is a way to map frames (or at least functions) to source locations (e.g. file/line/column).
- is anyone working on this?
Not that I know of.
- if not, i would like to work on it with help from the slime community...
I've heard that the CLISP developers want to keep CLISP a small and clean "execution engine" and that IDE like features should be implemented with some form of hooks in the compiler. [Just that there are no hooks at all at the moment.] I think that means that CLISP's fasl files will not include debug info or doc strings in the near future.
So, if you want to improve the situation, you have to talk to the CLISP developers [I think none of them uses SLIME] and convince them to some keep some debug info around at runtime.
If there is some debug info around and accessible from Lisp, teaching SLIME how to use it shouldn't be hard.
(since i am just a newbie in lisp, but an experienced c/c++'er)
Wizardly C skills are certainly required for hacking CLISP internals.
Helmut.