General discussion of Steel Bank Common Lisp

Faheem Mitha | 15 May 2012 01:33

traceback line numbers


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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Nikodemus Siivola | 15 May 2012 07:25

Re: traceback line numbers

On 15 May 2012 02:33, Faheem Mitha <faheem <at> faheem.info> 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

(Continue reading)

Faheem Mitha | 16 May 2012 06:37

Re: traceback line numbers


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 <faheem <at> faheem.info> 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

(Continue reading)

Nikodemus Siivola | 17 May 2012 13:11

Re: traceback line numbers

On 16 May 2012 07:37, Faheem Mitha <faheem <at> faheem.info> 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
>

(Continue reading)

Faheem Mitha | 18 May 2012 20:57

Re: traceback line numbers


Hi Nikodemus,

On Thu, 17 May 2012, Nikodemus Siivola wrote:

> On 16 May 2012 07:37, Faheem Mitha <faheem <at> faheem.info> 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)))
?

(Continue reading)

Nikodemus Siivola | 18 May 2012 22:13

Re: traceback line numbers

On 18 May 2012 21:57, Faheem Mitha <faheem <at> faheem.info> 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.

(Continue reading)

Rupert Swarbrick | 19 May 2012 00:24

Picon

Re: traceback line numbers

Nikodemus Siivola <nikodemus <at> random-state.net> 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...

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

_______________________________________________
Sbcl-help mailing list
Sbcl-help <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

Nikodemus Siivola | 21 May 2012 07:59

Re: traceback line numbers

On 17 May 2012 14:11, Nikodemus Siivola <nikodemus <at> random-state.net> 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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Faheem Mitha | 21 May 2012 08:25

Re: traceback line numbers


On Mon, 21 May 2012, Nikodemus Siivola wrote:

> On 17 May 2012 14:11, Nikodemus Siivola <nikodemus <at> random-state.net> 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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

Nikodemus Siivola | 21 May 2012 22:18

Re: traceback line numbers

On 21 May 2012 09:25, Faheem Mitha <faheem <at> faheem.info> wrote:

> Since 1.0.57 has just been released, will this be in 1.0.58?

Yes,

 -- Nikodemus

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Sbcl-help mailing list
Sbcl-help <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

Return

Return to gmane.lisp.steel-bank.general.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane