[slime-devel] Patch: suppress duplicated frame variables (Allegro)
The Allegro debugger sometimes includes a local variable more than once as a variable in a frame. E.g. (defun f (x y) (declare (optimize debug)) (zut (bar x) y)) Allegro itself lists the frame variables as: Compiled lexical environment: 0(required): x: 1 1(required): y: 2 2(local): y: 2 This patch suppresses the duplicates as shown by Slime (which does not show the "required" / "local" labels). - Willem --- swank-allegro.lisp 10 Jun 2008 19:55:30 +0200 1.102 +++ swank-allegro.lisp 10 Jun 2008 22:16:09 +0200 @@ -173,11 +173,16 @@ (debugger:output-frame stream frame :moderate)) (defimplementation frame-locals (index) - (let ((frame (nth-frame index))) - (loop for i from 0 below (debugger:frame-number-vars frame) - collect (list :name (debugger:frame-var-name frame i) - :id 0 - :value (debugger:frame-var-value frame i))))) + (let* ((frame (nth-frame index)) + (locals (loop for i from 0 below (debugger:frame-number-vars frame) + collect (cons (debugger:frame-var-name frame i) + (debugger:frame-var-value frame i))))) + ;; Remove e.g. function arguments duplicated as local variables. + (setq locals (delete-duplicates locals :test (lambda (x y) + (and (eq (car x) (car y)) + (eq (cdr x) (cdr y)))))) + (loop for (name . val) in locals + collect (list :name name :id 0 :value val)))) (defimplementation frame-var-value (frame var) (let ((frame (nth-frame frame)))
Umm, did you test this against code like (defun f (x y) (let ((y x) (x y)) ...)) where there ARE both formal and local variables with the same name? -- Bradford W. Miller Cognitive/Computer Scientist/Engineer Raytheon, Inc. 1847 West Main Road Portsmouth, RI 02871-1087 (401) 842-3578 "Willem Broekema" <metawilm@gmail.com> Sent by: slime-devel-bounces@common-lisp.net 06/10/2008 04:28 PM To slime-devel@common-lisp.net cc Subject [slime-devel] Patch: suppress duplicated frame variables (Allegro) The Allegro debugger sometimes includes a local variable more than once as a variable in a frame. E.g. (defun f (x y) (declare (optimize debug)) (zut (bar x) y)) Allegro itself lists the frame variables as: Compiled lexical environment: 0(required): x: 1 1(required): y: 2 2(local): y: 2 This patch suppresses the duplicates as shown by Slime (which does not show the "required" / "local" labels). - Willem --- swank-allegro.lisp 10 Jun 2008 19:55:30 +0200 1.102 +++ swank-allegro.lisp 10 Jun 2008 22:16:09 +0200 @@ -173,11 +173,16 @@ (debugger:output-frame stream frame :moderate)) (defimplementation frame-locals (index) - (let ((frame (nth-frame index))) - (loop for i from 0 below (debugger:frame-number-vars frame) - collect (list :name (debugger:frame-var-name frame i) - :id 0 - :value (debugger:frame-var-value frame i))))) + (let* ((frame (nth-frame index)) + (locals (loop for i from 0 below (debugger:frame-number-vars frame) + collect (cons (debugger:frame-var-name frame i) + (debugger:frame-var-value frame i))))) + ;; Remove e.g. function arguments duplicated as local variables. + (setq locals (delete-duplicates locals :test (lambda (x y) + (and (eq (car x) (car y)) + (eq (cdr x) (cdr y)))))) + (loop for (name . val) in locals + collect (list :name name :id 0 :value val)))) (defimplementation frame-var-value (frame var) (let ((frame (nth-frame frame))) _______________________________________________ slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
On Tue, Jun 10, 2008 at 11:04 PM, Bradford W Miller <Bradford_W_Miller@raytheon.com> wrote:
Umm, did you test this against code like
(defun f (x y) (let ((y x) (x y)) ...))
where there ARE both formal and local variables with the same name?
It's not just about the names: to be considered a duplicate also the values must be eq. - Willem
On Tue, Jun 10, 2008 at 11:53 PM, Willem Broekema <metawilm@gmail.com> wrote:
On Tue, Jun 10, 2008 at 11:04 PM, Bradford W Miller
(defun f (x y) (let ((y x) (x y)) ...))
I should make clear that the frame variable duplication happens without the programmer introducing a new variable. The reason for this patch is that it is a bit annoying to see an extra line that has no extra information: (defun f (x y) (declare (optimize debug)) (zut (bar x) y)) Compiling and calling (f 1 2) results of course in: Error: attempt to call `bar' which is an undefined function. and zooming to the corresponding frame for of the f call gives: [1] cl-user(37): :loc Compiled lexical environment: 0(required): x: 1 1(required): y: 2 2(local): y: 2 which slime displays the frame as: 4: (f 1 2) Locals: x = 1 y = 2 y = 2 while it would make more sense to see: 4: (f 1 2) Locals: x = 1 y = 2 But there is the opposite case: a user introducing a variable binding that has identical name and value as a parameter (or an outer binding). This patch could remove a duplicated line that the user expected to see twice. However, it seems very unlikely to me that that poses any problem: the compiler could optimize away a local variable; there is no guaranteed order in which the variables are listed. Meanwhile the unintended duplicates are a more frequent annoyance. (Perhaps a better way to handle this, would be to include the "required" / "local" labels in the listing of the local variables?) - Willem
On 10-Jun-08, at 7:07 PM, Willem Broekema wrote:
But there is the opposite case: a user introducing a variable binding that has identical name and value as a parameter (or an outer binding). This patch could remove a duplicated line that the user expected to see twice.
As a regular user of Allegro + Slime, I'll join you in your labelling of this as a frequent annoyance. It can result in an unwieldy stack frame in some instances making navigation confusing. Furthermore, I have never come across the situation you describe, nor would I engineer it.
(Perhaps a better way to handle this, would be to include the "required" / "local" labels in the listing of the local variables?)
Perhaps, but I'm inclined to not show the duplicates at all. Technically speaking, I think they should be there to prevent serious confusion in the event the unlikely does happen, but I'd rather not clutter up the display with them. -- Geoff
participants (3)
-
Bradford W Miller -
Geoff Wozniak -
Willem Broekema