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
-- 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")))
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?
thank you very much Giorgos
* 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.
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
* Giorgos Pontikakis [2005-12-05 23:30+0100] writes:
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).
Yes that's probably true. I think SBCL records the source location also for LOADed source files, but SBCL has no interpreter (everything is compiled) and I think SBCL has the same issue as CMUCL with regard to local variables.
-- 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.
I don't quite understand how CLISP works. The backtrace is apparently the entire stack content which includes much more than "frames" with local variables. There is also no real API for the debugger; that makes it hard for SLIME to produce something sensible.
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!
Lispworks has a pretty good debugger in that regard. Lispworks also supports the "restart-frame" thing so that you can replace a compiled function with a interpreted version before restarting. Interpreted code can also be stepped, but that's not supported by SLIME.
OTOH, experienced programmers don't seem to use sophisticated debuggers. Most of them are happy with print statements. Probably because they write short and easy to test functions.
Helmut.
-
Giorgos Pontikakis -
Helmut Eller