Re: [R-pkg-devel] Testing for a Specific R Error

2017-12-02 Thread Duncan Murdoch 

On 02/12/2017 2:19 PM, Bill Denney wrote:



On Dec 2, 2017, at 09:43, Duncan Murdoch  wrote:

I don't think there's anything better than Bill's solution, though I imagine it is 
possible to ask for translation of the message.  For example, sqrt(-1) currently gives a 
warning with English message "NaNs produced".


Another idea just occurred to me.  Get the current error text as I'm expecting 
it from R by generating the error in a tryCatch and then test for equality to 
that string.  With that, changes in R (or other packages) would be 
automatically updated, and it would still be a precise test for the error I'm 
wanting to confirm in my test:

tryCatch(as.data.frame(structure(1, class="foo")), error=function(e) e$message)

Capture the output of that tryCatch and test for equality.

Then, it will be robust to language changes and to changes in R or other 
packages.

I'm going to implement that unless someone indicates something that I'm missing.


That sounds like a really good idea.  It should work in your use case, 
though in cases where the error message includes information about the 
arguments that led to the error (e.g. vignette("foobar") says "vignette 
‘foobar’ not found" in English and "vignette ‘foobar’ introuvable" in 
French) it might be harder.


Duncan Murdoch



Thanks,

Bill



I can ask to translate that into the current session language using

gettext("NaNs produced", domain = "R")

Figuring out the right thing for "domain" is likely a little painful: it 
depends on which package produced the message, and how.

I don't know if CRAN tests would complain if you tested for equality between a 
warning message and the result of gettext():  it's still true that if the 
English warning changed, the test would fail.

Duncan Murdoch


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

Re: [R-pkg-devel] Testing for a Specific R Error

2017-12-02 Thread Bill Denney 

> On Dec 2, 2017, at 09:43, Duncan Murdoch  wrote:
> 
> I don't think there's anything better than Bill's solution, though I imagine 
> it is possible to ask for translation of the message.  For example, sqrt(-1) 
> currently gives a warning with English message "NaNs produced".

Another idea just occurred to me.  Get the current error text as I'm expecting 
it from R by generating the error in a tryCatch and then test for equality to 
that string.  With that, changes in R (or other packages) would be 
automatically updated, and it would still be a precise test for the error I'm 
wanting to confirm in my test:

tryCatch(as.data.frame(structure(1, class="foo")), error=function(e) e$message)

Capture the output of that tryCatch and test for equality.

Then, it will be robust to language changes and to changes in R or other 
packages.

I'm going to implement that unless someone indicates something that I'm missing.

Thanks,

Bill

> 
> I can ask to translate that into the current session language using
> 
> gettext("NaNs produced", domain = "R")
> 
> Figuring out the right thing for "domain" is likely a little painful: it 
> depends on which package produced the message, and how.
> 
> I don't know if CRAN tests would complain if you tested for equality between 
> a warning message and the result of gettext():  it's still true that if the 
> English warning changed, the test would fail.
> 
> Duncan Murdoch

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

Re: [R-pkg-devel] adding rPython as a suggested package

2017-12-02 Thread Bruce Hoff 
Hi:

