From stassats at gmail.com  Tue Apr  2 14:41:13 2013
From: stassats at gmail.com (Stas Boukarev)
Date: Tue, 02 Apr 2013 18:41:13 +0400
Subject: [slime-devel] [PATCH] hiding swank frames from debugger
	backtrace on Allegro
In-Reply-To: <5141B4FC.40207@gmail.com> (=?utf-8?Q?=22Lu=C3=ADs?=
	Oliveira"'s message of "Thu, 14 Mar 2013 11:31:08 +0000")
References: <5141B4FC.40207@gmail.com>
Message-ID: <87y5d10zcm.fsf@gmail.com>

Lu?s Oliveira <luismbo at gmail.com> writes:

> Hello,
>
> As you well know, SLIME's debugger, when invoked, will inevitably add
> some frames to the current stack, which SWANK attempts to hide. On
> Allegro, when signalling an error from the REPL, those extra frames look
> something like this:
>
>   0: ((FLET (:TOP-LEVEL-FORM "swank-allegro.lisp" 4123) SWANK-
>        BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT) #<Function (:INTERNAL
>        SWANK::DEBUG-IN-EMACS 0)>)
>   1: (SWANK-BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT #<Function
>        (:INTERNAL SWANK::DEBUG-IN-EMACS 0)>)
>   2: (SWANK::DEBUG-IN-EMACS #<SIMPLE-ERROR @ #x218114d2>)
>   3: (SWANK:INVOKE-SLIME-DEBUGGER #<SIMPLE-ERROR @ #x218114d2>)
>   4: ((:INTERNAL SWANK:SWANK-DEBUGGER-HOOK 1))
>   5: ((:INTERNAL (:TOP-LEVEL-FORM "swank-backend.lisp" 32198) 0)
>        #<Function SWANK-DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK:SWANK-
>        DEBUGGER-HOOK 1) @ #x218115f2>)
>   6: (SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK #<Function SWANK-
>        DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK:SWANK-DEBUGGER-HOOK 1)
>        @ #x218115f2>)
>   7: (SWANK:SWANK-DEBUGGER-HOOK #<SIMPLE-ERROR @ #x218114d2> #<Function
>        SWANK-DEBUGGER-HOOK>)
>   8: (ERROR "foo")
>
>
> In this case, FIND-TOPLEVEL in swank-allegro.lisp successfully figures
> out that the first 8 frames are to be hidden.
>
> However, if the error comes from some other thread -- this can be
> reproduced via (mp:process-run-function nil (lambda () (error "foo")))
> for example -- there will a couple of extra frames:
>
>   0: ((FLET (:TOP-LEVEL-FORM "swank-allegro.lisp" 4123) SWANK-
>        BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT) #<Function (:INTERNAL
>        SWANK::DEBUG-IN-EMACS 0)>)
>   1: (SWANK-BACKEND:CALL-WITH-DEBUGGING-ENVIRONMENT #<Function
>        (:INTERNAL SWANK::DEBUG-IN-EMACS 0)>)
>   2: (SWANK::DEBUG-IN-EMACS #<SIMPLE-ERROR @ #x21552f92>)
>   3: ((:INTERNAL SWANK:INVOKE-SLIME-DEBUGGER 0))
>   4: ((:INTERNAL (:TOP-LEVEL-FORM "swank-backend.lisp" 32198) 0)
>        #<Function SWANK-DEBUGGER-HOOK> #<Closure (:INTERNAL
>        SWANK:INVOKE-SLIME-DEBUGGER 0) @ #x215530e2>)
>   5: (SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK #<Function SWANK-
>        DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK:INVOKE-SLIME-DEBUGGER
>        0) @ #x215530e2>)
>   6: ((:INTERNAL SWANK:INVOKE-SLIME-DEBUGGER 3))
>   7: (SWANK::CALL-WITH-BINDINGS ..)
>   8: (SWANK:INVOKE-SLIME-DEBUGGER #<SIMPLE-ERROR @ #x21552f92>)
>   9: ((:INTERNAL SWANK:SWANK-DEBUGGER-HOOK 1))
>  10: ((:INTERNAL (:TOP-LEVEL-FORM "swank-backend.lisp" 32198) 0)
>        #<Function SWANK-DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK:SWANK-
>        DEBUGGER-HOOK 1) @ #x2155309a>)
>  11: (SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK #<Function SWANK-
>        DEBUGGER-HOOK> #<Closure (:INTERNAL SWANK:SWANK-DEBUGGER-HOOK 1)
>        @ #x2155309a>)
>  12: (SWANK:SWANK-DEBUGGER-HOOK #<SIMPLE-ERROR @ #x21552f92> #<Function
>        SWANK-DEBUGGER-HOOK>)
>  13: (ERROR "foo")
>
>
> Because FIND-TOPLEVEL currently only looks at the first eleven frames,
> it will fail to find frame #12 in the stacktrace above. Consequently,
> the extra debugger frames won't be hidden.
>
> The attached patch fixes this by looking a bit further (30 frames)
> taking care not to fail on small stacks.
>
> I considered the idea of not hard-coding an arbitrary limit, but in the
> end went with the more conservative fix since walking through a very
> large stack takes a while. (However, it seems unlikely that
> FIND-TOPFRAME would ever be called in a context where
> SWANK-DEBUGGER-HOOK is not on the stack, modulo protocol changes that
> would break the whole scheme anyway.)
Applied, thanks.

-- 
With best regards, Stas.



From luismbo at gmail.com  Tue Apr  2 21:17:46 2013
From: luismbo at gmail.com (=?ISO-8859-1?Q?Lu=EDs_Oliveira?=)
Date: Tue, 2 Apr 2013 22:17:46 +0100
Subject: [slime-devel] [PATCH] hiding swank frames from debugger
 backtrace on Allegro
In-Reply-To: <CAFKQJ8k0tN1BQzwJmxQpjtQ-JQqFngHU-Nf2HFwSPfYUVvjFVA@mail.gmail.com>
References: <5141B4FC.40207@gmail.com>
	<CAFKQJ8k0tN1BQzwJmxQpjtQ-JQqFngHU-Nf2HFwSPfYUVvjFVA@mail.gmail.com>
Message-ID: <CAB-HnLTAEFWSoar5=xKXPGs1NiWBqLUOrYjCy3Ygh54VJPEUWQ@mail.gmail.com>

On Tue, Apr 2, 2013 at 10:10 PM, Alan Ruttenberg
<alanruttenberg at gmail.com> wrote:
> I think this should be factored out into an implementation specific method.
> I have messed similarly with ABCL to achieve a similar thing. My guess is
> that each implementation might have different things it needs to do.

The other implementations I looked at definitely do different things.
What would, say, the ABCL and ACL backends have in common? Not sure if
it's easy to share code amongst SWANK backends.

Cheers,

--
Lu?s Oliveira
http://r42.eu/~luis/



From heller at common-lisp.net  Wed Apr  3 09:44:01 2013
From: heller at common-lisp.net (Helmut Eller)
Date: Wed, 03 Apr 2013 02:44:01 -0700
Subject: [slime-devel] Daily ChangeLog diff
Message-ID: <E1UNKEb-0004k2-I0@common-lisp.net>

A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 769 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/slime-devel/attachments/20130403/8cc7d73d/attachment.obj>

From 9B7C48D at artepersianas.com.br  Thu Apr 11 13:56:43 2013
From: 9B7C48D at artepersianas.com.br (Meds USA)
Date: Thu, 11 Apr 2013 15:56:43 +0200
Subject: Save money. Official suppliers
Message-ID: <20130411155643.D748AE0FE1D029043DA85.2E01350@POSTE10>

An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/slime-devel/attachments/20130411/24a45eb6/attachment.html>

From fsiacibdmqac at microsoft.com  Mon Apr 15 18:12:17 2013
From: fsiacibdmqac at microsoft.com (=?GB2312?B?t7bv9PD5?=)
Date: Tue, 16 Apr 2013 02:12:17 +0800
Subject: =?GB2312?B?ob677s+4sPu8yMTcv7nLpcDP09bE3NbOsqGhvy0twLTX1LXCufrJ+s7v0r3Rp9bQ?=
	=?GB2312?B?0MS1xKGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaE=?=
	=?GB2312?B?ICAgICAgICAgICAgICAgICAgICAgICAgIA==?=
	=?GB2312?B?ICAgICAgICChoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoSA=?=
	=?GB2312?B?NTkyNDE=?=
Message-ID: <20130415181218.A3B4F4DB64E@wajuwa.com>

An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/slime-devel/attachments/20130416/382b45f6/attachment.html>

From 1D5FD89 at adamasrealty.com  Thu Apr 11 16:01:13 2013
From: 1D5FD89 at adamasrealty.com (myDating Service)
Date: Thu, 11 Apr 2013 18:01:13 +0200
Subject: Login and get off hot locals
Message-ID: <20130411180113.BCEDE8C411A12C101613.6E57482@96.226.78.188.dynamic.jazztel.es>

An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/slime-devel/attachments/20130411/bbe9f068/attachment.html>