unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: Mike Gran <spk121@yahoo.com>,
	"guile-devel@gnu.org" <guile-devel@gnu.org>,
	Bruno Victal <mirai@makinata.eu>
Subject: Re: Replacing Guile test-suite with SRFI-64?
Date: Mon, 25 Sep 2023 11:48:11 +0200	[thread overview]
Message-ID: <15925236-be88-2fa2-beef-8ce4dc422507@telenet.be> (raw)
In-Reply-To: <766877546.3324008.1695598324070@mail.yahoo.com>


[-- Attachment #1.1.1: Type: text/plain, Size: 2708 bytes --]

Op 25-09-2023 om 01:32 schreef Mike Gran:
>> A benefit of SRFI-64 is that the SRFI-64 implementation has tests
>> whereas (IIRC) Guile's custom thing doesn't.
> 
> OK two separate issues.
> 1. Mike G's gripes about SRFI-64.
> 2. Updating over 65,000 lines of test code

These aren't separate issues -- if SRFI-64 is worse than what Guile has 
currently and SRFI-64 can't be improved to make it better, then that's a 
good reason

> I don't want to be put in the position of having to make a critique of
> SRFI-64, and, once my critique is dissected, make it
> appear that that is justification for updating the test suite.
> 
> I wouldn't be the decision maker, anyway.
This last sentence is irrelevant.

> It is 2 MB of test code that has served Guile well so far.

Nobody claimed that these 2MB hasn't served Guile well.  Instead, the 
proposal is about serving Guile better.  That things might be going well 
currently doesn't mean we can't do better.

Also, I dispute that it has served Guile well.  It is difficult to 
select which tests to run (it is easier to delete all the other tests 
than to find/remember the documentation stating how to do this), whereas 
with typical SRFI-64 test runners you can just set 
TESTS=some-scheme-file.scm.  Also test-suite/README is rather obsolete.

A more general problem is that Guile's test library is undocumented.

> I think the argument for srfi-64 is not self-evident. 

Nobody claimed it is self-evident -- instead, Bruno and I gave some 
explanation on how SRFI-64 can be better and didn't say ‘SRFI-64 better 
because duh SRFI-64, self-evident, no?’. (And conversely, you pointed 
out some problems with the current SRFI-64.)

> That
> srfi-64 is familiar to some and has a test suite does not prove
> that the current test suite is difficult for newcomers to understand
> and is buggy.

This message is weird -- you already made a (short) critique about 
SRFI-64, and nobody claimed ‘has test suite -> current test suite is 
difficult to understand / buggy’.  To be clear, this critique is the 
following message.

> IMHO, I think Guile should not depend too heavily on Guile for testing itself.
> It is bad bootstrapping practice.
> 
> And personally, I find that errors in srfi-64 tests are more difficult to interpret
> that errors in the guile test suite framework. The logging is worse.

And if it turns out to be justification for updating the test suite, 
then how would that be a bad thing?  After all, it would be justified.

(Also, which test suite are you talking about -- the test suite of 
SRFI-64, or Guile's test suite in its entirety?)

Best regards,
Maxime Devos.

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

  reply	other threads:[~2023-09-25  9:48 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-23 12:49 Replacing Guile test-suite with SRFI-64? Bruno Victal
2023-09-23 15:13 ` Mike Gran
2023-09-24 22:27   ` Maxime Devos
2023-09-24 23:32     ` Mike Gran
2023-09-25  9:48       ` Maxime Devos [this message]
2023-09-26  8:17         ` Taylan Kammer
2023-09-27 16:12           ` Taylan Kammer
2023-09-26 12:25   ` Bruno Victal
2023-10-31 13:20 ` Maxim Cournoyer

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=15925236-be88-2fa2-beef-8ce4dc422507@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=guile-devel@gnu.org \
    --cc=mirai@makinata.eu \
    --cc=spk121@yahoo.com \
    /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).