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

[Doug Evans <xdje42 at gmail dot 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.