Hi Nikodemus,
On Thu, 17 May 2012, Nikodemus Siivola wrote:
> On 16 May 2012 07:37, Faheem Mitha <faheem@...> wrote:
>
>> Ok, I tried this. You mention debug 2, but your example does not use
>> that, so I added it. Maybe debug 2 is the default, but if so, that is
>> not mentioned, at least not in the SBCl user manual. However, I get
>> exactly the same results as listed below with just 'debug'.
>
> It's in the standard:
>
> (declare (optimize foo)) == (declare (optimize (debug 3)))
Sorry, I don't follow. I looked at
http://clhs.lisp.se/Body/d_optimi.htm. I see the line
"(quality 3) can be abbreviated to quality."
which I missed in my first two readings of that section, so perhaps
you meant to write
> (declare (optimize foo)) == (declare (optimize (foo 3)))
or possibly
> (declare (optimize debug)) == (declare (optimize (debug 3)))
?
>> By "give the SOURCE command in the debugger", I assume you mean the
>> SBCL debugger, which is distinct from sldb, right? So, continuing with
>> sldb...
>
> Yes, that was referring the build-in debugger as distinct from Slime.
> The one you get if you run SBCL in the terminal.
>
>> I pressed v with the cursor on top of frame 0. I got the following
>> curious error message in the minibuffer
>> Error: failed to find the WRITE-DATE of
>> /build/buildd-sbcl_1.0.56.0-1-i386-KfmyJG/sbcl-1.0.56.0/src/code/numbers.lisp:
>> No such file or directory
> That was the frame for /. You don't have SBCL sources present or
> configured properly, so it could not jump to the source for /.
Ah. Ok. I've tried installing sbcl-source in Debian, which apparently
exists for this purpose, but haven't yet managed to get it to work. It
is looking in the wrong place - I need to get it to look in
/usr/share/doc/sbcl-source/ as opposed to
/build/buildd-sbcl_1.0.56.0-1-i386-KfmyJG/sbcl-1.0.56.0/src/. Any
tips?
This looks like something that could also be usefully documented in
the manual for Debian/Ubuntu users, who probably number a sizeable
proportion of SBCL users. However, I'm not attempting documentation
since I can't get it to work.
>> When I put the cursor on top of frame 1, and pressed v I got
>>
>> (foo 1)
>>
>> in the minibuffer, and the cursor (not in focus) in the source file
>> jumped here
>>
>> (z (/ x y)))
>> ^
>>
>> namely, where the division by zero error occurs, and the form (/ x y)
>> briefly flashed yellow.
>>
>> I assume that the change in position of the cursor in the source file
>> and the flashing is the main intended effect.
>
> Yes.
>
>> Anyway, if SLIME can reliably show me exactly where the error occurs
>> by jumping there (I haven't tested it on any complicated code), I
>> guess the source code line is not needed.
>
> Yes.
>
>> I tried using the SBCL debugger directly from the SBCL interpreter
>> (see session below) but the SOURCE command did not show me anything. I
>> got the message "The source path no longer exists."
>
> That's because showing the source doesn't work currently for things
> defined at the REPL or via EVAL -- it's a known bug.
I see. Is this bug documented anywhere? I could not find it. I can report
it if you want.
I don't know whether the SBCL developers are interested to
user-contributed patches to the manual, but I made one, mostly out of
your replies to my question. See below and attached. Some comments:
* The patch is just suggestions. Use or discard as you wish.
* I was unable to compile the manual to test the patch. I get
faheem@...$ sh make-doc.sh
for module in :sb-md5 :sb-queue :sb-concurrency :sb-rotate-byte :sb-grovel :sb-sprof :sb-bsd-sockets :sb-cover :sb-posix; do \
test -f "../../contrib/"/`echo $module | tr -d :`/test-passed \
|| { echo "The documented contrib $module seems \
to have failed its tests." && exit 1; } \
done
The documented contrib :sb-md5 seems to have failed its tests.
make: *** [docstrings] Error 1
I tried similar commands like `make` in doc/manual, but get the same
error. This doesn't seem to have anything to do with my patch. I get
the same error with a pristine copy. Maybe the developers could
document how to build this?
* The SBCL manual is a bit "high level", at least for a beginning
user. In particular, it could use more concrete examples, e.g. in the
debugging section. Also, I think details of interactive sessions are
useful, again, for the beginner at least.
* I notice your manual doesn't mention SLIME anywhere. I don't know
whether this is by design, but I added a reference to the SLIME debugger
at what seemed like the natural place. An argument for including this is
that SLIME is what most of your users will be using anyway.
* I don't understand the last section in that source level debugging
section, namely
#####################################################################
If enclosing source is printed by giving an argument to
@command{source} or @command{vsource}, then the actual source form is
marked by wrapping it in a list whose first element is
@samp{#:***HERE***}. In the previous example, @code{source 1} would
print:
@example
; File: /usr/me/mystuff.lisp
(DEFUN FOO ()
(#:***HERE***
(MYMAC))
...)
@end example
#######################################################################
What is the use of this feature? What happens differently for different
versions of the argument?
Regards, Faheem
[Snip SBCL interpreter session].
diff --git a/doc/manual/debugger.texinfo b/doc/manual/debugger.texinfo
index 82e6b7d..9cef672 100644
--- a/doc/manual/debugger.texinfo
+++ b/doc/manual/debugger.texinfo
@@ -654,6 +654,62 @@ return, then the @command{source} command would print:
Note that the macro use was printed, not the actual function call form,
@code{(myfun)}.
+Here is a more concrete example not involving a macro. Suppose the file
+@file{/usr/me/foo.lisp} looked like this:
+
+@lisp
+(defun foo (x)
+ (declare (optimize debug))
+ (let* ((y (- x x))
+ (z (/ x y)))
+ (+ y z)))
+@end lisp
+
+Then we can run the following commands to get the source form. We first
+compile, load and execute @code{(foo)}, and then use the
+@command{source} command as before.
+
+@example
+* (compile-file "foo.lisp")
+* (load *)
+* (foo 1)
+
+debugger invoked on a DIVISION-BY-ZERO in thread
+#<THREAD "main thread" RUNNING {1003600EA3}>:
+ arithmetic error DIVISION-BY-ZERO signalled
+Operation was SB-KERNEL::DIVISION, operands (1 0).
+
+Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
+
+restarts (invokable by number or by possibly-abbreviated name):
+ 0: [ABORT] Exit debugger, returning to top level.
+
+(SB-KERNEL::INTEGER-/-INTEGER 1 0)
+0] source
+
+#<SB-DI::COMPILED-DEBUG-FUN SB-KERNEL::INTEGER-/-INTEGER> has no
+debug-block information.
+0] d
+(FOO 1)
+1] source
+
+; file: /Users/nikodemus/tmp/foo.lisp
+
+(/ X Y)
+1]
+@end example
+
+For the form to be printed, the source must be compiled with a debugger
+optimization level greater than or equal to 2.
+
+This command does not work currently for code defined at the REPL or via
+@code{eval}. See bug >>bug number here<<.
+
+An alternative to using the source command is to use the SLIME debugger
+sldb within SLIME. Pressing v on a frame will make the cursor jump to
+the location of the form which is giving the error in the source, and
+while the key is depressed the source form will be highlighted.
+
If enclosing source is printed by giving an argument to
@command{source} or @command{vsource}, then the actual source form is
marked by wrapping it in a list whose first element is
|