Small enhancement for CMD check

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.

It would be nice if the 00check.log file also included this part of the
output:
 Running ?bladder.R?
 Comparing ?bladder.Rout? to ?bladder.Rout.save? ... OK
 Running ?book1.R?
 Comparing ?book1.Rout? to ?book1.Rout.save? ... OK
 Running ?book2.R?
 Comparing ?book2.Rout? to ?book2.Rout.save? ... OK

etc.

 The survival package has enough test scripts that it exceeds my
terminal's scroll bar; I have to either watch closely or run
R CMD check survival >& mylog

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.

Terry Therneau

Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

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