Re: [R-pkg-devel] A replacement idiom for \value{\item{\var{...}}{}}
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, 5))
as.data.frame(setNames(
lapply(out.M, \(M) M * runif(n)),
paste0('fooval.', out.M)
))
If I call it as foo(out.M = 1), I get a data.frame containing a column
named fooval.1. If I call it as foo(), I get columns fooval.2,
fooval.3, and fooval.5 instead.
I would like to document this relationship between the arguments and
the output value like so:
\arguments{
\item{out.M}{Return the foo vectors for every M value given here.}
% more arguments that behave in a similar manner
}
% ...
\value{
A \code{data.frame} containing the following columns:
\item{fooval.\var{m}}{
The foo values, for every \var{m} in \code{out.M}.
}
% more parametrised output columns to follow
}
It turns out that \value{} description lists now escape their \item{}
arguments, preventing me from using \var{} markup there, but only in
plain text and HTML outputs. I think that the change occurred in the
last year or so; old versions of R process markup in \item{} arguments
even in \value{} description lists, but they have other Rd problems. I
understand the motivation of the change: in \arguments{} and \value{}
environments, it makes sense to typeset \item{} headings as \code{}.
Thank you for the report. AFAICS, this only affects HTML conversion in R
>= 4.3.0. It is an "internally" known limitation (see corresponding
source code comment in Rd2HTML).
OTOH, WRE does not clearly specify that \item labels in \arguments or
\value could actually contain any markup. That said, the referenced
"Parsing Rd files" document
() does tell us that
\item{}{} arguments are parsed as LaTeX-like text, \dots probably being
the most common example.
Should I try to fix Rd2latex (or at least file a ticket) to escape the
\item{...} arguments in \value{} (but not \describe{}!) environments
too?
Yes, I think this belongs to "R-devel" and a problem report in Bugzilla
would be useful; the problem being that Rd markup in \item labels is
handled inconsistently by the Rd converters. It is currently unclear to
me, however, which one is at fault here. Your example at least provides
one (admittedly quiet special) use case for LaTeX-like content in an
\item label of the \value section.
What would be a better Rd idiom for such function argument — output
component relationships?
I think a workaround that currently works for your use case is to use
\code{fooval.\var{m}} as the label (i.e., wrapped inside \code).
Best regards,
Sebastian Meyer
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] A replacement idiom for \value{\item{\var{...}}{}}
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(
lapply(out.M, \(M) M * runif(n)),
paste0('fooval.', out.M)
))
If I call it as foo(out.M = 1), I get a data.frame containing a column
named fooval.1. If I call it as foo(), I get columns fooval.2,
fooval.3, and fooval.5 instead.
I would like to document this relationship between the arguments and
the output value like so:
\arguments{
\item{out.M}{Return the foo vectors for every M value given here.}
% more arguments that behave in a similar manner
}
% ...
\value{
A \code{data.frame} containing the following columns:
\item{fooval.\var{m}}{
The foo values, for every \var{m} in \code{out.M}.
}
% more parametrised output columns to follow
}
It turns out that \value{} description lists now escape their \item{}
arguments, preventing me from using \var{} markup there, but only in
plain text and HTML outputs. I think that the change occurred in the
last year or so; old versions of R process markup in \item{} arguments
even in \value{} description lists, but they have other Rd problems. I
understand the motivation of the change: in \arguments{} and \value{}
environments, it makes sense to typeset \item{} headings as \code{}.
Should I try to fix Rd2latex (or at least file a ticket) to escape the
\item{...} arguments in \value{} (but not \describe{}!) environments
too?
What would be a better Rd idiom for such function argument — output
component relationships?
--
Best regards,
Ivan
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Is it a wrong assumption that ${R_HOME}/lib always exists?
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 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 some configurations, R does not need *any* shared libraries,
> and there, $R_HOME/lib does *not* exist.
>
> E.g., I have one of my R-devel versions installed (on Fedora
> Linux) with
>
> ../R/configure --with-blas=-lflexiblas
>
> using the nice, currently Fedora/Redhat-only "flexiblas"
> approach, with which I can nicely switch the versions of BLAS
> and Lapack libraries that R works with from within R.
>
> As that version of R is not "shared", i.e., no libR.so , *and*
> gets both its BLAS and Lapack libraries from "external" (not
> from R), there's no need for a ./lib/ and so none is created.
>
> Martin Maechler
> ETH Zurich and R Core Team
>
>
> > Is it possible
> > that this path doesn't exist on the MKL server?
>
> > Actually, it compiles fine on the other Linux platforms,
> > so I'm wondering what's different there from the other
> > servers.
>
>
> > Best, Yutani
> > [[alternative HTML version deleted]]
>
>
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
Re: [R-pkg-devel] Is it a wrong assumption that ${R_HOME}/lib always exists?
> 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 some configurations, R does not need *any* shared libraries,
and there, $R_HOME/lib does *not* exist.
E.g., I have one of my R-devel versions installed (on Fedora
Linux) with
../R/configure --with-blas=-lflexiblas
using the nice, currently Fedora/Redhat-only "flexiblas"
approach, with which I can nicely switch the versions of BLAS
and Lapack libraries that R works with from within R.
As that version of R is not "shared", i.e., no libR.so , *and*
gets both its BLAS and Lapack libraries from "external" (not
from R), there's no need for a ./lib/ and so none is created.
Martin Maechler
ETH Zurich and R Core Team
> Is it possible
> that this path doesn't exist on the MKL server?
> Actually, it compiles fine on the other Linux platforms,
> so I'm wondering what's different there from the other
> servers.
> Best, Yutani
> [[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
[R-pkg-devel] Is it a wrong assumption that ${R_HOME}/lib always exists?
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" }',
/data/gannet/ripley/R/packages/tests-MKL/string2path/src/rust/vendor/libR-sys/build.rs:637
:40
The line 637 of build.rs of libR-sys crate is here [2]:
r_paths.library.canonicalize().unwrap().display()
Compared to the previous version, which didn't experience such a failure,
.canonicalize() was added, and it seems this is the cause. This method
normalizes the path expression like R's normalizePath(), and it fails
because the path specified didn't exist.
libR-sys assumes the path to R's shared libraries is `${R_HOME}/lib` on
Unix-alike platforms. Is it possible that this path doesn't exist on the
MKL server? Actually, it compiles fine on the other Linux platforms, so I'm
wondering what's different there from the other servers.
Best,
Yutani
[1]: https://cran.r-project.org/web/checks/check_results_string2path.html
[2]: https://github.com/extendr/libR-sys/blob/v0.5.0/build.rs#L637C1-L637C58
[[alternative HTML version deleted]]
__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
