On Fri, 24 Sep 2021 07:49:44 -0700
Roy Mendelssohn - NOAA Federal via R-package-devel
wrote:
> All internet calls are wrapped in 'try()'. If that shows an error,
> I write a message to the screen about the error, and call stop(),
> perhaps with a further message in that call. Somehow this do
try/stop is in the operational code. But it is easy enough to make it so that
the code always returns something, even when there is an internet access
problem.
As I said, if "failing gracefully" and ever actually been defined with
examples life would have been much easier for a number of pac
I am trying solve an issue where my tests run fine when run with R CMD
check, but not with R CMD check --as-cran. In the tests pandoc is called
using system; pandoc then calls R again with a script which is part of
the package. The last part seems to fail, see error message below:
Running
Roy,
> All internet calls are wrapped in 'try()'. If that shows an error, I
> write a message to the screen about the error, and call stop(),
> perhaps with a further message in that call.
out of ignorance, i ask ...
in your package's operational code ("its API", or whatever), when a
required i
Not off-hand. it is weird that the only error is on Solaris. I do test on the
r-hub Solaris before submission. But at the same time, given some of the
responses that I have received (which I thank) I probably don't meet the CRAN
idea of "graceful". Easy enough for me to change as I am catch
Can you tell if the failure to download was due to a Solaris-specific issue
or due to the Solaris test machine not being fully connected to the
internet?
-Bill
On Fri, Sep 24, 2021 at 7:50 AM Roy Mendelssohn - NOAA Federal via
R-package-devel wrote:
> Hi All:
>
> I am getting dinged again on CR
Thanks to all who replied. I want to especially point out Maelle's response
because as I said I am not the first person to raise this question in terms of
accessing internet resources. Yes, graceful is in the eye of the beholder,
which i why such guidelines are really helpful.
-Roy
> On Se
On 24/09/2021 11:27 a.m., Roy Mendelssohn - NOAA Federal via
R-package-devel wrote:
Just so I am clear, I should not call stop(), but instead call a return() and
return something or other (there is nothing to skip to - it is doing a data
download and either it works or it failed). Is there
Grace is in the eyes of the beholder.
Using stop in your functions can be perfectly valid. But within the context of
examples or tests you need to catch those errors because one key definition of
success in normal building of a package is that no uncaught errors occur. So
either don't call thos
Hi,
Regarding Solaris, while the criteria is unknown, it seems Solaris can
be excluded from the CRAN check targets when there's a good reason not
to support Solaris. My package got a failure on Solaris check and I
resubmitted with the following comment, then Solaris disappeared from
the check resu
Just so I am clear, I should not call stop(), but instead call a return() and
return something or other (there is nothing to skip to - it is doing a data
download and either it works or it failed). Is there a preferred something to
return? And it is okay to write a message to the screen?
We've summarized some advice around graceful packages in this chapter of the
HTTP testing in R book: https://books.ropensci.org/http-testing/graceful.html I
hope this can help too!
Le ven., sept. 24, 2021 à 17:03, Ben Bolker a écrit: I
think you're not supposed to stop().
You shoul
I think you're not supposed to stop().
You should just proceed with the other tests (skipping any
tests/examples that depend on access to the inaccessible internet
resources, or values derived from the failing call, to work)
Does that help?
On 9/24/21 10:49 AM, Roy Mendelssohn - NOAA F
Hi All:
I am getting dinged again on CRAN (just Solaris for some reason), and the
problem is how to exit if there is a failure of accessing the resource, I know
it has been discussed here before, but I just am not understanding what is
desired to end properly. As I have been reminded:
'Pac
That is very helpful --- thank you
John
On Fri, 24 Sept 2021 at 17:42, Maëlle SALMON wrote:
> Hello,
>
> It's better to get rid of this NOTE, by listing bookdown in
> VignetteBuilder and Suggests, not Imports see
> https://blog.r-hub.io/2020/06/03/vignettes/#infrastructure--dependencies-for-vign
Dear Tomas,
> thanks. The new results are now available and the patches issue was resolved.
geat work, thank you!
>
> These results are still with MiKTeX 21.8, with some crashes (e.g. when
> building the documentation for R), but it seems dataquieR is not affected. I
> will downgrade to 21.6,
I had very hard time with this error. But I think I have solved it now.
I made several tests recently trying to identify where it came from.
This cryptic error was not random, I was able to reproduce it.
It only appeared on rhub Oracle Solaris 10, x86, 32 bit, R-release and not
on rhub Oracle So
17 matches
Mail list logo
