Re: Including SRFI-197

Tomas Volf <~@wolfsden.cz> writes: > I would assume the reason here is Automake. Exactly, we need some way to know which test harness we're using for each file, (test-suite lib) or (srfi srfi-64), and with the current arrangement, that ends up in in ./check.guile.in where we decide whether to run

Re: Including SRFI-197

Maxim Cournoyer writes: > Hi Rob, > > Rob Browning writes: > >> Rob Browning writes: >> >>> So for now I've attempted to just allow us to mix and match SRFI-64 and >>> (test-suite lib) based tests by integrating SRFI-64 into the existing >>> automake/check-guile arrangement via a suitable test

Re: Including SRFI-197

Hi Rob, Rob Browning writes: > Rob Browning writes: > >> So for now I've attempted to just allow us to mix and match SRFI-64 and >> (test-suite lib) based tests by integrating SRFI-64 into the existing >> automake/check-guile arrangement via a suitable test driver. > > I've pushed this prelimin

Re: Including SRFI-197

Hi, Rob Browning writes: [...] > I went ahead and moved SRFI-197 to the newer commit so we have the new > SPDX headers, but I also kept the license text in each file for now > under the assumption that I should stick to the current convention > until/unless Guile itself adopts SPDX. I think th

Re: Including SRFI-197

Maxim Cournoyer writes: > I'd recommend adding credits to the documentation too, as I had done for > example in the (unreviewed/unmerged) > series. Thanks, and done. I also put each "Additionally" license inside a @quotation block so it

Re: Including SRFI-197

Rob Browning writes: > So for now I've attempted to just allow us to mix and match SRFI-64 and > (test-suite lib) based tests by integrating SRFI-64 into the existing > automake/check-guile arrangement via a suitable test driver. I've pushed this preliminary support to main along with SRFI-197.

Re: Including SRFI-197

Rob Browning writes: > I was considering adding SRFI 197 > https://srfi.schemers.org/srfi-197/srfi-197.html, > i.e. "pipeline/threading operators". I've incorporated the reference > implementation, integrated the tests, and converted the documentation to > texinfo. Given the reponses, I've made

Re: Including SRFI-197

Maxim Cournoyer writes: >> Rob Browning writes: >> This does introduce some "noise" to the tests because it uses srfi-64 >> which writes to standard output by default. I imagine we might want to >> add a test-suite/lib specific srfi-64 reporter at some point. (Perhaps >> I'll look in to that la

Re: Including SRFI-197

Tomas Volf <~@wolfsden.cz> writes: > Honestly this is just under-specified in the SRFI-64. The full wording > of description for test-runner-test-name is: > >> Returns the name of the current test or test group, as a >> string. During execution of test-begin this is the name of the test >> group;

Re: Including SRFI-197

Hi, Mikael Djurfeldt writes: > Hi Rob, > > My personal view is that it would be great to include this. > > I guess the main underlying question is how "bloated" we want to make the > distribution. Your contribution is just 200 lines, so I think it is fine. > Of course, if we always say that...

Re: Including SRFI-197

Rob Browning writes: > And while looking at I wondered if I might have found a bug -- my > reading of the test-runner-test-name docs suggested that this might show > "outer group" for the final name:, but it still shows the test-assert > name. > > (define (show-name) > (format #t "name: ~a\

Re: Including SRFI-197

Hi Rob, My personal view is that it would be great to include this. I guess the main underlying question is how "bloated" we want to make the distribution. Your contribution is just 200 lines, so I think it is fine. Of course, if we always say that... My personal wish would be to have something

Re: Including SRFI-197

Maxim Cournoyer writes: > That's great. In case that could be useful for future ports, I had > devised a hacky script to automate the task to migrate the upstream html > documentation to texinfo, it's available here: > . Oh, that might

Re: Including SRFI-197

Maxim Cournoyer writes: > That would be a good idea. Or perhaps even use SRFI 64 for our test > suite, so that our SRFI 64 implementation is properly dog fooded and > self-documented via its use in the test suite. I briefly looked at this, and while not sure, I suspect there may be some things

Re: Including SRFI-197

Hi Rob, Rob Browning writes: > I was considering adding SRFI 197 > https://srfi.schemers.org/srfi-197/srfi-197.html, > i.e. "pipeline/threading operators". I've incorporated the reference > implementation, integrated the tests, and converted the documentation to > texinfo. That's great. In ca

Re: Including SRFI-197

Hi Rob, Rob Browning writes: > Rob Browning writes: > >> I've incorporated the reference >> implementation, integrated the tests, and converted the documentation to >> texinfo. > > This does introduce some "noise" to the tests because it uses srfi-64 > which writes to standard output by default

Including SRFI-197

I was considering adding SRFI 197 https://srfi.schemers.org/srfi-197/srfi-197.html, i.e. "pipeline/threading operators". I've incorporated the reference implementation, integrated the tests, and converted the documentation to texinfo. I'm not posting the patches here right now due to their rela

Re: Including SRFI-197

Rob Browning writes: > I've incorporated the reference > implementation, integrated the tests, and converted the documentation to > texinfo. This does introduce some "noise" to the tests because it uses srfi-64 which writes to standard output by default. I imagine we might want to add a test-sui