t; and https://github.com/extendr/hellorustc
> > <https://github.com/extendr/hellorustc>
> > >>> <https://github.com/extendr/hellorustc
> > <https://github.com/extendr/hellorustc>>, which showcases how Rust
> > >>>
>> > side-stepping `cargo` / crates.io
<http://crates.io> <http://crates.io <http://crates.io>>
> <http://crates.io <http://crates.io> <http://crates.io
<http://crates.io>>>, we are
> >>&g
It is also pretty straightforward to roll your own actions and / or use
different, simpler YAML setups. I still use a 'rolled forward and maintained
by me now version' of the shell script many of us started with at Travis CI.
It works, is portable across multiple CI backend, and is still a shell
robbing upstream authors of their download-numbers.
I do
> not think
> >>> such policy is honourable.
> >>> >
> >>> > While C/C++ do not have official package
repositories,
tp://crates.io>>
> <http://crates.io <http://crates.io> <http://crates.io
<http://crates.io>>>, we are
> >>> robbing upstream authors of their download-numbers.
I do
> not think
> >>
>>>> > >>> > it does seem very strange that we cannot get a
>>>> reasonable
>>>> > >>> dialogue going.
>>>> > >>> >
>>>>
> To Tim's comment—the check is a simple grep of the installation log for
> "Downloading crates." This could be easily circumvented on CRAN and locally
> by suppressing stdout/err. But that would be adversarial and I would like
> to adhere to the intent of the check.
Josiah - I do sympathise but
crates.io <http://crates.io>>
> <http://crates.io <http://crates.io> <http://crates.io
<http://crates.io>>>, we are
> >>> robbing upstream authors of their download-numbers.
I do
> not think
> &
s.io> <http://crates.io
<http://crates.io>>>, we are
> >>> robbing upstream authors of their download-numbers.
I do
> not think
> >>> such policy is honourable.
> >>> >
>
n is already conveyed to the user.
> >>> >
> >>> > Personally, I do wish we could debate this requirement
> further. I
> >>> do not believe that having R-packages on CRAN vendor rust
> >>> dependencies
&
<http://crates.io
<http://crates.io>>>, we are
> >>> robbing upstream authors of their download-numbers.
I do
> not think
> >>> such policy is honourable.
> >>> >
> &
t;http://crates.io>>, we are
>>> robbing upstream authors of their download-numbers. I do
not think
>>> such policy is honourable.
>>> >
>>> > While C/C++ do not have official package repositories,
it could
On Mon, 31 Mar 2025, at 4:50 PM, Josiah Parry wrote:
> Following up with this as I address the new R-devel "Compiled code should
> not call entry points which might terminate R" WARNING and this issue has
> reared its head again.
>
> Would a path forward be an environment variable similar
> to _R_C
ired my end of the community for suggestions
> to compile a larger proposal, but then I was afraid that this
would be perceived as a big, bulky demand.
>
> Rust is not C/C++/Java, and the support for Rust cannot look like
the support for these languages.
>
&g
Mossa,
> On Mar 2, 2025, at 11:45 PM, Mossa Merhi Reimert wrote:
>
> There has been very little engagement with the issue I referred to. If it was
> decided that this “check” ought to be part of the default checks for R, then
> that could have been written to us. Either on the bugs.r-project.
demand.
>
> Rust is not C/C++/Java, and the support for Rust cannot look like
the support for these languages.
>
>
>
> From: Simon Urbanek
> Date: Sunday, 2 March 2025 at 00.39
> To: Mossa Merhi Reimert <mailto:mo...@sund.ku.dk
gt; to compile a larger proposal, but then I was afraid that this
would be perceived as a big, bulky demand.
>
> Rust is not C/C++/Java, and the support for Rust cannot look like
the support for these languages.
>
>
>
> From: Simon Urbanek
andom demands” comment, as this is not a
> demand, nor is it random.
> > I have inquired my end of the community for suggestions
> > to compile a larger proposal, but then I was afraid that this would be
> perceived as a big, bulky demand.
> >
> > Rust is not C/C++
h, before embarking on a larger discussion.
> > I do not appreciate the “random demands” comment, as this is not a
> demand, nor is it random.
> > I have inquired my end of the community for suggestions
> > to compile a larger proposal, but then I was afraid that this would be
> p
fraid that this would be
perceived as a big, bulky demand.
Rust is not C/C++/Java, and the support for Rust cannot look like the support
for these languages.
From: Simon Urbanek
Date: Sunday, 2 March 2025 at 00.39
To: Mossa Merhi Reimert
Cc: r-devel@r-project.org
Subject: Re: [Rd] R CMD c
Urbanek
Date: Sunday, 2 March 2025 at 00.39
To: Mossa Merhi Reimert
Cc: r-devel@r-project.org
Subject: Re: [Rd] R CMD check and CRAN's Rust policy
[Du får ikke ofte mails fra simon.urba...@r-project.org. Få mere at vide om,
hvorfor dette er vigtigt, på https://a
Mossa,
the issue you cite is lacking any pertinent information and it's not even clear
why it should be an issue. The check is perfectly justified, it just reports
whether a package using rust declares this correctly and where it downloads 3rd
party content - something that is important to R us
Thank you, Tomas, for the clarification!
On Sun, Oct 13, 2024 at 14:59 Tomas Kalibera
wrote:
> On 10/13/24 19:30, Josiah Parry wrote:
> > Hi all,
> >
> > I'm new to contributing to r-devel. The trunk of r-devel right now
> includes
> > a `check_rust()` function for adherence to CRAN's evolving r
On 10/13/24 19:30, Josiah Parry wrote:
Hi all,
I'm new to contributing to r-devel. The trunk of r-devel right now includes
a `check_rust()` function for adherence to CRAN's evolving rust policy (see
commit
https://github.com/r-devel/r-svn/commit/6114d4126434c056b476cbc5db2657536c153d9a
).
As it
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
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
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:
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,
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
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
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
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
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 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
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
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
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
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
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
> 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
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
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
1 - 100 of 412 matches
Mail list logo
