GNU bug report logs - #48442
[PATCH] Use a better SRFI-64 implementation

Previous Next

Package: guile;

Reported by: Taylan Kammer <taylan.kammer <at> gmail.com>

Date: Sat, 15 May 2021 14:17:02 UTC

Severity: normal

Tags: patch

To reply to this bug, email your comments to 48442 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guile <at> gnu.org:
bug#48442; Package guile. (Sat, 15 May 2021 14:17:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Taylan Kammer <taylan.kammer <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-guile <at> gnu.org. (Sat, 15 May 2021 14:17:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Taylan Kammer <taylan.kammer <at> gmail.com>
To: bug-guile <at> gnu.org
Subject: [PATCH] Use a better SRFI-64 implementation
Date: Sat, 15 May 2021 16:16:25 +0200
[Message part 1 (text/plain, inline)]
Tag: patch


Hi Guilers,

I've posted this to guile-devel already but thought I'd make it a
debbugs ticket to ensure it doesn't get forgotten and because I
made another minor improvement to the implementation. :-)

The first attached patch changes the SRFI-64 implementation shipped
with Guile to the one from the Scheme-SRFIs project.[0]

This implementation has the following advantages:

* Compile times of test suites reduced to less than half. [1]
  This can be quite significant for large test suites.  The one of
  the scheme-bytestructures project is merely a file of less than
  300 tests and yet takes about 9.5s to compile with the old SRFI-64
  implementation on a very modern CPU (Ryzen 9 3900X), and about
  4.5s with the new implementation.  (Using Guile 3.0)

* Modular, clean code using modern Scheme features.  While "clean"
  code may be a subjective thing without concrete, agreed-upon
  criteria, I would implore you to simply take a look at the old
  implementation and compare it to the new one.  I'm confident that
  the new implementation is significantly easier to reason about and
  modify if needed.

* The default test runner outputs results in a format familiar to
  users of GNU software and makes it easier to identify which tests
  failed when they occur in nested test groups.

* The implementation is more conformant to the specification than the
  reference implementation.  In the reference implementation, the
  test runner returned by 'test-runner-simple' uses the 'aux' field
  for a log file, meaning that a user extending the simple test runner
  may not use the aux field.  The spec also says that the runner
  returned by 'test-runner-simple' does no logging.

* Offers a small number of extensions to the standard:
  1. The 'test-runner-simple' procedure takes an optional argument
     that specifies the name of a log file.  (A sane default is chosen
     if the user does not explicitly install any test runner.)  This
     does *not* use the 'aux' field of the runner.
  2. The 'test-read-eval-string' procedure takes an optional argument
     to specify an environment argument to be passed to 'eval'.
  3. The new procedure 'test-exit' exits the running Scheme program,
     with an exit status indicating whether there have been any
     failures or unexpected passes.

* Fixes a pair of bugs that still exist in the old implementation:
  1. https://bugs.gnu.org/21181  "Possible bug in test-group"
  2. Reported via IRC: per specification, test-end should remove any
     test runner that was installed automatically by test-begin.


There is one incompatibility with the old implementation:

* The reference implementation exports a non-standard variable called
  'test-log-to-file' which can be set to #false to disable the logging
  performed by the default test runner.  In the new implementation,
  the same effect can be achieved by explicitly installing the simple
  test runner without providing the optional log-file argument:
  (current-test-runner (test-runner-simple))


So far I've had positive feedback over, with one person saying that
they've been recommending this implementation to everyone.


One might think that the reference implementation is more stable as
it has been around longer, but the very long-standing bugs in it
prove this wrong in my opinion.  I believe that the convoluted way
the code is written invites programmer mistakes and discourages
people from trying to find and fix bugs.


The second attached patch contains a small number of additions to
the SRFI-64 meta-test-suite that tests the SRFI-64 implementation.


With kind regards,

Taylan


[0] https://github.com/TaylanUB/scheme-srfis
[1] https://lists.gnu.org/archive/html/guile-devel/2021-05/msg00007.html
[0001-Use-a-different-SRFI-64-implementation.patch (text/plain, attachment)]
[0002-Augment-SRFI-64-test-suite.patch (text/plain, attachment)]

This bug report was last modified 3 years and 228 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.