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 12:51:37 +0100 Message-ID: <20241220125141.qzrg2D00G2kJuzj06zrg2X@albert.telenet-ops.be> References: <43ad0b39-03cf-b648-3bc9-8c4a064519a8@disroot.org> <8e113f49-c1dc-313b-e65a-24a73c5b887a@disroot.org> <20241220101533.qxFY2D00e2kJuzj01xFZgG@baptiste.telenet-ops.be> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_F61C2AB0-60CC-4FF6-9440-AF60089FFA8A_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35589"; 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 12:52:09 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 1tObY8-00091D-NE for guile-devel@m.gmane-mx.org; Fri, 20 Dec 2024 12:52:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tObXr-000379-QR; Fri, 20 Dec 2024 06:51:51 -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 1tObXo-00036V-LP for guile-devel@gnu.org; Fri, 20 Dec 2024 06:51:49 -0500 Original-Received: from albert.telenet-ops.be ([2a02:1800:110:4::f00:1a]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tObXl-0003Cz-CZ for guile-devel@gnu.org; Fri, 20 Dec 2024 06:51:48 -0500 Original-Received: from [IPv6:2a02:1811:8c0e:ef00:f87b:b2ea:4352:aa46] ([IPv6:2a02:1811:8c0e:ef00:f87b:b2ea:4352:aa46]) by albert.telenet-ops.be with cmsmtp id qzrg2D00G2kJuzj06zrg2X; Fri, 20 Dec 2024 12:51:41 +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=1734695501; bh=slMYWDHTD4Y+Et+zlpRG8SY2GMN0e1Vz9pUHozXnDSU=; h=Message-ID:MIME-Version:To:Cc:From:Subject:Date:In-Reply-To: References:Content-Type:From; b=l/uzX0sJnwYb7YZwwia3P/O9jEV3dBWIdOVsGSK7rgirYK1kNQJqHvly5WdBrMYEb 7y/jp8IwnSbvCaRVSsf7DOlUnt4l3+ftNAFsgFz1sPM9TNWFdDrJym9LHFwJGzDmc9 AFGrtRAit8yqz8xLKmvOGbXrfPOm6XKaNKVkb2KmpVcasKVNv/EBHegkZdLCC+TyoF NgwJD/wg1d3Xd3B59gnhH2i976/GW/piR60I+fm9kiQNlxS2eG5XmIuisx0oKdqLr7 TKFNQszbRecDLfM4qN1O00vY1N0yFtIuOnd/nUlR8TnH28zZK3Mi3xomjUd7b7w4Il jFjcLRR09nxkQ== Received-SPF: pass client-ip=2a02:1800:110:4::f00:1a; envelope-from=maximedevos@telenet.be; helo=albert.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:22842 Archived-At: --_F61C2AB0-60CC-4FF6-9440-AF60089FFA8A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" >>Also, you are assuming =E2=80=9C\n=E2=80=9D is a line delimiter. This is = true under Unix according to the documentation. But it doesn=E2=80=99t say = anything about non-Unix systems. >RnRs defined read-line to handle different newline properly.=20 It=E2=80=99s named (ice-9 rdelim) not (rnrs rdelim). Perhaps (ice-9 rdelim)= could defer to RnRS, but its documentation currently doesn=E2=80=99t. (If = it does defer, it also needs to document what additional newline separators= it recognises.) >My original idea is to stick to a pure line string reader iterator helper = function. So we can just use read-line to make things simpler. The more gen= eral implementation has to consider this issue out of the standard API. What issue? You aren=E2=80=99t mentioning any bug in this paragraph, and th= e feature missing is also covered by the general interface (since it is gen= eral). If you are referring to the newline thing: naturally, a general API = _wouldn=E2=80=99t_ have to consider what the behaviour of read-line is or s= hould be, since it is up to the caller to decide what behaviour (and hence,= which passed procedure) they want. (Except where used in the test cases --= to test the general interface, some specific reader needs to be passed.) >The proposed generalisation could introduce extra complexity and seems lik= e over engineering. But as I said, it's still beautiful way to go and I don= 't against such an effort. Only if we can spend extra effort to make it=C2= =A0work properly. What extra complexity, and what extra effort, and what doesn=E2=80=99t work= properly about it? The generalisation I proposed: =E2=80=A2 does not introduces any complexity =E2=80=93 in fact, it=E2=80=99= s less, since it does not have to have any knowledge about the =E2=80=98set= tings=E2=80=99 of (ice-9 rdelim) =E2=80=A2 is not any more work than the specific application - in fact, it = is slightly less, because of the previous point (or about equal since a sin= gle (and only a single) extra argument needs to be passed) =E2=80=A2 in another sense, there is no extra work, since its implementatio= n is already provided =E2=80=A2 in another sense, there is _less_ work, since generalisations are= more broadly usable (instead of having to re-implement the thing for each = differerent reader(get-u8,read-json,read-line,etc.), now you could use the = generalisation for all of them) =E2=80=A2 it is a fairly minimal generalisation and this generalisation has= various uses, so there is no overengineering. I keep hearing claims about complexity, over-engineering, extra work, but n= obody actually says what the complexity, over-engineering or extra work _is= _. As I=E2=80=99ve written the above kind of response (in less detail) multipl= e times, yet I keep hearing =E2=80=9Cbut brr complexity/=E2=80=A6, and no I= =E2=80=99m not telling you what this supposed complexity/=E2=80=A6 is, and = I=E2=80=99m ignoring the evidence(not just disagreeing on some particular p= oints, but _ignoring_)=E2=80=9D, by now I have to assume malice (=E2=80=9C= proof by assertion=E2=80=9D / =E2=80=9C=E2=80=A6 ad nauseam=E2=80=9D is a f= allacy, and not the kind to make by accident). Like, in all the time that was spent claiming without evidence that this is= overengineered, and claiming that it=E2=80=99s too much work/... while ign= oring evidence to the contrary, the zero-additional-effort zero-additional-= complexity generalisation could have been integrated in the patch and in Gu= ile, and other things in Guile could perhaps have been improved as well. If you keep doing this I=E2=80=99m going to shorten future responses to thi= ngs like =E2=80=98This ignores previous evidence to the contrary, and is si= mply ad nauseum.=E2=80=99, as apparently there is some selective hearing go= ing on so a full response is not worth the effort. > Alright, I just elaborate my opinion before in case any misunderstanding = of my previous words. Let's face the problem. >I remember there's way to detect the current platform on the fly, so that = we can test for each supported OS. >How about Guile wrapped (uname), I used it in GNU Artanis to detect the ke= rnel version. But there's also brief OS info. Guile already has knows what system it is on, see e.g. %host-type. There is= no need for an additional syscall at runtime. This seems overly complicated, extra work and overengineerd, compared to si= mply fully documenting what (ice-9 rdelim) considers to be a line ending. P= erhaps it might turn out that the current behaviour is not always desirable= , but the first step is _knowing_ what the current behaviour is (the wordin= g sounds like it is platform-dependent, but it doesn=E2=80=99t inspire conf= idence that all cases were considered, and it is impossible to determine fr= om the documentation _what_ systems it knows about). >I don't think we need to handle Windows case, since nowadays there's WSL a= nd people like to run GNU things on WSL. Untrue, see e.g. Lilypond. While WSL is at times convenient, it is not the = same as native Windows support. (For example, the file names probably aren= =E2=80=99t like C:\Dir\Subdir\=E2=80=A6, which is incongruent with what you= would expect to be able to use in a Windows application.) Also, I was thinking on some old Mac(?) systems, where =E2=80=9C\r=E2=80=9D= instead of =E2=80=9C\n=E2=80=9D is the line feed (I don=E2=80=99t know whe= ther it recognised =E2=80=9C\n=E2=80=9D, IIRC it doesn=E2=80=99t). Regards. Maxime Devos --_F61C2AB0-60CC-4FF6-9440-AF60089FFA8A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

