Guillermo,
That phrase is referring to using .Call in your package to call a C
function that shipped with a DIFFERENT package or is part of R itself
(defined in the R source code).
As long as you are only calling C functions you define in the C++ code that
ships with your package you are fine.
~
Dear Kevin, Berwin and Gabriel,
Thank you very much for your detailed and clear answers.
According to your comments, in a few days I will submit my package to CRAN.
I would also like to take this opportunity to thank all the R-devel list
for being a wonderful place to discuss and clarify doubts
I think the key word here is _other_ packages. It's entirely okay to call
your package's own compiled code through the .Call interface (and the code
you write may link to other packages; the obvious example being Rcpp code
you write); however, it is not portable to use .Call to call compiled code
f
This would be easier if base::set.seed() accepted a value of .Random.seed
instead of just a scalar integer or, new to R-3.0.0, NULL. If set.seed()
returned the
previous value of .Random.seed (NULL if there was no previous value) things
might be even easier. People should not have to know where .
Hello Core Folk.
Quite by accident I discovered today that col2rgb, when fed factors, acts on
the integer representation of those factors:
td <- as.factor(rainbow(5)) # not how I discovered the issue!
td
res <- col2rgb(td)
res
# but
col2rgb("#FFFF") # this is td[1] but does not produce the s
Hi,
relist() is broken when the skeleton is a list with empty list elements:
> x <- list(1:3, integer(0), 11:14)
> relist(unlist(x), x)
[[1]]
[1] 1 2 3
[[2]]
[1] 11 3
[[3]]
[1] 11 12 13 14
Hard to believe that such a bug has been around for 6 years (i.e. since
the introducti
