[gambit-list] Tests, docs, reflection, CI
Lassi Kortela
lassi at lassi.io
Sat Nov 2 05:21:45 EDT 2019
>> A lot of SRFIs don't have many tests. It might be nice to gather a big,
>> up-to-date test suite for all SRFIs.
>
>> Or keep up-to-date tests in each SRFI's repo with the sample implementation.
>
> That will be nice.
The problem with updating test in SRFI sample implementations is that we
would probably need permission from each SRFI's author, and we probably
can't reach most of them to approve new code. Some popular SRFIs are
almost 20 years old.
It might be good for Scheme implementors to create a common test repo on
GitHub or GitLab and gather tests for lots of different SRFIs there. It
would also be an opportunity to use the same testing framework for all
of them. I'll start a thread about this on srfi-dicsuss.
>> the SRFI is the documentation.
>
> We already discussed that matter in SRFI schemedoc mailing list. We
> disagree. In my opinion, SRFI documents are not user documentation.
> Simply refering gambit user to the SRFI document is not good enough. A
> proper implementation documentation will need examples uses, a useable
> comment system. And also systematic documentation of all forms. Unlike
> some SRFI document like (scheme mapping) aka. SRFI-146 that bolt
> together (scheme mapping) and (scheme mapping hash) together (see
> https://srfi.schemers.org/srfi-146/)
Those are good points. Perhaps it would be better to rely on a
Scheme-wide documentation site for this stuff instead of Gambit (and
every other Scheme) having its own detailed documentation for each SRFI.
It would take a lot of effort and pressure off Scheme implementors.
The <https://clojuredocs.org/> and <https://www.php.net/> facility where
users can post comments to supplement the official documentation is
nice. Perhaps a Wiki would be even better. The
<https://srfi-email.schemers.org/schemedoc/> list is probably the best
place to discuss this.
>> Most of the SRFI implementations from udem-dlteam/libs will probably be
>> merged into Gambit's main repo once they have been tested enough; libs
>> is mostly for work-in-progress stuff.
>
> It will be easier if that was a draft pull-request against gambit
> repository. It will help with discovery and it will also take
> advantage of gambit repository Continuous Integration.
They're in a separate repo instead of a PR so we can do:
gsi -:whitelist=github.com/udem-dlteam/libs
A GitHub pull request corresponds to a Git branch in someone's fork of
the Gambit repo. In principle, the module system ought to be able to
download that branch instead of the master branch. I don't know whether
anyone has tried this.
Gambit's CI builds all of Gambit (gsc and gsi) which does quite a bit
more work than just building some SRFI implementations. Eventually, once
the SRFI implementations are optimized for Gambit, it makes sense to
build them with Gambit and rely on the CI.
> I don't like SRFI 64. It is impossible to run a single test with
> SRFI-64. I am looking forward an introspection or reflection library
> system (something like guile or chez does) so that it is possible to
> run a single test where a test are procedures.
That probably doesn't require reflection; just a command-line flag for
the test runner to specify which tests to run or which to skip.
Reflection would probably help with running tests in a running gsi from
Emacs using Geiser.
SRFI 64 is popular so we should to have it. That doesn't mean we can't
have other APIs as well. For example, (chibi test) is also popular so it
would be good to have. It's best if all these different test APIs can be
implemented using Gambit's native API.
> See `library-exports` at
> https://github.com/amirouche/arew-scheme/blob/master/make-check.scm#L22
>
> I already tried to use SRFI-64, at the very minimum it requires to
> wrap `test-fu` forms inside a procedure like chibi scheme does.
Not sure what to do about this.
Trying with tab completion in gsi, Gambit already has things like:
##procedure?
##procedure-friendly-name
as well as the ##symbol-table used in the apropos. You might be able to
put something together using the primitives that are already there.
More information about the Gambit-list
mailing list