From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Denis 'GNUtoo' Carikli Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH v1] SRFI-19: Add support for ISO 8601 zones with a colon. Date: Mon, 11 Mar 2024 19:25:08 +0100 Message-ID: <20240311192508.5b974e64@trisquel64> References: <20240229212343.10442-1-GNUtoo@cyberdimension.org> <87r0gnjj7h.fsf@trouble.defaultvalue.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/l2W4RsrCmaa38Tr0Bwlxy4S"; protocol="application/pgp-signature"; micalg=pgp-sha256 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27472"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-devel@gnu.org To: Rob Browning Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Mon Mar 11 19:31:38 2024 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rjkR0-0006sk-Il for guile-devel@m.gmane-mx.org; Mon, 11 Mar 2024 19:31:38 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rjkLQ-0006WS-4N; Mon, 11 Mar 2024 14:25:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rjkLF-0006Ar-Cx for guile-devel@gnu.org; Mon, 11 Mar 2024 14:25:44 -0400 Original-Received: from cyberdimension.org ([80.67.179.20] helo=gnutoo.cyberdimension.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rjkLC-0008L5-6P for guile-devel@gnu.org; Mon, 11 Mar 2024 14:25:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=dkim; bh=NGb4ecadaLuNFZ9 eq8kY2TbjQ662N1NCLTVhofNOvmY=; h=references:in-reply-to:subject:cc:to: from:date; d=cyberdimension.org; b=oHQecWKFw5SdrxIXTklngZMo10ACYDeFPCV nUNOimkYbntjX/p7cm5pKhUUD1la7ZSuadOC5bNhu2wXFslQwr0+rP5WMwCwQeFeuUXGnB CWBZ7X6IXW0ngZHUgu9DI8Uo+/gGq5fkENZwqwovt8TzykXHppDYhdmGtcVfaka92/5dPI 3Yca6q5Lv6behw4jyJ0sHY8x/8NpG5wGaaMDRHXpBvc+uPXbIuUuc7jcVlxkH8tp6fv5rv aRaDXzVQVq9N8vmi+4ErTFrxCPlmg5C6xItvm1mpZG3sH0lj71VQ5BQIwrfGhwqPg25Z3u p3CTsp9PwM+XL674Hf2xa/+5mKw== Original-Received: from trisquel64 (localhost [::1]) by gnutoo.cyberdimension.org (OpenSMTPD) with ESMTP id dd1b716f; Mon, 11 Mar 2024 18:25:31 +0000 (UTC) In-Reply-To: <87r0gnjj7h.fsf@trouble.defaultvalue.org> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.37; x86_64-pc-linux-gnu) Received-SPF: pass client-ip=80.67.179.20; envelope-from=GNUtoo@cyberdimension.org; helo=gnutoo.cyberdimension.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.devel:22348 Archived-At: --Sig_/l2W4RsrCmaa38Tr0Bwlxy4S Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi, Sorry for the delay, On Wed, 06 Mar 2024 12:42:10 -0600 Rob Browning wrote: > Denis 'GNUtoo' Carikli writes: > (...and (not related), I also wondered about making some of the error > messsages more specific, i.e. "Invalid time zone minutes digit" or > something.) Would something like that be OK instead?: > (time-error > 'string->date 'bad-date-template-string=20 > (list "Invalid time zone number" ch)) My code had indeed big duplication of code: it duplicated the read, the test and even the error message: > > + (if (char=3D? ch #\:) > > + (set! ch (read-char port)) > > + (if (eof-object? ch) > > + (time-error 'string->date > > 'bad-date-template-string > > + (list "Invalid time zone number" > > ch)))) (set! offset (+ offset (* (char->int ch) > > 10 60)))) =20 And if I understood right the goal of this example is to avoid this duplication of code: > This looks reasonable to me -- I wondered about moving the check "up > front", eliminating the need for the extra eof?, i.e. >=20 > (let ((ch (read-char port))) > (when (char=3D? ch #\:) > (set! ch (read-char port)) > (if (eof-object? ch) > (time-error 'string->date 'bad-date-template-string > (list "Invalid time zone number" ch))) > (set! ...)) However here (char=3D? ch #\:) can fail if ch is an eof-object. I tested that by adding that in some test.scm file: > (define ch (read-char)) > (char=3D? ch #\:) and running guile test.scm and typing ctrl+d to make ch an eof-object, and that produces the following error: > In procedure char=3D?: Wrong type argument in position 1 (expecting > character): # And since we can read a character twice we need to do that eof-object? test twice. So would something like that work instead?: > (let ((f (lambda () > (let ((ch (read-char port))) > (if (eof-object? ch) > (time-error > 'string->date 'bad-date-template-string > (list "Missing required time zone minutes" ch)) > ch))))) > (let ((ch (f))) > (if (char=3D? ch #\:) (set! ch (f))) > (set! offset (+ offset (* (char->int ch) 10 60))))) Here the downside is that the code is slightly more complex but there is no duplication of code and it also does one check for each read. Also note that I didn't test the code above yet. If all that is good, I can send a v2 of the patch. Denis. --Sig_/l2W4RsrCmaa38Tr0Bwlxy4S Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAmXvTIQACgkQX138wUF3 4mMyxg//arD/nJ3pm2bj46SEcmEagyEdlk8TAsRtEOnueenfwJOuHAZHrezN+jY8 e8VU8f0k7ckI4yOV3bKT7wN6BtS6RWjWYffI5CRDMOto1dswD62AiYm+P38Xo2sT IcVeP1lfCDs+/9U9IJhcOkZynTpZD8tzOwGnFutP38itR2mMRdgf58sHOhbvIiC1 fHJlsbeLbFg9IQCe+ivnyJFMfNTeocb16XJDYWA27KFQ9gVsooK+QXtoMvd2EuKX SxFhkc6vlkIzlWshez3PJCxbGCtG0Dv2rZ5fZiGdABasCPoGxNXJDOJCse6dAE8O vwenmqtvQbyDf1WncLZitGMSdG1SyIVWiG1K7iXiw1XDSQn3ult6Z3/7azEEFaX1 VxJi1AW+ijJ/GmoR9lTOOzn17qAl28scnPThYA5kvvGHMx3Bpm2+urAJFzIsHTwe 0qXpNbg17wZxvyg7Y0Slw+wFwYN9xdQ1zAXYrf7X1gTSEfsbVKayWYmVIQwYfPDG fJuJTiWHqyAU2KJaTYE46ajHjAwrM7N29/UGC+8htdKEKXDpCbkqY8SOMkPEiZC2 05Dpl4rLj1DKxOBmzek5pX4iIkq8yAhbfEmjGELsV9MHbr/3EiHIy8t02WIURBf+ c++TKY2ZE+UQn7UPWjzX3yEQDmYiOqXyQ7NK4ROOxKLCku+y7mI= =0vs8 -----END PGP SIGNATURE----- --Sig_/l2W4RsrCmaa38Tr0Bwlxy4S--