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: Fri, 06 Dec 2013 23:24:00 -0000	[thread overview]
Message-ID: <CAGyQ6gyoZdRdXr9PY-ZaO=X1z7v8uj2i_PSzLi-ZMnr=J0LvJQ@mail.gmail.com> (raw)
In-Reply-To: <m3wqjize2h.fsf@sspiff.org>

On Thu, Dec 5, 2013 at 10:30 PM, Doug Evans <xdje42@gmail.com> wrote:
> Sorry for the delay.
> I've been wanting to find time to investigate some of the suggestions I made.
> e.g., instead of DEFAULT_DEBUG_METHOD_GROUP, etc.
> have the grouping work the same way it does for the libstdc++
> pretty-printers.  Have you thought about it?

I have removed DEFAULT_DEBUG_METHOD_GROUP from the code in my latest
patch. However, there is one reference to it in the brief (really
brief!) doc change I have in the patch [1]. About grouping in
libstdc++, is it not doing a grouping within what is facilitated by
the pretty printing API? For debug methods, I have added grouping wrt
obj file, progspace, and global. I have not implemented the notion of
sub debug methods (pretty printing API allows the user to bring in a
notion of sub printers). There are two reason for this. 1. It is a
convenience facility for the user which can be added easily if the
base API is agreed upon. 2. This is a personal reason, which you could
override: In the pretty printers world, each class would typically
have only one pretty printer implementation. For debug methods though,
each class could possibly have multiple debug methods. In which case,
having a notion of sub debug methods is probably more meaningful at
the class level. That is, it is more meaningful to have a "debug
methods of a class" grouping. And, this grouping can be easily
achieved by a debug method naming convention.

[1] I am really scared to write a full doc entry if the base API is
not agreed upon yet.

Thanks,
Siva Chandra

  reply	other threads:[~2013-12-06 23:24 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 [this message]
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
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='CAGyQ6gyoZdRdXr9PY-ZaO=X1z7v8uj2i_PSzLi-ZMnr=J0LvJQ@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).