From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10565 invoked by alias); 19 Jan 2014 21:37:19 -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 10554 invoked by uid 89); 19 Jan 2014 21:37:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 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-wi0-f178.google.com Received: from mail-wi0-f178.google.com (HELO mail-wi0-f178.google.com) (209.85.212.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 19 Jan 2014 21:37:17 +0000 Received: by mail-wi0-f178.google.com with SMTP id cc10so2529928wib.5 for ; Sun, 19 Jan 2014 13:37:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.181.13.40 with SMTP id ev8mr6442822wid.16.1390167434191; Sun, 19 Jan 2014 13:37:14 -0800 (PST) Received: by 10.194.17.104 with HTTP; Sun, 19 Jan 2014 13:37:14 -0800 (PST) In-Reply-To: <87ppnom3l8.fsf@gnu.org> References: <52b9da59.64ab440a.0b0b.7e1c@mx.google.com> <83ha9w68av.fsf@gnu.org> <87sit4kb1t.fsf@gnu.org> <8761phqaws.fsf@gnu.org> <87ppnom3l8.fsf@gnu.org> Date: Sun, 19 Jan 2014 21:37:00 -0000 Message-ID: Subject: Re: [PATCH v1 02/36] Guile extension language: doc additions From: Doug Evans To: =?ISO-8859-1?Q?Ludovic_Court=E8s?= Cc: Eli Zaretskii , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00726.txt.bz2 On Sun, Jan 19, 2014 at 6:46 AM, Ludovic Court=E8s wrote: > Doug Evans skribis: > >> On Sat, Jan 18, 2014 at 12:42 PM, Ludovic Court=E8s wrote: >>> Doug Evans skribis: >>> >>>> On Fri, Jan 3, 2014 at 1:30 PM, Ludovic Court=E8s wrote: >>>>>>> +The optional @var{errors} argument is either @code{"strict"} >>>>>>> +or @code{"replace"}. A value of @code{"strict"} corresponds to >>>>>>> +Guile's @code{SCM_FAILED_CONVERSION_ERROR} and a value of @code{"r= eplace"} >>>>>>> +corresponds to Guile's @code{SCM_FAILED_CONVERSION_QUESTION_MARK}. >>>>>> >>>>>> Suggest a cross-reference to Guile documentation here. >>>>> >>>>> Agreed. Also, Guile talks of =93conversion strategy=94 and =93conver= sion >>>>> error handler=94, with values =91error=92, =91substitute=92, and =91e= scape=92 (at the >>>>> Scheme level), and I=92d recommend sticking to those names and termin= ology. >>>> >>>> The values chosen were to be consistent with the python support. >>>> OTOH I *do* like being more consistent with the particular extension >>>> language at hand. >>>> I've tentatively changes things to use "error" and "substitute". >>>> Question: How about exporting the SCM_FAILED_CONVERSION_* constants >>>> and using those instead? >>>> >>>> E.g, (value->string foo #:errors SCM_FAILED_CONVERSION_ERROR) ? >>> >>> I=92d rather use a symbol: >> >> Yeah, I thought of that, but the encoding is a string, >> so it'd be "#:encoding string #:errors symbol". > > Right. Looks good to me. > >> I don't have a strong preference, but using a symbol here while >> feeling Schemey feels too weird. >> It's not a strong preference though. > > Using a symbol for #:errors? It would be natural and consistent with > the rest of Guile=92s API (notably and =91string->bytevector=92, > =91set-port-conversion-strategy!=92.) "works for me" Though I see %default-port-conversion-strategy is used by more than just ports, so it seems reasonable for gdb to use that as the default too (obtainable by calling scm_port_conversion_strategy (SCM_BOOL_F)). >>> (value->string foo #:conversion-strategy 'error) >>> >>> So that has to be converted in C but I think that=92s OK. >> >> #:conversion-strategy is more to type than #:errors but I'm happy to >> change it if you want. >> Though this is a case where I would not want to support both >> #:conversion-strategy and #:errors so whatever we pick is it. > > Right. Or =91value->string=92 could have this signature: > > value->string VAL [ENCODING [ERRORS]] > > The precedent being =91string->pointer=92 and =91string->bytevector=92. I'd like to stick with the current signature. >> We can create a 'error symbol at start up and just use scm_eq so the >> comparison is easy enough. > > Exactly, that=92s what I would suggest. Righto.