[slime-devel] Re: local variables lost in cmucl

[Giorgos Pontikakis]

Helmut Eller <heller <at> common-lisp.net> writes: 
 
>  
> * 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. 
>  
Ok, first of all, thank you for your answer. I had read and had trusted  
the CMUCL manual regarding the (debug 3) statement, that's why I had  
expected this was a SLIME issue. 
 
Of course, I am unable to fix such issues in CMUCL :-). I am a Lisp newbie 
and I have been learning Lisp just for fun, after a PhD coding in fortran. 
(I studied and work as a mechanical engineer -- I am not a professional 
programmer).  
 
So, my next question is: Are there any other alternatives for having 
information for local variables _and_ source code location recording 
simultaneously? Maybe with another Lisp implementation (preferably  
on Linux)?  
 
I have tried SBCL and CLISP, but: 
-- SBCL+SLIME behaves similarly with (if not worse than) CMUCL+SLIME. 
(which I find plausible, since SBCL is a CMUCL fork). 
-- CLISP+SLIME does not even give me a backtrace (although the CLISP  
debugger alone does. I think I've read somewhere in the SLIME docs that 
this is a CLISP issue. 
 
Or maybe I didn't set up thing appropriately with either implementation. 
I don't know. If you can enlighten me, I would be grateful! 
 
Thanks again 
-- Giorgos