GNU bug report logs - #24753
26.0.50; Error using Edebug on code that uses cl-defmethod

Previous Next

Full log

Message #22 received at 24753 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Gemini Lasswell <gazally <at> runbox.com>
Cc: 24753 <at> debbugs.gnu.org
Subject: Re: bug#24753: 26.0.50; Error using Edebug on code that uses
 cl-defmethod
Date: Tue, 2 May 2017 04:11:25 +0300

Hey Gemini,

I've read the edebug manual, read the patch some more, and it looks good.

Please go ahead and install it, since nobody else seems to have any 
objections either. Thank you.

On 27.04.2017 0:39, Gemini Lasswell wrote:

> I'm not totally clear on what that example is doing either. I just
> grabbed it from cl-generic-tests.el because it was short and reproduced
> the bug. But I think the idea is to let you define a method so that
> (setf (foo x) y) does something analogous to (setf (cdr x) y).

Ah, cool.

> Your scenario is another way to reproduce the bug. When Edebug
> instruments something it attaches a cache of markers to the symbol. So
> when two methods with the same name are instrumented, the cache of
> markers pointing into the first method's source is replaced with a cache
> of markers for the second method. And then if you debug into the first
> method Edebug sees markers pointing at the wrong method and gets
> confused. My patch works by making Edebug generate new symbols for each
> method.

I wish there was a better way to generate that symbol, taking into 
account the arguments list. But probably not without some changes to edebug.

When the `name' specification element is absent, do you know if can 
affect anything else, aside from a few markers being 
non-garbage-collectable?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.