public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Siva Chandra <sivachandra@google.com>
To: Doug Evans <xdje42@gmail.com>
Cc: gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Debug Methods in GDB Python
Date: Mon, 16 Dec 2013 22:43:00 -0000	[thread overview]
Message-ID: <CAGyQ6gynZSRmgZgjLdG=XH-GBPJLptWbVezyG27ZGrO=Ohp8xA@mail.gmail.com> (raw)
In-Reply-To: <CAP9bCMT0M9ZM+hiF9A0jKb125F+9a9b84+hp9mNkj7ek-a0T-w@mail.gmail.com>

On Mon, Dec 16, 2013 at 9:56 AM, Doug Evans <xdje42@gmail.com> wrote:
> Note that the grouping in the pretty-printer API is because one
> pretty-printer can pretty-print several objects, and the functionality
> is split into two steps: the lookup object returns a separate object
> which is then later used to do the printing, and the lookup can record
> in the returned pretty-printer-worker object whatever state it wants.
> In dm-v6 AFAICT lookup and functionality exist in the same object so
> that's not possible (e.g., the DebugMethod.match method returns
> True/False instead of, e.g., a debug-method-worker object).
>
> We could, I think(!), go with debug-methods as in v6, sans method
> groups, and later extend it if a more formal grouping is needed.
> I wonder, though, about the match method returning True/False vs the
> pretty-printer way of the lookup object returning an object that then
> does the printing.
> [In the debug method case the lookup method might want to return a
> list if the method is overloaded.]
> Unless there's a compelling reason to be different, I like
> "Consistency Is Good", so that's what I'm shooting for.
> [But if there is a compelling reason to be different, I'm not opposed
> to being different here.]

I do not have a compelling reason to be different here. I only have
couple of personal reasons for doing it that way:

1. <locus>.pretty_printers is actually not a list of pretty printers,
but a list of functions which return a pretty printer. I wanted
<locus>.debug_methods to be a list of actual debug methods.
2. Debug methods are queried for a match twice; Once for object type
and name match, next for argument type match. I wanted these to be
together instead of in separate places (as in, an object-method
matching function and a stateful worker object which does arg type
matching). But I agree that this makes the debug methods stateless
(almost! They do have a name and enabled flag.) for most cases.

I can modify and send a new patch if you feel debug methods should
parallel pretty printers here.

Thanks,
Siva Chandra

  reply	other threads:[~2013-12-16 22:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-22 22:41 Siva Chandra
2013-11-26  3:22 ` Siva Chandra
2013-12-06  6:31   ` Doug Evans
2013-12-06 23:24     ` Siva Chandra
2013-12-12  5:26       ` Doug Evans
2013-12-13 19:25         ` Siva Chandra
2013-12-16 17:56           ` Doug Evans
2013-12-16 22:43             ` Siva Chandra [this message]
2014-01-01 12:23             ` Siva Chandra
2014-01-03 18:52               ` Doug Evans
2014-01-08  0:49                 ` Siva Chandra
2014-01-09 19:01                   ` Doug Evans

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='CAGyQ6gynZSRmgZgjLdG=XH-GBPJLptWbVezyG27ZGrO=Ohp8xA@mail.gmail.com' \
    --to=sivachandra@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=xdje42@gmail.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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).