From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Nala Ginrut Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] test-suite: Add tests for `for-rdelim-in-port`-related functions. Date: Fri, 20 Dec 2024 21:00:49 +0900 Message-ID: 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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000008f6fe20629b26651" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34883"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "mikael@djurfeldt.com" , Adam Faiz , guile-devel , Ricardo Wurmus , Tomas Volf <~@wolfsden.cz> To: Maxime Devos Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Fri Dec 20 13:01:48 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 1tObhT-0008sa-L8 for guile-devel@m.gmane-mx.org; Fri, 20 Dec 2024 13:01:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tObhB-0005FM-LO; Fri, 20 Dec 2024 07:01:30 -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 1tObgp-000586-Q0 for guile-devel@gnu.org; Fri, 20 Dec 2024 07:01:11 -0500 Original-Received: from mail-pj1-x102b.google.com ([2607:f8b0:4864:20::102b]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tObgl-0004w3-LK for guile-devel@gnu.org; Fri, 20 Dec 2024 07:01:07 -0500 Original-Received: by mail-pj1-x102b.google.com with SMTP id 98e67ed59e1d1-2f43d17b0e3so1707986a91.0 for ; Fri, 20 Dec 2024 04:01:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1734696062; x=1735300862; darn=gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Y80OVJn+5dllTXnJegpEAA1U2DZGZCyhZSFKvwV2w6s=; b=ZsLTfuIcNtkFTu19NWed7EyCkHoTa+KGGFu5QpR6jIJHS0FgwhuImziHFmccmHTEym WcoZtYWmM4onrasH+3yE5dzglLM+ke9VOHAeMVGnlslHAz2pRiKLJNBai15vef6scd/p Sk38eOXSXdymsdS1F1ZBuRgEUAhNwHw7wbFiIFYjHdVTGyC53+K4iT/xMLhIMFgXvT1S CKNDiytUstyXMiWooysdFkIuWGmHuJ2UcThXUwOAHA9ngqMLNvlF3uQjTZvvvcGGAkHh vdFXf/iTU+yvWX/aswmc+DYnTmTpe5PgM3Xcz77Jt8pU744bgVtEW39LsAy39zwYjPnf wUFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1734696062; x=1735300862; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Y80OVJn+5dllTXnJegpEAA1U2DZGZCyhZSFKvwV2w6s=; b=wkisOqp/RJXkspOacoFte1b8puVfz3hkEwWyVfpD0YC66mCbApsRQHUgRsxdrvmyW2 y6JMsqN47zB+Tz1jnRY6z0oWmCu2toiJrYIJYfjizBYQWruzx8MzC+XiGzAIwRekN/Fc cBhWXCahRfB/OA1mwEWYY7AEtHQ7lnzHzjjjBR6Dl9dryNVtq7Ilte3rcWbz63XnONBO tU1IwdRcd08j/mKx7b4JLwUHIyupFi34wExelmG9LLUdv2JvO1Gw00o3kzCn9P8Thvsj STffyApIIoYjRGBlpeFAPS/Q53rrcgpuf1AYtwd0c9y7uCPU7/V/dqGqa4inZSskIlNt vhaA== X-Forwarded-Encrypted: i=1; AJvYcCWT3Df0TS/p5zn4tGpiYrUvGCmxt6Ai81AkttX+IEr/DZxft9PYPNTjzvVMJyjpVGvwGql4WKRExbh/JQ==@gnu.org X-Gm-Message-State: AOJu0Yy8BxFrWOENjVxwvR1r9+I5Z3dlCsIJfOaFCXSrzYXE4pz99o/q blZic89iHztQHUCRSkTc+zfVNKF5tHvYf/p+a30lMjcn7yh3+96mMjkkJ9wA/evPxlnA6Mb6+XE pJ+MISvclZlWKPW9qnl75gbAgy6s= X-Gm-Gg: ASbGncv4rI2Jo3E0e+4i6L1G7LijkBOrZi7rRLP6QE/qZJcWNecSKe8QB4kkoIURqRd WA/i71sm2hDe34CVICdBbajZAReFCC1q4FIXVTQ== X-Google-Smtp-Source: AGHT+IEvC6GUtjgy+F7PdOPae8W16p6Hy4G/lRiQ9RZ/VmgKo36IKjG65MQO4K9OllkkbUNe+eO2Li2RVjh9XnmD8Fo= X-Received: by 2002:a17:90b:2545:b0:2ee:74a1:fba2 with SMTP id 98e67ed59e1d1-2f452e3e83cmr4031945a91.20.1734696061855; Fri, 20 Dec 2024 04:01:01 -0800 (PST) In-Reply-To: <20241220125141.qzrg2D00G2kJuzj06zrg2X@albert.telenet-ops.be> Received-SPF: pass client-ip=2607:f8b0:4864:20::102b; envelope-from=nalaginrut@gmail.com; helo=mail-pj1-x102b.google.com 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:22843 Archived-At: --0000000000008f6fe20629b26651 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have no any interest to persuade you, just show my opinion and suggestions. And I also have no interest to argue with you about the design, because the efforts has made according to you suggestions. I'm trying to follow the idea to not waste any efforts have been made. My suggestion is to find something function to test under different platforms. And if you think (uname) is not a good way, you should give a better solution. If any possible, follow the path technically, not waste anyone's time, include me, to discuss things that outside of the patch itself. Best regards. On Fri, Dec 20, 2024, 20:51 Maxime Devos wrote: > >>Also, you are assuming =E2=80=9C\n=E2=80=9D is a line delimiter. This i= s 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. > > > > It=E2=80=99s named (ice-9 rdelim) not (rnrs rdelim). Perhaps (ice-9 rdeli= m) could > defer to RnRS, but its documentation currently doesn=E2=80=99t. (If it do= es defer, > it also needs to document what additional newline separators it recognise= s.) > > > > >My original idea is to stick to a pure line string reader iterator helpe= r > function. So we can just use read-line to make things simpler. The more > general 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 = the > feature missing is also covered by the general interface (since it is > general). 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 > 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.) > > > > >The proposed 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 against 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: > > > > - does not introduces any complexity =E2=80=93 in fact, it=E2=80=99s l= ess, 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 work than the specific application - in fact, it is > slightly less, because of the previous point (or about equal since a s= ingle > (and only a single) extra argument needs to be passed) > - in another sense, there is no extra work, since its implementation > is already provided > - in another sense, there is _*less*_ work, since generalisations are > more broadly usable (instead of having to re-implement the thing for e= ach > differerent reader(get-u8,read-json,read-line,etc.), now you could use= the > generalisation for all of them) > - 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 > 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) multi= ple > 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 points, but _*ignoring*_)=E2=80=9D, by now= I have > to assume malice (=E2=80=9Cproof by assertion=E2=80=9D / =E2=80=9C=E2=80= =A6 ad nauseam=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 generalisation could have been integrated in t= he > patch and in Guile, 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 t= hings > like =E2=80=98This ignores previous evidence to the contrary, and is simp= ly ad > nauseum.=E2=80=99, as apparently there is some selective hearing going on= so a full > response is not worth the effort. > > > > > Alright, I just elaborate my opinion before in case any misunderstandin= g > of my previous words. Let's face the problem. > > > > >I remember there's way to detect the current platform on the fly, so tha= t > we can test for each supported OS. > > >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, 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 > simply fully documenting what (ice-9 rdelim) considers to be a line endin= g. > 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 all cases were considered, and it is impossible t= o > determine from the documentation _*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 not th= e > 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 wh= at 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 whether it re= cognised =E2=80=9C\n=E2=80=9D, IIRC it > doesn=E2=80=99t). > > > > Regards. > > Maxime Devos > --0000000000008f6fe20629b26651 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I have no any interest to persuade you, just show my opinion= and suggestions.

