I have found win-builder timings come close, but only close. My experience is
that the CRAN timings were uniformly slower than those on win-builder. But I
also find that I can get quite significant differences between
win-builder-release and win-builder-devel. So I also take the slowest that I
can find as a basis, and assume the actual times will be slower than that.
HTH,
-Roy
> On Nov 22, 2020, at 5:15 PM, Ben Bolker <bbol...@gmail.com> wrote:
>
> And one more (last for a while): presumably there is no way to check CRAN
> windows timing without submitting to CRAN ... ? (I will obviously do my best
> by doing arithmetic on the tests that I set to be skipped, but it would be
> nice to be able to double-check without wasting everyone's time ... I guess
> if I knew that CRAN submissions would *always automatically* be rejected with
> Windows test times>10 min, I could use CRAN submission itself as my test ...
> but maybe that's a bad idea?)
>
> On 11/22/20 4:06 PM, Uwe Ligges wrote:
>> Thanks Dirk. Yes, for lme4 the tests for each archiecture take longer than 5
>> min, so the overall check time exceeds 10 min.
>> So one can follow Dirk's advise.
>> As a general remark for others who will read this in the future:
>> tests should test the software, but it is generally not important to have
>> real world examples. Small data and few iterations are typically sufficient
>> for tests.
>> It is also possible to run less important tests only conditionally if some
>> environment variable is set that you only define on your machine.
>> Best,
>> Uwe Ligges
>> On 22.11.2020 20:36, Dirk Eddelbuettel wrote:
>>>
>>> On 22 November 2020 at 13:44, Ben Bolker wrote:
>>> | My current guess is that the problem is with the too-long check time
>>> on Windows (NOTE: "Overall checktime 18 min > 10 min")
>>>
>>> Yes.
>>> | I guess I have to get busy setting more tests and examples to
>>> skip-on-CRAN (kind of a pain as there's no low-hanging fruit - other than
>>> the 'testthat' tests, none of the individual test files take longer than
>>> 15sec, although this is doubled because they have to be run on 386 and x64
>>> ...)
>>>
>>> It's under your control. You can detect 'are we on Windows' and branch or,
>>> as
>>> I do with test runner I use, exit_file("...") based on such conditions.
>>>
>>> | An alternative is that this is a confusingly worded message indicating
>>> that there are strong rev dependencies so the package needs to be further
>>> checked? (That seems unlikely as it explicitly asks me to resubmit)
>>>
>>> No. If there were any (even false positive ones) they'd be listed there.
>>>
>>> Hth, Dirk
>>>
>
> ______________________________________________
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel
**********************
"The contents of this message do not reflect any position of the U.S.
Government or NOAA."
**********************
Roy Mendelssohn
Supervisory Operations Research Analyst
NOAA/NMFS
Environmental Research Division
Southwest Fisheries Science Center
***Note new street address***
110 McAllister Way
Santa Cruz, CA 95060
Phone: (831)-420-3666
Fax: (831) 420-3980
e-mail: roy.mendelss...@noaa.gov www: https://www.pfeg.noaa.gov/
"Old age and treachery will overcome youth and skill."
"From those who have been given much, much will be expected"
"the arc of the moral universe is long, but it bends toward justice" -MLK Jr.
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
