[R-pkg-devel] new package submission: "check log incomplete, web timeout?"
jdv at base2bio.com
Mon Apr 24 05:43:06 CEST 2017
>A completely different alternative, is to have a way to disable
>parallel processing in your examples / tests / vignettes, e.g. if (np
>== 1) registerDoSEQ() else registerDoParallel(np). Personally, I'm
>not a big fan of that approach because it's an ad-hoc workaround and
>you're end up not testing all of your package.
Supporting parallel processing has already caused me untold headaches as
a not-overly-fluent R user (including over an hour on Friday try to
figure out why my Windows tests were hanging indefinitely -- had to add
"Sys.unsetenv("R_TESTS") to the top of my test script which I still
don't understand). However, I would consider it an important feature of
the package where actual usage typically involves modeling data from
thousands of proteins, each of which can be bootstrapped up to 20 times.
For this reason, I also don't like the idea of "testing around" the
issue. While I don't use Windows myself, it doesn't make sense to claim
my package runs on Windows if it is going to randomly freeze up for
users on that platform.
I will ask Uwe Ligges to re-check my submission as you suggested. I
would really like to get this past the pre-check stage so I can start
dealing with the issues that I'm sure will come up in the human review.
>Hope this helps
>On Sun, Apr 23, 2017 at 9:17 AM, Jeremy Volkening <jdv at base2bio.com> wrote:
>> On Sun, Apr 23, 2017 at 10:17:01AM +0200, Alexandre Courtiol wrote:
>>> Could it be that one your computer you can build vignettes quickly thanks
>>> to some caching of the knitr chunk output but that it takes too much time
>>> building that without the cache...? ... CRAN does not like when
>>> anything takes more than a few seconds...
>> Thanks for the reply. The vignettes do take a little time to build, as the
>> knitr code is doing some modeling, but I wouldn't have thought it excessive.
>> According to the logs from the win-builder service, it took 28s (about the
>> same as each of the i386 and x64 tests). Is this too long for the CRAN
>> submission service? I've already pruned down my example data to just a
>> couple of samples instead of the thousands normally modeled in a session.
>> If this is indeed the issue, do I need to remove the knitr code and just
>> include static images of the output plots in the vignette? This would seem
>> to go against most of the recommendations I have read from various sources
>> on best practice.
>>> On 23 April 2017 at 05:08, Jeremy Volkening <jdv at base2bio.com> wrote:
>>>> I am trying to submit a package to CRAN for the first time. I have gone
>>>> through testing on my own machines (Linux, Windows x64, Windows i386), on
>>>> Travis CI and using win-builder. All tests are now passing on all of
>>>> platforms. However, when I try to submit the package to CRAN I get an
>>>> that the pre-test has failed, with the following line:
>>>> Status: NA (check log incomplete, web timeout?)
>>>> The pre-test link is here: https://win-builder.r-project.
>>>> If I check the '00check.log' file I can see that it ends with the line "*
>>>> checking re-building of vignette outputs ...", so apparently the test is
>>>> quitting before it finishes this step. I'm not sure how to proceed, since
>>>> everything is working for all of my own manual tests (as well as
>>>> win-builder). See the log for my manual submission of exactly the same
>>>> package to win-builder, which passes:
>>>> Any help would be greatly appreciated. The package itself can be found
>>>> R-package-devel at r-project.org mailing list
>>> Alexandre Courtiol
>>> *"Science is the belief in the ignorance of experts"*, R. Feynman
>> Nothing so needs reforming as other people's habits.
>> -- Mark Twain, "Pudd'nhead Wilson's Calendar"
>> R-package-devel at r-project.org mailing list
Few things are harder to put up with than the annoyance of a good example.
-- "Mark Twain, Pudd'nhead Wilson's Calendar"
More information about the R-package-devel