[Rd] \Sexpr[results=hide] produces \verb{ newlines }
Hello R-devel!
Here's an Rd file that produces a large empty area when converted to
HTML:
\name{repro}
\title{title}
\description{description}
\details{
Hello
\Sexpr[stage=build,results=hide]{
invisible(NULL)
invisible(NULL)
invisible(NULL)
invisible(NULL)
invisible(NULL)
invisible(NULL)
invisible(NULL)
invisible(NULL)
invisible(NULL)
invisible(NULL)
invisible(NULL)
"" # workaround: remove results=hide and use the return value
}
}
This seems to happen because \Sexpr gets expanded to \verb{ as many
newlines as there were code lines } by processRdChunk, by first storing
a newline for each line of the code:
https://github.com/wch/r-source/blob/d7a4ed9aaeee1f57c3c165aefa08b8d69dfe59fa/src/library/tools/R/RdConv2.R#L257
...and then the newlines get translated to \verb because res is
not empty:
https://github.com/wch/r-source/blob/d7a4ed9aaeee1f57c3c165aefa08b8d69dfe59fa/src/library/tools/R/RdConv2.R#L332
As long as Rd above doesn't stem from my misuse of \Sexpr, I would like
to propose the following patch, which seems to fix the problem:
Index: src/library/tools/R/RdConv2.R
===
--- src/library/tools/R/RdConv2.R (revision 80675)
+++ src/library/tools/R/RdConv2.R (working copy)
@@ -329,6 +329,8 @@
}
} else if (options$results == "text")
res <- tagged(err, "TEXT")
+ else if (options$results == "hide")
+ res <- tagged("", "COMMENT")
else if (length(res)) {
res <- lapply(as.list(res), function(x) tagged(x, "VERB"))
res <- tagged(res, "\\verb")
There are probably other ways of fixing this problem, e.g. by only
populating res if options$results != "hide" or only appending newlines
if res is non-empty.
--
Best regards,
Ivan
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Check if (embedded) R has been initialized from C code
Dear Tomas,
It’s exactly how you describe it. And, you’re right, the R library can tell
SWI-prolog that R has been initialized, so there’s no need to expose a function
such as Rf_initialized().
Best wishes,
Matthias
Von: Tomas Kalibera
Gesendet: Donnerstag, 29. Juli 2021 14:50
An: Matthias Gondan; r-devel@r-project.org
Betreff: Re: [Rd] Check if (embedded) R has been initialized from C code
Dear Matthias,
On 6/17/21 8:25 AM, Matthias Gondan wrote:
> Dear R developers,
>
> (This email has also been sent to R-help before, but I was told that it
> doesn’t really fit there)
>
> I am currently trying to write a piece of C code that uses „embedded R“, and
> for specific reasons*, I cannot keep track if R already has been initialized.
> So the code snippet looks like this:
>
> LibExtern char *R_TempDir;
>
> if(R_TempDir == NULL)
> …throw exception R not initialized…
>
> I have seen that the source code of Rf_initialize_R itself checks if it is
> ivoked twice (num_initialized), but this latter flag does not seem to
> accessible, or is it?
No, it is static (private) in the file.
>
> int Rf_initialize_R(int ac, char **av)
> {
> int i, ioff = 1, j;
> Rboolean useX11 = TRUE, useTk = FALSE;
> char *p, msg[1024], cmdlines[1], **avv;
> structRstart rstart;
> Rstart Rp = &rstart;
> Rboolean force_interactive = FALSE;
>
> if (num_initialized++) {
> fprintf(stderr, "%s", "R is already initialized\n");
> exit(1);
> }
>
>
> Is the test of the TempDir a good substitute, or should I choose another
> solution? Having said this, it may be a good idea to expose a function
> Rf_R_initialized that performs such a test.
I think using R_TempDir should be fine (as long as you are not setting
it yourself to a non-NULL value, which would be permitted by the
documentation).
The documentation does not say explicitly that R_TempDir is actually set
to a non-NULL value by R, so technically speaking one should not be
relying on that, but in case of embedding there are probably a number of
"worse" assumptions about R behavior one makes. In the unlikely case
that this behavior would change, and R_TempDir remain NULL after R
initialization, your program would trigger repeated initialization and
exit, so that would be immediately discovered by testing. So I think
this is reasonably safe.
> Thank you for your consideration.
>
> Best regards,
>
> Matthias
>
> *The use case is an R library that connects to swi-prolog and allows the
> „embedded“ swi-prolog to establish an additional reverse connection to R. In
> that case, i.e., R -> Prolog -> R, I do not want to initialize R a second
> time. But since the interaction may also start from the swi-prolog system
> (and in the latter case, R needs to be initialized), I need a function such
> as the one mentioned here.
In principle, it would be easy to add a function to tell if R has been
initialized, but I am not sure I fully understand the problem, why is it
needed.
You have a Prolog library, which can be used from an R package (then
should not initialize R), or from some other application (then should
initialize R)? And you can modify the code of the Prolog library, but
would prefer not to require that the Prolog library is being told
whether it is linked to an R package, or not? And you would prefer not
having to modify that other application to initialize R before calling
the Prolog library, because, the library may not use R? So - having a
flag in the Prolog library, set from the R package wrapper/external
application - telling if used as an R package or not - would not work
for you?
Best
Tomas
>
>
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Suggested change to cor.test.default
The stats:::cor.test.default function has these tests near the start:
if (length(x) != length(y))
stop("'x' and 'y' must have the same length")
if (!is.numeric(x))
stop("'x' must be a numeric vector")
if (!is.numeric(y))
stop("'y' must be a numeric vector")
I'd like to suggest putting the first test in last place instead, which
would make some user errors easier to diagnose. For example, if I
misspell one of the column names, I get
df <- data.frame(x = 1:10, y = 1:10)
cor.test(df$X, df$y)
#> Error in cor.test.default(df$X, df$y): 'x' and 'y' must have the
same length
because df$X is NULL. It would be more obvious what went wrong if the
error said
Error in cor.test.default(df$X, df$y): 'x' must be a numeric vector
Duncan Murdoch
P.S. An even more friendly error message would give the actual
expression for x instead, i.e.
Error in cor.test.default(df$X, df$y): 'df$X' is not a numeric vector
but that's not the style of error used in most stats functions.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Check if (embedded) R has been initialized from C code
Dear Matthias,
On 6/17/21 8:25 AM, Matthias Gondan wrote:
Dear R developers,
(This email has also been sent to R-help before, but I was told that it doesn’t
really fit there)
I am currently trying to write a piece of C code that uses „embedded R“, and
for specific reasons*, I cannot keep track if R already has been initialized.
So the code snippet looks like this:
LibExtern char *R_TempDir;
if(R_TempDir == NULL)
…throw exception R not initialized…
I have seen that the source code of Rf_initialize_R itself checks if it is
ivoked twice (num_initialized), but this latter flag does not seem to
accessible, or is it?
No, it is static (private) in the file.
int Rf_initialize_R(int ac, char **av)
{
int i, ioff = 1, j;
Rboolean useX11 = TRUE, useTk = FALSE;
char *p, msg[1024], cmdlines[1], **avv;
structRstart rstart;
Rstart Rp = &rstart;
Rboolean force_interactive = FALSE;
if (num_initialized++) {
fprintf(stderr, "%s", "R is already initialized\n");
exit(1);
}
Is the test of the TempDir a good substitute, or should I choose another
solution? Having said this, it may be a good idea to expose a function
Rf_R_initialized that performs such a test.
I think using R_TempDir should be fine (as long as you are not setting
it yourself to a non-NULL value, which would be permitted by the
documentation).
The documentation does not say explicitly that R_TempDir is actually set
to a non-NULL value by R, so technically speaking one should not be
relying on that, but in case of embedding there are probably a number of
"worse" assumptions about R behavior one makes. In the unlikely case
that this behavior would change, and R_TempDir remain NULL after R
initialization, your program would trigger repeated initialization and
exit, so that would be immediately discovered by testing. So I think
this is reasonably safe.
Thank you for your consideration.
Best regards,
Matthias
*The use case is an R library that connects to swi-prolog and allows the „embedded“
swi-prolog to establish an additional reverse connection to R. In that case, i.e., R
-> Prolog -> R, I do not want to initialize R a second time. But since the
interaction may also start from the swi-prolog system (and in the latter case, R
needs to be initialized), I need a function such as the one mentioned here.
In principle, it would be easy to add a function to tell if R has been
initialized, but I am not sure I fully understand the problem, why is it
needed.
You have a Prolog library, which can be used from an R package (then
should not initialize R), or from some other application (then should
initialize R)? And you can modify the code of the Prolog library, but
would prefer not to require that the Prolog library is being told
whether it is linked to an R package, or not? And you would prefer not
having to modify that other application to initialize R before calling
the Prolog library, because, the library may not use R? So - having a
flag in the Prolog library, set from the R package wrapper/external
application - telling if used as an R package or not - would not work
for you?
Best
Tomas
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trivial typo in help("browser")
Hello,
Double thanks, for the correction and for the lesson.
In particular, I had never noticed the f2() example's behavior.
It's always good to learn something new.
Rui Barradas
Às 08:57 de 29/07/21, Martin Maechler escreveu:
Rui Barradas
on Thu, 29 Jul 2021 07:52:02 +0100 writes:
> Hello,
> R 4.1.0 on Ubuntu 20.04, session info below.
> I am not an English native speaker but in help("browser"),
> section Arguments, argument expr, there is a wrong verb
> tense:
> "invoked" should be "invoke", right?
> expr An expression, which if it evaluates to TRUE the
> debugger will invoked, otherwise control is returned
> directly.
> sessionInfo() R version 4.1.0 .
Thank you, Rui. Indeed, there's a typo there.
I claim that it is a missing 'be': "be invoked" almost surealy
was intended.
As we are on the R-devel mailing list, however, let's dig and learn a bit more:
Note that the *default* is `expr = TRUE`
which is already a bit "special" for an "expression"..
Let's try to understand what was meant --- NB a strategy I
strongly recommend even if you're somewhat experienced :
ff <- function(x) { y <- x^2; browser("in ff():", expr = (y == 4)); y }
ff(1)
[1] 1
ff(2)
Called from: ff(2)
Browse[1]> debug at #1: y
Browse[2]> ls.str()
x : num 2
y : num 4
Browse[2]> c
[1] 4
ff(3)
[1] 9
So indeed, it does behave as I expected.
A further experiment, play with
f2 <- function(x, e=1) { y <- x^2; browser("in ff():", expr = e); y }
shows that 'evaluates to TRUE' is also
not as precise as it could be, and even "wrong":
'expr = pi' also behaves as TRUE, and even
'expr = NA' behaves the same.
I don't know when/how `expr` was introduced (probably taken
from 'S / S+' ..), but to me it seems actually somewhat a
misnomer because in that generalized sense, *every*
argument passed to an R function is an "expression".
Instead, what counts is that a low-level as.logical(expr) is not TRUE.
So, yes, the documentation about `expr` definitely needs to be
changed.
Unless I get convincing suggestions for improvements, I'll commit
\item{expr}{a \dQuote{condition}. By default, and whenever not false
after being coerced to \code{\link{logical}}, the debugger will be
invoked, otherwise control is returned directly.}
(and also amend the formulation a bit later on the help page
where expr is mentioned again).
Martin
> Thanks to all R Core Team members for their great work for
> all of us.
> Hope this helps,
> Rui Barradas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trivial typo in help("browser")
Hello,
Thanks, you are absolutely right. I had noticed that last night and then
I din't know what happened but it went like that.
Thanks for the correction.
Rui Barradas
Às 07:59 de 29/07/21, Peter Langfelder escreveu:
I'm also not a native speaker but my take is that a "be" is missing in
the sentence and it should read
An expression, which if it evaluates to TRUE the debugger will be invoked,
otherwise control is returned directly.
On Wed, Jul 28, 2021 at 11:52 PM Rui Barradas wrote:
Hello,
R 4.1.0 on Ubuntu 20.04, session info below.
I am not an English native speaker but in help("browser"), section
Arguments, argument expr, there is a wrong verb tense:
"invoked" should be "invoke", right?
expr
An expression, which if it evaluates to TRUE the debugger will invoked,
otherwise control is returned directly.
sessionInfo()
R version 4.1.0 (2021-05-18)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.2 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0
locale:
[1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
[3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
[5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
[7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.1.0
Thanks to all R Core Team members for their great work for all of us.
Hope this helps,
Rui Barradas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trivial typo in help("browser")
> Rui Barradas
> on Thu, 29 Jul 2021 07:52:02 +0100 writes:
> Hello,
> R 4.1.0 on Ubuntu 20.04, session info below.
> I am not an English native speaker but in help("browser"),
> section Arguments, argument expr, there is a wrong verb
> tense:
> "invoked" should be "invoke", right?
> expr An expression, which if it evaluates to TRUE the
> debugger will invoked, otherwise control is returned
> directly.
> sessionInfo() R version 4.1.0 .
Thank you, Rui. Indeed, there's a typo there.
I claim that it is a missing 'be': "be invoked" almost surealy
was intended.
As we are on the R-devel mailing list, however, let's dig and learn a bit more:
Note that the *default* is `expr = TRUE`
which is already a bit "special" for an "expression"..
Let's try to understand what was meant --- NB a strategy I
strongly recommend even if you're somewhat experienced :
> ff <- function(x) { y <- x^2; browser("in ff():", expr = (y == 4)); y }
> ff(1)
[1] 1
> ff(2)
Called from: ff(2)
Browse[1]> debug at #1: y
Browse[2]> ls.str()
x : num 2
y : num 4
Browse[2]> c
[1] 4
> ff(3)
[1] 9
>
So indeed, it does behave as I expected.
A further experiment, play with
f2 <- function(x, e=1) { y <- x^2; browser("in ff():", expr = e); y }
shows that 'evaluates to TRUE' is also
not as precise as it could be, and even "wrong":
'expr = pi' also behaves as TRUE, and even
'expr = NA' behaves the same.
I don't know when/how `expr` was introduced (probably taken
from 'S / S+' ..), but to me it seems actually somewhat a
misnomer because in that generalized sense, *every*
argument passed to an R function is an "expression".
Instead, what counts is that a low-level as.logical(expr) is not TRUE.
So, yes, the documentation about `expr` definitely needs to be
changed.
Unless I get convincing suggestions for improvements, I'll commit
\item{expr}{a \dQuote{condition}. By default, and whenever not false
after being coerced to \code{\link{logical}}, the debugger will be
invoked, otherwise control is returned directly.}
(and also amend the formulation a bit later on the help page
where expr is mentioned again).
Martin
> Thanks to all R Core Team members for their great work for
> all of us.
> Hope this helps,
> Rui Barradas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trivial typo in help("browser")
Thanks, fixed now.
Tomas
On 7/29/21 8:59 AM, Peter Langfelder wrote:
I'm also not a native speaker but my take is that a "be" is missing in
the sentence and it should read
An expression, which if it evaluates to TRUE the debugger will be invoked,
otherwise control is returned directly.
On Wed, Jul 28, 2021 at 11:52 PM Rui Barradas wrote:
Hello,
R 4.1.0 on Ubuntu 20.04, session info below.
I am not an English native speaker but in help("browser"), section
Arguments, argument expr, there is a wrong verb tense:
"invoked" should be "invoke", right?
expr
An expression, which if it evaluates to TRUE the debugger will invoked,
otherwise control is returned directly.
sessionInfo()
R version 4.1.0 (2021-05-18)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 20.04.2 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0
locale:
[1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
[3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
[5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
[7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.1.0
Thanks to all R Core Team members for their great work for all of us.
Hope this helps,
Rui Barradas
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Trivial typo in help("browser")
I'm also not a native speaker but my take is that a "be" is missing in
the sentence and it should read
An expression, which if it evaluates to TRUE the debugger will be invoked,
otherwise control is returned directly.
On Wed, Jul 28, 2021 at 11:52 PM Rui Barradas wrote:
>
> Hello,
>
> R 4.1.0 on Ubuntu 20.04, session info below.
>
> I am not an English native speaker but in help("browser"), section
> Arguments, argument expr, there is a wrong verb tense:
>
> "invoked" should be "invoke", right?
>
> expr
> An expression, which if it evaluates to TRUE the debugger will invoked,
> otherwise control is returned directly.
>
>
>
> sessionInfo()
> R version 4.1.0 (2021-05-18)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 20.04.2 LTS
>
> Matrix products: default
> BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.9.0
> LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.9.0
>
> locale:
> [1] LC_CTYPE=pt_PT.UTF-8 LC_NUMERIC=C
> [3] LC_TIME=pt_PT.UTF-8LC_COLLATE=pt_PT.UTF-8
> [5] LC_MONETARY=pt_PT.UTF-8LC_MESSAGES=pt_PT.UTF-8
> [7] LC_PAPER=pt_PT.UTF-8 LC_NAME=C
> [9] LC_ADDRESS=C LC_TELEPHONE=C
> [11] LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats graphics grDevices utils datasets methods base
>
> loaded via a namespace (and not attached):
> [1] compiler_4.1.0
>
>
>
> Thanks to all R Core Team members for their great work for all of us.
>
> Hope this helps,
>
> Rui Barradas
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
