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

[ludo at gnu dot org (Ludovic CourtÃs)]

Doug Evans <xdje42@gmail.com> skribis:

> On Mon, Jun 2, 2014 at 1:31 AM, Ludovic CourtÃs <ludo@gnu.org> wrote:

[...]

>>> +The argument @var{set-func} is a function of one argument: @var{self} which

I realized that #:set-proc (or even just #:set) would be more idiomatic.

>>> +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.

Yeah, understood.

>> 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.

Exactly.

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

Then it sounds like keeping the API you propose is the right strategy,
so letâs go for it.

Thanks,
Ludoâ.