In my package I open handles to temporary files from c++, handles to
them are returned to R through vptr objects. The files are deleted then
the corresponding R-object is deleted and the garbage collector runs:
a <- lvec(10, "integer")
rm(a)
Then when the garbage collector runs the file
I am trying solve an issue where my tests run fine when run with R CMD
check, but not with R CMD check --as-cran. In the tests pandoc is called
using system; pandoc then calls R again with a script which is part of
the package. The last part seems to fail, see error message below:
weird errors when people have multiple versions of R on their system.
Best,
Jan
On 30-09-2021 18:59, Ivan Krylov wrote:
On Fri, 24 Sep 2021 21:48:12 +0200
Jan van der Laan wrote:
my tests run fine when run with R CMD check, but not with R CMD check
--as-cran
<...>
pandoc then c
You are not the only one; I did the same with some of my examples.
Would it be an option to ask for a default R-option, 'max.ncores', that
specifies the maximum number of cores a process is allowed to use? CRAN
could then require that that examples, tests and vignettes respect this
option.
Sep 2022, Jan van der Laan wrote:
I have a function in which I need to draw some random numbers.
However, for some use cases, it is necessary that the same random
numbers are drawn (when the input is the same) [1]. So I would like to
do a set.seed in my function. This could, however, mess up
I have a function in which I need to draw some random numbers. However,
for some use cases, it is necessary that the same random numbers are
drawn (when the input is the same) [1]. So I would like to do a set.seed
in my function. This could, however, mess up the seed set by the user.
So
I am trying to upload a new version of the reclin2 package, but it fails
the pre-tests on Debian with the following message:
> * checking examples ... [14s/4s] NOTE
> Examples with CPU time > 2.5 times elapsed time
> user system elapsed ratio
> select_threshold 3.700 0.122
This error indicates that the arrow package is unavailable on the system
where your package is checked. At
https://cran.r-project.org/web/checks/check_results_arrow.html you can
see that the arrow package is currently not working with clang on fedora
an debian. This is not something that you
Can't/don't you use relative paths?
library(..., lib.loc = "./MyLibrary")
Then your project is perfectly portable. The only thing you need to take
care of is to run your code from your project directory. In R-studio
this is easily done by using projects. Outside of R-studio it depends on
Interesting. That would also mean that putting a company repo first does
not protect against dependency confusion attacks (people intentionally
uploading packages with the same name as company internal packages on
CRAN;
10 matches
Mail list logo
