This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC][python] Add support for commands implemented in Python
- From: Daniel Jacobowitz <drow at false dot org>
- To: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- Cc: gdb-patches ml <gdb-patches at sourceware dot org>
- Date: Tue, 3 Feb 2009 19:31:53 -0500
- Subject: Re: [RFC][python] Add support for commands implemented in Python
- References: <1233580405.7000.13.camel@localhost.localdomain>
On Mon, Feb 02, 2009 at 11:13:25AM -0200, Thiago Jung Bauermann wrote:
> +@defmethod Command invoke argument from_tty
> +This method is called by @value{GDBN} when this command is invoked.
> +
> +@var{argument} is the argument to the command. The argument
> +ordinarily is a string, but may be @code{None}, meaning that there was
> +no argument.
Any opinion on making it always a string? The 'do I get NULL or an
empty string?' ambiguity shows up every time I write a new command in
C. If you prefer None, let's document what whitespace trimming does
or does not happen before it is converted from a string to None.
> +@defmethod Command complete text word
> +This method is called by @value{GDBN} when the user attempts @key{TAB}
> +completion on this command.
> +
> +The arguments @var{text} and @var{word} are both strings. @var{text}
> +holds the complete command line up to the cursor's location.
> +@var{word} holds the last word of the command line; this is computed
> +using a word-breaking heuristic.
> +
> +The @code{invoke} method can return several values:
Isn't this @code{complete} method? Same problem repeated below.
> +/* A gdb command. For the time being only ordinary commands (not
> + set/show commands) are allowed. */
> +struct cmdpy_object
> +{
> + PyObject_HEAD
> +
> + /* The corresponding gdb command object, or NULL if the command is
> + no longer installed. */
> + struct cmd_list_element *command;
> +
> + /* For a prefix command, this is the list of sub-commands. */
> + struct cmd_list_element *sub_list;
> +};
What's sub_list for? There's *command->prefixlist too. Overall, I'm
confused about why prefix commands are 'special' here. When core GDB
adds a command, it doesn't need any new code to handle it as a prefix;
just calls add_prefix_cmd. I'd expect to do the same here but fill in
a local FUN.
> + /* Note: alias and user seem to be special; pseudo appears to be
> + unused, and there is no reason to expose tui or xdb, I think. */
Yes, alias and user are special. User is where "define"'d commands
go; should there be a command to show all Python-defined
commands similar to "show user"?
The rest of the code looks fine.
--
Daniel Jacobowitz
CodeSourcery