On 4/13/21 4:36 PM, Witold E Wolski wrote:
Hello,
I am trying to run a package check on windows 10.
But it fails with the following errors:
```
$ R CMD check prolfqua_0.1.5.3.tar.gz
During startup - Warning message:
Setting LC_CTYPE=en_US.UTF-8 failed
* using log directory 'C:/Users/wewol/__che
Hello,
I am trying to run a package check on windows 10.
But it fails with the following errors:
```
$ R CMD check prolfqua_0.1.5.3.tar.gz
During startup - Warning message:
Setting LC_CTYPE=en_US.UTF-8 failed
* using log directory 'C:/Users/wewol/__checkout/prolfqua.Rcheck'
* using R version 4.0.
This has been fixed in R-devel:
r78046 | ripley | 2020-03-24 06:51:35 -0700 (Tue, 24 Mar 2020) | 1 line
handle Renviron files in the same way as POSIX shells
(diff:
https://github.com/wch/r-source/commit/1658c8491e9cdc6d2fe61603ed23ae56232b6727)
I've verified that 'R CMD check --as-cran' now h
On Wed, Mar 18, 2020 at 8:04 PM Dirk Eddelbuettel wrote:
>
>
> On 18 March 2020 at 19:19, Henrik Bengtsson wrote:
> | AFAIU, 'R CMD check --as-cran' tries to hide any site and user package
> | libraries by setting R_LIBS_SITE and R_LIBS_USER. However, contrary
>
> What makes you think that? AFAIK
On 18 March 2020 at 19:19, Henrik Bengtsson wrote:
| AFAIU, 'R CMD check --as-cran' tries to hide any site and user package
| libraries by setting R_LIBS_SITE and R_LIBS_USER. However, contrary
What makes you think that? AFAIK --as-cran just sets a bunch of the (nearly
countless) environment va
AFAIU, 'R CMD check --as-cran' tries to hide any site and user package
libraries by setting R_LIBS_SITE and R_LIBS_USER. However, contrary
to R_LIBS_SITE, it fails for R_LIBS_USER and the user's personal
library is still available for test scripts. Should I revise my
assumptions, or is that inten
The warning is that the vignette failed to be rebuilt due to an error in
its code. The error log was truncated.
Of course for practical purposes errors and warnings both constitute check
failures
On Thu, 29 Aug 2019 at 1:56 am, Therneau, Terry M., Ph.D. via R-devel <
r-devel@r-project.org> wrote:
I'm running "R CMD check" for 600+ of the packages that depend on survival, and
at the end
look for
grep Status *.Rcheck/00check.log | grep ERROR
to find any that failed. But by accident I just looked at the log for the
Greg package,
which finishes with the lines found below. Is the f
Hi
Following-up on this question. I don't understand why R CMD check creates
.Rout files that do not contain the message "Registered S3 method
overwritten by..." that I otherwise obtain with an interactive R session,
or with R CMD BATCH? Can I recreate the behaviour of R CMD check calling
directly
Hi
Since I believe 3.6, there is a message when loading a package that
overwrites S3 methods, reading like "Registered S3 method overwritten
by...". Should this message be included in the xxx.Rout.save files saved in
the tests/ folder of a package? It seems R CMD check is not happy about it?
I si
Hi,
FWIW I also noticed this problem and reported it on R’s Bugzilla 4 years
ago:
https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16223
I actually had to report it twice because my first report
(https://bugs.r-project.org/bugzilla/show_bug.cgi?id=16153) was closed
after a few days and tag
R's checks seem to be failing to notice a redundant '...' argument described in
the documentation of a function.
Consider a function:
fun_3 <- function(arg1, arg2, arg3) {
"I am fun_3"
}
If its documentation describes an argument, say 'dummy', R check reports
something like:
* checking Rd
I don't think this has anything to do with Fortran.
The full warning message is presumably like
Warning: S3 methods . . . were declared in NAMESPACE but not found
which according to google-fu happens if you are declaring methods from a
package that isn't loaded, in this case possibly dplyr.
O
Hi all,
For the R package bujar, the warnings below were generated on CRAN's Windows
systems. The package uses some Fortran subroutines. I would appreciate any
advice to eliminate the warnings. By the way, similar warnings were generated
to some unrelated R packages as well:
https://www.r-proj
I repeat it for all the reason I gave to Duncan on a personal E-mail, It is
a lot of text, and I might be wrong, but I attach it in case it is useful:
A) I feel Version Control (SVN) is great when there is a little group of
people maintaining the code (RCore ~ 20); but Git could allow a bigger
gro
On 03/01/2018 6:11 PM, Uwe Ligges wrote:
On 26.12.2017 00:45, Juan Telleria wrote:
However, and hope not to be off-topic, a git repository (github, gitlab,
codeplex, etc., not just solely github) could constitute a tidy approach,
and make things easier to R Core :)
By putting the focus on ver
On 26.12.2017 00:45, Juan Telleria wrote:
However, and hope not to be off-topic, a git repository (github, gitlab,
codeplex, etc., not just solely github) could constitute a tidy approach,
and make things easier to R Core :)
By putting the focus on version control, the line of changes made wit
However, and hope not to be off-topic, a git repository (github, gitlab,
codeplex, etc., not just solely github) could constitute a tidy approach,
and make things easier to R Core :)
By putting the focus on version control, the line of changes made with each
commit (With the possibility to reverse
M... I see... thank you Suzen.
Juan
> I strongly disagree. Are you aware that github is a commercial
> company, github inc. [1] ?
> What about gitlab? or Microsoft's codeplex? There are other services
> similar to github, why github?
> What happens if github goes out of business?
>
> R-proje
On 26 December 2017 at 00:00, Juan Telleria wrote:
> Maybe I'm new, and forgive my ignorance, but maybe in the future (~ X years
> from now) the R Project could be managed entirely from github, by doing
I strongly disagree. Are you aware that github is a commercial
company, github inc. [1] ?
What
Maybe I'm new, and forgive my ignorance, but maybe in the future (~ X years
from now) the R Project could be managed entirely from github, by doing
pull requests and only R Core having commit rights...
Would make the forking process also easier... And could be a good roadmap.
But we're not using
On 25/12/2017 7:00 AM, Iñaki Úcar wrote:
2017-12-25 12:30 GMT+01:00 Duncan Murdoch :
The one negative aspect of Winston's effort is caused by this weakness. If
you tell me that something happened in revision 73909, I know it was recent.
If you tell me that something appeared in commit 2e80059, i
2017-12-25 12:30 GMT+01:00 Duncan Murdoch :
> The one negative aspect of Winston's effort is caused by this weakness. If
> you tell me that something happened in revision 73909, I know it was recent.
> If you tell me that something appeared in commit 2e80059, it wastes my time
> looking up that com
On 22/12/2017 10:46 AM, Marc Schwartz wrote:
Hi,
See inline below.
On Dec 22, 2017, at 9:12 AM, Martin Maechler wrote:
Duncan Murdoch
on Thu, 21 Dec 2017 14:23:13 -0500 writes:
On 21/12/2017 1:02 PM, Winston Chang wrote:
On recent builds of R-devel, R CMD check gives a
WARNING whe
Hi,
See inline below.
> On Dec 22, 2017, at 9:12 AM, Martin Maechler
> wrote:
>
>> Duncan Murdoch
>>on Thu, 21 Dec 2017 14:23:13 -0500 writes:
>
>> On 21/12/2017 1:02 PM, Winston Chang wrote:
> On recent builds of R-devel, R CMD check gives a
> WARNING when some compiler
> Duncan Murdoch
> on Thu, 21 Dec 2017 14:23:13 -0500 writes:
> On 21/12/2017 1:02 PM, Winston Chang wrote:
On recent builds of R-devel, R CMD check gives a
WARNING when some compiler warning flags are detected,
such as -Werror, because they are non-port
On 12/21/2017 01:02 PM, Winston Chang wrote:
On recent builds of R-devel, R CMD check gives a WARNING when some
compiler warning flags are detected, such as -Werror, because they are
non-portable. This appears to have been added in this commit:
https://github.com/wch/r-source/commit/2e80059
On 21/12/2017 1:02 PM, Winston Chang wrote:
On recent builds of R-devel, R CMD check gives a WARNING when some
compiler warning flags are detected, such as -Werror, because they are
non-portable. This appears to have been added in this commit:
https://github.com/wch/r-source/commit/2e80059
>> On recent builds of R-devel, R CMD check gives a WARNING when some
>> compiler warning flags are detected, such as -Werror, because they are
>> non-portable. This appears to have been added in this commit:
>>https://github.com/wch/r-source/commit/2e80059
>
> That is not the canonical R sourc
On 20/12/2017 6:52 PM, Duncan Murdoch wrote:
On 20/12/2017 5:48 PM, Hadley Wickham wrote:
On Wed, Dec 20, 2017 at 4:26 PM, Prof Brian Ripley
wrote:
On 20/12/2017 17:42, Winston Chang wrote:
On recent builds of R-devel, R CMD check gives a WARNING when some
compiler warning flags are detected
On 20/12/2017 5:48 PM, Hadley Wickham wrote:
On Wed, Dec 20, 2017 at 4:26 PM, Prof Brian Ripley
wrote:
On 20/12/2017 17:42, Winston Chang wrote:
On recent builds of R-devel, R CMD check gives a WARNING when some
compiler warning flags are detected, such as -Werror, because they are
non-portab
On Wed, Dec 20, 2017 at 4:26 PM, Prof Brian Ripley
wrote:
> On 20/12/2017 17:42, Winston Chang wrote:
>>
>> On recent builds of R-devel, R CMD check gives a WARNING when some
>> compiler warning flags are detected, such as -Werror, because they are
>> non-portable. This appears to have been added
On 20/12/2017 17:42, Winston Chang wrote:
On recent builds of R-devel, R CMD check gives a WARNING when some
compiler warning flags are detected, such as -Werror, because they are
non-portable. This appears to have been added in this commit:
https://github.com/wch/r-source/commit/2e80059
Tha
On recent builds of R-devel, R CMD check gives a WARNING when some
compiler warning flags are detected, such as -Werror, because they are
non-portable. This appears to have been added in this commit:
https://github.com/wch/r-source/commit/2e80059
I'm working on a package where these compiler war
Martin,
That was it- I forgot the "LinkingTo" line. I had read that section of the manual
twice in the last 2 days, yet somehow missed that critical line both times. And even
worse, the final sentence of said section references my own coxme package as an example of
how to do it correctly!
> Therneau, Terry M , Ph D
> on Thu, 9 Feb 2017 12:56:17 -0600 writes:
> Martyn,
> No, that didn't work.
> One other thing in the mix (which I don't think is the issue) is that I
call one of the
> C-entry points of expm. So the DESCRIPTION file imports expm, the
NA
Martyn,
No, that didn't work.
One other thing in the mix (which I don't think is the issue) is that I call one of the
C-entry points of expm. So the DESCRIPTION file imports expm, the NAMESPACE file imports
expm, and the init.c file is
#include "R.h"
#include "R_ext/Rdynload.h"
/* Interf
On Thu, 2017-02-09 at 09:52 -0600, Therneau, Terry M., Ph.D. wrote:
> Martin,
> I am aware of --vanilla; I use it myself for some testing. In this case
> R_LIBS_USER was
> set externally (part of my login) and does not involve any of the R scripts.
> That means
> it is inherited by any subp
Martin,
I am aware of --vanilla; I use it myself for some testing. In this case R_LIBS_USER was
set externally (part of my login) and does not involve any of the R scripts. That means
it is inherited by any subprocess. For example:
tmt1495% R --vanilla --no-environ
R version 3.3.1 (2016-0
On Wed, 2017-02-08 at 15:51 -0600, Therneau, Terry M., Ph.D. wrote:
> I have a local library which depends on the expm library. The expm library
> is loaded into
> my personal space and I have the environment variable R_LIBS_USER set
> appropriately. The
> command "library(expm)" works just f
I have a local library which depends on the expm library. The expm library is loaded into
my personal space and I have the environment variable R_LIBS_USER set appropriately. The
command "library(expm)" works just fine from the command line, and in fact the package
works if I do the source() a
On 07.11.2016 22:43, Henrik Bengtsson wrote:
On R 3.2.5, 3.3.2 and devel for Windows, R CMD check --as-cran gives me:
Found the following (possibly) invalid URLs:
URL: https://www.stat.auckland.ac.nz/~paul/Reports/DisplayList/dl-record.html
From: man/capturePlot.Rd
Status: Error
On R 3.2.5, 3.3.2 and devel for Windows, R CMD check --as-cran gives me:
Found the following (possibly) invalid URLs:
URL: https://www.stat.auckland.ac.nz/~paul/Reports/DisplayList/dl-record.html
From: man/capturePlot.Rd
Status: Error
Message: libcurl error code 35
error:14077410
On 10/10/2015 6:30 AM, Kirill Müller wrote:
Today, a package that has an HTML vignette (but no PDF vignette) failed
R CMD check --as-cran on a system without qpdf. I think the warning
originates here [1], due to a premature check for the existence of qpdf
[2]. Setting R_QPDF=true (as in /bin/true
Today, a package that has an HTML vignette (but no PDF vignette) failed
R CMD check --as-cran on a system without qpdf. I think the warning
originates here [1], due to a premature check for the existence of qpdf
[2]. Setting R_QPDF=true (as in /bin/true) helped, but perhaps it's
possible to che
On Thu, Apr 30, 2015 at 3:44 AM, Martin Maechler <
maech...@lynne.stat.math.ethz.ch> wrote:
[...]
>
> If I have understood your main point correctly, you are
> suggesting that 'R CMD check' should start putting out a NOTE
> when package code calls a function from one of a set of
> "standard packa
> Gábor Csárdi
> on Wed, 29 Apr 2015 23:07:09 -0400 writes:
> On Wed, Apr 29, 2015 at 8:12 PM, Paul Gilbert
wrote:
>>
>> As I recall, several packages mask the simulate generic in stats, if you
>> are looking for examples.
>>
> FWIW, here is a list of base
On Wed, Apr 29, 2015 at 8:12 PM, Paul Gilbert wrote:
>
> As I recall, several packages mask the simulate generic in stats, if you
> are looking for examples.
>
FWIW, here is a list of base* functions masked** by CRAN packages:
https://github.com/gaborcsardi/rfunctions/blob/master/rfunctions.md
Lo
On 04/29/2015 05:38 PM, William Dunlap wrote:
And in general a developer would avoid masking a function
in a base package, so as not to require the user to distinguish
between stats::density() and igraph::density(). Maybe the
example is not meant literally.
The 'filter' function in the popula
> And in general a developer would avoid masking a function
> in a base package, so as not to require the user to distinguish
> between stats::density() and igraph::density(). Maybe the
> example is not meant literally.
The 'filter' function in the popular 'dplyr' package masks the one
that has be
On Wed, Apr 29, 2015 at 4:24 PM, Martin Morgan
wrote:
> On 04/28/2015 01:04 PM, Gábor Csárdi wrote:
>
[...]
> E.g. if package 'ggplot2' uses 'stats::density()', and package 'igraph'
>> also defines 'density()', and 'igraph' is on the search path, then
>> 'ggplot2' will call 'igraph::density()' i
On 04/28/2015 01:04 PM, Gábor Csárdi wrote:
When a symbol in a package is resolved, R looks into the package's
environment, and then into the package's imports environment. Then, if the
symbol is still not resolved, it looks into the base package. So far so
good.
If still not found, it follows t
On Wed, Apr 29, 2015 at 3:24 PM, Duncan Murdoch
wrote:
[...]
> Yes, people can do this already. But why not help them with a NOTE if they
>> don't know that this is good practice, or they just simply forget?
>>
>
> I suspect the reason for this is historical: at the time that the current
> warni
On Wed, Apr 29, 2015 at 3:28 PM, John Nolan wrote:
[...]
> 1. have R CMD check show how every external function reference gets
> resolved.
>
That's not possible, because it depends on the currently attached packages,
and even on the order of their attachment.
> 2. have R CMD check warn anytime
To: Gabriel Becker ,
Cc: "r-devel@r-project.org"
Date: 04/29/2015 01:57 PM
Subject: Re: [Rd] R CMD check and missing imports from base
packages
Sent by:"R-devel"
On Wed, Apr 29, 2015 at 1:45 PM, Gabriel Becker
wrote:
> Gabor,
>
> T
On 29/04/2015 1:57 PM, Gábor Csárdi wrote:
On Wed, Apr 29, 2015 at 1:45 PM, Gabriel Becker
wrote:
> Gabor,
>
> To play devil's advocate a bit, why not just have the package formally
> import the functions it wants to use (or the whole package if that is
> easier)?
>
This is exactly my goal. A
On Wed, Apr 29, 2015 at 1:45 PM, Gabriel Becker
wrote:
> Gabor,
>
> To play devil's advocate a bit, why not just have the package formally
> import the functions it wants to use (or the whole package if that is
> easier)?
>
This is exactly my goal. And to facilitate this, R CMD check could remi
Gabor,
To play devil's advocate a bit, why not just have the package formally
import the functions it wants to use (or the whole package if that is
easier)? Also, if your package Depends on another package, instead of
importing it (e.g. because the end user will need functions in it in order
to m
On Wed, Apr 29, 2015 at 12:53 PM, Winston Chang
wrote:
> On Tue, Apr 28, 2015 at 3:04 PM, Gábor Csárdi
> wrote:
> >
> >
> > E.g. if package 'ggplot2' uses 'stats::density()', and package 'igraph'
> > also defines 'density()', and 'igraph' is on the search path, then
> > 'ggplot2' will call 'igra
On Tue, Apr 28, 2015 at 3:04 PM, Gábor Csárdi wrote:
>
>
> E.g. if package 'ggplot2' uses 'stats::density()', and package 'igraph'
> also defines 'density()', and 'igraph' is on the search path, then
> 'ggplot2' will call 'igraph::density()' instead of 'stats::density()'.
Just to be clear: you m
When a symbol in a package is resolved, R looks into the package's
environment, and then into the package's imports environment. Then, if the
symbol is still not resolved, it looks into the base package. So far so
good.
If still not found, it follows the 'search()' path, starting with the
global e
On Tue, Feb 10, 2015 at 5:10 AM, Xavier Robin wrote:
> Oh, I completely missed that one.
> It's very neat as it seems to work both on Windows and Unix.
>
It works on both Windows and *nix because it combines functionality
from snow (Windows) and multicore (*nix).
> Thanks!
> Xavier
>
>
> On 10/02
Oh, I completely missed that one.
It's very neat as it seems to work both on Windows and Unix.
Thanks!
Xavier
On 10/02/15 10:52, Martyn Plummer wrote:
> The CRAN package snow is superseded by the parallel package which is
> distributed with R since version 2.14.0. Here are the release notes
>
>
The CRAN package snow is superseded by the parallel package which is
distributed with R since version 2.14.0. Here are the release notes
\item There is a new package \pkg{parallel}.
It incorporates (slightly revised) copies of packages
\CRANpkg{multicore} and \CRANpkg{snow} (excluding MPI, PVM
Dear list,
When I run an R CMD check --as-cran on my package (pROC) I get the
following note:
> Uses the superseded package: ‘doSNOW’
The fact that it uses the doSNOW package is correct as I have the
following example in an .Rd file:
> #ifdef windows
> if (require(doSNOW)) {
> registerDoSNOW(c
I just wanted to share my findings on this topic with you:
Custom variables for checking and building can be set through
"~/.R/check.Renviron" and " ~/.R/build.Renviron". But not the "LANGUAGE"
variable; it will always be set to "C". I couldn't find a way to change the
locales for a check or build
a ACT 0200.
On 26 Jan 2015, at 22:00,
mailto:r-devel-requ...@r-project.org>>
mailto:r-devel-requ...@r-project.org>> wrote:
From: Prof Brian Ripley mailto:rip...@stats.ox.ac.uk>>
Subject: Re: [Rd] R CMD check message: "The following files should probably not
be installed&quo
On 25/01/2015 23:25, John Maindonald wrote:
I am doing [R version 3.1.2 (2014-10-31) -- "Pumpkin Helmet”; Platform:
x86_64-apple-darwin10.8.0 (64-bit)]
R CMD build DAAGviz
R CMD check DAAGviz_1.0.3.tar.gz
Without a .Rinstignore file, I get:
<<<
The following files should probably not be ins
I am doing [R version 3.1.2 (2014-10-31) -- "Pumpkin Helmet”; Platform:
x86_64-apple-darwin10.8.0 (64-bit)]
> R CMD build DAAGviz
> R CMD check DAAGviz_1.0.3.tar.gz
Without a .Rinstignore file, I get:
<<<
The following files should probably not be installed:
‘figs10.pdf’, ‘figs11.pdf’, ‘figs1
Dear All
The "R CMD check" on the "zoo" (1.7-11) package results in an error on my
environment. It can be reduced to the following example:
> require(zoo)
> read.zoo(system.file("doc", "demo1.txt", package = "zoo"), sep = "|",
format="%d %b %Y"
On 14/01/2015 4:47 AM, Hadley Wickham wrote:
> I think this is bug in R CMD check code. I get a similar error:
>
> rule: possible error in paste0(...): ... used in a situation where it
> does not exist
>
> for the simple:
>
> rule <- function(..., pad = "-") {
> if (nargs() == 0) {
> ti
I think this is bug in R CMD check code. I get a similar error:
rule: possible error in paste0(...): ... used in a situation where it
does not exist
for the simple:
rule <- function(..., pad = "-") {
if (nargs() == 0) {
title <- ""
} else {
title <- paste0(...)
}
width <- getO
Dear R developers,
when running R CMD check, the R Under development (unstable)
(2015-01-13 r67453) gives me the following NOTE:
cbind.fsets: possible error in list(...): ... used in a situation
where it does not exist
The file that causes this note contains:
cbind.fsets <- function(..., dep
> Henrik Bengtsson
> on Fri, 5 Dec 2014 18:17:57 -0800 writes:
> Does anyone know if it is possible to add a dictionary
> file of known words that becomes part of the *built*
> package to tell 'R CMD check --as-cran' not to report
> these words as misspelled. I want t
Does anyone know if it is possible to add a dictionary file of known
words that becomes part of the *built* package to tell 'R CMD check
--as-cran' not to report these words as misspelled. I want this
dictionary to come with the *.tar.gz such that it will be available
regardless where the package
Dear R developers,
As far as I can see
R CMD CHECK --run-donttest
does not test the \donttest examples.
By contrast, --run-dontrun appears to run the \dontrun examples as expected.
I have prepared a minimal package archive for illustrating this bug,
which I can send to anyone interested (but I
On 05/09/2014 08:04, Mikko Korpela wrote:
On 04.09.2014 18:15, Thalles wrote:
I am writing a package with some R functions and try to submit it to CRAN.
After build and check the package a number of times, I am struggling with
the fact that the CRAN people responsible for checking packages are
On 04.09.2014 18:15, Thalles wrote:
> I am writing a package with some R functions and try to submit it to CRAN.
> After build and check the package a number of times, I am struggling with
> the fact that the CRAN people responsible for checking packages are
> replying me with some mistakes that
Hello, That is my first post here and I'd like to thanks everybody in
advance.
I am writing a package with some R functions and try to submit it to CRAN.
After build and check the package a number of times, I am struggling with
the fact that the CRAN people responsible for checking packages are
r
On Mon, Jun 30, 2014 at 6:19 AM, Duncan Murdoch
wrote:
> On 30/06/2014 8:51 AM, Michael Lawrence wrote:
>
>> I think it's generally nice to be able to compute on the network of
>> imported and exported symbols, and exportFrom() preserves the information
>> that a symbol has been forwarded. But le
On 30/06/2014 8:51 AM, Michael Lawrence wrote:
I think it's generally nice to be able to compute on the network of
imported and exported symbols, and exportFrom() preserves the
information that a symbol has been forwarded. But let's focus on the
use case of documenting the symbol.
First, from
I think it's generally nice to be able to compute on the network of
imported and exported symbols, and exportFrom() preserves the information
that a symbol has been forwarded. But let's focus on the use case of
documenting the symbol.
First, from the user perspective: my understanding (without tes
On 29/06/2014, 3:07 PM, Michael Lawrence wrote:
> While the change to the symbol lookup is generally useful (e.g., for
> finding S4 methods that become available whenever a package is loaded),
> it seems that we ultimately want a mechanism by which a package
> namespace can formally declare that it
While the change to the symbol lookup is generally useful (e.g., for
finding S4 methods that become available whenever a package is loaded), it
seems that we ultimately want a mechanism by which a package namespace can
formally declare that it is re-exporting a symbol from some package. Then,
for e
Hi Duncan,
Again, thanks a lot for making this change (help requests are tried
over all loaded instead of attached packages):
https://github.com/wch/r-source/commit/21d2f7430b4 This makes what I
proposed last time possible now: if pkg B imports FUN from A and
re-exports it, ?FUN will work after B
Plummer
Cc: winstoncha...@gmail.com; r-devel@r-project.org
Subject: Re: [Rd] R CMD check warning with S3 method
> When you provide a method for a generic function imported from another
> package then the generic must be on the search path. Otherwise if a user
> types "filter" the dispatc
> When you provide a method for a generic function imported from another
> package then the generic must be on the search path. Otherwise if a user
> types "filter" the dispatch to "filter.test" will never occur.
Right, and this is as desired. If dplyr is not explicitly loaded by
the user, filter.
On Fri, 2014-06-20 at 01:34 -0500, Yihui Xie wrote:
> but note that you will have to document it even if it is a function
> imported from another package...
Let's not go round in circles. I already pointed this out in my earlier
reply to Winston. It has been snipped from the thread history so I'l
On 20/06/2014, 8:34 AM, Yihui Xie wrote:
> but note that you will have to document it even if it is a function
> imported from another package... Perhaps help() should be intelligent
> enough to link the documentation of `FUN` from package A for package B
> when B imports `FUN` from A, and exports
but note that you will have to document it even if it is a function
imported from another package... Perhaps help() should be intelligent
enough to link the documentation of `FUN` from package A for package B
when B imports `FUN` from A, and exports it in B's NAMESPACE. The
package name of A may be
On Thu, Jun 19, 2014 at 3:15 PM, Martyn Plummer wrote:
> Export filter in the NAMESPACE file *without copying it* in the R source
> code.
>
>
Ah, it works! Thank you!
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
Export filter in the NAMESPACE file *without copying it* in the R source code.
From: Winston Chang [winstoncha...@gmail.com]
Sent: 19 June 2014 21:28
To: Martyn Plummer
Cc: r-devel@r-project.org
Subject: Re: [Rd] R CMD check warning with S3 method
Oh, I forgot to
Oh, I forgot to mention I tried a few other variations:
=
Re-export dplyr::filter:
filter <- dplyr::filter
NAMESPACE has:
S3method(filter,test)
export(filter)
importFrom(dplyr,filter)
Then the filter.test method from s3methodtest doesn't seem to get
registered properly:
When you provide a method for a generic function imported from another
package then the generic must be on the search path. Otherwise if a user
types "filter" the dispatch to "filter.test" will never occur.
What is happening here is worse because "filter" is a non-generic
function in the stats pac
I forgot to add this - here's the warning:
* checking S3 generic/method consistency ... WARNING
Warning: declared S3 method 'filter.test' not found
See section 'Generic functions and methods' of the 'Writing R
Extensions' manual.
On Tue, Jun 17, 2014 at 2:21 PM, Winston Chang wrote:
> I'm getti
I'm getting an R CMD check warning with a package (call it package A)
that defines an S3 method but not the generic. The generic is defined
in another package (package B). Package A imports the S3 generic from
B. And there's one additional detail: the generic overrides a function
in the stats packa
You need to run "R CMD build" on your package, then run "R CMD check" on
the resulting tarball, as recommended in section 1.3.1 of the "Writing R
Extensions" manual.
The tarball will contain a version of the DESCRIPTION file with Author
and Maintainer fields built from the Authors@R field.
Martyn
Section 1.1 of R-exts mentions that the Maintainer and Author fields can be
omitted from the DESCRIPTION file if Authors@R is supplied. However, R CMD
check does not seem to like this.
package.skeleton("foo")
desc <- readLines("foo/DESCRIPTION")
desc[6] <- "Authors@R: person('Mathew', 'McLean', e
On 03/06/2014, 2:04 PM, Yihui Xie wrote:
As I pointed out, \Sexpr{} is not the only potential problem. Besides,
side effects are not necessarily evil in all cases.
Since I have been described as "nitpicky", it is time for me to quit
the discussion now
In that case I'll also consider the issue
As I pointed out, \Sexpr{} is not the only potential problem. Besides,
side effects are not necessarily evil in all cases.
Since I have been described as "nitpicky", it is time for me to quit
the discussion now (adjectives on personal pronouns instead of nouns
in a discussion is a sign for me to q
1 - 100 of 497 matches
Mail list logo
