Re: [Rd] How to catch warnings sent by arguments of s4 methods ?
Hi,
Just to add some information and to clarify why I feel this is an
important issue.
If you have a S4 method with a default argument, it seems that you can
not catch the warnings
emitted during their evaluation. It matters because on some occasions
those warnings carry an essential information,
that your code needs to use.
Martin Morgan added some information about this issue on:
http://stackoverflow.com/questions/20268021/how-to-catch-warnings-sent-during-s4-method-selection
Basically the C function R_dispatchGeneric uses R_tryEvalSilent to
evaluate the method arguments, that seems no to use the calling
handlers.
Best,
Karl
On Fri, Nov 29, 2013 at 11:30 AM, Karl Forner wrote:
> Hello,
>
> I apologized if this had already been addressed, and I also submitted
> this problem on SO:
> http://stackoverflow.com/questions/20268021/how-to-catch-warnings-sent-during-s4-method-selection
>
> Example code:
> setGeneric('my_method', function(x) standardGeneric('my_method') )
> setMethod('my_method', 'ANY', function(x) invisible())
>
> withCallingHandlers(my_method(warning('argh')), warning = function(w)
> { stop('got warning:', w) })
> # this does not catch the warning
>
> It seems that the warnings emitted during the evaluation of the
> arguments of S4 methods can not get caught using
> withCallingHandlers().
>
> Is this expected ? Is there a work-around ?
>
> Best,
> Karl Forner
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] R 3.1.0 and C++11
Following up on the thread spawned a while back, I just wanted to say that I appreciate today's RSS serving of R-devel NEWS: CHANGES IN R-devel PACKAGE INSTALLATION There is _experimental_ support for compiling C++11 code in packages. The file ‘src/Makevars’ or ‘src/Makevars.win’ should define the macro ‘USE_CXX11 = true’. Where needed, an alternative C++11 compiler can be specified by setting macros ‘CXX11’, ‘CXX11FLAGS’ and so on, either when R is configured or in a personal ‘Makevars’ file. (The default is to use ‘$(CXX) -std=c++11’.) Thanks for initial and incremental changes. They are appreciated. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pesky \usage-warnings with R CMD check
I’m in the process of preparing a package for CRAN.
The package is called “exportR” and since it really just consists of one
function, I found it natural to call it “exportR” too.
The function returns a function that does the actual job, but it is set up to
work in different ways, depending on the arguments given to its creator. In
short:
library( exportR )
exporter <- exportR( the, arguments )
exporter( its, own, arguments )
When I run R CMD check I get two warnings:
-
* checking for code/documentation mismatches ... WARNING
Functions or methods with usage in documentation object 'exportR' but not in
code:
exporter
* checking Rd \usage sections ... WARNING
Assignments in \usage in documentation object 'exportR':
exporter <- exportR(fname, type = "latex", format = "4", prefix = "",
append = FALSE)
Functions with \usage entries need to have the appropriate \alias
entries, and all their arguments documented.
The \usage entries must correspond to syntactically valid R code.
See the chapter ‘Writing R documentation files’ in the ‘Writing R
Extensions’ manual.
The first warning I understand, but I don’t know how to proceed to rid myself
of it. Indeed it is nowhere in my code, as exportR creates it, but I still need
to document it. I would very much appreciate advice.
The second warning I don’t understand. I do have both \name{exportR} and
\alias{exportR} (as well as \alias{exporter}) at the top of the .Rd file. The
function name, arguments, and default values are copied directly from the
source, so they are identical. I changed the package name to exporteR to see if
the problem was that the package name and the function name were the same, but
that did not remove the warning. I used package.skeleton to create a .Rd
template for the function and it was syntactically identical. Installing the
package and running it works, obviously. I’m running out of ideas and any help
is appreciated. I have this nagging feeling that I’m missing something
obvious…?
I post the entire contents of the .Rd file at the bottom.
Best regards,
Peder Axensten
Research engineer
Swedish University of Agricultural Sciences
Department of Forest Resource Management
Remote Sensing
SE-901 83 Umeå
Visiting address: Skogsmarksgränd
Phone: +46 90 786 85 00
peder.axens...@slu.se, www.slu.se/srh
The Department of Forest Resource Management is environmentally certified in
accordance with ISO 14001.
——
\name{exportR}
\alias{exportR}
\alias{export}
\alias{exporter}
\alias{latex}
\alias{conversion}
\alias{exportR.latex}
\title{Easy export of R results}
\description{A flexible and simple way to export R results to LaTeX and [maybe
later] other formats.}
\usage{
exporter <- exportR( fname, type="latex", format="4", prefix="", append=FALSE )
exporter( ..., format=NA, prefix=NA, named=FALSE )
}
\arguments{
\item{...}{The value[s] to be exported. To name them, use the normal R
convention: \code{exporter(first=123, second=456)}. If no such name is given,
the variable name is used: \code{exporter(myvar, second=456)}. For other
expressions the naming is undetermined, be sure to name them:
\code{exporter(myname=2*pi/sqrt(2))}. Non-valid characters will be substituted
by \code{x}, i.e. \code{my_var1} will result in \code{\\myxvarx} in LaTeX.}
\item{fname}{The path to the destination file.}
\item{type}{The name of export file type, e.g. \code{exporter}. May be
a string vector to export to more than one format at once. But presently, only
\code{exporter} is implemented.}
\item{format}{The numerical format to use. When given to
\code{exportR}, it sets the default \code{.format} to be used by
\code{exporter}. When used in a call to \code{exporter}, it is used for the
present value[s]. The number suffix is the number of significant digits to use.
The formats are: \tabular{}{
\tab Format \tab
Example\tab \cr
sprintf expression \tab \% \tab \%.5e
\tab 1*pi -> 3.14159*10^4\cr
flexible\tab
\tab 8 \tab 1*pi -> 31415.927\cr
integer \tab i
\tab i \tab 1*pi -> 31415\cr
float \tab f
\tab f4 \tab 1*pi -> 3.142*10^4\cr
float, factor 3 exponent\tab e \tab e4
\tab 1*pi -> 31.42*10^3\cr
float, with suffix \tab s \tab s4
\tab 1*pi -> 31.42 k\cr
float, with 2^10 suffix \tab b \tab b3
\tab 1*pi -> 12.06 Ki\cr
fraction\tab d or d \tab d6
\tab pi -> 1146408/364913\cr
Re: [Rd] pesky \usage-warnings with R CMD check
On 02/12/2013 9:57 AM, Peder Axensten wrote:
I’m in the process of preparing a package for CRAN.
The package is called “exportR” and since it really just consists of one
function, I found it natural to call it “exportR” too.
The function returns a function that does the actual job, but it is set up to
work in different ways, depending on the arguments given to its creator. In
short:
library( exportR )
exporter <- exportR( the, arguments )
exporter( its, own, arguments )
When I run R CMD check I get two warnings:
-
* checking for code/documentation mismatches ... WARNING
Functions or methods with usage in documentation object 'exportR' but not in
code:
exporter
* checking Rd \usage sections ... WARNING
Assignments in \usage in documentation object 'exportR':
exporter <- exportR(fname, type = "latex", format = "4", prefix = "",
append = FALSE)
Functions with \usage entries need to have the appropriate \alias
entries, and all their arguments documented.
The \usage entries must correspond to syntactically valid R code.
See the chapter ‘Writing R documentation files’ in the ‘Writing R
Extensions’ manual.
The first warning I understand, but I don’t know how to proceed to rid myself
of it. Indeed it is nowhere in my code, as exportR creates it, but I still need
to document it. I would very much appreciate advice.
You should put exportR in your usage section, not exporter. To document
exporter, you have at least a couple of choices:
1. The most straightforward way is simply to document it in the Details
section of the help page. You can write what
you like there; syntax of the help text will be checked, but not content.
2. You could actually run exportR in your package .R file, and create
and export an exporter function. This will only make
sense if there's a simple default one that would make sense for all
users. But if you do that, then you can include exporter(its, own,
arguments) in the usage section, and in the value section, say that the
result of exportR will be a function that looks like exporter.
You should not include an assignment in your usage section. I think it
is being seen as a call to the "<-" function, so you get the warning
about documenting something that is not an alias. (I might be wrong
about the last part of the warning, I haven't looked closely.)
Duncan Murdoch
The second warning I don’t understand. I do have both \name{exportR} and
\alias{exportR} (as well as \alias{exporter}) at the top of the .Rd file. The
function name, arguments, and default values are copied directly from the
source, so they are identical. I changed the package name to exporteR to see if
the problem was that the package name and the function name were the same, but
that did not remove the warning. I used package.skeleton to create a .Rd
template for the function and it was syntactically identical. Installing the
package and running it works, obviously. I’m running out of ideas and any help
is appreciated. I have this nagging feeling that I’m missing something obvious…?
I post the entire contents of the .Rd file at the bottom.
Best regards,
Peder Axensten
Research engineer
Swedish University of Agricultural Sciences
Department of Forest Resource Management
Remote Sensing
SE-901 83 Umeå
Visiting address: Skogsmarksgränd
Phone: +46 90 786 85 00
peder.axens...@slu.se, www.slu.se/srh
The Department of Forest Resource Management is environmentally certified in
accordance with ISO 14001.
——
\name{exportR}
\alias{exportR}
\alias{export}
\alias{exporter}
\alias{latex}
\alias{conversion}
\alias{exportR.latex}
\title{Easy export of R results}
\description{A flexible and simple way to export R results to LaTeX and [maybe
later] other formats.}
\usage{
exporter <- exportR( fname, type="latex", format="4", prefix="", append=FALSE )
exporter( ..., format=NA, prefix=NA, named=FALSE )
}
\arguments{
\item{...}{The value[s] to be exported. To name them, use the normal R
convention: \code{exporter(first=123, second=456)}. If no such name is given,
the variable name is used: \code{exporter(myvar, second=456)}. For other
expressions the naming is undetermined, be sure to name them:
\code{exporter(myname=2*pi/sqrt(2))}. Non-valid characters will be substituted
by \code{x}, i.e. \code{my_var1} will result in \code{\\myxvarx} in LaTeX.}
\item{fname}{The path to the destination file.}
\item{type}{The name of export file type, e.g. \code{exporter}. May be
a string vector to export to more than one format at once. But presently, only
\code{exporter} is implemented.}
\item{format}{The numerical format to use. When given to
\code{exportR}, it sets the default \code{.format} to be used by
\code{exporter}. When used in a call to \code{exporter}, it is used for the
present value[s]. The number suffix is the number of significant digits to use.
The formats are: \tabular{}{
[Rd] Arithmetic Error while compiling R with the Intel compilers
Hi Team, I downloaded the R 3.0.2 and, built and installed it using Intel compilers (icc and ifort) from Intel parallel studio 2013, sp1. After performing make tried to check it using 'make check'. Most of the tests passed successfully but while checking a 'stats' package I saw many lines were printed which did not match the desired output. e.g. There were two types of mismatch Case 1) 6300c6300 < Grand Mean: 291.5937 --- > Grand Mean: 291.5938 Case 2) 12699c12699 < UrbanPop *0.278* -0.873 -0.378 0.134 --- > UrbanPop *-0.278* -0.873 -0.378 0.134 Case 1 was having slight difference in the values and assumed due to the floating point error, but Case 2 is having values with difference signs. Is such behaviour is normal or there is any issue with the Intel libraries. I used some of the libraries from Intel MKL like fftw, mkl_lapack etc. I am pasting below the command that I used to configure this R package. ./configure --prefix=$INSTALL_DIR --with-blas="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_lapack -lmkl_core -lpthread -lfftw3xf_intel -lfftw3xc_intel" --with-lapack I also tried installing using Intel compilers without using Intel MKL libraries. It was done using below command. ./configure --prefix=$INSTALL_DIR Exactly same errors were there. There were no mismatch observed while compiling with gcc.Kindly provide your suggestions whether it is good idea to use Intel compilers. Thanks for your kind attention and time. Sincerely, Swapnil [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Arithmetic Error while compiling R with the Intel compilers
On 02/12/2013 1:39 PM, Swapnil Gaikwad wrote: Hi Team, I downloaded the R 3.0.2 and, built and installed it using Intel compilers (icc and ifort) from Intel parallel studio 2013, sp1. After performing make tried to check it using 'make check'. Most of the tests passed successfully but while checking a 'stats' package I saw many lines were printed which did not match the desired output. e.g. There were two types of mismatch Case 1) 6300c6300 < Grand Mean: 291.5937 --- > Grand Mean: 291.5938 Case 2) 12699c12699 < UrbanPop *0.278* -0.873 -0.378 0.134 --- > UrbanPop *-0.278* -0.873 -0.378 0.134 Case 1 was having slight difference in the values and assumed due to the floating point error, but Case 2 is having values with difference signs. Is such behaviour is normal or there is any issue with the Intel libraries. You need to look at the context of what is being tested. In this particular case, you are testing principal component loadings: they can all be multiplied by -1 and give exactly the same results, so this one is okay. (The choice of sign is probably being made in the linear algebra routines.) I used some of the libraries from Intel MKL like fftw, mkl_lapack etc. I am pasting below the command that I used to configure this R package. ./configure --prefix=$INSTALL_DIR --with-blas="-lmkl_intel_lp64 -lmkl_intel_thread -lmkl_lapack -lmkl_core -lpthread -lfftw3xf_intel -lfftw3xc_intel" --with-lapack I also tried installing using Intel compilers without using Intel MKL libraries. It was done using below command. ./configure --prefix=$INSTALL_DIR Exactly same errors were there. There were no mismatch observed while compiling with gcc.Kindly provide your suggestions whether it is good idea to use Intel compilers. Thanks for your kind attention and time. Can't help you with your final question, I have no experience with them. Duncan Murdoch __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] pesky \usage-warnings with R CMD check
Duncan,
As soon as I read your letter I realized the logic. I followed your advice and
the warnings are gone. I don’t know how long it would have taken me to see it
myself, but probably quite some time – thank you!
I do think it’s a pity, in this special case, that I can’t put the returning
function inside \usage. It would have made the documentation more clear and
concise.
Best regards,
Peder Axensten
Research engineer
Swedish University of Agricultural Sciences
Department of Forest Resource Management
Remote Sensing
SE-901 83 Umeå
Visiting address: Skogsmarksgränd
Phone: +46 90 786 85 00
peder.axens...@slu.se, www.slu.se/srh
The Department of Forest Resource Management is environmentally certified in
accordance with ISO 14001.
On 2 dec 2013, at 17:26, Duncan Murdoch wrote:
> On 02/12/2013 9:57 AM, Peder Axensten wrote:
>> I’m in the process of preparing a package for CRAN.
>>
>> The package is called “exportR” and since it really just consists of one
>> function, I found it natural to call it “exportR” too.
>>
>> The function returns a function that does the actual job, but it is set up
>> to work in different ways, depending on the arguments given to its creator.
>> In short:
>> library( exportR )
>> exporter <- exportR( the, arguments )
>> exporter( its, own, arguments )
>>
>> When I run R CMD check I get two warnings:
>> -
>> * checking for code/documentation mismatches ... WARNING
>> Functions or methods with usage in documentation object 'exportR' but not in
>> code:
>> exporter
>>
>> * checking Rd \usage sections ... WARNING
>> Assignments in \usage in documentation object 'exportR':
>> exporter <- exportR(fname, type = "latex", format = "4", prefix = "",
>> append = FALSE)
>>
>> Functions with \usage entries need to have the appropriate \alias
>> entries, and all their arguments documented.
>> The \usage entries must correspond to syntactically valid R code.
>> See the chapter ‘Writing R documentation files’ in the ‘Writing R
>> Extensions’ manual.
>>
>>
>> The first warning I understand, but I don’t know how to proceed to rid
>> myself of it. Indeed it is nowhere in my code, as exportR creates it, but I
>> still need to document it. I would very much appreciate advice.
>
> You should put exportR in your usage section, not exporter. To document
> exporter, you have at least a couple of choices:
>
> 1. The most straightforward way is simply to document it in the Details
> section of the help page. You can write what
> you like there; syntax of the help text will be checked, but not content.
>
> 2. You could actually run exportR in your package .R file, and create and
> export an exporter function. This will only make
> sense if there's a simple default one that would make sense for all users.
> But if you do that, then you can include exporter(its, own, arguments) in the
> usage section, and in the value section, say that the result of exportR will
> be a function that looks like exporter.
>
> You should not include an assignment in your usage section. I think it is
> being seen as a call to the "<-" function, so you get the warning about
> documenting something that is not an alias. (I might be wrong about the last
> part of the warning, I haven't looked closely.)
>
> Duncan Murdoch
>
>>
>> The second warning I don’t understand. I do have both \name{exportR} and
>> \alias{exportR} (as well as \alias{exporter}) at the top of the .Rd file.
>> The function name, arguments, and default values are copied directly from
>> the source, so they are identical. I changed the package name to exporteR to
>> see if the problem was that the package name and the function name were the
>> same, but that did not remove the warning. I used package.skeleton to create
>> a .Rd template for the function and it was syntactically identical.
>> Installing the package and running it works, obviously. I’m running out of
>> ideas and any help is appreciated. I have this nagging feeling that I’m
>> missing something obvious…?
>>
>> I post the entire contents of the .Rd file at the bottom.
>>
>> Best regards,
>>
>> Peder Axensten
>> Research engineer
>>
>> Swedish University of Agricultural Sciences
>> Department of Forest Resource Management
>> Remote Sensing
>> SE-901 83 Umeå
>> Visiting address: Skogsmarksgränd
>> Phone: +46 90 786 85 00
>> peder.axens...@slu.se, www.slu.se/srh
>>
>> The Department of Forest Resource Management is environmentally certified in
>> accordance with ISO 14001.
>>
>> ——
>> \name{exportR}
>> \alias{exportR}
>> \alias{export}
>> \alias{exporter}
>> \alias{latex}
>> \alias{conversion}
>> \alias{exportR.latex}
>> \title{Easy export of R results}
>> \description{A flexible and simple way to export R results to LaTeX and
>> [maybe later] other formats.}
>> \usage{
>> exporter <- exportR( fname, type="latex", format="4", prefix="",
>> append=FALSE )
>> exporter( ..., for
Re: [Rd] pesky \usage-warnings with R CMD check
On 13-12-02 5:25 PM, Peder Axensten wrote:
Duncan,
As soon as I read your letter I realized the logic. I followed your advice and
the warnings are gone. I don’t know how long it would have taken me to see it
myself, but probably quite some time – thank you!
I do think it’s a pity, in this special case, that I can’t put the returning
function inside \usage. It would have made the documentation more clear and
concise.
I partially disagree. It's not up to you to name function results:
users should do that. So documenting "exporter" doesn't make sense,
beyond the documentation you give in the Details or Value section of
your help page, unless there really is an object named "exporter" in
your package.
On the other hand, I do agree it is a pity that you can't somehow
document return values that are functions using code that is similar to
the \usage code, and have automatic Rd checking give some quality
assurance. (It wouldn't be easy to write those QA checks, but they'd be
useful.)
Duncan Murdoch
Best regards,
Peder Axensten
Research engineer
Swedish University of Agricultural Sciences
Department of Forest Resource Management
Remote Sensing
SE-901 83 Umeå
Visiting address: Skogsmarksgränd
Phone: +46 90 786 85 00
peder.axens...@slu.se, www.slu.se/srh
The Department of Forest Resource Management is environmentally certified in
accordance with ISO 14001.
On 2 dec 2013, at 17:26, Duncan Murdoch wrote:
On 02/12/2013 9:57 AM, Peder Axensten wrote:
I’m in the process of preparing a package for CRAN.
The package is called “exportR” and since it really just consists of one
function, I found it natural to call it “exportR” too.
The function returns a function that does the actual job, but it is set up to
work in different ways, depending on the arguments given to its creator. In
short:
library( exportR )
exporter <- exportR( the, arguments )
exporter( its, own, arguments )
When I run R CMD check I get two warnings:
-
* checking for code/documentation mismatches ... WARNING
Functions or methods with usage in documentation object 'exportR' but not in
code:
exporter
* checking Rd \usage sections ... WARNING
Assignments in \usage in documentation object 'exportR':
exporter <- exportR(fname, type = "latex", format = "4", prefix = "",
append = FALSE)
Functions with \usage entries need to have the appropriate \alias
entries, and all their arguments documented.
The \usage entries must correspond to syntactically valid R code.
See the chapter ‘Writing R documentation files’ in the ‘Writing R
Extensions’ manual.
The first warning I understand, but I don’t know how to proceed to rid myself
of it. Indeed it is nowhere in my code, as exportR creates it, but I still need
to document it. I would very much appreciate advice.
You should put exportR in your usage section, not exporter. To document
exporter, you have at least a couple of choices:
1. The most straightforward way is simply to document it in the Details
section of the help page. You can write what
you like there; syntax of the help text will be checked, but not content.
2. You could actually run exportR in your package .R file, and create and
export an exporter function. This will only make
sense if there's a simple default one that would make sense for all users. But
if you do that, then you can include exporter(its, own, arguments) in the usage
section, and in the value section, say that the result of exportR will be a
function that looks like exporter.
You should not include an assignment in your usage section. I think it is being seen as a
call to the "<-" function, so you get the warning about documenting something
that is not an alias. (I might be wrong about the last part of the warning, I haven't
looked closely.)
Duncan Murdoch
The second warning I don’t understand. I do have both \name{exportR} and
\alias{exportR} (as well as \alias{exporter}) at the top of the .Rd file. The
function name, arguments, and default values are copied directly from the
source, so they are identical. I changed the package name to exporteR to see if
the problem was that the package name and the function name were the same, but
that did not remove the warning. I used package.skeleton to create a .Rd
template for the function and it was syntactically identical. Installing the
package and running it works, obviously. I’m running out of ideas and any help
is appreciated. I have this nagging feeling that I’m missing something obvious…?
I post the entire contents of the .Rd file at the bottom.
Best regards,
Peder Axensten
Research engineer
Swedish University of Agricultural Sciences
Department of Forest Resource Management
Remote Sensing
SE-901 83 Umeå
Visiting address: Skogsmarksgränd
Phone: +46 90 786 85 00
peder.axens...@slu.se, www.slu.se/srh
The Department of Forest Resource Management is environmentally certified in
accordance with ISO 14001.
——
