From: Tobias C. R. <tc...@fr...> - 2009-09-29 22:07:16
|
Attila Lendvai <att...@gm...> writes: >> What is the reason that >> >> (SB-PCL::FAST-METHOD FOO:BAR (FUNCTION)) >> >> is printed as >> >> (FOO:BAR (FUNCTION)) >> >> and not simply >> >> FOO:BAR ? >> >> What useful information does the CDDR of a FAST-METHOD name ever >> provide? > > > well, one can argue: > 1) that form points out that it's a method not a function > 2) shows which specific method is used there > > although 2) is a bit redundant with 'v' in sldb (which doesn't work > after C-c C-c'ing anything with a custom reader, but that's a > different issue...) > > so, after quickly trying out your suggestion, i've ended up with the > modified patch that does what you proposed on (<= *verbosity* 1) and > the previous behavior when it's 2. this way both behavior is available > with a more sensible default. I totally missed that FUNCTION in the abovely cited (SB-PCL::FAST-METHOD FOO:BAR (FUNCTION)) represents the specializer list. That's very valuable information, of course, and I retract my ill-conceived wish of getting rid of that. Sorry, -T. |
From: Attila L. <att...@gm...> - 2009-10-09 12:44:26
|
> represents the specializer list. That's very valuable information, of > course, and I retract my ill-conceived wish of getting rid of that. even if you add a shortcut to sldb to switch verbosity? ;) but either way, now the cleaning functionality is there. it's just a question of adjusting what should be cleared on which verbosity level... fyi, our changes (including this one) are available in the hu.dwim branch at: http://dwim.hu/gitweb/gitweb.cgi?p=sbcl;a=summary note: i'm regularly rebasing the patches there, if you pull that branch then reset your local repo after a rebase. -- attila |
From: Attila L. <att...@gm...> - 2009-10-31 01:11:50
|
fyi, i've amended the patch (two calls to backtrace from :sb-show were not changed). available at: http://dwim.hu/gitweb/gitweb.cgi?p=sbcl;a=summary -- attila |
From: Nikodemus S. <nik...@ra...> - 2010-09-02 10:33:28
|
So, I decided to try to tackle this. As I've said before, I don't want to push the responsibility for frame cleaning to Slime -- setting options yes, but actually doing the cleaning should be done by SBCL. Without getting into implementation details right now, here's my proposal for a brave new SB-DEBUG:BACKTRACE interface. I think FRAME-CALL-AS-LIST and PRINT-FRAME-CALL should have similar toggles. (defun backtrace (&key (stream *debug-io*) (count *backtrace-frame-count*) (skip 0) (print-thread t) (print-frame-source nil) (method-frame-style *method-frame-style*) (show-entry-point-details *show-entry-point-details*)) "Print a listing of the call stack to STREAM, going down from the current frame. In the debugger, the current frame is indicated by the prompt. COUNT is the number of frames to print (defaulting to *BACKTRACE-FRAME-COUNT*, initially MOST-POSITIVE-FIXNUM), and SKIP is the number of frames to skip before starting to print (defaulting to zero). If PRINT-THREAD is true (the default), the backtrace is preceded by printing the current thread object. If PRINT-FRAME-SOURCE is true (the default is false), each frame is followed by printing the source responsible for it, when available. METHOD-FRAME-STYLE (defaulting to *METHOD-FRAME-STYLE*, initially :NORMAL), determines how frames corresponding SBCL generated method functions are printed. Possible values are :MINIMAL, :NORMAL, and :FULL. :MINIMAL prints them as (<NAME> ...args...) :NORMAL prints them as ((<NAME> [<QUALIFIER>] (<SPECIALIZER>*)) ...args...) :FULL prints them using the exact method function name: ((SB-PCL:FAST-METHOD <NAME> [<QUALIFIER>] (<SPECIALIZER>*)) ...args...) or ((SB-PCL:SLOW-METHOD <NAME> [<QUALIFIER>] (<SPECIALIZER>*)) ...args...) If SHOW-ENTRY-POINT-DETAILS is true (defaulting to *SHOW-ENTRY-POINT-DETAILS*, initially false), each frame is printed with entry point details. This is mostly of interest to SBCL developers, but in case you are seeing backtraces such as 2: (FOO 42) 3: (FOO 42) turning on entry point details can assure you that FOO is not actually being called twice, but you are eg. seeing both the external and normal entry points in the backtrace. " As a point of order, let's please not focus on the exact names of the arguments (should it be :PRINT-ENTRY-POINT-DETAILS instead, etc.), but rather on the meaning of the toggles themselves and their defaults. Names can be hashed over after we have something resembling a consensus... I'm particularly interested in hearing from the two extremes here -- those wanting to have the full method function names, and those preferring the minimal version. Is the interface bad? What should change? Is it good, but defaults are wrong? Is it perfect? Cheers, -- Nikodemus |
From: Tobias C R. <tc...@fr...> - 2010-09-03 21:38:00
|
In article <AAN...@ma...>, Nikodemus Siivola <nik...@ra...> wrote: > So, I decided to try to tackle this. As I've said before, I don't want > to push the responsibility for frame cleaning to Slime -- setting > options yes, but actually doing the cleaning should be done by SBCL. > > Without getting into implementation details right now, here's my > proposal for a brave new SB-DEBUG:BACKTRACE interface. I think > FRAME-CALL-AS-LIST and PRINT-FRAME-CALL should have similar toggles. > > (defun backtrace (&key > (stream *debug-io*) > (count *backtrace-frame-count*) > (skip 0) > (print-thread t) > (print-frame-source nil) > (method-frame-style *method-frame-style*) > (show-entry-point-details *show-entry-point-details*)) > "Print a listing of the call stack to STREAM, going down from the current > frame. In the debugger, the current frame is indicated by the prompt. > > COUNT is the number of frames to print (defaulting to > *BACKTRACE-FRAME-COUNT*, > initially MOST-POSITIVE-FIXNUM), and SKIP is the number of frames to skip > before starting to print (defaulting to zero). > > If PRINT-THREAD is true (the default), the backtrace is preceded by printing > the current thread object. > > If PRINT-FRAME-SOURCE is true (the default is false), each frame is followed > by printing the source responsible for it, when available. > > METHOD-FRAME-STYLE (defaulting to *METHOD-FRAME-STYLE*, initially :NORMAL), > determines how frames corresponding SBCL generated method functions are > printed. > Possible values are :MINIMAL, :NORMAL, and :FULL. > > :MINIMAL prints them as > > (<NAME> ...args...) > > :NORMAL prints them as > > ((<NAME> [<QUALIFIER>] (<SPECIALIZER>*)) ...args...) > > :FULL prints them using the exact method function name: > > ((SB-PCL:FAST-METHOD <NAME> [<QUALIFIER>] (<SPECIALIZER>*)) ...args...) > > or > > ((SB-PCL:SLOW-METHOD <NAME> [<QUALIFIER>] (<SPECIALIZER>*)) ...args...) > > If SHOW-ENTRY-POINT-DETAILS is true (defaulting to > *SHOW-ENTRY-POINT-DETAILS*, > initially false), each frame is printed with entry point details. This is > mostly of interest to SBCL developers, but in case you are seeing > backtraces such > as > > 2: (FOO 42) > 3: (FOO 42) > > turning on entry point details can assure you that FOO is not actually being > called twice, but you are eg. seeing both the external and normal entry > points > in the backtrace. > " Is there technical difficulty which would prevent merging of these in case SHOW-ENTRY-POINT-DETAILS is NIL? I would like to see a keyword parameter that make it also print local variables of each frame. -T. |
From: Attila L. <att...@gm...> - 2012-05-21 15:58:16
|
Nikodemus, any news on this? i used to keep on rebasing my changes but it starts to feel as wasted time... the most recent version, modulo the last conflicts, is available here: http://dwim.hu/gitweb/gitweb.cgi?p=sbcl;a=summary -- attila Notice the erosion of your (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06 |
From: Nikodemus S. <nik...@ra...> - 2012-05-21 18:49:48
|
On 21 May 2012 18:57, Attila Lendvai <att...@gm...> wrote: > Nikodemus, > > any news on this? Still in my "queue", which looks more like a spread every day... > the most recent version, modulo the last conflicts, is available here: > > http://dwim.hu/gitweb/gitweb.cgi?p=sbcl;a=summary What's the pull-url? I'll try to get at least some of these in this month. Cheers, -- nikodemus |
From: Attila L. <att...@gm...> - 2012-05-29 17:50:17
|
> What's the pull-url? > > I'll try to get at least some of these in this month. sorry, i got used to darcsweb which is advertising that... git://dwim.hu/sbcl -- attila Notice the erosion of your (digital) freedom, and do something about it! PGP: 2FA1 A9DC 9C1E BA25 A59C 963F 5D5F 45C7 DFCD 0A39 OTR XMPP: 8647EEAC EA30FEEF E1B55146 573E52EE 21B1FF06 |
From: Nikodemus S. <nik...@ra...> - 2012-06-12 06:13:59
|
On 29 May 2012 20:49, Attila Lendvai <att...@gm...> wrote: >> What's the pull-url? >> >> I'll try to get at least some of these in this month. > > sorry, i got used to darcsweb which is advertising that... > > git://dwim.hu/sbcl Progress. I've merged one of my long-pending backtrace cleanups to make way for this... Hopefully I can manage to move this a couple of steps further over the next few days. Cheers, -- nikodemus |