And I also have no interest to argue with you about the desi= gn, because the efforts has made according to you suggestions.

I'm trying to follow the idea to not waste any efforts h= ave been made.

My suggestion is to find something function to test under di= fferent platforms. And if you think (uname) is not a good way, you should g= ive a better solution.

If any possible, follow the path technically, not waste anyo= ne's time, include me, to discuss things that outside of the patch itse= lf.

Best regards.

On Fri, Dec 20, 2024, 20:51 Maxime Devos <maximedevos@telenet.be> wrote:
=

>>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 s= ystems.

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

=C2=A0

It=E2= =80=99s named (ice-9 rdelim) not (rnrs rdelim). Perhaps (ice-9 rdelim) coul= d defer to RnRS, but its documentation currently doesn=E2=80=99t. (If it do= es defer, it also needs to document what additional newline separators it r= ecognises.)

=C2=A0

>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 general implementation has to consider this issue out of the standard = API.

=C2=A0

Wh= at issue? You aren=E2=80=99t mentioning any bug in this paragraph, and the = feature missing is also covered by the general interface (since it is gener= al). If you are referring to the newline thing: naturally, a general API _<= i>wouldn=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 h= ence, which passed procedure) they want. (Except where used in the test cas= es -- to test the general interface, some specific reader needs to be passe= d.)

