This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Implement set/show callback functions in gdb.Parameter
- From: Eli Zaretskii <eliz at gnu dot org>
- To: pmuldoon at redhat dot com
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 15 Feb 2011 20:24:35 +0200
- Subject: Re: [patch] Implement set/show callback functions in gdb.Parameter
- References: <m3bp2dw9io.fsf@redhat.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> From: Phil Muldoon <pmuldoon@redhat.com>
> Date: Tue, 15 Feb 2011 16:24:47 +0000
>
>
> This patch allows the user to implement two methods in the gdb.Parameter
> object.
Thanks.
> +There are two methods that should be implemented in any Parameter
> +class. These are:
"Parameter" should be in @code, since it is a Python symbol.
> +@defop Operation {parameter} get_set_string (self)
The @def... commands in Texinfo don't use parentheses to enclose
argument. Just use
@defop Operation {parameter} get_set_string self
> +@value{GDBN} will call this method when a parameter has been
> +invoked via the set API (for example, set foo off). The @code{value}
Are talking here about a Python API or about the CLI command "set"?
"set" should be in @code in both cases. "set foo off" should be in
@kbd if it's about a CLI command; if it is about a Python API, I'm not
sure I understand what it means.
Similar issues with get_show_string.
> + The argument
> +@code{svalue} contains a string representing what @value{GDBN} has
> +stored for this parameter.
Suggest to rephrase:
The argument @code{svalue} receives the string representation of the
current value.
> This method must return a string.
You mean, in `svalue'? If so, "return" is not really appropriate, is
it?
If you mean something else, then I think we should elaborate about
that.
Thanks.