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