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
Hello everyone!
I'm Mossa, I'm one of the maintainers of extendr, an automated generation of
bindings project for
Rust code, for use in R-packages.
I'm writing to you, as R 4.4.3 was just released, and there have not been
follow-up on an issue important to us. Link to the issue as discussed on r
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
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 stands R 4.4.2 will codify CRAN policy o
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
1 - 100 of 523 matches
Mail list logo