>>Also, you are assuming =E2=80=9C\n=E2=80=9D is a line= delimiter. This is true under Unix according to the documentation. But it = doesn=E2=80=99t say anything about non-Unix systems.

<= div>

>RnRs defined read-line= to handle different newline properly.

 

= It=E2=80=99s named (ice-9 rdelim) not (rnrs rdelim). Per= haps (ice-9 rdelim) could defer to RnRS, but its documentation currently do= esn=E2=80=99t. (If it does defer, it also needs to document what additional= newline separators it recognises.)

 

>My original idea is to stick to a pure line string reade= r iterator helper function. So we can just use read-line to make things sim= pler. The more general implementation has to consider this issue out of the= standard API.

 

What i= ssue? You aren=E2=80=99t mentioning any bug in this paragraph, and the feat= ure missing is also covered by the general interface (since it is general).= If you are referring to the newline thing: naturally, a general API _wo= uldn=E2=80=99t_ have to consider what the behaviour of read-line is or = should be, since it is up to the caller to decide what behaviour (and hence= , which passed procedure) they want. (Except where used in the test cases -= - to test the general interface, some specific reader needs to be passed.)<= o:p>

 

>The pr= oposed generalisation could introduce extra complexity and seems like over = engineering. But as I said, it's still beautiful way to go and I don't agai= nst such an effort. Only if we can spend extra effort to make it work = properly.

 

