Email list hosting service & mailing list manager

Gathering comprehensive SRFI test suites in one place Lassi Kortela (26 Jan 2020 15:12 UTC)
Re: Gathering comprehensive SRFI test suites in one place Lassi Kortela (26 Jan 2020 15:15 UTC)
Re: Gathering comprehensive SRFI test suites in one place Lassi Kortela (26 Jan 2020 17:13 UTC)
Re: Gathering comprehensive SRFI test suites in one place Lassi Kortela (26 Jan 2020 17:25 UTC)
Re: Gathering comprehensive SRFI test suites in one place Peter Bex (26 Jan 2020 17:56 UTC)
Re: Gathering comprehensive SRFI test suites in one place Lassi Kortela (26 Jan 2020 18:48 UTC)
Re: Gathering comprehensive SRFI test suites in one place Lassi Kortela (26 Jan 2020 19:28 UTC)
Re: Gathering comprehensive SRFI test suites in one place Lassi Kortela (26 Jan 2020 20:01 UTC)
Re: Gathering comprehensive SRFI test suites in one place Lassi Kortela (26 Jan 2020 20:22 UTC)
Re: Gathering comprehensive SRFI test suites in one place Per Bothner (26 Jan 2020 19:33 UTC)
Re: Gathering comprehensive SRFI test suites in one place Lassi Kortela (26 Jan 2020 19:49 UTC)
Re: Gathering comprehensive SRFI test suites in one place Per Bothner (26 Jan 2020 20:03 UTC)
Re: Gathering comprehensive SRFI test suites in one place Lassi Kortela (26 Jan 2020 20:11 UTC)
Re: Gathering comprehensive SRFI test suites in one place Per Bothner (26 Jan 2020 20:22 UTC)
Re: Gathering comprehensive SRFI test suites in one place Lassi Kortela (26 Jan 2020 20:31 UTC)
Re: Gathering comprehensive SRFI test suites in one place Arthur A. Gleckler (26 Jan 2020 17:50 UTC)

Re: Gathering comprehensive SRFI test suites in one place Peter Bex 26 Jan 2020 17:56 UTC
On Sun, Jan 26, 2020 at 07:25:10PM +0200, Lassi Kortela wrote:
> Could we get away with not putting the tests in libraries at all, and
> instead having each SRFI's in a "123.scm" file that must be run as a
> top-level program?

I think that would work.

> Didn't Chicken 5 also switch from (use ...) to (import ...) as its main
> library importing mechanism?

Yep!

On Sun, Jan 26, 2020 at 07:13:26PM +0200, Lassi Kortela wrote:
> > I'm reasonably happy with
> > the "test" egg in CHICKEN and it's simple, but its implementation is
> > kinda messy and reporting is not so easily customizable (that I know of).
>
> You know about its Chibi-Scheme re-implementation, right? It should be
> approximately portable, at least among R7RS Schemes.
> <http://snow-fort.org/s/gmail.com/alexshinn/chibi/test/0.7.3/index.html>

I didn't know about it until now.

> I looked into the SRFI 64 Chicken egg a while back. That code is also messy
> because it's a lightly edited version of the sample implementation with
> cond-expands for (possibly obsolete) versions of various Schemes.
>
> We could take this opportunity to clean all of those libraries up :)

Excellent!

> > It would also ease automated CI across Schemes, for example.
>
> That would be totally awesome! But I'm not sure it makes a different for
> that purpose which testing library or API is used.

I was thinking about something like Perl's Test Anything Protocol (TAP),
which I've not really looked into much detail.  It doesn't look very
popular, and for example the Python implementation is really ugly and
I haven't encountered it so far.

Perhaps I'm overthinking things, though.

> As long as there's a simple "run all tests" command
> or procedure that emits a test report in a standardized format, it can
> support several different APIs for specifying tests.

Yeah that's true.

> What I've done in the past is to write a trivial program that reads the
> Scheme file with the R7RS library and writes an equivalent file for R6RS.

Suits me fine, but like I said I don't care about R6RS.  Onwards!

Cheers,
Peter