From: Phil Muldoon <pmuldoon@redhat.com>
To: Scott Goldman <scottjg@vmware.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH] Allow user-defined as a category for python gdb macros (resend)
Date: Tue, 14 Feb 2012 12:48:00 -0000 [thread overview]
Message-ID: <4F3A5820.3080905@redhat.com> (raw)
In-Reply-To: <03E840D17E263A48A5766AD576E0423A03D72B653F@exch-mbx-111.vmware.com>
On 02/14/2012 12:48 AM, Scott Goldman wrote:
> This patch allows python macros to coexist with legacy gdb macros in
> user-defined category. This way, it's possible to organize your macros
> such that `help user` shows both legacy and python macros. I also
> modified the documentation to use the `user` category in the example
> python macro. It seemed like a more reasonable default category than
> `obscure`.
Thanks.
> 2012-02-13 Scott J. Goldman <scottjg@vmware.com>
>
> * gdb.texinfo: put example python macro in COMMAND_USER category
> rather than COMMAND_OBSCURE.
Documentation entries have their own ChangeLog in doc/. Also, you
should put the node in the () where that change occurs. Also,
ChangeLogs require complete sentences with punctuation/capitalization;
here, and other entries.
> * py-cmd.c (cmdpy_init): treat class_user as a valid class in error check
> (gdbpy_initialize_commands): Add COMMAND_USER as a constant in
> gdb python api.
Paths have to be complete in ChangeLogs relative to where the
ChangeLog is located, so in this case: python/py-cmd.c
> * top.c (execute_command): only execute a user-defined command as a
> legacy macro if c->user_commands is set.
I think this patch is generally fine, but I think it needs a
test-case. It should be fairly simple to write one. Any new feature,
or regression fix generally requires a test-case to catch any future
regression. This is especially relevant in the Python areas of GDB
which are under constant development.
Cheers,
Phil
next prev parent reply other threads:[~2012-02-14 12:48 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-14 0:49 Scott Goldman
2012-02-14 3:12 ` Doug Evans
2012-02-14 7:57 ` Scott Goldman
2012-02-14 18:09 ` Eli Zaretskii
2012-02-14 20:19 ` Doug Evans
2012-02-14 12:48 ` Phil Muldoon [this message]
2012-02-15 9:27 ` Scott Goldman
2012-02-16 14:23 ` Phil Muldoon
2012-02-16 17:16 ` Eli Zaretskii
2012-02-23 3:03 ` Doug Evans
2012-02-23 3:32 ` Scott Goldman
2012-02-23 4:24 ` Eli Zaretskii
2012-02-23 5:13 ` Scott Goldman
2012-02-23 6:03 ` Doug Evans
2012-02-23 6:56 ` Scott Goldman
2012-02-23 8:21 ` Scott Goldman
2012-02-24 23:49 ` Scott Goldman
2012-02-28 1:36 ` Doug Evans
2012-02-28 4:18 ` Scott Goldman
2012-02-28 7:51 ` Doug Evans
2012-02-29 0:45 ` [doc RFA] " Doug Evans
2012-02-29 4:17 ` Eli Zaretskii
2012-03-01 19:31 ` Doug Evans
2012-03-01 20:26 ` Keith Seitz
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=4F3A5820.3080905@redhat.com \
--to=pmuldoon@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=scottjg@vmware.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