What extra complexity, and what extra effort, and what doesn=E2=80=99t wo= rk properly about it? The generalisation I proposed:

<= p class=3DMsoNormal> 

  • does not introd= uces any complexity =E2=80=93 in fact, it=E2=80=99s less, since it does not= have to have any knowledge about the =E2=80=98settings=E2=80=99 of (ice-9 = rdelim)
  • is not any more wo= rk than the specific application - in fact, it is slightly less, because of= the previous point (or about equal since a single (and only a single) extr= a argument needs to be passed)
  • in another sense, there is no extra work, since its implementation is = already provided
  • in anot= her sense, there is _less_ work, since generalisations are more broa= dly usable (instead of having to re-implement the thing for each differeren= t reader(get-u8,read-json,read-line,etc.), now you could use the generalisa= tion for all of them)
  • it i= s a fairly minimal generalisation and this generalisation has various uses,= so there is no overengineering.

 

<= span lang=3DEN-GB>I keep hearing claims about complexity, over-engineering,= extra work, but nobody actually says what the complexity, over-engineering= or extra work _is_.

 

As I=E2=80=99ve written the above kind of response (in less detail= ) multiple times, yet I keep hearing =E2=80=9Cbut brr complexity/=E2=80=A6,= and no I=E2=80=99m not telling you what this supposed complexity/=E2=80=A6= is, and I=E2=80=99m ignoring the evidence(not just disagreeing on some par= ticular points, but _ignoring_)=E2=80=9D, by now I have to assume ma= lice=C2=A0 (=E2=80=9Cproof by assertion=E2=80=9D / =E2=80=9C=E2=80=A6 ad na= useam=E2=80=9D is a fallacy, and not the kind to make by accident).

 = ;

Like, in all the = time that was spent claiming without evidence that this is overengineered, = and claiming that it=E2=80=99s too much work/... while ignoring evidence to= the contrary, the zero-additional-effort zero-additional-complexity genera= lisation could have been integrated in the patch and in Guile, and other th= ings in Guile could perhaps have been improved as well.

 

If you keep doing this I=E2=80=99m going= to shorten future responses to things like =E2=80=98This ignores previous = evidence to the contrary, and is simply ad nauseum.=E2=80=99, as apparently= there is some selective hearing going on so a full response is not worth t= he effort.

 

> Alrig= ht, I just elaborate my opinion before in case any misunderstanding of my p= revious words. Let's face the problem.

 

=

>I remember there's way to detec= t the current platform on the fly, so that we can test for each supported O= S.

= >How about Guile wrapped (uname), I used it in GNU Artanis to detect the= kernel version. But there's also brief OS info.

 

Guile already has knows what system it is on, s= ee e.g. %host-type. There is no need for an additional syscall at runtime.<= o:p>

 

This seems overly com= plicated, extra work and overengineerd, compared to simply fully documentin= g what (ice-9 rdelim) considers to be a line ending. Perhaps it might turn = out that the current behaviour is not always desirable, but the first step = is _knowing_ what the current behaviour is (the wording sounds like = it is platform-dependent, but it doesn=E2=80=99t inspire confidence that al= l cases were considered, and it is impossible to determine from the documen= tation _what_ systems it knows about).

 

>I don't think we need to= handle Windows case, since nowadays there's WSL and people like to run GNU= things on WSL.

 

Untrue, see e.g. Lilypond. While WSL is at times convenient, it is no= t the same as native Windows support. (For example, the file names probably= aren=E2=80=99t like C:\Dir\Subdir\=E2=80=A6, which is incongruent with wha= t you would expect to be able to use in a Windows application.)<= /span>

 <= /p>

Also, I was thinking on some old= Mac(?) systems, where =E2=80=9C\r=E2=80=9D instead of =E2=80=9C\n=E2=80=9D= is the line feed (I don=E2=80=99t know whether it recognised =E2=80=9C\n= =E2=80=9D, IIRC it doesn=E2=80=99t).

 

Regards.

Maxime Devos

<= /body>= --_F61C2AB0-60CC-4FF6-9440-AF60089FFA8A_--