From: Faheem M. <fa...@fa...> - 2012-05-14 23:33:39
|
Hi, Maybe I'm missing something, but... why aren't line numbers of the source file given as part of the SBCL runtime traceback? I'm running SBCL inside SLIME, but the tracebacks look like they are output directly from SBCL, so I doubt SLIME is affecting something here. The tracebacks do mention the function that is causing the error, but in cases where that function is called several times, it would definitely be most helpful to have a line number. I notice the line numbers *are* given for compilation errors, so perhaps this is a language or implementation limitation? I don't know much about CL's compilation model, except that it compiles stuff down to machine code. If possible, I would of course like to have the line numbers. Regards, Faheem |
From: Nikodemus S. <nik...@ra...> - 2012-05-15 05:25:46
|
On 15 May 2012 02:33, Faheem Mitha <fa...@fa...> wrote: > Maybe I'm missing something, but... why aren't line numbers of the source > file given as part of the SBCL runtime traceback? I'm running SBCL inside > SLIME, but the tracebacks look like they are output directly from SBCL, so > I doubt SLIME is affecting something here. The tracebacks do mention the > function that is causing the error, but in cases where that function is > called several times, it would definitely be most helpful to have a line > number. SBCL doesn't save line numbers but relative source locations (at sufficiently high debug level.) Source location refers to logical position in the file: Nth toplevel form, subform N2, subsubform N3, etc. (defun foo (x) (declare (optimize debug)) (let* ((y (- x x)) (z (/ x y))) (+ y z))) compile this, evaluate (foo 1) and give the SOURCE command in he debugger and you'll see /exactly/ where the error occurs -- or you can use v in the slime debugger: move on top of the frame you want to investigate first. (The you currently need debug 2 or greater for this information to be saved. Perhaps that decision should be revisited. Doing that would be relatively easy -- but needs measurements to see effect on code sizes for large systems. It might even be that advantages of source locations vs lines numbers should be revisited -- but doing that is a substantial enough a change that unless a volunteer shows up and does all the work it is unlikely to happen in near future.) Cheers, -- Nikodemus |
From: Faheem M. <fa...@fa...> - 2012-05-16 04:38:03
|
Hi Nikodemus, Thanks for the helpful reply. See comments below. On Tue, 15 May 2012, Nikodemus Siivola wrote: > On 15 May 2012 02:33, Faheem Mitha <fa...@fa...> wrote: > >> Maybe I'm missing something, but... why aren't line numbers of the source >> file given as part of the SBCL runtime traceback? I'm running SBCL inside >> SLIME, but the tracebacks look like they are output directly from SBCL, so >> I doubt SLIME is affecting something here. The tracebacks do mention the >> function that is causing the error, but in cases where that function is >> called several times, it would definitely be most helpful to have a line >> number. > SBCL doesn't save line numbers but relative source locations (at > sufficiently high debug level.) Source location refers to logical > position in the file: Nth toplevel form, subform N2, subsubform N3, > etc. > (defun foo (x) > (declare (optimize debug)) > (let* ((y (- x x)) > (z (/ x y))) > (+ y z))) > compile this, evaluate (foo 1) and give the SOURCE command in he > debugger and you'll see /exactly/ where the error occurs -- or you > can use v in the slime debugger: move on top of the frame you want > to investigate first. > (The you currently need debug 2 or greater for this information to > be saved. Perhaps that decision should be revisited. Doing that > would be relatively easy -- but needs measurements to see effect on > code sizes for large systems. It might even be that advantages of > source locations vs lines numbers should be revisited -- but doing > that is a substantial enough a change that unless a volunteer shows > up and does all the work it is unlikely to happen in near future.) 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'. The following is with SLIME. I got the following backtrace in sldb. Backtrace: 0: (SB-KERNEL::INTEGER-/-INTEGER 1 0) 1: (FOO 1) 2: (SB-INT:SIMPLE-EVAL-IN-LEXENV (FOO 1) #<NULL-LEXENV>) 3: (EVAL (FOO 1)) 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... 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 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. Without the debug, the cursor jumped to the beginning of the function, and the whole function flashed yellow. 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. 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." Regards, Faheem ###################################################################### faheem@orwell[default branch:rev 35]:~/lisp$ rlwrap sbcl This is SBCL 1.0.56.0.debian, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. (defun foo (x) (declare (optimize (debug 2))) (let* ((y (- x x)) (z (/ x y))) (+ y z))) FOO * (foo 1) debugger invoked on a DIVISION-BY-ZERO in thread #<THREAD "initial thread" RUNNING {AB19809}>: 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] down 1 (FOO 1) 1] SOURCE debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" RUNNING {AB19809}>: The source path no longer exists. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Reduce debugger level (to debug level 1). 1: Exit debugger, returning to top level. (SB-DEBUG::CODE-LOCATION-SOURCE-FORM #<SB-DI::COMPILED-CODE-LOCATION FOO> 0) |
From: Nikodemus S. <nik...@ra...> - 2012-05-17 11:11:56
|
On 16 May 2012 07:37, Faheem Mitha <fa...@fa...> 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))) > 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 /. > 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. [nikodemus@delirium:~/tmp] > cat foo.lisp (defun foo (x) (declare (optimize (debug 2))) (let* ((y (- x x)) (z (/ x y))) (+ y z))) [nikodemus@delirium:~/tmp] > sbcl --no-userinit This is SBCL 1.0.56.56.master.1-b568ed0, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (compile-file "foo.lisp") ; compiling file "/Users/nikodemus/tmp/foo.lisp" (written 17 MAY 2012 01:56:03 PM): ; compiling (DEFUN FOO ...) ; /Users/nikodemus/tmp/foo.fasl written ; compilation finished in 0:00:00.026 #P"/Users/nikodemus/tmp/foo.fasl" NIL NIL * (load *) T * (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] Cheers, -- Nikodemus |
From: Faheem M. <fa...@fa...> - 2012-05-18 18:58:09
Attachments:
patch
|
Hi Nikodemus, On Thu, 17 May 2012, Nikodemus Siivola wrote: > On 16 May 2012 07:37, Faheem Mitha <fa...@fa...> 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@orwell:/usr/local/src/sbcl/sbcl/doc$ 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 |
From: Nikodemus S. <nik...@ra...> - 2012-05-18 20:13:40
|
On 18 May 2012 21:57, Faheem Mitha <fa...@fa...> wrote: > which I missed in my first two readings of that section, so perhaps > you meant to write > >> (declare (optimize foo)) == (declare (optimize (foo 3))) Yes. :) > 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 See SB-EXT:SET-SBCL-SOURCE-LOCATION. > 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 Hard to tell, but I would strongly prefer not to add distro specific bits to the manual. General advice on the subject is a different matter. SET-SBCL-SOURCE-LOCATION is documented in the manual, but not mentioned in the chapter on debugger. > 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: We're always interested in patches. :) Documentation is very welcome. See HACKING file in the distribution for patch submission guidelines. > * The patch is just suggestions. Use or discard as you wish. Thank you. > * I was unable to compile the manual to test the patch. I get The manual build assumes you have a freshly built SBCL in the same tree. After running sh make.sh --fancy successfully, you get output which tells you how to build the manual. Ie. cd doc/manual && make make-doc.sh does the same thing pretty much, but is there for compatibility with old scripts from time of the dinosaurs. > * 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 think sooner or later we want to have a User Guide and a Reference Manual as separate entities. Current manual strikes an uneasy balance between the two. > * 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. --snip-- 2.4.1 Editor Integration Though SBCL can be used running “bare”, the recommended mode of development is with an editor connected to SBCL, supporting not only basic lisp editing (paren-matching, etc), but providing among other features an integrated debugger, interactive compilation, and automated documentation lookup. Currently SLIME1 (Superior Lisp Interaction Mode for Emacs) together with Emacs is recommended for use with SBCL, though other options exist as well. SLIME can be downloaded from http://www.common-lisp.net/project/slime/. --snap-- More could, and perhaps should be said, but I don't think it's a good idea to expand on Slime in depth in the SBCL manual. > * I don't understand the last section in that source level debugging > section, namely I'll let someone else field this. If no-one picks up the slack, remind me next week. Cheers, -- nikodemus (sorry about the short answers, in a bit of a rush) |
From: Rupert S. <rsw...@gm...> - 2012-05-18 22:30:19
|
Nikodemus Siivola <nik...@ra...> writes: >> 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 > > See SB-EXT:SET-SBCL-SOURCE-LOCATION. Specifically, the following lines are in my ~/.sbclrc: ;; Tell SBCL that it's sources are in debian-land. (sb-ext:set-sbcl-source-location (pathname "/usr/share/sbcl-source/")) Presumably it's the same for you... |
From: Nikodemus S. <nik...@ra...> - 2012-05-21 05:59:32
|
On 17 May 2012 14:11, Nikodemus Siivola <nik...@ra...> wrote: >> 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. This particular bug is now fixed on git master as of this morning, and will be in the next release -- but is not in 1.0.57 yet. Cheers, -- nikodemus |
From: Faheem M. <fa...@fa...> - 2012-05-21 06:48:30
|
On Mon, 21 May 2012, Nikodemus Siivola wrote: > On 17 May 2012 14:11, Nikodemus Siivola <nik...@ra...> wrote: >>> 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. > This particular bug is now fixed on git master as of this morning, and > will be in the next release -- but is not in 1.0.57 yet. Thanks Nikodemus, nice work. Since 1.0.57 has just been released, will this be in 1.0.58? Regards, Faheem |
From: Nikodemus S. <nik...@ra...> - 2012-05-21 20:18:43
|
On 21 May 2012 09:25, Faheem Mitha <fa...@fa...> wrote: > Since 1.0.57 has just been released, will this be in 1.0.58? Yes, -- Nikodemus |