> From: Lassi Kortela <xxxxxx@lassi.io>
> Date: Thursday, August 20, 2020 1:59 PM
>
> Thanks for the initiative Harold!

You're welcome.

> I'm pressed for time, but quick comments:
>
> [ We agree that testing in Scheme needs a bit of work. ]
>
>> It's also a special case for SRFIs, ideally the sample
>> implementations will always have a test suite, and for many SRFIs this
>> could be the only non-standard, higher numbered SRFI they depend on.
>
> https://github.com/srfi-explorations/srfi-test is a repo I started a
> while back to collect tests for as many SRFIs as we can in one place.
> The tests in that repo use the SRFI 64 test definition primitives....

This dovetails with my first objective for Schemetest, making versions
of SRFI 64 for "as many Scheme implementations as practical" in
https://github.com/Schemetest/srfi-64-implementations.  I'm working on
Chibi Scheme at the moment, but help right now for other Scheme
implementations and other test libraries would be very welcome.

> The ultimate idea would be that the repo can have the test suites in a
> format that Scheme implementations can simply copy those files verbatim
> into their source trees. Doing whatever it takes to get them into a form
> that implementors find agreeable. (include "...") in (define-library)
> does wonders to enable portable .scm files. I haven't yet had the energy
> to pursue this since there are so many things to do, but it'd be awesome
> if you do. Aggregating the tests already uncovered a bunch of bugs; I
> expect doing it more would uncover more and save everyone time in the
> long run.

Not sure it's going to be on my personal TODO list ever, and probably
not anytime soon, e.g. my rudely interrupted Schemepersist sdbi
project comes first, and there's a bunch of things before that.  But I
put that in https://github.com/Schemetest/website/blob/master/TODO.txt.

And it's implicitly congruent in shaking out bugs in SRFI 64 setups;
right now I'm working on the SRFI bundled Meta-Test Suite for that.

> [ +1 GitHub Schemetest organization created. ]
>
> [...]
>
>> First question: how to subdivide the space of testing libraries and
>> Schemes they run on.  A general repo, page, or file can be consulted to
>> tell you "if you want to use SRFI 64 in Chibi Scheme, then use /this/
>> library", rather than having a repo or sub-directory per implementation
>> with messy duplication.  So ... no great reason not to do it in grab bag
>> fashion, after people's names or user ids, or whatever???

Your answers below are very useful, but I failed to communicate what I
need *today*; how to create a sane SRFI 64 repo tree.  E.g. at the
moment the best I could come up with is:

srfi-64-implementations/chibi-scheme/lib-per.bothner and lib-taylan.

But sooner or later artifacts in the above will need to be shared with
other Scheme implementations, etc. etc.

> [ Lassi's take on dominate testing frameworks. ]
>
> - SRFI 64

For the moment, the only one I'm personally focusing on, after having
used and liked (chibi test) a lot, but also found it limiting, even
before I started delving into SRFI 64 due to Marc providing a neat
test suite for the WIP plist SRFI.

> [ Details on SRFI 64, issues, maybe a new SRFI, etc. ]

All stuff I might contribute to, but have no informed opinions on yet,
and only relevant to Schemetest's starting goal WRT prioritization.

>> Anyone out there interested in this who's already running a bunch of
>> different Scheme implementations so we can do some testing?  If not,
>> I've got a bit of spare time to devote to that.
>
> We have Docker containers for 45 Scheme implementations at
> <https://hub.docker.com/u/schemers>, including a container build
> from git master for many of the actively developed Schemes. I can
> give ssh access to people I know from the lists to a Linux server
> with Docker pre-configured.

Thanks, I'd forgotten about that.

- Harold