[slime-devel] slime + CLISP: jump to source code

[Helmut Eller]

Onay <onayu at 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.