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`-relatedfunctions. Date: Fri, 20 Dec 2024 19:40:33 +0100 Message-ID: <20241220194033.r6gY2D0052kJuzj016gY2m@xavier.telenet-ops.be> References: <43ad0b39-03cf-b648-3bc9-8c4a064519a8@disroot.org> <8e113f49-c1dc-313b-e65a-24a73c5b887a@disroot.org> <20241220161547.r3Fm2D00N2kJuzj013FmRb@andre.telenet-ops.be> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_E6621FAC-3C32-4C6F-BEBB-02BF212B441F_" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18446"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Adam Faiz , "guile-devel@gnu.org" , Mikael Djurfeldt To: "mikael@djurfeldt.com" Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Fri Dec 20 19:41:23 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 1tOhwB-0004ev-4g for guile-devel@m.gmane-mx.org; Fri, 20 Dec 2024 19:41:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tOhvZ-0000BJ-Ek; Fri, 20 Dec 2024 13:40:45 -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 1tOhvV-0000Ay-GM for guile-devel@gnu.org; Fri, 20 Dec 2024 13:40:41 -0500 Original-Received: from xavier.telenet-ops.be ([2a02:1800:120:4::f00:14]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tOhvR-0002GZ-Rm for guile-devel@gnu.org; Fri, 20 Dec 2024 13:40:41 -0500 Original-Received: from [IPv6:2a02:1811:8c0e:ef00:f87b:b2ea:4352:aa46] ([IPv6:2a02:1811:8c0e:ef00:f87b:b2ea:4352:aa46]) by xavier.telenet-ops.be with cmsmtp id r6gY2D0052kJuzj016gY2m; Fri, 20 Dec 2024 19:40:33 +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=1734720033; bh=GTPE5u2xfAPWE9qY5YVzIZJi9DkNyGGmHNZW5XkKMRw=; h=Message-ID:MIME-Version:To:Cc:From:Subject:Date:In-Reply-To: References:Content-Type:From; b=kbzy+PtBcOM+DPkmliQibXeps2KBAGPYw9s3nyZ5elXgjAQaz8IHX0RsdgC6zLS09 07q9eHANQa5OLGNbjKdtU2tLAdoYN66aap4eq+AwOQV7M2uNz1nM+ElVz05xdERoNl zNhyO0oFy5WK0V9rkPkQF/ww/yuXMgi6AizXAGVJ++2i2KbPd+XFSXCHpCrBcWtRQG IENO0BGVwRGtVeBCvPRBnSnDIMPTjgIELDXGgrXCpXKv+aXbxx670d5ZW2cyfCVxEp qa4LngJdrRDUVo/+NmOqdF7Cz8qHXQuwF2VngMOAdj5FQBPj5J0sVjxAMIru5lpN6j kCitrExzPvViw== Received-SPF: pass client-ip=2a02:1800:120:4::f00:14; envelope-from=maximedevos@telenet.be; helo=xavier.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:22858 Archived-At: --_E6621FAC-3C32-4C6F-BEBB-02BF212B441F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > [...] > Maybe there's a misunderstanding here: What Adams test does is to compile= a list of results. What he refers to is the #t returned by the test checki= ng that the compiled results are correct. I changed that wording. Otherwise= , I think the test is fine (on a Unix system). Sounds reasonable. >>Also, there was the thing about needing to verify whether (ice-9 rdelim) = always recognises \n or whether that=E2=80=99s Unix-dependent (if the latte= r, (ice-9 rdelim) or the test needs to be adjusted, and in case of the form= er the documentation needs to be adjusted). >You're right that the behavior is Unix-dependent, as is the behavior of re= ad-line! in the same file. Perhaps one should do something about that. If s= o, the entire (ice-9 rdelim) module needs to be revised as well as libguile= /rdelim.c since the current implementation assumes that the line delimiter = is a single character, which was not true under Windows last time I checked= . (With Unix-dependent I actually meant =E2=80=98on Unix(-like) Guile does th= is, on others Guile does that=E2=80=99.) Yes, Windows convention is \r\n. I imagine Windows probably recognises \n i= n many contexts as well though I=E2=80=99m not completely sure about that, = but \r\n is its =E2=80=98standard=E2=80=99 line ending last time I checked. That rdelim behaviour looks more problematic than what I expected. Looking = at rdelim.scm, it only considers =E2=80=98\n=E2=80=99. Also, the interface = of read-delimited is intrinsically can=E2=80=99t support multiple-character= delimiters (you could replace the string of characters by a list of string= s, but ergh). Since other procedures for reading lines exist, I think it=E2= =80=99s best to just leave reading lines up to them. Although, likely read-= line and read-line! can be fixed. Proposed documentation modifications, to bring it in line with the implemen= tation, without preventing future fixes (even if a fixed implementation isn= =E2=80=99t yet available, it is better to have documentation that acknowled= ges the faults than having the faults be unknown, and it also provides an o= pportunity to mention potential incompatible API changes in advance). > (ice-9 rdelim) documentation: >(Old) It can be used to read or write lines of text, or read text delimite= d by a specified set of characters. >(New) It can be used to read text delimited by a specified set of charact= ers. You can also use it to read lines of text delimited by a single-charac= ter delimiter. However, this will not give appropriate results for text pro= duced on Windows, which delimits lines by a two-character sequence. For gen= eral line reading, get-line from (rnrs io ports) is more appropriate. >(Old) Return a line of text from=C2=A0port=C2=A0if specified, otherwise fr= om the value returned by=C2=A0(current-input-port). Under Unix, a line of t= ext is terminated by the first end-of-line character or by end-of-file. >(New) Return a newline-terminated line of text from=C2=A0port=C2=A0if spec= ified, otherwise from the value returned by=C2=A0(current-input-port). In f= uture versions of Guile, this may be modified to also recognise other line = terminators. >(Old)Read a line of text into the supplied string buf and return the numbe= r of characters added to buf. If buf is filled, then #f is returned. Read f= rom port if specified, otherwise from the value returned by (current-input-= port). >(New)Read a newline-terminated line of text into the supplied string buf a= nd return the number of characters added to buf. If buf is filled, then #f = is returned. Read from port if specified, otherwise from the value returned= by (current-input-port). In future versions of Guile, this may be modified= to also recognise other line terminators. >(Old)Read a newline-terminated line from port, allocating storage as neces= sary. The newline terminator (if any) is removed from the string, and a pai= r consisting of the line and its delimiter is returned. The delimiter may b= e either a newline or the eof-object; if %read-line is called at the end of= file, it returns the pair (# . #). > (New) Read a newline-terminated line from port, allocating storage as nec= essary. The newline terminator (if any) is removed from the string, and a p= air consisting of the line and its delimiter is returned. The delimiter may= be either a newline or the eof-object; if %read-line is called at the end = of file, it returns the pair (# . #). The newline is returned as = a character. In future versions of Guile, this may be modified to also reco= gnise other line terminators, and the delimiter might be returned as a stri= ng instead. > (rnrs io ports) documentation: > Scheme Procedure:=C2=A0get-line=C2=A0input-port=C2=A0=C2=B6 > (New) See Textual I/O. Unlike Textual I/O, eol-style should be taken into= account according to R6RS. However, this is not implemented. >Old: Display=C2=A0obj=C2=A0and a newline character to=C2=A0port. If=C2=A0p= ort=C2=A0is not specified,=C2=A0(current-output-port)=C2=A0is used. This pr= ocedure is equivalent to: [=E2=80=A6] >New: Display=C2=A0obj=C2=A0and a newline character to=C2=A0port. If=C2=A0p= ort=C2=A0is not specified,=C2=A0(current-output-port)=C2=A0is used. This pr= ocedure is equivalent to: [=E2=80=A6] In future versions of Guile, this may= be modified to write other line terminators depending on its end-of-line s= tyle. > Scheme Procedure: write-char char textual-output-port >old: These procedures are identical to the ones provided by Guile=E2=80=99= s core library. See Venerable Port Interfaces, and See Writing Scheme Value= s, for documentation. >old: These procedures are identical to the ones provided by Guile=E2=80=99= s core library. See Venerable Port Interfaces, and See Writing Scheme Value= s, for documentation. Contrary to what R6RS prescribes, neither module auto= matically convers line feed characters to the line terminator of the end-of= -line style. (Please check the last point, seems like something that should be tested ex= perimentally and I don=E2=80=99t have a Guile setup on this computer.) (Also, docstrings are to be modified accordingly) Best regards, Maxime Devos --_E6621FAC-3C32-4C6F-BEBB-02BF212B441F_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

><= span lang=3DEN-GB> [...]

>= Maybe there's a misunderstanding here: What Adams test does is to compile = a list of results. What he refers to is the #t returned by the test checkin= g that the compiled results are correct. I changed that wording. Otherwise,= I think the test is fine (on a Unix system).

 

Sounds reasonable.

 

>>Also, there was the thing about needing to verify whether (ice-9 = rdelim) always recognises \n or whether that=E2=80=99s Unix-dependent (if t= he latter, (ice-9 rdelim) or the test needs to be adjusted, and in case of = the former the documentation needs to be adjusted).

 

>= ;You're right that the behavior is Unix-dependent, as is the behavior of re= ad-line! in the same file. Perhaps one should do something about that. If s= o, the entire (ice-9 rdelim) module needs to be revised as well as libguile= /rdelim.c since the current implementation assumes that the line delimiter = is a single character, which was not true under Windows last time I checked= .

 

(With Unix-dependent I actually meant =E2=80=98on Unix(-like) Guile doe= s this, on others Guile does that=E2=80=99.)

&= nbsp;

Yes, Windows convention is \r\n. I imag= ine Windows probably recognises \n in many contexts as well though I=E2=80= =99m not completely sure about that, but \r\n is its =E2=80=98standard=E2= =80=99 line ending last time I checked.

 =

That rdelim behaviour looks more problematic= than what I expected. Looking at rdelim.scm, it only considers =E2=80=98\n= =E2=80=99. Also, the interface of read-delimited is intrinsically can=E2=80= =99t support multiple-character delimiters (you could replace the string of= characters by a list of strings, but ergh). Since other procedures for rea= ding lines exist, I think it=E2=80=99s best to just leave reading lines up = to them. Although, likely read-line and read-line! can be fixed.

 

Proposed documentat= ion modifications, to bring it in line with the implementation, without pre= venting future fixes (even if a fixed implementation isn=E2=80=99t yet avai= lable, it is better to have documentation that acknowledges the faults than= having the faults be unknown, and it also provides an opportunity to menti= on potential incompatible API changes in advance).

=  

> (ice-9 rdelim) documentation= :

>(Old) It can be used to read or wr= ite lines of text, or read text delimited by a specified set of characters.=

>(New)=C2=A0 It can be = used to read text delimited by a specified set of characters. You can also = use it to read lines of text delimited by a single-character delimiter. How= ever, this will not give appropriate results for text produced on Windows, = which delimits lines by a two-character sequence. For general line reading,= get-line from (rnrs io ports) is more appropriate.

>(Old) Return a line of text from por= t if specified, otherwise from the value returned by (current-input-port). Under Unix, a line of text is terminated by the first end-= of-line character or by end-of-file.

. In future versions of Guile, this may be modifie= d to also recognise other line terminators.

>(Old)Read a line of text= into the supplied string buf and return the number of characters added to = buf. If buf is filled, then #f is returned. Read from port if specified, ot= herwise from the value returned by (current-input-port).<= /p>

>(New)Read a newline-terminated line of te= xt into the supplied string buf and return the number of characters added t= o buf. If buf is filled, then #f is returned. Read from port if specified, = otherwise from the value returned by (current-input-port). In future versio= ns of Guile, this may be modified to also recognise other line terminators.=

 

>(Old)Read a newline-terminated line from p= ort, allocating storage as necessary. The newline terminator (if any) is re= moved from the string, and a pair consisting of the line and its delimiter = is returned. The delimiter may be either a newline or the eof-object; if %r= ead-line is called at the end of file, it returns the pair (#<eof> . = #<eof>).

> (New) R= ead a newline-terminated line from port, allocating storage as necessary. T= he newline terminator (if any) is removed from the string, and a pair consi= sting of the line and its delimiter is returned. The delimiter may be eithe= r a newline or the eof-object; if %read-line is called at the end of file, = it returns the pair (#<eof> . #<eof>). The newline is returned = as a character. In future versions of Guile, this may be modified to also r= ecognise other line terminators, and the delimiter might be returned as a s= tring instead.

 <= /o:p>

> (rnrs io ports) docume= ntation:

> Scheme Procedure: get-line input-port =C2=B6=

> <= span style=3D'font-size:12.0pt;font-family:"Times New Roman",serif;color:bl= ack'>(New) See Textual I/O. Unlike Textual I/O, eol-style should be taken i= nto account according to R6RS. However, this is not implemented.=

>Old: Display obj a= nd a newline character to port. If port is not specified,&nb= sp;(current-o= utput-port) is used. This procedure is equivalent = to: [=E2=80=A6]

>New: Display obj and a newline character to port. If&nb= sp;port is not specified, (current-output-port) is us= ed. This procedure is equivalent to: [=E2=80=A6] In future versions of Guil= e, this may be modified to write other line terminators depending on its en= d-of-line style.

 = ;

> Scheme Procedure: write-c= har char textual-output-port

>old: These procedures are identical to the ones provided by Guile=E2= =80=99s core library. See Venerable Port Interfaces, and See Writing Scheme= Values, for documentation. Contrary to what R6RS prescribes, neither modul= e automatically convers line feed characters to the line terminator of the = end-of-line style.

(Please = check the last point, seems like something that should be tested experiment= ally and I don=E2=80=99t have a Guile setup on this computer.)

(Also, docstrings are to be modified ac= cordingly)

 

<= p class=3DMsoNormal>Best regards,
Maxime Devos

= --_E6621FAC-3C32-4C6F-BEBB-02BF212B441F_--