From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19472 invoked by alias); 4 Jan 2014 11:57:27 -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 19460 invoked by uid 89); 4 Jan 2014 11:57:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL autolearn=no version=3.3.2 X-HELO: mail2-relais-roc.national.inria.fr Received: from mail2-relais-roc.national.inria.fr (HELO mail2-relais-roc.national.inria.fr) (192.134.164.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Sat, 04 Jan 2014 11:57:24 +0000 Received: from reverse-83.fdn.fr (HELO pluto) ([80.67.176.83]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 04 Jan 2014 12:57:21 +0100 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v1 02/36] Guile extension language: doc additions References: <52b9da59.64ab440a.0b0b.7e1c@mx.google.com> <83ha9w68av.fsf@gnu.org> <87sit4kb1t.fsf@gnu.org> <83eh4ow78t.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 15 =?utf-8?Q?Niv=C3=B4se?= an 222 de la =?utf-8?Q?R?= =?utf-8?Q?=C3=A9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Sat, 04 Jan 2014 11:57:00 -0000 In-Reply-To: <83eh4ow78t.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 04 Jan 2014 09:12:18 +0200") Message-ID: <87k3egez8e.fsf@gnu.org> User-Agent: Gnus/5.130007 (Ma Gnus v0.7) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-01/txt/msg00027.txt.bz2 Eli Zaretskii skribis: >> >> +@defun value? object >>=20 >> What about distinguishing Scheme functions, like: >>=20 >> @deffn {Scheme Procedure} value? object > > If it's important (is it?), then yes. I think I would find it clearer, to someone who skims over the manual. >> >> +If @var{type} is not provided, >> >> +a Scheme real is converted to the C @code{double} type for the >> >> +current architecture. >> > >> > Isn't Guile built with libgmp? If so, doesn't it support floats >> > which, when converted to a double, will lose accuracy? >>=20 >> Guile uses GMP, but GMP is for integers (bignums). > > What about long double support? Guile doesn=E2=80=99t support it out of the box. If needed, it could easily be implemented as an extension: one would use a SMOB to wrap long doubles and pass them to Scheme, and possibly define methods for =E2=80=98+=E2=80=99, =E2=80=98-=E2=80=99, etc. for objects of t= his type. Of course, this wouldn=E2=80=99t be terribly efficient, but that=E2=80=99s = not so important here I think; what matters is that it would allow =E2=80=98long double=E2=80=99 values to be passed around without loss of accuracy. That said, my feeling is that leaving things as is (with long doubles cast to doubles) may prove to be sufficient for most practical uses of GDB. WDYT? >> >> +A Scheme string is converted to a target string, using the current >> >> +target encoding. >> > >> > What if target encoding doesn't support some of the characters in the >> > string? >>=20 >> Guile=E2=80=99s behavior can be controlled with >> =E2=80=98%default-port-conversion-strategy=E2=80=99: it can raise an exc= eption, or >> substitute any characters that could not be converted, or escape them >> (info "(guile) Ports"). >>=20 >> Perhaps this should be briefly mentioned, with a cross-ref. > > It should, because the issue will certainly arise, especially since > (AFAIU) Guile prefers UTF-8. Right. (UTF-8 is just the default encoding for source code; it=E2=80=99s n= ot =E2=80=9Cpreferred=E2=80=9D in any other way.) >> >> +If the optional @var{length} argument is given, the string will be >> >> +fetched and encoded to the length of characters specified. If >> >> +the @var{length} argument is not provided, the string will be fetched >> >> +and encoded until a null of appropriate width is found. >> > >> > Isn't this null termination description skewed towards C-like >> > languages? Aren't there languages where strings don't have to be >> > null-terminated? >>=20 >> Yes, and that=E2=80=99s when LENGTH should be provided, AIUI. > > Then I guess the above should say that explicitly. But it would be > nice if GDB could support strings in languages that don't > null-terminate even without LENGTH. Agreed (I had misread the description above as saying that, if LENGTH is provided, then the string is *not* assumed to be nul-terminated.) Thanks, Ludo=E2=80=99.