[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