Just a comment tangentially related to this topic:  There are a number of R
packages for calling Python from R, including the "rPython" and
"reticulate" packages mentioned in this thread.  Another is "PythonInR".  (
https://cran.r-project.org/web/packages/PythonInR/index.html).  These
packages address the problem of invoking a Python module or package which
is installed on the user's machine.  I.e., they answer the question, "How
can I access from R a suite of useful Python tools I have configured in my
workspace?"  There is a complementary question, "How can I expose in an R
package specific functionality written in Python?"  In the latter case the
Python function is written specifically for the R package and the R package
should be *isolated* from any installed Python environment.  The package
should not change any installed Python environment and anything you do in
Python should not affect how the R package executes.

We have addressed this second problem with a package PythonEmbedInR (
https://github.com/Sage-Bionetworks/PythonEmbedInR).  This is a
modification of PythonInR which *embeds* a hidden/private copy of Python 3
within the R package, totally isolated from any other Python runtime
concurrently installed on the machine.  Further it works *cross platform*
(Linux, Windows and MacOS).  We build the package binaries and host them
using Github pages, so to install you simply add to your list of CRAN
repo's, "https://sage-bionetworks.github.io/ran;. You need not build from
source to use the package on Windows or Mac.  This is significant because
building the package also builds the Python runtime.

Any questions, please ask.

Bruce Hoff
Sage Bionetworks


2017-12-01 7:50 GMT+01:00 Slava Lyubchich :
> Hello,
>
> I have a package on CRAN (funtimes) and I am trying to add a function
> that uses some Python code (only one function in the package needs
> Python, others do not). In order to do that, I
> 1) add in the DESCRIPTION
> Suggests: rPython
> 2) in the R function, use
> rPython::python.load("CRAD.py")
> 3) put CRAD.py  in the top folder of the package (together with
> DESCRIPTION and NAMESPACE).
>
> The automatic CRAN check returns it with notes:
> -- Package suggested but not available for checking: 'rPython'

rPython is not available for Windows. You can see "OS_type: unix" in
its DESCRIPTION. If you want to support Windows systems, take a look
at the reticulate package, which is another R interface to Python.

> -- Non-standard file/directory found at top level:   'CRAD.py'

Create an inst/ directory and put it there, as suggested in "1.1.7
Non-R scripts in packages" in the "Writing R Extensions" manual.

I?aki

>
> Could you recommend how to fix that? Where should I move to the
> additional file with code?
> https://cran.r-project.org/package=rPython
> 
>
> Best regards,
> Slava
>
> --
> V. Lyubchich
> Research Assistant Professor
> Chesapeake Biological Laboratory
> University of Maryland Center for Environmental Science

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Testing for a Specific R Error

2017-12-02 Thread Duncan Murdoch 

On 02/12/2017 9:23 AM, Dirk Eddelbuettel wrote:


On 2 December 2017 at 08:38, Bill Denney wrote:
| Hi,
|
| I got a message last night that some of the tests in the PKNCA package do not follow 
best practices.  ("Do not test the exact format of R messages (from R itself or from 
other packages): They change, and they can be translated.")  Specifically, I test to 
ensure that an error is generated when a class cannot be coerced into a data.frame: 
https://cran.r-project.org/web/checks/check_results_PKNCA.html
|
| I want to ensure that I'm getting an error that the variable cannot be 
coerced into a data.frame.
|
| What is the best practice to ensure that I'm getting a specific R error 
(about coercion) without testing the formatting of the error text?

To me this suggest testing the _condition_ triggering the error message, as
opposed to testing for the displayed text of the error message.


Isn't that what Bill suggested in the line below?

> | The only solution that immediately occurs to me is to wrap the 
coercion in a tryCatch and give my own error.  But, then were the R 
error translated, the users of my package would lose the benefit of 
translation.


R does have a system for giving language-independent information about 
errors and warnings:  see the ?signalCondition help page. 
Unfortunately, support for this at the C level is missing, so base 
functions generally don't use it.  You only get something of class 
c("simpleError", "error", "condition").


I don't think there's anything better than Bill's solution, though I 
imagine it is possible to ask for translation of the message.  For 
example, sqrt(-1) currently gives a warning with English message "NaNs 
produced".


I can ask to translate that into the current session language using

gettext("NaNs produced", domain = "R")

Figuring out the right thing for "domain" is likely a little painful: 
it depends on which package produced the message, and how.


I don't know if CRAN tests would complain if you tested for equality 
between a warning message and the result of gettext():  it's still true 
that if the English warning changed, the test would fail.


Duncan Murdoch

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

Re: [R-pkg-devel] Testing for a Specific R Error

2017-12-02 Thread Henrik Bengtsson 
For the translation part, you can test the received error message against
the translated message. You can get the translated version from the
original one using gettext("").

