On 12/14/2012 9:32 AM, Dirk Eddelbuettel wrote:
On 14 December 2012 at 18:19, Uwe Ligges wrote:
|
|
| On 14.12.2012 18:11, Dirk Eddelbuettel wrote:
| >
| > On 14 December 2012 at 18:07, Uwe Ligges wrote:
| > | without overhead of packages. The CRAN check times of > 4000 packages
| > | are typically a good indicator, and they are a bit slower for R-2.15.2
|
| Please do not quote only parts of my sentences, that one was continued:
|
| "but not that it is generally worrying (since we also run more checks)."
I understand the resource constraint, but the fact remains that on the CRAN
side most-visible package I am involved with now runs _way fewer_ tests than
it used to, making these very comparisons across time a little tricky.
Rock, meet hard place. In an ideal world we had way more tests, and
comparisons among them. But time is, alas, finite...
This raises again the question of why the CRAN resources are so
constrained?
I don't know the answer to that, but I assume it's because the
current CRAN maintainers would rather force package maintainers to turn
off tests than recruit help to fix the resource constraints in other
ways. I just fit a log-logistic model using drm{drc} to the number of
CRAN packages using data from John Fox (2009) "Aspects of the Social
Organization and Trajectory of the R Project", R Journal
(http://journal.r-project.org/archive/2009-2/RJournal_2009-2_Fox.pdf),
with some points I added with more recent data.
From this model fit, I estimate the doubling time for the number
of CRAN packages at roughly 4.5 years. This is triple the historic 18
month speed improvements achieved since 1971 and is still 1.5 times the
3 year doubling time for number of transistors per chip forecasted by
the 2010 update to the International Technology Roadmap for
Semiconductors (Wikipedia, "Moore's Law"). From this, I infer that a
reasonable replacement schedule for hardware in the current CRAN server
farm should be able to solve this problem and release this constraint on
CRAN test time.
Jim Ramsay suggested that if money is a constraint, he has grant
money that could pay some nominal fee for CRAN usage provided he could
get an invoice. CRAN could still be free for anyone without the ability
to easily pay such, like page charges in many journal. However, his
grant money can NOT be used to make contributions.
A "CRAN" function has been added to the "fda" package to test to
see if it was running "--as-cran"; we use this to skip tests if TRUE.
Ramsay and I are with Dirk: We wish there were a way to release this
compute time constraint on CRAN. However, we have so far been unable to
get information on the source of that constraint. (R-Forge is similarly
a very valuable service with other known problems, also with unknown
causes.)
Best Wishes,
Spencer
Dirk
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
