GNU bug report logs - #74385
[PATCH 0/4] Patches for SRFI-64

Previous Next

Full log

View this message in rfc822 format

From: Tomas Volf <~@wolfsden.cz>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 74385 <at> debbugs.gnu.org, Janneke Nieuwenhuizen <janneke <at> gnu.org>
Subject: bug#74385: [PATCH 4/4] srfi-64: Report failed tests in (standards)Errors format.
Date: Fri, 13 Dec 2024 17:05:59 +0100

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> writes:

> Tomas Volf <~@wolfsden.cz> skribis:
>
>> There is a page in the GNU Standards document regarding the format of error
>> messages.  Both GNU Emacs and Vim are able to parse it and support jumping to
>> next/previous error.  My version did not produce a line in this format for
>> failed tests and this commit rectifies that.
>>
>> * module/srfi/srfi-64.scm (test-on-test-end-simple)[non-passed]: Write
>> out (standards)Errors compatible line.
>>
>> Reported-by: Janneke Nieuwenhuizen <janneke <at> gnu.org>
>
> I personally like this but my gut feeling is that we may want to stick
> to whatever the previous SRFI-64 implementation was doing, to avoid
> disruption or breakage for users (remember we’re applying this to a
> stable series).

I agree that the output of the simple test runner of the current and the
reference versions do differ, by necessity.  I tested the change in
Emacs and it seems to work out of the box, the compilation buffer
correctly navigates to the locations.

However I understand your worries regarding the stable series.  What I
would suggest is that I can extract the test runner from the reference
implementation, and package it as reference/test-runner-simple.  User
then could, with a simple code change, use it instead of the new
compliant runner.

I would even go as far as to provide a mechanism to select the runner by
environment, so GUILE_SRFI64_DEFAULT_TEST_RUNNER=reference would cause
test-runner-factory to return reference/test-runner-simple.  If unset or
empty value, it would use the new runner as it does now.  This will
allow restoring the previous output format even with no code changes.

Combined with NEWS entry, that could be sufficient?  What do you think?

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.