On Mon, 2011-02-28 at 16:57 +0000, Prof Brian Ripley wrote: > Unfortunately it would need a major rewrite, and either piping output > through a pager (surely the standard Unix way to handle this) or > redirecting to a file is the simplest way to do this. > > R CMD check calls a process to run .runPackageTestsR, which calls > further processes to run each test and diff the results. We could > simply capture stdout/stderr of .runPackageTestsR, but then one would > have to wait until all the tests had run before seeing any output, > which may mean waiting hours -- that was decided to be too > undesirable.
Fair enough. My request was of the "if it's easy to do...." class. Thanks for looking. (On Unix you could avoid the wait by using tee, BTW) > The most prolix are > survival portfolio matlab kappalab spatstat > 68 36 32 30 28 > BB HSAUR2 fields pcalg aster > 26 22 22 22 21 > > The remedy seems to be to group the tests into larger units. It appears that I'm an outlier. I certainly didn't start thinking that there would be so many tests. But whenever I track down a new bug in response to a user I'll have created some code to isolate and define the error first, and then more lines to verify the fix; I usually find the extra 15-20 minutes to 'formalize' this and add it to the test suite to be a good investment. Hopefully the 68 is taken as a measure of longivity of the package and not of bad programming skills! Terry T ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
