From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13080 invoked by alias); 2 Jun 2014 15:21:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 13066 invoked by uid 89); 2 Jun 2014 15:21:54 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yh0-f52.google.com Received: from mail-yh0-f52.google.com (HELO mail-yh0-f52.google.com) (209.85.213.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 02 Jun 2014 15:21:53 +0000 Received: by mail-yh0-f52.google.com with SMTP id z6so3895300yhz.39 for ; Mon, 02 Jun 2014 08:21:51 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.161.10 with SMTP id v10mr53586914yhk.27.1401722511434; Mon, 02 Jun 2014 08:21:51 -0700 (PDT) Received: by 10.170.150.70 with HTTP; Mon, 2 Jun 2014 08:21:51 -0700 (PDT) In-Reply-To: <87vbsj3e6v.fsf@gnu.org> References: <87lhtnd2q9.fsf@gnu.org> <87vbsj3e6v.fsf@gnu.org> Date: Mon, 02 Jun 2014 15:21:00 -0000 Message-ID: Subject: Re: [PATCH, doc RFA] Add guile gdb parameter support From: Doug Evans To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: Eli Zaretskii , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00022.txt.bz2 On Mon, Jun 2, 2014 at 1:31 AM, Ludovic Court=C3=A8s wrote: > > Also, after =E2=80=9CGuile=E2=80=9D, I would add something like: > > @footnote{Note that @value{GDBN} parameters must not be confused with > Guile=E2=80=99s parameter objects (@pxref{Parameters,,, guile, GNU Guile > Reference Manual}).} Ok. >> +The argument @var{set-func} is a function of one argument: @var{self} w= hich >> +is the @code{} 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 =E2=80=98set-func=E2=80=99 were passed both the para= meter and the > new value, such that it would be its responsibility to validate the > value and set it, but it seems that that=E2=80=99s not how =E2=80=98cmd_s= func_ftype=E2=80=99 > 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 =E2=80=9Cconversion=E2=80=9D fu= nction, rather > than a real =E2=80=98set=E2=80=99 function, just like SRFI-39 parameters = (info "(guile) > Parameters"). That would free users from the need to explicitly call > =E2=80=98set-parameter-value!=E2=80=99. > > 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: > > =E2=80=9CParameters=E2=80=9D Righto. >> +/* A helper which computes the list of enum values. >> + Throw's an exception if there's a problem with the values. > > =E2=80=9CThrows=E2=80=9D Fixed. > Maybe a more descriptive first sentence could be =E2=80=9CReturn an array= of > strings corresponding to the value enum values for ENUM_VALUES_SCM.=E2=80= =9D? > > [...] > >> +/* Subroutine of pascm_set_value, pascm_show_value to simplify them. > > =E2=80=98pascm_set_value=E2=80=99 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 (>=3D value 0) (<=3D value 10))" "" \ >> + " \"\"" "" \ >> + " (begin" "" \ >> + " (set-parameter-value! self (object-property self 'va= lue))" "" \ >> + " \"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 =E2=80=98set-func=E2=80= =99 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.