all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Gemini Lasswell <gazally@runbox.com>
Cc: 22294@debbugs.gnu.org
Subject: bug#22294: Patch
Date: Sun, 7 May 2017 05:34:23 +0300	[thread overview]
Message-ID: <793941ae-4e88-80ef-3ac7-7bd5019b97f7@yandex.ru> (raw)
In-Reply-To: <871ssevk4e.fsf_-_@runbox.com>

Hi Gemini,

Thank you very much for tackling this. I've tried the patch out, and it 
seems to work well.

We can install it if nobody else has any strong objections.

On 27.04.2017 2:12, Gemini Lasswell wrote:
> Some limitations:
> 
> - All the methods get debug instrumentation and temporary breakpoints,
> not just the one that's about to be executed. But given the potential
> complexity of method dispatch, it seems that fixing that would require
> some deep intertwining of Edebug and cl-generic.

This sounds totally fine to me, at this stage. I _think_ it shouldn't be 
too hard to change this, given that all the arguments are known by the 
time edebug-step-in, but it's not a major issue.

It might change the return value of edebug-instrument-function back 
again, though.

> - If you use edebug-step-in twice on the same generic function it will
> reinstrument the methods, as opposed to using edebug-step-in twice on a
> regular function where Edebug can figure out that the function is
> already instrumented.

This is a bit wasteful. But more importantly, it causes us to collect 
the list of anonymous symbols in a dynamic variable, instead of a more 
explicit data flow. Which is not great.

> Fixing that would require some way to include
> dynamic elements in the :name construct of an Edebug spec so that each
> method could get a unique deterministic symbol as opposed to an
> anonymous generated symbol.

Ideally, we'd do this, I think. If :name spec is allowed to be a 
function, it could construct the unique symbol like (intern (format 
"%s-%s" name arguments)). Then edebug-instrument-function could also 
call this logic itself, instead of relying on the symbol being recorded 
in edebug--step-in-symbols.

(On the other hand, the proposed approach probably fixes stepping into 
any edebug-able form, not just generic methods).

> Or it could be fixed by the "future"
> described in edebug-form-data's docstring.

We'd still need to construct the unique symbol this way, at least 
somewhere, I think.

A couple notes on the patch itself:

> -  ;; Func should be a function symbol.
> -  ;; Return the function symbol, or nil if not instrumented.
> -  (let ((func-marker (get func 'edebug)))
> +  "Instrument the function or generic method FUNC.
> +Return the list of function symbols which were instrumented.
> +This may be simply (FUNC) for a normal function, or a list of
> +generated symbols for methods.  If a function or method to
> +instrument cannot be found, signal an error."
> +  (let ((func-marker (get func 'edebug))

The signature change looked worrying, but all the callers seem fine 
(there are not many of them).

> +     ((get func 'cl--generic)
> +      (let ((method-defs (method-files func)))
> +        (unless method-defs
> +          (error "Could not find any me
> 
> thod definitions for %s" func))
> +        (while method-defs
> +          (let* ((file (caar method-defs))
> +                 (spec (cdar method-defs))

It would be better to use `dolist' here, or even `pcase-dolist', see an 
example in pcase-dolist.

>   
> +
> +(require 'cl-generic)

This adds a second empty line in a row.





  reply	other threads:[~2017-05-07  2:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-02 18:53 bug#22294: 25.0.50; edebug should support jumping into generic methods Dmitry Gutov
2017-03-03  2:52 ` Gemini Lasswell
2017-04-11 10:57   ` Dmitry Gutov
2017-04-26 23:12     ` bug#22294: Patch (was: bug#22294: 25.0.50; edebug should support jumping into generic methods) Gemini Lasswell
2017-05-07  2:34       ` Dmitry Gutov [this message]
2017-05-07 20:28         ` bug#22294: Patch Gemini Lasswell
2017-05-08  2:19           ` Dmitry Gutov
2017-05-10  5:07             ` bug#22294: Generating Edebug names for generic methods (was: bug#22294: Patch) Gemini Lasswell
2017-05-10 14:18               ` bug#22294: Generating Edebug names for generic methods Dmitry Gutov
2017-05-13 20:58                 ` Gemini Lasswell
2017-05-14  1:17                   ` Dmitry Gutov
2017-05-14 20:33                     ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=793941ae-4e88-80ef-3ac7-7bd5019b97f7@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=22294@debbugs.gnu.org \
    --cc=gazally@runbox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.