bug#73605: [PATCH] Replace SRFI-64 with a new implementation.
Hi, lloda skribis: > I'm pleased to see all these fixes. However, I noticed a few breakages. They > come from relying on undocumented behavior, but only using the public > interface, so others might be affected. I don't propose to patch them, but > perhaps to make a note in NEWS or (for the last two) to add a paragraph in > the manual explaining how to achieve the same goal – the reference > documentation doesn't have enough examples. > > * test-begin and test-end now require strings. The old version accepted > symbols. > * test-approximate requires real arguments. The old version accepted complex > arguments. > * The exported variable test-log-to-file is gone. As discussed on IRC, I think we should consider restoring support for these idioms, whether or not they conform to the reference, in an effort to minimize breakage (especially since this is slated for a point release). WDYT, Tomas? Ludo’.
bug#73605: [PATCH] Replace SRFI-64 with a new implementation.
Hello,
I was thinking about this and then forgot to reply. Sorry about that.
Ludovic Courtès writes:
> Hi,
>
> lloda skribis:
>
>> I'm pleased to see all these fixes. However, I noticed a few breakages. They
>> come from relying on undocumented behavior, but only using the public
>> interface, so others might be affected. I don't propose to patch them, but
>> perhaps to make a note in NEWS or (for the last two) to add a paragraph in
>> the
>> manual explaining how to achieve the same goal – the reference documentation
>> doesn't have enough examples.
>>
>> * test-begin and test-end now require strings. The old version accepted
>> symbols.
No problem with this one. Even the specification for test-begin does
note:
> Rationale: In some ways using symbols would be preferable. However, we
> want human-readable names, and standard Scheme does not provide a way
> to include spaces or mixed-case text in literal symbols.
I am just thinking how to express it neatly, maybe something like the
following would work well enough?
--8<---cut here---start->8---
--- a/wolfsden/srfi/srfi-64.scm
+++ b/wolfsden/srfi/srfi-64.scm
@@ -513,6 +513,14 @@ returning new test runner. Defaults to
@code{test-runner-simple}.")
((test-runner-on-group-begin r) r suite-name count)))
+(define (%cmp-group-name a b)
+ (match (list a b)
+(((? string?) (? string?))
+ (string=? a b))
+(((? symbol?) (? symbol?))
+ (eq? a b))
+(_ #f)))
+
(define* (test-end #:optional suite-name)
"Leave the current test group."
(let* ((r (test-runner-current))
@@ -520,7 +528,7 @@ returning new test runner. Defaults to
@code{test-runner-simple}.")
(let ((begin-name (car (test-runner-group-stack r)))
(end-name suite-name))
- (when (and end-name (not (string=? begin-name end-name)))
+ (when (and end-name (not (%cmp-group-name begin-name end-name)))
((test-runner-on-bad-end-name r) r begin-name end-name)
(raise-exception (make-bad-end-name begin-name end-name
--8<---cut here---end--->8---
Is there more elegant way to express this?
>> * test-approximate requires real arguments. The old version accepted complex
>> arguments.
No objections, since it seems that (imag-part 0) works just fine, I can
basically rewrite it to always consider the input complex, and it will
work.
>> * The exported variable test-log-to-file is gone.
I oppose to restoring this one. When you loaded test file into REPL, it
used to just litter your file system with random test log files created
in whatever the current working directory is. I do not consider that to
be a good behavior.
>
> As discussed on IRC, I think we should consider restoring support for
> these idioms, whether or not they conform to the reference, in an effort
> to minimize breakage (especially since this is slated for a point
> release).
>
> WDYT, Tomas?
Reacted above, I am fine with the first two, oppose to the third one.
I will send a patch for the first two today.
Tomas
--
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
bug#74031: [PATCH] srfi-64: Accept complex numbers in test-approximate.
The specification mandates reals, but the reference implementation
supports complex numbers. So as implementation extension, support them
as well.
* module/srfi/srfi-64.scm (within-epsilon): Support complex arguments.
---
Proposal for how to extend test-approximate to handle complex arguments.
However it differs from the original one. That one expected `error' to be a
real number, and used it for comparing both real parts and imaginary parts.
To me, that seems weird. I would consider it useful to be able to have
different errors for real and imaginary parts.
However I cannot remember the last time I have used complex numbers, so I am not
sure I am qualified to have an opinion here. What do other people think?
module/srfi/srfi-64.scm | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/module/srfi/srfi-64.scm b/module/srfi/srfi-64.scm
index 1f60a72e5..5fc23e28a 100644
--- a/module/srfi/srfi-64.scm
+++ b/module/srfi/srfi-64.scm
@@ -776,8 +776,16 @@ Test whether result of @var{test-expr} matches
@var{expected} using
(define (within-epsilon ε)
(λ (expected actual)
-(and (>= actual (- expected ε))
- (<= actual (+ expected ε)
+(let ((e-r (real-part expected))
+ (e-i (imag-part expected))
+ (a-r (real-part actual))
+ (a-i (imag-part actual))
+ (ε-r (real-part ε))
+ (ε-i (imag-part ε)))
+ (and (>= a-r (- e-r ε-r))
+ (<= a-r (+ e-r ε-r))
+ (>= a-i (- e-i ε-i))
+ (<= a-i (+ e-i ε-i))
(define-syntax %test-approximate
(λ (x)
@@ -808,6 +816,10 @@ Test whether result of @var{test-expr} matches
@var{expected} using
Test whether result of @var{test-expr} is within @var{error} of
@var{expected}.
+As implementation extension, complex numbers are supported as well. It tests
+whether real parts are within @code{(real-part @var{error})}, and imaginary
+parts within @code{(imag-part @var{error})}.
+
@end defspec")
(define-syntax %test-error
--
2.46.0
bug#74030: [PATCH] srfi-64: Accept symbols as test group names.
The specification mandates a string, but with rationale suggesting symbols
would be a more natural fit.
> In some ways using symbols would be preferable. However, we want
> human-readable names, and standard Scheme does not provide a way to include
> spaces or mixed-case text in literal symbols.
Add support for symbols as implementation extension.
* module/srfi/srfi-64.scm (%cmp-group-name): New procedure.
(test-end): Use it.
---
module/srfi/srfi-64.scm | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/module/srfi/srfi-64.scm b/module/srfi/srfi-64.scm
index 1f60a72e5..98fcef645 100644
--- a/module/srfi/srfi-64.scm
+++ b/module/srfi/srfi-64.scm
@@ -522,7 +522,10 @@ returning new test runner. Defaults to
@code{test-runner-simple}.")
(1+ (group-executed-count group)))
(define* (test-begin suite-name #:optional count)
- "Enter a new test group."
+ "Enter a new test group.
+
+As implementation extension, in addition to strings, symbols are also
+supported as @var{suite-name}."
(let* ((r (test-runner-current))
(r install? (if r
(values r#f)
@@ -544,6 +547,14 @@ returning new test runner. Defaults to
@code{test-runner-simple}.")
((test-runner-on-group-begin r) r suite-name count)))
+(define (%cmp-group-name a b)
+ (match (list a b)
+(((? string?) (? string?))
+ (string=? a b))
+(((? symbol?) (? symbol?))
+ (eq? a b))
+(_ #f)))
+
(define* (test-end #:optional suite-name)
"Leave the current test group."
(let* ((r (test-runner-current))
@@ -551,7 +562,7 @@ returning new test runner. Defaults to
@code{test-runner-simple}.")
(let ((begin-name (car (test-runner-group-stack r)))
(end-name suite-name))
- (when (and end-name (not (string=? begin-name end-name)))
+ (when (and end-name (not (%cmp-group-name begin-name end-name)))
((test-runner-on-bad-end-name r) r begin-name end-name)
(raise-exception (make-bad-end-name begin-name end-name
--
2.46.0
bug#71800: [PATCH 0/2] Improve documentation about using modules.
Tomas Volf <~@wolfsden.cz> skribis: > Document the #:hide argument. Correct text for implication of leaving > all optional arguments out. > > Tomas Volf (2): > doc: Document #:hide. > doc: Fix implication of omitting optional arguments. Applied, thanks!
bug#71253: [PATCH] doc: minor typo fix
Nikolaos Chatzikonstantinou skribis: > From bfeb86d9c7c258ac67de9cdd0b6eabbc01ab0114 Mon Sep 17 00:00:00 2001 > From: Nikolaos Chatzikonstantinou > Date: Tue, 28 May 2024 23:27:38 -0400 > Subject: [PATCH] doc: minor typo fix > > The incorrect procedure is mentioned; see the example that immediately > follows. > > * doc/ref/api-foreign.texi (Foreign Functions): fix typo to > pointer->procedure. Finally applied. Thank you and apologies for the delay! Ludo’.
bug#71684: [PATCH v4] doc: Document the peek and pk procedures.
Hi! Juliana Sims skribis: > * doc/ref/api-debug.texi: Document the peek and pk procedures. Nice work; documenting it was long overdue! Finally applied. Thank you and thanks to everyone who helped along the way! Ludo’.
bug#71047: [PATCH] doc: Recommend alist-copy instead of list-copy.
Tomas Volf <~@wolfsden.cz> skribis: > The current recommendation of `list-copy' is not right and does not lead > to preserving the original list: > > scheme@(guile-user)> (define x (list (cons 'a 1) (cons 'b 2))) > scheme@(guile-user)> (define y (list-copy x)) > scheme@(guile-user)> (assq-set! y 'b 3) > $1 = ((a . 1) (b . 3)) > scheme@(guile-user)> x > $2 = ((a . 1) (b . 3)) > > Correct approach seems to be use `alist-copy' from SRFI-1 leading to the > expected behavior of: > > scheme@(guile-user)> ,use (srfi srfi-1) > scheme@(guile-user)> (define x (list (cons 'a 1) (cons 'b 2))) > scheme@(guile-user)> (define y (alist-copy x)) > scheme@(guile-user)> (assq-set! y 'b 3) > $1 = ((a . 1) (b . 3)) > scheme@(guile-user)> x > $2 = ((a . 1) (b . 2)) > > * doc/ref/api-data.texi (Adding or Setting Alist Entries): Recommend > `alist-copy'. Applied, thanks!
bug#73605: [PATCH] Replace SRFI-64 with a new implementation.
> On 26 Oct 2024, at 16:09, Tomas Volf <~@wolfsden.cz> wrote: >>> * test-approximate requires real arguments. The old version accepted >>> complex arguments. > > No objections, since it seems that (imag-part 0) works just fine, I can > basically rewrite it to always consider the input complex, and it will > work. I think just changing within-epsilon to check (<= (magnitude (- expected value)) epsilon) would work. While looking at this I noticed that 1) the default test runner doesn't print either the computed error or the specified error and 2) test-approximate doesn't store the computed error in the test result (it does store the specified error). This makes it difficult for a custom test runner to print these things. I think test-approximate should store the computed error and also that these properties should be documented, so user-defined test routines (to compare other types) can use them as well. >>> * The exported variable test-log-to-file is gone. > > I oppose to restoring this one. When you loaded test file into REPL, it > used to just litter your file system with random test log files created > in whatever the current working directory is. I do not consider that to > be a good behavior. I don't think the variable should be restored. I also think that if the option were to be offered in a different way, not writing files is the better default. However, users who relied on the variable should not lose functionality. Perhaps add an argument to the default runner? Regards lloda
bug#74031: [PATCH] srfi-64: Accept complex numbers in test-approximate.
Like I wrote in a separate message, I think test-approximate should check the https://en.wikipedia.org/wiki/Euclidean_distance : (<= (magnitude (- expected value)) epsilon) For real numbers, it means the same as the current test. It would also work for other types for which the user has defined - and magnitude, like vectors. I just checked the old impl: -(define (%test-approximate= error) - (lambda (value expected) -(let ((rval (real-part value)) - (ival (imag-part value)) - (rexp (real-part expected)) - (iexp (imag-part expected))) - (and (>= rval (- rexp error)) - (>= ival (- iexp error)) - (<= rval (+ rexp error)) - (<= ival (+ iexp error)) This is still *a* distance (https://en.wikipedia.org/wiki/Chebyshev_distance), and close numbers will be close either way, but speaking as an engineer who uses complex numbers all day, Euclidean distance is the only one I've ever wanted to use. Regards lloda
bug#74031: [PATCH v2] srfi-64: Accept complex numbers in test-approximate.
The specification mandates reals, but the reference implementation
supports complex numbers. So as implementation extension, support them
as well.
* module/srfi/srfi-64.scm (within-epsilon): Support complex arguments.
---
Require error to be real number and check using (checks notes) Chebyshev
distance.
module/srfi/srfi-64.scm | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/module/srfi/srfi-64.scm b/module/srfi/srfi-64.scm
index 1f60a72e5..453296364 100644
--- a/module/srfi/srfi-64.scm
+++ b/module/srfi/srfi-64.scm
@@ -776,8 +776,14 @@ Test whether result of @var{test-expr} matches
@var{expected} using
(define (within-epsilon ε)
(λ (expected actual)
-(and (>= actual (- expected ε))
- (<= actual (+ expected ε)
+(let ((e-r (real-part expected))
+ (e-i (imag-part expected))
+ (a-r (real-part actual))
+ (a-i (imag-part actual)))
+ (and (>= a-r (- e-r ε))
+ (<= a-r (+ e-r ε))
+ (>= a-i (- e-i ε))
+ (<= a-i (+ e-i ε))
(define-syntax %test-approximate
(λ (x)
@@ -808,6 +814,10 @@ Test whether result of @var{test-expr} matches
@var{expected} using
Test whether result of @var{test-expr} is within @var{error} of
@var{expected}.
+As implementation extension, complex numbers are supported as well. It tests
+whether real parts are within @code{(real-part @var{error})}, and imaginary
+parts within @code{(imag-part @var{error})}.
+
@end defspec")
(define-syntax %test-error
--
2.46.0
bug#74031: [PATCH] srfi-64: Accept complex numbers in test-approximate.
Hello, lloda writes: >> On 26 Oct 2024, at 19:22, Ludovic Courtès wrote: >> >> Hi, >> >> (Cc: lloda.) >> >> Tomas Volf <~@wolfsden.cz> skribis: >> >>> The specification mandates reals, but the reference implementation >>> supports complex numbers. So as implementation extension, support them >>> as well. >>> >>> * module/srfi/srfi-64.scm (within-epsilon): Support complex arguments. >>> --- >>> Proposal for how to extend test-approximate to handle complex arguments. >>> However it differs from the original one. That one expected `error' to be a >>> real number, and used it for comparing both real parts and imaginary parts. >>> >>> To me, that seems weird. I would consider it useful to be able to have >>> different errors for real and imaginary parts. >>> >>> However I cannot remember the last time I have used complex numbers, so I >>> am not >>> sure I am qualified to have an opinion here. What do other people think? >> >> Not sure either. Daniel, is that what you would expect? >> >> Perhaps we should check the reference implementation? >> >> Ludo’. > > Sorry, I didn't notice this. I replied on another message, but to be clear, > the > expected error should always be a real number, no matter what you're > comparing. Got it, I have sent v2 using the same logic the original implementation did (according to your message "Chebyshev distance"). Since we are doing this for purpose of backwards compatibility, it makes sense to just restore the original behavior as it was. > If one wants to have separate errors for real and imaginary parts, > then one can simply use test-approximate on the real and imaginary parts > separately. By the same logic, if one wants to use the standard compliant test-approximate with complex numbers, one can simply call it on real and imaginary parts separately. ^_^ Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
bug#74031: [PATCH v3] srfi-64: Accept complex numbers in test-approximate.
The specification mandates reals, but the reference implementation
supports complex numbers. So as implementation extension, support them
as well.
* module/srfi/srfi-64.scm (within-epsilon): Support complex arguments.
---
v2: Use the same test logic as the reference implementation.
v3: Also adjust the docstring.
module/srfi/srfi-64.scm | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/module/srfi/srfi-64.scm b/module/srfi/srfi-64.scm
index 1f60a72e5..0f1b5c117 100644
--- a/module/srfi/srfi-64.scm
+++ b/module/srfi/srfi-64.scm
@@ -776,8 +776,14 @@ Test whether result of @var{test-expr} matches
@var{expected} using
(define (within-epsilon ε)
(λ (expected actual)
-(and (>= actual (- expected ε))
- (<= actual (+ expected ε)
+(let ((e-r (real-part expected))
+ (e-i (imag-part expected))
+ (a-r (real-part actual))
+ (a-i (imag-part actual)))
+ (and (>= a-r (- e-r ε))
+ (<= a-r (+ e-r ε))
+ (>= a-i (- e-i ε))
+ (<= a-i (+ e-i ε))
(define-syntax %test-approximate
(λ (x)
@@ -808,6 +814,10 @@ Test whether result of @var{test-expr} matches
@var{expected} using
Test whether result of @var{test-expr} is within @var{error} of
@var{expected}.
+As implementation extension, complex numbers are supported as well. It tests
+whether both real and imaginary parts of @var{test-expr} are within
+@var{error} of real and imaginary parts of @var{expected}.
+
@end defspec")
(define-syntax %test-error
--
2.46.0
bug#74030: [PATCH] srfi-64: Accept symbols as test group names.
Tomas Volf <~@wolfsden.cz> skribis: > The specification mandates a string, but with rationale suggesting symbols > would be a more natural fit. > >> In some ways using symbols would be preferable. However, we want >> human-readable names, and standard Scheme does not provide a way to include >> spaces or mixed-case text in literal symbols. > > Add support for symbols as implementation extension. > > * module/srfi/srfi-64.scm (%cmp-group-name): New procedure. > (test-end): Use it. I added “for backwards compatibility with the reference implementation” and credited Daniel for reporting the issue. Applied, thanks! Ludo’.
bug#74031: [PATCH] srfi-64: Accept complex numbers in test-approximate.
Hi, (Cc: lloda.) Tomas Volf <~@wolfsden.cz> skribis: > The specification mandates reals, but the reference implementation > supports complex numbers. So as implementation extension, support them > as well. > > * module/srfi/srfi-64.scm (within-epsilon): Support complex arguments. > --- > Proposal for how to extend test-approximate to handle complex arguments. > However it differs from the original one. That one expected `error' to be a > real number, and used it for comparing both real parts and imaginary parts. > > To me, that seems weird. I would consider it useful to be able to have > different errors for real and imaginary parts. > > However I cannot remember the last time I have used complex numbers, so I am > not > sure I am qualified to have an opinion here. What do other people think? Not sure either. Daniel, is that what you would expect? Perhaps we should check the reference implementation? Ludo’.
bug#72208: [PATCH] doc: tour: note the top-level modules ice-9, scheme, and srfi
Hello,
"Dr. Arne Babenhauserheide" skribis:
> From 6838e4da9712425e7e45805a73731bb399d90a86 Mon Sep 17 00:00:00 2001
> From: Arne Babenhauserheide
> Date: Sat, 20 Jul 2024 15:03:15 +0200
> Subject: [PATCH] doc: reference ice-9, scheme, and srfi
>
> * doc/ref/tour.texi (Using Modules): reference ice-9, scheme, and srfi.
Good idea!
> +Most provided modules use prefixes based on their origin:
> +
> +@itemize @bullet
> +@item @code{ice-9} includes guile-specific modules: the standard library of
> Guile. @xref{Status, History of ice-9, History of ice-9}
s/guile/Guile/
Also: please leave two spaces after an end-of-sentence period and add a
semicolon at the end of the line.
> +@item @code{rnrs} and @code{scheme} include modules from the RnRS standard
> (@url{https://standards.scheme.org/}). @xref{R7RS Support} and @xref{R6RS
> Support}
s/RnRS standard/Scheme standards/
Likewise, semicolon at the end of the line
> +@item @code{srfi} includes Scheme Requests For Implementation; SRFI’s
> (@url{https://srfi.schemers.org/}). @xref{SRFI Support}
Rather:
… includes @uref{https://srfi.schemers.org/, Scheme Requests for
Implementation or ``SRFIs''} (@pxref{SRFI Support});
> +@item Some larger features have their own prefix. These include @code{web}
> (@pxref{Web}), @code{oop} (@xref{GOOPS}), @code{sxml} (@pxref{SXML}), and
> @code{language} (@pxref{Other Languages}).
s/@xref{GOOPS}/@pxref{GOOPS}/ (since it’s in parentheses)
Fine with me with these changes!
Ludo’.
bug#74031: [PATCH] srfi-64: Accept complex numbers in test-approximate.
> On 26 Oct 2024, at 19:22, Ludovic Courtès wrote: > > Hi, > > (Cc: lloda.) > > Tomas Volf <~@wolfsden.cz> skribis: > >> The specification mandates reals, but the reference implementation >> supports complex numbers. So as implementation extension, support them >> as well. >> >> * module/srfi/srfi-64.scm (within-epsilon): Support complex arguments. >> --- >> Proposal for how to extend test-approximate to handle complex arguments. >> However it differs from the original one. That one expected `error' to be a >> real number, and used it for comparing both real parts and imaginary parts. >> >> To me, that seems weird. I would consider it useful to be able to have >> different errors for real and imaginary parts. >> >> However I cannot remember the last time I have used complex numbers, so I am >> not >> sure I am qualified to have an opinion here. What do other people think? > > Not sure either. Daniel, is that what you would expect? > > Perhaps we should check the reference implementation? > > Ludo’. Sorry, I didn't notice this. I replied on another message, but to be clear, the expected error should always be a real number, no matter what you're comparing. If one wants to have separate errors for real and imaginary parts, then one can simply use test-approximate on the real and imaginary parts separately. Regards Daniel
