unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Tomas Volf <~@wolfsden.cz>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 74385@debbugs.gnu.org, Janneke Nieuwenhuizen <janneke@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	[thread overview]
Message-ID: <875xnnmuu0.fsf@wolfsden.cz> (raw)
In-Reply-To: <87ed2gn60u.fsf@gnu.org> ("Ludovic Courtès"'s message of "Mon, 09 Dec 2024 18:02:57 +0100")

[-- Attachment #1: Type: text/plain, Size: 1915 bytes --]

Ludovic Courtès <ludo@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@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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 853 bytes --]

  reply	other threads:[~2024-12-13 16:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-16 17:39 bug#74385: [PATCH 0/4] Patches for SRFI-64 Tomas Volf
2024-11-16 17:42 ` bug#74385: [PATCH 1/4] srfi-64: Fix maybe-print-prop Tomas Volf
2024-11-16 17:42   ` bug#74385: [PATCH 2/4] srfi-64: Use ~s when printing some properties Tomas Volf
2024-11-16 17:42   ` bug#74385: [PATCH 3/4] srfi-64: Export define-equality-test Tomas Volf
2024-12-09 17:01     ` Ludovic Courtès
2024-12-13 16:16       ` Tomas Volf
2024-11-16 17:42   ` bug#74385: [PATCH 4/4] srfi-64: Report failed tests in (standards)Errors format Tomas Volf
2024-12-09 17:02     ` Ludovic Courtès
2024-12-13 16:05       ` Tomas Volf [this message]
2024-12-09 17:04   ` bug#74385: [PATCH 1/4] srfi-64: Fix maybe-print-prop Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875xnnmuu0.fsf@wolfsden.cz \
    --to=~@wolfsden.cz \
    --cc=74385@debbugs.gnu.org \
    --cc=janneke@gnu.org \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).