xxxxxx@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> - It doesn't attempt to record line numbers itself, [...]
> - It doesn't litter your working directory with a log file [...]

I'd like to give an update on this.

After all, both source location information (file and line number), and
logging to a log file, have been implemented now.  I figure the former
is pretty useful when tests have repetitive names or no names for some
reason, and the latter might be important for some workflows.

Source info was tricky to get right across Kawa and Guile, but I managed
to avoid horrid hacks and the result is pretty clean.  Other systems
will have to see if either the Kawa or Guile way of doing it works for
them, and hook themselves into the 'source-info' macro accordingly.

(In the absolute worst case, where an implementation just *needs* a
syntax-case macro to be able to save the source location at which it's
invoked, I can still imagine a decent solution of using a macro-defining
macro, like 'define-syntax/source-location', which defines a syntax-case
macro where supported, which does said source location recording, and a
syntax-rules one without source location recording otherwise.)

Log file support is implemented without breaching the specification.
The runner returned by (test-runner-simple) doesn't do logging by
default, and doesn't use its "aux value" field, as specified.  However,
using test-begin (or test-group) without installing a runner first will
install a modified simple-test-runner that does logging.  (This logging
can also be enabled on a simple-test-runner via 'test-runner-log-file!',
a non-standard extension.)  Thus the original implementation's behavior
is imitated in the most usual case, and pedantic conformance to the spec
is upheld.

I also noticed that big macro bodies were blowing code size through the
roof, making compile times suffer, and that was likely also the reason I
hit the code size limit on Kawa.  This has been fixed now.  After some
tweaks I was finally able to go through Kawa's test suite with this
implementation, and couldn't spot any failures that seemed obviously
related to the SRFI-64 implementation.

Furthermore the code is split into sub-libraries that are pretty easy to
understand in isolation.  See the *.body.scm files:

    https://github.com/TaylanUB/scheme-srfis/tree/master/srfi/64

I am now very happy about the state of this again.

Taylan