This should be agile to user's language settings but, of course, not to
changes that the developer does to the the error message.

Henrik

On Dec 2, 2017 05:38, "Bill Denney"  wrote:

Hi,

I got a message last night that some of the tests in the PKNCA package do
not follow best practices.  ("Do not test the exact format of R messages
(from R itself or from other packages): They change, and they can be
translated.")  Specifically, I test to ensure that an error is generated
when a class cannot be coerced into a data.frame:
https://cran.r-project.org/web/checks/check_results_PKNCA.html

I want to ensure that I'm getting an error that the variable cannot be
coerced into a data.frame.

What is the best practice to ensure that I'm getting a specific R error
(about coercion) without testing the formatting of the error text?

The only solution that immediately occurs to me is to wrap the coercion in
a tryCatch and give my own error.  But, then were the R error translated,
the users of my package would lose the benefit of translation.

Thanks,

Bill

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

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] Testing for a Specific R Error

2017-12-02 Thread Dirk Eddelbuettel 

On 2 December 2017 at 08:38, Bill Denney wrote:
| Hi,
| 
| I got a message last night that some of the tests in the PKNCA package do not 
follow best practices.  ("Do not test the exact format of R messages (from R 
itself or from other packages): They change, and they can be translated.")  
Specifically, I test to ensure that an error is generated when a class cannot 
be coerced into a data.frame: 
https://cran.r-project.org/web/checks/check_results_PKNCA.html
| 
| I want to ensure that I'm getting an error that the variable cannot be 
coerced into a data.frame.
| 
| What is the best practice to ensure that I'm getting a specific R error 
(about coercion) without testing the formatting of the error text?

To me this suggest testing the _condition_ triggering the error message, as
opposed to testing for the displayed text of the error message.

Dirk
 
| The only solution that immediately occurs to me is to wrap the coercion in a 
tryCatch and give my own error.  But, then were the R error translated, the 
users of my package would lose the benefit of translation.
| 
| Thanks,
| 
| Bill
| 
| __
| R-package-devel@r-project.org mailing list
| https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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

[R-pkg-devel] Testing for a Specific R Error

2017-12-02 Thread Bill Denney 
Hi,

I got a message last night that some of the tests in the PKNCA package do not 
follow best practices.  ("Do not test the exact format of R messages (from R 
itself or from other packages): They change, and they can be translated.")  
Specifically, I test to ensure that an error is generated when a class cannot 
be coerced into a data.frame: 
https://cran.r-project.org/web/checks/check_results_PKNCA.html

I want to ensure that I'm getting an error that the variable cannot be coerced 
into a data.frame.

What is the best practice to ensure that I'm getting a specific R error (about 
coercion) without testing the formatting of the error text?

The only solution that immediately occurs to me is to wrap the coercion in a 
tryCatch and give my own error.  But, then were the R error translated, the 
users of my package would lose the benefit of translation.

Thanks,

Bill

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

Re: [R-pkg-devel] Simple URL error

2017-12-02 Thread Murray Efford 
Thanks. I have not seen any problem with that site (checking several times this 
afternoon) and I assume it is now OK. Package resubmitted.
Murray

From: Uwe Ligges 
Sent: Saturday, 2 December 2017 12:23 p.m.
To: Murray Efford; r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Simple URL error

On 02.12.2017 00:06, Murray Efford wrote:
> Hi all
> This is no doubt a trivial question but I haven't found a direct answer on 
> searching. My package passes R CMD check locally and on winbuilder (R-release 
> and R-devel) but stalled in CRAN submission with -
>
> Found the following (possibly) invalid URLs:
> URL: http://www.phidot.org/forum/index.php
>   From: man/secr-package.Rd
>   Status: 503
>   Message: Service Unavailable
>
> The terminal '/index.php' is not needed. Should I expect removing it will fix 
> the problem, or might this be a transient web access issue?

Apparently the latter, our auto-check and a later manual check of the
URL in a webbrowser showed that problem.

If the website is active again, simply resubmit.

Best,
Uwe Ligges




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

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