From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Maxime Devos Newsgroups: gmane.lisp.guile.devel Subject: RE: [PATCH] test-suite: Add tests for `for-rdelim-in-port`-related functions. Date: Fri, 20 Dec 2024 15:18:34 +0100 Message-ID: <20241220151837.r2Jc2D00o2kJuzj012JdDJ@laurent.telenet-ops.be> References: <43ad0b39-03cf-b648-3bc9-8c4a064519a8@disroot.org> <8e113f49-c1dc-313b-e65a-24a73c5b887a@disroot.org> <20241220101533.qxFY2D00e2kJuzj01xFZgG@baptiste.telenet-ops.be> <20241220125141.qzrg2D00G2kJuzj06zrg2X@albert.telenet-ops.be> <20241220135310.r0t92D0082kJuzj010t981@laurent.telenet-ops.be> <20241220144559.r1ly2D00i2kJuzj061lzzE@albert.telenet-ops.be> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_7E40D2FC-2232-408A-9AD8-0817F7A03836_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20048"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "mikael@djurfeldt.com" , Adam Faiz , guile-devel , Ricardo Wurmus , Tomas Volf <~@wolfsden.cz> To: Nala Ginrut Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Fri Dec 20 15:19:12 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 1tOdqR-00055T-O6 for guile-devel@m.gmane-mx.org; Fri, 20 Dec 2024 15:19:11 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tOdq5-00029Q-3C; Fri, 20 Dec 2024 09:18:49 -0500 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 1tOdq1-000299-7K for guile-devel@gnu.org; Fri, 20 Dec 2024 09:18:45 -0500 Original-Received: from laurent.telenet-ops.be ([2a02:1800:110:4::f00:19]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tOdpy-00022o-CW for guile-devel@gnu.org; Fri, 20 Dec 2024 09:18:44 -0500 Original-Received: from [IPv6:2a02:1811:8c0e:ef00:f87b:b2ea:4352:aa46] ([IPv6:2a02:1811:8c0e:ef00:f87b:b2ea:4352:aa46]) by laurent.telenet-ops.be with cmsmtp id r2Jc2D00o2kJuzj012JdDJ; Fri, 20 Dec 2024 15:18:37 +0100 Importance: normal X-Priority: 3 In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telenet.be; s=r24; t=1734704317; bh=L1LkMtW6vqPrmsKCxjVGwbZGKGoEb+wOn7JTEfCcAN8=; h=Message-ID:MIME-Version:To:Cc:From:Subject:Date:In-Reply-To: References:Content-Type:From; b=jTCQe26813KZYOdDIPEpzdz7D6K8UYcGY/VENUQ93gHMKMpTWkCs6fXXQntCNpJ1p aUt3S/Rx2z4H7EkK4uQEM0LORRxwFtstB6P3EIGzoaOq4+VpmcplsyEJePLY2gLyEr 5GWJs5dJhiPLUYX3AdZE/D9ADceBTBqJaNFOmgv0bs0b+/4ID187HLRfBqfVtyYMpd jER6OtnWXCPH7TcgUy3LiJSmpygac8rBWAhbdAOp2Tuir3BaEB9ze2Dkbn7ggSa6gC mkpv9tfPVhaErTO2Gr+BvbZkWV6N0WYwFgnZyAa1BzVJD/XS508leysh02w6Il0/67 tRa+zhDv/MYyg== Received-SPF: pass client-ip=2a02:1800:110:4::f00:19; envelope-from=maximedevos@telenet.be; helo=laurent.telenet-ops.be X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 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:22848 Archived-At: --_7E40D2FC-2232-408A-9AD8-0817F7A03836_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" >Here are the "back to the track" reply for folks in this thread. > >So the situation is more clear now. The newline in various OS need to resp= ectively tested. And my idea is to check OS via (uname) in test cases. >Now that it's in tests, I think we don't have to talk much about the effic= iency issue for this specific case. No. See what I wrote previously about the subject, and note that most of it= is independent of whether it=E2=80=99s for testing or not. As you previous= ly said you intentionally did not read (parts of) the messages, I=E2=80=99m= not going to repeat it for you. In addition: why not simply _read_ the implementation of (ice-9 rdelim) to = see what platform-detecting mechanism it uses (if any) and reuse that, inst= ead of reinventing the wheel? Sounds like it would save effort and time, wh= ich you seem particularly interested in, and claimed effort/time is one of = your own arguments against generalisation. Also, it doesn=E2=80=99t need to be tested, since read-line is not what=E2= =80=99s being added or modified here. (Tests for that may be good, but that= =E2=80=99s off-topic, which you are rather against, and is your most cohere= nt argument against generalisation.) Rather, either the used newline in the= test needs to be adjusted per-platform, or the documentation of read-line = needs to be adjusted to that \n is always a newline. Also, it=E2=80=99s also not a proper =E2=80=9Cback to the track=E2=80=9D re= ply, since it ignores the =E2=80=98generalisation=E2=80=99 component of the= track. Regards, Maxime Devos --_7E40D2FC-2232-408A-9AD8-0817F7A03836_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

>Here are the "back to the track" repl= y for folks in this thread.

> 

>So the situation is more clear now. Th= e newline in various OS need to respectively tested. And my idea is to chec= k OS via (uname) in test cases.

>Now that it's in tests, I think we don't h= ave to talk much about the efficiency issue for this specific case.

 = ;

No. See what I wr= ote previously about the subject, and note that most of it is independent o= f whether it=E2=80=99s for testing or not. As you previously said you inten= tionally did not read (parts of) the messages, I=E2=80=99m not going to rep= eat it for you.

 

In ad= dition: why not simply _read_ the implementation of (ice-9 rdelim) t= o see what platform-detecting mechanism it uses (if any) and reuse that, in= stead of reinventing the wheel? Sounds like it would save effort and time, = which you seem particularly interested in, and claimed effort/time is one o= f your own arguments against generalisation.

 

Also, it doesn=E2=80=99t need to be tested, since = read-line is not what=E2=80=99s being added or modified here. (Tests for th= at may be good, but that=E2=80=99s off-topic, which you are rather against,= and is your most coherent argument against generalisation.) Rather, either= the used newline in the test needs to be adjusted per-platform, or the doc= umentation of read-line needs to be adjusted to that \n is always a newline= .

 <= /o:p>

Also, it=E2=80=99s = also not a proper =E2=80=9Cback to the track=E2=80=9D reply, since it ignor= es the =E2=80=98generalisation=E2=80=99 component of the track.<= /span>

 <= /p>

Regards,

Maxime Devos

= --_7E40D2FC-2232-408A-9AD8-0817F7A03836_--