Re: [PATCH, doc RFA] Add guile gdb parameter support

[Doug Evans <xdje42@gmail.com>]

On Mon, Jun 2, 2014 at 1:31 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>
> Also, after “Guile”, I would add something like:
>
>   @footnote{Note that @value{GDBN} parameters must not be confused with
>   Guile’s parameter objects (@pxref{Parameters,,, guile, GNU Guile
>   Reference Manual}).}

Ok.

>> +The argument @var{set-func} is a function of one argument: @var{self} which
>> +is the @code{<gdb:parameter>} object representing the parameter.
>> +@value{GDBN} will call this function when a @var{parameter}'s value has
>> +been changed via the @code{set} API (for example, @kbd{set foo off}).
>
> It would be nicer if ‘set-func’ were passed both the parameter and the
> new value, such that it would be its responsibility to validate the
> value and set it, but it seems that that’s not how ‘cmd_sfunc_ftype’
> callbacks work.

I know.
It's not my first choice either, but it's not clear to me that taking
on redesigning this part of gdb internals would be a useful
expenditure of time.

> Alternately, parameters could have just a “conversion” function, rather
> than a real ‘set’ function, just like SRFI-39 parameters (info "(guile)
> Parameters").  That would free users from the need to explicitly call
> ‘set-parameter-value!’.
>
> Thoughts?

I'm guessing by needing to call set-parameter-value! you mean in the
set-func to undo a bad setting.

gdb parameters are the way they are, and python parameters must
indefinitely support the broken API.

>> +/* A GDB parameter.
>> +
>> +   Note: Parameteres are added to gdb using a two step process:
>
> “Parameters”

Righto.

>> +/* A helper which computes the list of enum values.
>> +   Throw's an exception if there's a problem with the values.
>
> “Throws”

Fixed.

> Maybe a more descriptive first sentence could be “Return an array of
> strings corresponding to the value enum values for ENUM_VALUES_SCM.”?
>
> [...]
>
>> +/* Subroutine of pascm_set_value, pascm_show_value to simplify them.
>
> ‘pascm_set_value’ now has a different name.

Fixed.

>> +gdb_test_multiline "restricted gdb parameter" \
>> +    "guile" "" \
>> +    "(register-parameter! (make-parameter \"test-restricted-param\"" "" \
>> +    "   #:command-class COMMAND_DATA" "" \
>> +    "   #:parameter-type PARAM_ZINTEGER" "" \
>> +    "   #:set-func (lambda (self)" "" \
>> +    "      (let ((value (parameter-value self)))" "" \
>> +    "        (if (and (>= value 0) (<= value 10))" "" \
>> +    "            \"\"" "" \
>> +    "            (begin" "" \
>> +    "              (set-parameter-value! self (object-property self 'value))" "" \
>> +    "              \"Error: Range of parameter is 0-10.\"))))" "" \
>> +    "   #:show-func (lambda (self value)" "" \
>> +    "      (format #f \"The value of the restricted parameter is ~a.\" value))" "" \
>> +    "   #:initial-value (lambda (self)" "" \
>> +    "      (set-object-property! self 'value 2)" "" \
>> +    "      2)))" "" \
>> +    "end"
>
> This example is what makes me think that current ‘set-func’ callbacks
> are inconvenient.

Yep.
We could add a new interface to gdb for calling a function before a
parameter is set.  Not sure how that would fly though.