[slime-devel] local variables lost in cmucl

[Helmut Eller]

* Giorgos Pontikakis [2005-12-04 12:28+0100] writes:

> Hi,  
> I'm using CMUCL 19c and Slime from CVS. I get this strange  
> behaviour when I debug a lisp program: 
>  
> -- When I compile and load my files with the following: 
>  
> (dolist (i *source-files*) 
>   (declaim (optimize (speed 0) (space 0) (safety 3) (debug 3))) 
>   (compile-file (concatenate 'string i ".lisp"))) 
>  
>  
> (dolist (i *source-files*) 
>   (declaim (optimize (speed 0) (space 0) (safety 3) (debug 3))) 
>   (load (concatenate 'string i ".x86f"))) 
>  
> I can use the 'v' command of the slime-debugger to see my source 
> code, but I lose information for local variables 

Here you are working with _compiled_ code ...

>  
> -- When I just load the files using the following: 
>  
> (dolist (i *source-files*) 
>   (declaim (optimize (speed 0) (space 0) (safety 3) (debug 3))) 
>   (load (concatenate 'string i ".lisp"))) 

and here with _interpreted_ code.

> I have information for local variables, but the 'v' command 
> of the debugger does not jump to the source code. Instead, it 
> presents me with some representation of the code which I believe 
> that is the interpreted one, and is much more difficult to use. 
>  
> Is there something that I'm doing wrong, or is it a limitation 
> of slime? 

It's a CMUCL issue, i.e. it's unlikely that you will see different
behavior if you use CMUCL without SLIME.

I think the compiler does some register coalescing so that variables
which aren't "live" are not available in the debugger.  (The CMUCL
manual says that all local variables are available with (optimize
(debug 3)) but that claim is not consistent with reality.)

The interpreter on the other hand doesn't record source location
information (it only records the source s-expression but not the
file/position where that came from).

Unless you are willing to fix those issues in CMUCL, you have to
choose either compiled or interpreted code depending on what info you
want to preserve.  I tend to compile most of my code and if I know
that a bug is in a particular function, I switch to interpreted code
(with C-M-x on the source).

Good ol' print statements also help to preserve debug info for local
variables.

Helmut.