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?
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
-
Bradford W Miller -
Geoff Wozniak -
Willem Broekema