= =C2=A0

>The proposed generalisation could introduce extra complexity an= d seems like 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 ef= fort to make it=C2=A0work properly.

=C2=A0

What extra complexity, and what ext= ra effort, and what doesn=E2=80=99t work properly about it? The generalisat= ion I proposed:

=C2=A0

  • does not introduces 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=98setti= ngs=E2=80=99 of (ice-9 rdelim)
  • is not any more work = than the specific application - in fact, it is slightly less, because of th= e previous point (or about equal since a single (and only a single) extra a= rgument needs to be passed)
  • in another sense, there = is no extra work, since its implementation is already provided
  • in another sense, there is _less_ work, since generalisat= ions are more broadly usable (instead of having to re-implement the thing f= or each differerent reader(get-u8,read-json,read-line,etc.), now you could = use the generalisation for all of them)
  • it is a fai= rly minimal generalisation and this generalisation has various uses, so the= re is no overengineering.

=C2=A0

I keep hearing claims about complexity, over-engin= eering, extra work, but nobody actually says what the complexity, over-engi= neering or extra work _is_.

=C2=A0

As I=E2=80=99ve written the above kind of respo= nse (in less detail) multiple times, yet I keep hearing =E2=80=9Cbut brr co= mplexity/=E2=80=A6, and no I=E2=80=99m not telling you what this supposed c= omplexity/=E2=80=A6 is, and I=E2=80=99m ignoring the evidence(not just disa= greeing on some particular points, but _ignoring_)=E2=80=9D, by now = I have to assume malice=C2=A0 (=E2=80=9Cproof by assertion=E2=80=9D / =E2= =80=9C=E2=80=A6 ad nauseam=E2=80=9D is a fallacy, and not the kind to make = by accident).

=C2=A0

Like, in all the time that was spent claiming without evi= dence that this is overengineered, and claiming that it=E2=80=99s too much = work/... while ignoring evidence to the contrary, the zero-additional-effor= t zero-additional-complexity generalisation could have been integrated in t= he patch and in Guile, and other things in Guile could perhaps have been im= proved as well.

=C2=A0

If you keep doing this I=E2=80=99m going to shorten future respo= nses 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 the effort.=

=C2=A0=

> Alright, I just= elaborate my opinion before in case any misunderstanding of my previous wo= rds. Let's face the problem.

=C2=A0

<= div>

>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 Ar= tanis to detect the kernel version. But there's also brief OS info.<= /u>

=C2= =A0

Guile alre= ady has knows what system it is on, see e.g. %host-type. There is no need f= or an additional syscall at runtime.

=C2=A0

This seems overly complicated, extra work and= overengineerd, compared to simply fully documenting what (ice-9 rdelim) co= nsiders to be a line ending. Perhaps it might turn out that the current beh= aviour 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 all cases were considered,= and it is impossible to determine from the documentation _what_ sys= tems it knows about).

=C2=A0

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

=C2=A0

Untrue, see e.g. Lilypond. While WSL is at times convenie= nt, it is not the same as native Windows support. (For example, the file na= mes probably aren=E2=80=99t like C:\Dir\Subdir\=E2=80=A6, which is incongru= ent with what you would expect to be able to use in a Windows application.)=

=C2=A0

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

=C2=A0<= /span>

Regards.

Maxime Devos

--0000000000008f6fe20629b26651--