From therneau at mayo.edu  Mon Feb 28 19:29:23 2011
From: therneau at mayo.edu (Terry Therneau)
Date: Mon, 28 Feb 2011 12:29:23 -0600
Subject: [Rd] Small enhancement for CMD check
In-Reply-To: <alpine.LFD.2.02.1102281641400.19979@gannet.stats.ox.ac.uk>
References: <1298658255.4670.64.camel@punchbuggy>
	<alpine.LFD.2.02.1102281641400.19979@gannet.stats.ox.ac.uk>
Message-ID: <1298917763.15393.27.camel@punchbuggy>

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



[Rd] Small enhancement for CMD check
Terry Therneau