Re: [Rd] CRAN test / avoidance

2012-09-19 Thread Hadley Wickham
 The question becomes: how does information get passed along to indicate
 things that may take a long time to run. The discussion so far has focused
 on developers setting, or using, some flags to indicate tests and examples
 that take a long time. Another option would be to have the check/build
 process generate a file with information about the time it took to run
 tests, vignettes, and examples, probably with some information about the
 speed of the machine it was run on. Then CRAN and anyone else that wants to
 run tests can take this information into consideration.

To paraphrase Uwe (fortunes::fortune(192)): computing is cheap and
thinking hurts.

I don't understand why we are spending so much time discussing what
probably amounts (at most) to a couple of thousand of dollars of
compute time.

Hadley

-- 
RStudio / Rice University
http://had.co.nz/

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] CRAN test / avoidance

2012-09-19 Thread Spencer Graves

On 9/19/2012 11:51 AM, Hadley Wickham wrote:

The question becomes: how does information get passed along to indicate
things that may take a long time to run. The discussion so far has focused
on developers setting, or using, some flags to indicate tests and examples
that take a long time. Another option would be to have the check/build
process generate a file with information about the time it took to run
tests, vignettes, and examples, probably with some information about the
speed of the machine it was run on. Then CRAN and anyone else that wants to
run tests can take this information into consideration.

To paraphrase Uwe (fortunes::fortune(192)): computing is cheap and
thinking hurts.

I don't understand why we are spending so much time discussing what
probably amounts (at most) to a couple of thousand of dollars of
compute time.



  I raised the question, because CRAN maintainers rejected the 
latest version of fda because some of the examples took too long to 
run on their computers.



  Spencer



Hadley




--
Spencer Graves, PE, PhD
President and Chief Technology Officer
Structure Inspection and Monitoring, Inc.
751 Emerson Ct.
San José, CA 95126
ph:  408-655-4567
web:  www.structuremonitoring.com

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel