Usually the compiler will optimize things out and this will reduce the amount of information available to the debugger. For example sometimes we can’t see intermediate variables of computations. You know there are here, but you can't see them in the debugger, or you use a break point but you can't evaluate an expression in the context of your function because the compiler says that an intermediate variable doesn't exist (even though it does in your code). We can change the optimization choices with a declaration:
(declaim (optimize (speed 0) (space 0) (debug 3)))
and recompile the code.
But we can achieve the same with a handy shortcut: C-u C-c C-c: the form is compiled with maximum debug settings. You can on the contrary use a negative prefix argument (M--) to compile for speed. And use a numeric argument to set the setting to it (you should read the docstring of slime-compile-defun).
Usually the compiler will optimize things out and this will reduce the amount of information available to the debugger. For example sometimes we can’t see intermediate variables of computations. You know there are here, but you can't see them in the debugger, or you use a
breakpoint but you can't evaluate an expression in the context of your function because the compiler says that an intermediate variable doesn't exist (even though it does in your code). We can change the optimization choices with a declaration:and recompile the code.
But we can achieve the same with a handy shortcut:
C-u C-c C-c: the form is compiled with maximum debug settings. You can on the contrary use a negative prefix argument (M--) to compile for speed. And use a numeric argument to set the setting to it (you should read the docstring of slime-compile-defun).