Re: [R-pkg-devel] A replacement idiom for \value{\item{\var{...}}{}}

2023-07-10 Thread Sebastian Meyer
Am 10.07.23 um 16:30 schrieb Ivan Krylov: Hello R-package-devel, I've got a function that returns a data.frame. The columns (and their names) of the return value are parametrised by the arguments of the function. See, for example, the following function: foo <- function(n = 10, out.M = c(2, 3,

[R-pkg-devel] A replacement idiom for \value{\item{\var{...}}{}}

2023-07-10 Thread Ivan Krylov
Hello R-package-devel, I've got a function that returns a data.frame. The columns (and their names) of the return value are parametrised by the arguments of the function. See, for example, the following function: foo <- function(n = 10, out.M = c(2, 3, 5)) as.data.frame(setNames(

Re: [R-pkg-devel] Is it a wrong assumption that ${R_HOME}/lib always exists?

2023-07-10 Thread Hiroaki Yutani
Thanks so much for the quick response. It answered everything! It was my mistake that I didn't consider these types of installations. I'll fix my package as soon as I can. Best, Yutani 2023年7月10日(月) 17:51 Martin Maechler : > > Hiroaki Yutani > > on Mon, 10 Jul 2023 17:24:37 +0900

Re: [R-pkg-devel] Is it a wrong assumption that ${R_HOME}/lib always exists?

2023-07-10 Thread Martin Maechler
> Hiroaki Yutani > on Mon, 10 Jul 2023 17:24:37 +0900 writes: [...] Short answer to your questsion (from the 'Subject') is :NO ! For an example, see below: > libR-sys assumes the path to R's shared libraries is > `${R_HOME}/lib` on Unix-alike platforms. In

[R-pkg-devel] Is it a wrong assumption that ${R_HOME}/lib always exists?

2023-07-10 Thread Hiroaki Yutani
Hi, My package, string2path, using Rust fails on the CRAN check of MKL [1], with an error that seems irrelevant to MKL. The error says: > thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 2, kind: NotFound, message: "No such file or directory" }',