bug#72370: srfi-64: test-apply requires at least one specifier

bug#72370: srfi-64: test-apply requires at least one specifier

[Tomas Volf]

Hello,

I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.

The specification says the following regarding the test-apply:

> If one or more specifiers are listed then only tests matching the specifiers
> are executed.

That implies that specifiers are optional and the following code should work:

    (use-modules (srfi srfi-64))
    (test-apply (λ () #t))

However it does not:

    Backtrace:
    In ice-9/boot-9.scm:
      1752:10  8 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
    In unknown file:
               7 (apply-smob/0 #<thunk 7fdf6ecc4300>)
    In ice-9/boot-9.scm:
        724:2  6 (call-with-prompt _ _ #<procedure default-prompt-handler (k proc)>)
    In ice-9/eval.scm:
        619:8  5 (_ #(#(#<directory (guile-user) 7fdf6ecc7c80>)))
    In ice-9/boot-9.scm:
       2836:4  4 (save-module-excursion _)
      4388:12  3 (_)
    In srfi/srfi-64/testing.scm:
       947:34  2 (test-apply #<procedure 7fdf63956108 at /home/wolf/src/guile-wolfsden/tests/s…>)
       938:47  1 (test-apply #<procedure 7fdf63956108 at /home/wolf/src/guile-wolfsden/test…> . _)
    In unknown file:
               0 (reverse #t)

    ERROR: In procedure reverse:
    In procedure reverse: Wrong type argument in position 1: #t

Have a nice day
Tomas Volf

bug#72370: srfi-64: test-apply requires at least one specifier

[Taylan Kammer]

On 30.07.2024 21:51, Tomas Volf wrote:
> Hello,
>
> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>
> The specification says the following regarding the test-apply:
>
>> If one or more specifiers are listed then only tests matching the specifiers
>> are executed.
> That implies that specifiers are optional and the following code should work:
>
>     (use-modules (srfi srfi-64))
>     (test-apply (λ () #t))
>
> However it does not:
>
>     Backtrace:
>     In ice-9/boot-9.scm:
>       1752:10  8 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
>     In unknown file:
>                7 (apply-smob/0 #<thunk 7fdf6ecc4300>)
>     In ice-9/boot-9.scm:
>         724:2  6 (call-with-prompt _ _ #<procedure default-prompt-handler (k proc)>)
>     In ice-9/eval.scm:
>         619:8  5 (_ #(#(#<directory (guile-user) 7fdf6ecc7c80>)))
>     In ice-9/boot-9.scm:
>        2836:4  4 (save-module-excursion _)
>       4388:12  3 (_)
>     In srfi/srfi-64/testing.scm:
>        947:34  2 (test-apply #<procedure 7fdf63956108 at /home/wolf/src/guile-wolfsden/tests/s…>)
>        938:47  1 (test-apply #<procedure 7fdf63956108 at /home/wolf/src/guile-wolfsden/test…> . _)
>     In unknown file:
>                0 (reverse #t)
>
>     ERROR: In procedure reverse:
>     In procedure reverse: Wrong type argument in position 1: #t
>
> Have a nice day
> Tomas Volf

If anyone's wondering why I don't want to work with the upstream SRFI-64 code, reading the implementation of test-apply is all you need. :-)

It almost makes me think it must be machine-generated code, or intentionally obfuscated. But anyway.

My implementation actually had a similar bug, but it should be fixed now with this commit:

    https://codeberg.org/taylan/scheme-srfis/commit/3091e3b863d53a012b4be4376814bb67bf09020d

I've also noticed the other issue with test-apply that you reported as a separate bug report, and will fix that later.

Thanks a ton for all these reports, because it seems you've really caught a ton of edge-cases, and some glaring issues in seldom-used parts of the API.

- Taylan

bug#72370: srfi-64: test-apply requires at least one specifier

[Taylan Kammer]

On 30.09.2024 20:50, Taylan Kammer wrote:
> On 30.07.2024 21:51, Tomas Volf wrote:
>> Hello,
>>
>> I think I found a bug in (srfi srfi-64) module shipped with GNU Guile.
>>
>> The specification says the following regarding the test-apply:
>>
>>> If one or more specifiers are listed then only tests matching the specifiers
>>> are executed.
>> That implies that specifiers are optional and the following code should work:
>>
>>     (use-modules (srfi srfi-64))
>>     (test-apply (λ () #t))
>>
>> However it does not:
>>
>>     Backtrace:
>>     In ice-9/boot-9.scm:
>>       1752:10  8 (with-exception-handler _ _ #:unwind? _ #:unwind-for-type _)
>>     In unknown file:
>>                7 (apply-smob/0 #<thunk 7fdf6ecc4300>)
>>     In ice-9/boot-9.scm:
>>         724:2  6 (call-with-prompt _ _ #<procedure default-prompt-handler (k proc)>)
>>     In ice-9/eval.scm:
>>         619:8  5 (_ #(#(#<directory (guile-user) 7fdf6ecc7c80>)))
>>     In ice-9/boot-9.scm:
>>        2836:4  4 (save-module-excursion _)
>>       4388:12  3 (_)
>>     In srfi/srfi-64/testing.scm:
>>        947:34  2 (test-apply #<procedure 7fdf63956108 at /home/wolf/src/guile-wolfsden/tests/s…>)
>>        938:47  1 (test-apply #<procedure 7fdf63956108 at /home/wolf/src/guile-wolfsden/test…> . _)
>>     In unknown file:
>>                0 (reverse #t)
>>
>>     ERROR: In procedure reverse:
>>     In procedure reverse: Wrong type argument in position 1: #t
>>
>> Have a nice day
>> Tomas Volf
> If anyone's wondering why I don't want to work with the upstream SRFI-64 code, reading the implementation of test-apply is all you need. :-)
>
> It almost makes me think it must be machine-generated code, or intentionally obfuscated. But anyway.
>
> My implementation actually had a similar bug, but it should be fixed now with this commit:
>
>     https://codeberg.org/taylan/scheme-srfis/commit/3091e3b863d53a012b4be4376814bb67bf09020d
>
> I've also noticed the other issue with test-apply that you reported as a separate bug report, and will fix that later.
>
> Thanks a ton for all these reports, because it seems you've really caught a ton of edge-cases, and some glaring issues in seldom-used parts of the API.
>
> - Taylan
>
By the way, I just noticed another issue with test-apply:

It will sometimes call the supplied test runner's on-final handler, and sometimes not.

I had made sure to imitate the behavior one-to-one in my own SRFI-64 implementation, but looking at the code one more time and pondering on the behavior a bit, this seems rather arbitrary and most likely not intended.

So, I've changed it in my implementation so that the on-final handler will always be called at the end when using test-apply. Fix is implemented with this commit:

    https://codeberg.org/taylan/scheme-srfis/commit/a33b9f0cd4558d255605eccfa1a59111b8eb3716

- Taylan