On 12-09-03 11:18 AM, Martin Maechler wrote:
Dirk Eddelbuettel <e...@debian.org> on Mon, 3 Sep 2012 09:34:06 -0500 writes:> On 3 September 2012 at 00:49, Henrik Bengtsson wrote: > | Hi, see thread "[Rd] Proposal: Mechanism for controlling the amount of > | testing 'R CMD check' performs" on April 8, 2012: > | > | https://stat.ethz.ch/pipermail/r-devel/2012-April/063809.html > Good proposal, somehow I missed that at the time. > Something like this ought be to implemented in R proper. I agree.... but the CRAN maintainers have to agree too. > In Rcpp, I am now using a similar > environment-variable-based approach, and it doesn't scale > particularly well if every (large) package does its own thing. yes, my packages do their own thing too, now, e.g., Matrix (not yet released): doExtras <- interactive() || nzchar(Sys.getenv("R_MATRIX_CHECK_EXTRA")) || identical("true", unname(Sys.getenv("R_PKG_CHECKING_doExtras"))) and then I use if(doExtras) { .... } but I agree with Henrik that it would make sense to have more than just two levels for the amount of testing, not just for CRAN. An additional, slightly more interesting feature request that you may also want in these cases, is the following: Assume, that we have a function testingLevel() and the following code should only be run, if the testing level is 2 or higher if(testingLevel() > 2) { .......1 .......2 ........ ........ .......n } Now what we all really wanted was that the ........ code ran just as in toplevel. While I think that's almost impossible, as the .....1 to .....n must first be parsed all, and then evaluated (which is already different from top level), I would at least want that the auto-printing worked like in toplevel, so I don't have to write a print(.) around every ......i that would autoprint if in toplevel, and of course does *not* autoprint inside if(.) { .. }.
I prefer the current scheme where individual tests can be turned on and off. The space of tests is a 2^N factorial space, not a chain of n possible levels.
The only problem I see with the current scheme is that code being tested can't find out which tests are being run. In some cases, that's fine: there's no point in example code knowing about tests for consistency between documentation and implementation. In other cases it might even be a good thing: do you want packages to be able to hide dependencies on non-CRAN packages, for example?
Duncan Murdoch ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
