[Rd] GCC warning
I am trying to submit a package on CRAN, and everything passes ok on all platforms but Debian, where CRAN responds with an automatic "significant" warning: * checking whether package ‘QCA’ can be installed ... [35s/35s] WARNING Found the following significant warnings: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: ‘__builtin_strncpy’ output may be truncated copying 12 bytes from a string of length 79 [-Wstringop-truncation] See ‘/srv/hornik/tmp/CRAN/QCA.Rcheck/00install.out’ for details. I know the cause of this: using a cursomized version of some external C library, coupled with in the Description. But I do not know hot to get past this warning, since it refers to a builtin GCC function strncpy. As far as I read, this should be solved by a simple GCC upgrade to the newest version, but that is something outside my code base, since GCC resides on the CRAN servers. In the meantime, to get the package published, did anyone encountered a similar problem? If so, is there a workaround? — Adrian Dusa University of Bucharest Romanian Social Data Archive Soseaua Panduri nr. 90-92 050663 Bucharest sector 5 Romania https://adriandusa.eu __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Build failing on win64
As of commit 78536 earlier this morning the build is failing on windows 64, see https://r-devel.github.io I cannot immediately spot what is the problem. The build fails with: installing 'sysdata.rda' make[3]: *** [../../../share/make/basepkg.mk:151: sysdata] Error 127 make[2]: *** [Makefile.win:22: all] Error 2 make[1]: *** [Makefile.win:32: R] Error 1 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
Hi Martin et al,
On Thu, May 21, 2020 at 9:42 AM Martin Maechler
wrote:
> > Hervé Pagès
> > on Fri, 15 May 2020 13:44:28 -0700 writes:
>
> > There is still the situation where **both** 'sep' and 'collapse' are
> > specified:
>
> >> paste(integer(0), "nth", sep="", collapse=",")
> > [1] "nth"
>
> > In that case 'recycle0' should **not** be ignored i.e.
>
> > paste(integer(0), "nth", sep="", collapse=",", recycle0=TRUE)
>
> > should return the empty string (and not character(0) like it does at
> the
> > moment).
>
> > In other words, 'recycle0' should only control the first operation
> (the
> > operation controlled by 'sep'). Which makes plenty of sense: the 1st
> > operation is binary (or n-ary) while the collapse operation is
> unary.
> > There is no concept of recycling in the context of unary operations.
>
> Interesting, ..., and sounding somewhat convincing.
>
> > On 5/15/20 11:25, Gabriel Becker wrote:
> >> Hi all,
> >>
> >> This makes sense to me, but I would think that recycle0 and
> collapse
> >> should actually be incompatible and paste should throw an error if
> >> recycle0 were TRUE and collapse were declared in the same call. I
> don't
> >> think the value of recycle0 should be silently ignored if it is
> actively
> >> specified.
> >>
> >> ~G
>
> Just to summarize what I think we should know and agree (or be
> be "disproven") and where this comes from ...
>
> 1) recycle0 is a new R 4.0.0 option in paste() / paste0() which by default
>(recycle0 = FALSE) should (and *does* AFAIK) not change anything,
>hence paste() / paste0() behave completely back-compatible
>if recycle0 is kept to FALSE.
>
> 2) recycle0 = TRUE is meant to give different behavior, notably
>0-length arguments (among '...') should result in 0-length results.
>
>The above does not specify what this means in detail, see 3)
>
> 3) The current R 4.0.0 implementation (for which I'm primarily responsible)
>and help(paste) are in accordance.
>Notably the help page (Arguments -> 'recycle0' ; Details 1st para ;
> Examples)
>says and shows how the 4.0.0 implementation has been meant to work.
>
> 4) Several provenly smart members of the R community argue that
>both the implementation and the documentation of 'recycle0 =
>TRUE' should be changed to be more logical / coherent / sensical ..
>
> Is the above all correct in your view?
>
> Assuming yes, I read basically two proposals, both agreeing
> that recycle0 = TRUE should only ever apply to the action of 'sep'
> but not the action of 'collapse'.
>
> 1) Bill and Hervé (I think) propose that 'recycle0' should have
>no effect whenever 'collapse = '
>
> 2) Gabe proposes that 'collapse = ' and 'recycle0 = TRUE'
>should be declared incompatible and error. If going in that
>direction, I could also see them to give a warning (and
>continue as if recycle = FALSE).
>
Herve makes a good point about when sep and collapse are both set. That
said, if the user explicitly sets recycle0, Personally, I don't think it
should be silently ignored under any configuration of other arguments.
If all of the arguments are to go into effect, the question then becomes
one of ordering, I think.
Consider
paste(c("a", "b"), NULL, c("c", "d"), sep = " ", collapse = ",",
recycle0=TRUE)
Currently that returns character(0), becuase the logic is essenttially (in
pseudo-code)
collapse(paste(c("a", "b"), NULL, c("c", "d"), sep = " ",
recycle0=TRUE), collapse = ", ", recycle0=TRUE)
-> collapse(character(0), collapse = ", " recycle0=TRUE)
-> character(0)
Now Bill Dunlap argued, fairly convincingly I think, that paste(...,
collapse=) should *always* return a character vector of length
exactly one. With recycle0, though, it will return "" via the progression
paste(c("a", "b"), NULL, c("c", "d"), sep = " ", collapse = ",",
recycle0=TRUE)
-> collapse(character(0), collapse = ", ")
-> ""
because recycle0 is still applied to the sep-based operation which occurs
before collapse, thus leaving a vector of length 0 to collapse.
That is consistent but seems unlikely to be what the user wanted, imho. I
think if it does this there should be at least a warning when paste
collapses to "" this way, if it is allowed at all (ie if mixing
collapse= and recycle0=TRUE is not simply made an error).
I would like to hear others' thoughts as well though. @Pages, Herve
@William Dunlap is "" what you
envision as thee desired and useful behavior there?
Best,
~G
> I have not yet my mind up but would tend to agree to "you guys",
> but I think that other R Core members should chime in, too.
>
> Martin
>
> >> On Fri, May 15, 2020 at 11:05 AM Hervé Pagès >> > wrote:
> >>
> >> Totally agree with that.
> >>
> >> H.
> >>
> >> On 5/15/20 10:34, William Dunlap via R-devel wrote:
> >> > I agree: paste(
Re: [Rd] Build failing on win64
Thanks, fixed now. Tomas On 5/22/20 10:18 AM, Jeroen Ooms wrote: As of commit 78536 earlier this morning the build is failing on windows 64, see https://r-devel.github.io I cannot immediately spot what is the problem. The build fails with: installing 'sysdata.rda' make[3]: *** [../../../share/make/basepkg.mk:151: sysdata] Error 127 make[2]: *** [Makefile.win:22: all] Error 2 make[1]: *** [Makefile.win:32: R] Error 1 __ 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
[Rd] Compatibility issues caused by new simplify argument in apply function
Dear R Developers,
the new simplify argument in apply causes that my package (hsdar) does not
pass the
checks in R-devel.
The workaround, Kurt Hornik send me, is working for the R-code:
if("simplify" %in% names(formals(base::apply)))
do something
else
do something else
Unfortunately, I cannot conditionalize the man pages of the functions. I get
the message
that "applySpeclib.Rd:12-14: Section \Sexpr is unrecognized and will be
dropped" if I try to
dynamically define the entire usage section. If I try to use \Sexpr inside the
\usage section,
I get the following warning: "applySpeclib.Rd:13-15: Tag \Sexpr is invalid in
a \usage block"
Does anybody have an idea how to proceed. The full code is available below.
Thanks
Lukas
*1. Code for full usage section:*
..
\description{
Apply function over all spectra or a subset of spectra in a \code{Speclib}.
}
\Sexpr[echo=TRUE,results=rd,stage=install]{
hsdar:::.applyInHelp1("Speclib", usage = TRUE)
}
\arguments{
..
*Function .applyInHelp1*
.applyInHelp1 <- function(fun_name, usage)
{
if (usage)
{
if ("simplify" %in% names(formals(base::apply)))
{
return(paste0("\\usage{\n",
"\\S4method{apply}{", fun_name, "}(X, MARGIN, FUN, ...,
simplify = TRUE)\n",
"}"))
} else {
return(paste0("\\usage{\n",
"\\S4method{apply}{", fun_name, "}(X, MARGIN, FUN, ...)
\n",
"}"))
}
} else {
if ("simplify" %in% names(formals(base::apply)))
{
return("}\n\\item{simplify}{Currently ignored")
} else {
return("")
}
}
}
*2. Using \Sexpr inside the \usage block*
\usage{
\S4method{apply}{Speclib}(X, FUN, bySI = NULL, ...
\Sexpr[echo=TRUE,results=rd,stage=install]{
hsdar:::.applyInHelp2(usage = TRUE)
}
)
}
*Function .applyInHelp2*
.applyInHelp2 <- function(usage)
{
if (usage)
{
if ("simplify" %in% names(formals(base::apply)))
{
return(", simplify = TRUE)")
}
} else {
if ("simplify" %in% names(formals(base::apply)))
{
return("}\n\\item{simplify}{Currently ignored")
} else {
return("")
}
}
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] pbirthday() for larger number of classes
Hi,
pbirthday(, coincident = 2) starts to issue warnings (see (*) below)
for larger number of classes (R 4.0.0, R-devel
./src/library/stats/R/birthday.R:47).
The default coincident = 2 is computed as 1 - prod((c:(c - n +
1))/rep(c, n)) where c = classes.
Using exp(log(...)), one can derive the return value if(n > 0) 1 -
exp(sum(log1p(-(0:(n-1))/c))) else 0.
Simplifying this a bit further one obtains if(n >= 2) 1 -
exp(sum(log1p(-(1:(n-1))/c))) else 0.
For large c, sum(log1p(-(1:(n-1))/c)) is close to 0, so a more robust
version would be
to return if(n >= 2) -expm1(sum(log1p(-(1:(n-1))/c))) else 0 in the
default case 'coincident = 2'
(internally: if (k == 2) ...).
## Auxiliary function *just* considering 'coincident = 2'
pbirthday2 <- function(n, classes = 365) {
c <- classes # as pbirthday()
if(n >= 2) -expm1(sum(log1p(-(1:(n-1))/c))) else 0 # return value
suggested for the case 'if (k == 2) ...'
}
pbirthday (3, classes = 2) == pbirthday2(3, classes = 2) # identical
pbirthday (3, classes = 2^53) == pbirthday2(3, classes = 2^53) # not
identical anymore...
stopifnot(all.equal(pbirthday (3, classes = 2^53), pbirthday2(3,
classes = 2^53))) # ... but numerically equal
pbirthday (3, classes = 2^54) # warnings start to appear (*)
pbirthday2(3, classes = 2^54) # fine
pbirthday (3, classes = 2^56) == 0 # numerically indistinguishable from 0
pbirthday2(3, classes = 2^56) # fine
Cheers,
M
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Compatibility issues caused by new simplify argument in apply function
You didn't explained what the error is. This is what it looks like to
me, but I'm probably wrong in some details:
1. R-devel added an argument to the apply() function, so the header has
changed from
function (X, MARGIN, FUN, ...)
to
function(X, MARGIN, FUN, ..., simplify = TRUE)
2. Your package converted the function apply() to an S4 generic.
3. Now the signatures of your methods for this generic need to have the
simplify argument, but if you do that, they won't work in previous
versions of R.
You'd like to have conditional code and documentation to depend on the
version of R.
Is that all correct?
I don't think it's possible, for the reasons you found. Certainly you
can have conditional code, but the docs are going to fail.
One thing that might work is in versions of R before this change, export
your own version of apply, with the change in place, i.e.
if(!("simplify" %in% names(formals(base::apply
apply <- function(X, MARGIN, FUN, ..., simplify = TRUE) {
base::apply(X, MARGIN, FUN, ...)
}
and then conditionally export "apply" in these old versions. Then your
docs could match the new version everywhere.
Another thing is to maintain two versions of your package, one for R
versions before the change, another for versions after the change. Add
appropriate entries in the DESCRIPTION file, e.g.
Depends: R (> 4.0)
Another is to argue with R Core that this change to a really old
function is too hard to accommodate, and they should back it out, maybe
by making a new function with the new signature.
Or you could make a new function with the old signature, and use that
instead of apply().
Duncan Murdoch
On 22/05/2020 6:26 a.m., Lukas Lehnert via R-devel wrote:
Dear R Developers,
the new simplify argument in apply causes that my package (hsdar) does not
pass the
checks in R-devel.
The workaround, Kurt Hornik send me, is working for the R-code:
if("simplify" %in% names(formals(base::apply)))
do something
else
do something else
Unfortunately, I cannot conditionalize the man pages of the functions. I get
the message
that "applySpeclib.Rd:12-14: Section \Sexpr is unrecognized and will be
dropped" if I try to
dynamically define the entire usage section. If I try to use \Sexpr inside the
\usage section,
I get the following warning: "applySpeclib.Rd:13-15: Tag \Sexpr is invalid in
a \usage block"
Does anybody have an idea how to proceed. The full code is available below.
Thanks
Lukas
*1. Code for full usage section:*
..
\description{
Apply function over all spectra or a subset of spectra in a \code{Speclib}.
}
\Sexpr[echo=TRUE,results=rd,stage=install]{
hsdar:::.applyInHelp1("Speclib", usage = TRUE)
}
\arguments{
..
*Function .applyInHelp1*
.applyInHelp1 <- function(fun_name, usage)
{
if (usage)
{
if ("simplify" %in% names(formals(base::apply)))
{
return(paste0("\\usage{\n",
"\\S4method{apply}{", fun_name, "}(X, MARGIN, FUN, ...,
simplify = TRUE)\n",
"}"))
} else {
return(paste0("\\usage{\n",
"\\S4method{apply}{", fun_name, "}(X, MARGIN, FUN, ...)
\n",
"}"))
}
} else {
if ("simplify" %in% names(formals(base::apply)))
{
return("}\n\\item{simplify}{Currently ignored")
} else {
return("")
}
}
}
*2. Using \Sexpr inside the \usage block*
\usage{
\S4method{apply}{Speclib}(X, FUN, bySI = NULL, ...
\Sexpr[echo=TRUE,results=rd,stage=install]{
hsdar:::.applyInHelp2(usage = TRUE)
}
)
}
*Function .applyInHelp2*
.applyInHelp2 <- function(usage)
{
if (usage)
{
if ("simplify" %in% names(formals(base::apply)))
{
return(", simplify = TRUE)")
}
} else {
if ("simplify" %in% names(formals(base::apply)))
{
return("}\n\\item{simplify}{Currently ignored")
} else {
return("")
}
}
}
__
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] Compatibility issues caused by new simplify argument in apply function
Interesting problem. I'm very rusty on S4 but would one solution be
to, already now, add 'simplify = TRUE' to the S4 method and document
it;
setMethod("apply", signature(X = "Speclib"),
function(X,
FUN,
bySI = NULL,
...,
simplify = TRUE) {
?
Henrik
On Fri, May 22, 2020 at 6:26 AM Duncan Murdoch wrote:
>
> You didn't explained what the error is. This is what it looks like to
> me, but I'm probably wrong in some details:
>
> 1. R-devel added an argument to the apply() function, so the header has
> changed from
>
>function (X, MARGIN, FUN, ...)
>
> to
>
>function(X, MARGIN, FUN, ..., simplify = TRUE)
>
> 2. Your package converted the function apply() to an S4 generic.
>
> 3. Now the signatures of your methods for this generic need to have the
> simplify argument, but if you do that, they won't work in previous
> versions of R.
>
> You'd like to have conditional code and documentation to depend on the
> version of R.
>
> Is that all correct?
>
> I don't think it's possible, for the reasons you found. Certainly you
> can have conditional code, but the docs are going to fail.
>
> One thing that might work is in versions of R before this change, export
> your own version of apply, with the change in place, i.e.
>
> if(!("simplify" %in% names(formals(base::apply
>apply <- function(X, MARGIN, FUN, ..., simplify = TRUE) {
> base::apply(X, MARGIN, FUN, ...)
>}
>
> and then conditionally export "apply" in these old versions. Then your
> docs could match the new version everywhere.
>
> Another thing is to maintain two versions of your package, one for R
> versions before the change, another for versions after the change. Add
> appropriate entries in the DESCRIPTION file, e.g.
>
> Depends: R (> 4.0)
>
> Another is to argue with R Core that this change to a really old
> function is too hard to accommodate, and they should back it out, maybe
> by making a new function with the new signature.
>
> Or you could make a new function with the old signature, and use that
> instead of apply().
>
> Duncan Murdoch
>
>
>
> On 22/05/2020 6:26 a.m., Lukas Lehnert via R-devel wrote:
> > Dear R Developers,
> >
> > the new simplify argument in apply causes that my package (hsdar) does not
> > pass the
> > checks in R-devel.
> >
> > The workaround, Kurt Hornik send me, is working for the R-code:
> > if("simplify" %in% names(formals(base::apply)))
> > do something
> > else
> > do something else
> >
> > Unfortunately, I cannot conditionalize the man pages of the functions. I get
> > the message
> > that "applySpeclib.Rd:12-14: Section \Sexpr is unrecognized and will be
> > dropped" if I try to
> > dynamically define the entire usage section. If I try to use \Sexpr inside
> > the
> > \usage section,
> > I get the following warning: "applySpeclib.Rd:13-15: Tag \Sexpr is invalid
> > in
> > a \usage block"
> >
> > Does anybody have an idea how to proceed. The full code is available below.
> >
> > Thanks
> >
> > Lukas
> >
> >
> > *1. Code for full usage section:*
> > ..
> > \description{
> > Apply function over all spectra or a subset of spectra in a \code{Speclib}.
> > }
> >
> > \Sexpr[echo=TRUE,results=rd,stage=install]{
> >hsdar:::.applyInHelp1("Speclib", usage = TRUE)
> > }
> >
> > \arguments{
> > ..
> >
> > *Function .applyInHelp1*
> > .applyInHelp1 <- function(fun_name, usage)
> > {
> >if (usage)
> >{
> > if ("simplify" %in% names(formals(base::apply)))
> > {
> >return(paste0("\\usage{\n",
> > "\\S4method{apply}{", fun_name, "}(X, MARGIN, FUN, ...,
> > simplify = TRUE)\n",
> > "}"))
> > } else {
> >return(paste0("\\usage{\n",
> > "\\S4method{apply}{", fun_name, "}(X, MARGIN, FUN, ...)
> > \n",
> > "}"))
> > }
> >} else {
> > if ("simplify" %in% names(formals(base::apply)))
> > {
> >return("}\n\\item{simplify}{Currently ignored")
> > } else {
> >return("")
> > }
> >}
> > }
> >
> >
> > *2. Using \Sexpr inside the \usage block*
> > \usage{
> > \S4method{apply}{Speclib}(X, FUN, bySI = NULL, ...
> > \Sexpr[echo=TRUE,results=rd,stage=install]{
> >hsdar:::.applyInHelp2(usage = TRUE)
> > }
> > )
> > }
> >
> >
> > *Function .applyInHelp2*
> > .applyInHelp2 <- function(usage)
> > {
> >if (usage)
> >{
> > if ("simplify" %in% names(formals(base::apply)))
> > {
> >return(", simplify = TRUE)")
> > }
> >} else {
> > if ("simplify" %in% names(formals(base::apply)))
> > {
> >return("}\n\\item{simplify}{Currently ignored")
> > } else {
> >return("")
> > }
> >}
> > }
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
>
> __
> R-devel@r-project
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
I think that
paste(c("a", "b"), NULL, c("c", "d"), sep = " ", collapse = ",",
recycle0=TRUE)
should just return an empty string and don't see why it needs to emit a
warning or raise an error. To me it does exactly what the user is asking
for, which is to change how the 3 arguments are recycled **before** the
'sep' operation.
The 'recycle0' argument has no business in the 'collapse' operation
(which comes after the 'sep' operation): this operation still behaves
like it always had.
That's all there is to it.
H.
On 5/22/20 03:00, Gabriel Becker wrote:
Hi Martin et al,
On Thu, May 21, 2020 at 9:42 AM Martin Maechler
mailto:maech...@stat.math.ethz.ch>> wrote:
> Hervé Pagès
> on Fri, 15 May 2020 13:44:28 -0700 writes:
> There is still the situation where **both** 'sep' and
'collapse' are
> specified:
>> paste(integer(0), "nth", sep="", collapse=",")
> [1] "nth"
> In that case 'recycle0' should **not** be ignored i.e.
> paste(integer(0), "nth", sep="", collapse=",", recycle0=TRUE)
> should return the empty string (and not character(0) like it
does at the
> moment).
> In other words, 'recycle0' should only control the first
operation (the
> operation controlled by 'sep'). Which makes plenty of sense:
the 1st
> operation is binary (or n-ary) while the collapse operation
is unary.
> There is no concept of recycling in the context of unary
operations.
Interesting, ..., and sounding somewhat convincing.
> On 5/15/20 11:25, Gabriel Becker wrote:
>> Hi all,
>>
>> This makes sense to me, but I would think that recycle0 and
collapse
>> should actually be incompatible and paste should throw an
error if
>> recycle0 were TRUE and collapse were declared in the same
call. I don't
>> think the value of recycle0 should be silently ignored if it
is actively
>> specified.
>>
>> ~G
Just to summarize what I think we should know and agree (or be
be "disproven") and where this comes from ...
1) recycle0 is a new R 4.0.0 option in paste() / paste0() which by
default
(recycle0 = FALSE) should (and *does* AFAIK) not change anything,
hence paste() / paste0() behave completely back-compatible
if recycle0 is kept to FALSE.
2) recycle0 = TRUE is meant to give different behavior, notably
0-length arguments (among '...') should result in 0-length results.
The above does not specify what this means in detail, see 3)
3) The current R 4.0.0 implementation (for which I'm primarily
responsible)
and help(paste) are in accordance.
Notably the help page (Arguments -> 'recycle0' ; Details 1st
para ; Examples)
says and shows how the 4.0.0 implementation has been meant to work.
4) Several provenly smart members of the R community argue that
both the implementation and the documentation of 'recycle0 =
TRUE' should be changed to be more logical / coherent / sensical ..
Is the above all correct in your view?
Assuming yes, I read basically two proposals, both agreeing
that recycle0 = TRUE should only ever apply to the action of 'sep'
but not the action of 'collapse'.
1) Bill and Hervé (I think) propose that 'recycle0' should have
no effect whenever 'collapse = '
2) Gabe proposes that 'collapse = ' and 'recycle0 = TRUE'
should be declared incompatible and error. If going in that
direction, I could also see them to give a warning (and
continue as if recycle = FALSE).
Herve makes a good point about when sep and collapse are both set. That
said, if the user explicitly sets recycle0, Personally, I don't think it
should be silently ignored under any configuration of other arguments.
If all of the arguments are to go into effect, the question then becomes
one of ordering, I think.
Consider
paste(c("a", "b"), NULL, c("c", "d"), sep = " ", collapse = ",",
recycle0=TRUE)
Currently that returns character(0), becuase the logic is
essenttially (in pseudo-code)
collapse(paste(c("a", "b"), NULL, c("c", "d"), sep = " ",
recycle0=TRUE), collapse = ", ", recycle0=TRUE)
-> collapse(character(0), collapse = ", " recycle0=TRUE)
-> character(0)
Now Bill Dunlap argued, fairly convincingly I think, that paste(...,
collapse=) should /always/ return a character vector of length
exactly one. With recycle0, though, it will return "" via the progression
paste(c("a", "b"), NULL, c("c", "d"), sep = " ", collapse = ",",
recycle0=TRUE)
-> collapse(character(0), collapse = ", ")
-> ""
because recycle0 is still applied to the sep-based operation which
occurs before collapse, thus leaving a vector of length 0 to collapse.
That is
Re: [Rd] Compatibility issues caused by new simplify argument in apply function
On 22/05/2020 11:47 a.m., Henrik Bengtsson wrote:
Interesting problem. I'm very rusty on S4 but would one solution be
to, already now, add 'simplify = TRUE' to the S4 method and document
it;
setMethod("apply", signature(X = "Speclib"),
function(X,
FUN,
bySI = NULL,
...,
simplify = TRUE) {
?
Yes, that sounds like an ideal solution. The docs can say it is ignored
in old versions and passed on in new ones.
Duncan Murdoch
Henrik
On Fri, May 22, 2020 at 6:26 AM Duncan Murdoch wrote:
You didn't explained what the error is. This is what it looks like to
me, but I'm probably wrong in some details:
1. R-devel added an argument to the apply() function, so the header has
changed from
function (X, MARGIN, FUN, ...)
to
function(X, MARGIN, FUN, ..., simplify = TRUE)
2. Your package converted the function apply() to an S4 generic.
3. Now the signatures of your methods for this generic need to have the
simplify argument, but if you do that, they won't work in previous
versions of R.
You'd like to have conditional code and documentation to depend on the
version of R.
Is that all correct?
I don't think it's possible, for the reasons you found. Certainly you
can have conditional code, but the docs are going to fail.
One thing that might work is in versions of R before this change, export
your own version of apply, with the change in place, i.e.
if(!("simplify" %in% names(formals(base::apply
apply <- function(X, MARGIN, FUN, ..., simplify = TRUE) {
base::apply(X, MARGIN, FUN, ...)
}
and then conditionally export "apply" in these old versions. Then your
docs could match the new version everywhere.
Another thing is to maintain two versions of your package, one for R
versions before the change, another for versions after the change. Add
appropriate entries in the DESCRIPTION file, e.g.
Depends: R (> 4.0)
Another is to argue with R Core that this change to a really old
function is too hard to accommodate, and they should back it out, maybe
by making a new function with the new signature.
Or you could make a new function with the old signature, and use that
instead of apply().
Duncan Murdoch
On 22/05/2020 6:26 a.m., Lukas Lehnert via R-devel wrote:
Dear R Developers,
the new simplify argument in apply causes that my package (hsdar) does not
pass the
checks in R-devel.
The workaround, Kurt Hornik send me, is working for the R-code:
if("simplify" %in% names(formals(base::apply)))
do something
else
do something else
Unfortunately, I cannot conditionalize the man pages of the functions. I get
the message
that "applySpeclib.Rd:12-14: Section \Sexpr is unrecognized and will be
dropped" if I try to
dynamically define the entire usage section. If I try to use \Sexpr inside the
\usage section,
I get the following warning: "applySpeclib.Rd:13-15: Tag \Sexpr is invalid in
a \usage block"
Does anybody have an idea how to proceed. The full code is available below.
Thanks
Lukas
*1. Code for full usage section:*
..
\description{
Apply function over all spectra or a subset of spectra in a \code{Speclib}.
}
\Sexpr[echo=TRUE,results=rd,stage=install]{
hsdar:::.applyInHelp1("Speclib", usage = TRUE)
}
\arguments{
..
*Function .applyInHelp1*
.applyInHelp1 <- function(fun_name, usage)
{
if (usage)
{
if ("simplify" %in% names(formals(base::apply)))
{
return(paste0("\\usage{\n",
"\\S4method{apply}{", fun_name, "}(X, MARGIN, FUN, ...,
simplify = TRUE)\n",
"}"))
} else {
return(paste0("\\usage{\n",
"\\S4method{apply}{", fun_name, "}(X, MARGIN, FUN, ...)
\n",
"}"))
}
} else {
if ("simplify" %in% names(formals(base::apply)))
{
return("}\n\\item{simplify}{Currently ignored")
} else {
return("")
}
}
}
*2. Using \Sexpr inside the \usage block*
\usage{
\S4method{apply}{Speclib}(X, FUN, bySI = NULL, ...
\Sexpr[echo=TRUE,results=rd,stage=install]{
hsdar:::.applyInHelp2(usage = TRUE)
}
)
}
*Function .applyInHelp2*
.applyInHelp2 <- function(usage)
{
if (usage)
{
if ("simplify" %in% names(formals(base::apply)))
{
return(", simplify = TRUE)")
}
} else {
if ("simplify" %in% names(formals(base::apply)))
{
return("}\n\\item{simplify}{Currently ignored")
} else {
return("")
}
}
}
__
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] Compatibility issues caused by new simplify argument in apply function
I am sorry for being not specific enough. Both of you were right with your
guess how the initial problem looked like.
I followed the suggestion of Henrik and at least on my computer it seems to
work (sometimes solutions are much easier than you think). Let's see what CRAN
tells me...
Thank you for your time and thinking about the problem!
Best
Lukas
Am Freitag, 22. Mai 2020, 17:47:00 CEST schrieb Henrik Bengtsson:
> Interesting problem. I'm very rusty on S4 but would one solution be
> to, already now, add 'simplify = TRUE' to the S4 method and document
> it;
>
> setMethod("apply", signature(X = "Speclib"),
> function(X,
>FUN,
>bySI = NULL,
>...,
>simplify = TRUE) {
>
> ?
>
> Henrik
>
> On Fri, May 22, 2020 at 6:26 AM Duncan Murdoch
wrote:
> > You didn't explained what the error is. This is what it looks like to
> > me, but I'm probably wrong in some details:
> >
> > 1. R-devel added an argument to the apply() function, so the header has
> > changed from
> >
> >function (X, MARGIN, FUN, ...)
> >
> > to
> >
> >function(X, MARGIN, FUN, ..., simplify = TRUE)
> >
> > 2. Your package converted the function apply() to an S4 generic.
> >
> > 3. Now the signatures of your methods for this generic need to have the
> > simplify argument, but if you do that, they won't work in previous
> > versions of R.
> >
> > You'd like to have conditional code and documentation to depend on the
> > version of R.
> >
> > Is that all correct?
> >
> > I don't think it's possible, for the reasons you found. Certainly you
> > can have conditional code, but the docs are going to fail.
> >
> > One thing that might work is in versions of R before this change, export
> > your own version of apply, with the change in place, i.e.
> >
> > if(!("simplify" %in% names(formals(base::apply
> >
> >apply <- function(X, MARGIN, FUN, ..., simplify = TRUE) {
> >
> > base::apply(X, MARGIN, FUN, ...)
> >
> >}
> >
> > and then conditionally export "apply" in these old versions. Then your
> > docs could match the new version everywhere.
> >
> > Another thing is to maintain two versions of your package, one for R
> > versions before the change, another for versions after the change. Add
> > appropriate entries in the DESCRIPTION file, e.g.
> >
> > Depends: R (> 4.0)
> >
> > Another is to argue with R Core that this change to a really old
> > function is too hard to accommodate, and they should back it out, maybe
> > by making a new function with the new signature.
> >
> > Or you could make a new function with the old signature, and use that
> > instead of apply().
> >
> > Duncan Murdoch
> >
> > On 22/05/2020 6:26 a.m., Lukas Lehnert via R-devel wrote:
> > > Dear R Developers,
> > >
> > > the new simplify argument in apply causes that my package (hsdar) does
> > > not
> > > pass the
> > > checks in R-devel.
> > >
> > > The workaround, Kurt Hornik send me, is working for the R-code:
> > > if("simplify" %in% names(formals(base::apply)))
> > >
> > > do something
> > >
> > > else
> > >
> > > do something else
> > >
> > > Unfortunately, I cannot conditionalize the man pages of the functions. I
> > > get the message
> > > that "applySpeclib.Rd:12-14: Section \Sexpr is unrecognized and will be
> > > dropped" if I try to
> > > dynamically define the entire usage section. If I try to use \Sexpr
> > > inside the \usage section,
> > > I get the following warning: "applySpeclib.Rd:13-15: Tag \Sexpr is
> > > invalid in a \usage block"
> > >
> > > Does anybody have an idea how to proceed. The full code is available
> > > below.
> > >
> > > Thanks
> > >
> > > Lukas
> > >
> > >
> > > *1. Code for full usage section:*
> > > ..
> > > \description{
> > > Apply function over all spectra or a subset of spectra in a
> > > \code{Speclib}.
> > > }
> > >
> > > \Sexpr[echo=TRUE,results=rd,stage=install]{
> > >
> > >hsdar:::.applyInHelp1("Speclib", usage = TRUE)
> > >
> > > }
> > >
> > > \arguments{
> > > ..
> > >
> > > *Function .applyInHelp1*
> > > .applyInHelp1 <- function(fun_name, usage)
> > > {
> > >
> > >if (usage)
> > >{
> > >
> > > if ("simplify" %in% names(formals(base::apply)))
> > > {
> > >
> > >return(paste0("\\usage{\n",
> > >
> > > "\\S4method{apply}{", fun_name, "}(X, MARGIN, FUN,
> > > ...,
> > >
> > > simplify = TRUE)\n",
> > >
> > > "}"))
> > >
> > > } else {
> > >
> > >return(paste0("\\usage{\n",
> > >
> > > "\\S4method{apply}{", fun_name, "}(X, MARGIN, FUN,
> > > ...)
> > >
> > > \n",
> > >
> > > "}"))
> > >
> > > }
> > >
> > >} else {
> > >
> > > if ("simplify" %in% names(formals(base::apply)))
> > > {
> > >
> > >return("}\n\\ite
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
I agree with Herve, processing collapse happens last so collapse=non-NULL
always leads to a single character string being returned, the same as
paste(collapse=""). See the altPaste function I posted yesterday.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, May 22, 2020 at 9:12 AM Hervé Pagès wrote:
> I think that
>
> paste(c("a", "b"), NULL, c("c", "d"), sep = " ", collapse = ",",
> recycle0=TRUE)
>
> should just return an empty string and don't see why it needs to emit a
> warning or raise an error. To me it does exactly what the user is asking
> for, which is to change how the 3 arguments are recycled **before** the
> 'sep' operation.
>
> The 'recycle0' argument has no business in the 'collapse' operation
> (which comes after the 'sep' operation): this operation still behaves
> like it always had.
>
> That's all there is to it.
>
> H.
>
>
> On 5/22/20 03:00, Gabriel Becker wrote:
> > Hi Martin et al,
> >
> >
> >
> > On Thu, May 21, 2020 at 9:42 AM Martin Maechler
> > mailto:maech...@stat.math.ethz.ch>> wrote:
> >
> > > Hervé Pagès
> > > on Fri, 15 May 2020 13:44:28 -0700 writes:
> >
> > > There is still the situation where **both** 'sep' and
> > 'collapse' are
> > > specified:
> >
> > >> paste(integer(0), "nth", sep="", collapse=",")
> > > [1] "nth"
> >
> > > In that case 'recycle0' should **not** be ignored i.e.
> >
> > > paste(integer(0), "nth", sep="", collapse=",", recycle0=TRUE)
> >
> > > should return the empty string (and not character(0) like it
> > does at the
> > > moment).
> >
> > > In other words, 'recycle0' should only control the first
> > operation (the
> > > operation controlled by 'sep'). Which makes plenty of sense:
> > the 1st
> > > operation is binary (or n-ary) while the collapse operation
> > is unary.
> > > There is no concept of recycling in the context of unary
> > operations.
> >
> > Interesting, ..., and sounding somewhat convincing.
> >
> > > On 5/15/20 11:25, Gabriel Becker wrote:
> > >> Hi all,
> > >>
> > >> This makes sense to me, but I would think that recycle0 and
> > collapse
> > >> should actually be incompatible and paste should throw an
> > error if
> > >> recycle0 were TRUE and collapse were declared in the same
> > call. I don't
> > >> think the value of recycle0 should be silently ignored if it
> > is actively
> > >> specified.
> > >>
> > >> ~G
> >
> > Just to summarize what I think we should know and agree (or be
> > be "disproven") and where this comes from ...
> >
> > 1) recycle0 is a new R 4.0.0 option in paste() / paste0() which by
> > default
> > (recycle0 = FALSE) should (and *does* AFAIK) not change anything,
> > hence paste() / paste0() behave completely back-compatible
> > if recycle0 is kept to FALSE.
> >
> > 2) recycle0 = TRUE is meant to give different behavior, notably
> > 0-length arguments (among '...') should result in 0-length
> results.
> >
> > The above does not specify what this means in detail, see 3)
> >
> > 3) The current R 4.0.0 implementation (for which I'm primarily
> > responsible)
> > and help(paste) are in accordance.
> > Notably the help page (Arguments -> 'recycle0' ; Details 1st
> > para ; Examples)
> > says and shows how the 4.0.0 implementation has been meant to
> work.
> >
> > 4) Several provenly smart members of the R community argue that
> > both the implementation and the documentation of 'recycle0 =
> > TRUE' should be changed to be more logical / coherent /
> sensical ..
> >
> > Is the above all correct in your view?
> >
> > Assuming yes, I read basically two proposals, both agreeing
> > that recycle0 = TRUE should only ever apply to the action of 'sep'
> > but not the action of 'collapse'.
> >
> > 1) Bill and Hervé (I think) propose that 'recycle0' should have
> > no effect whenever 'collapse = '
> >
> > 2) Gabe proposes that 'collapse = ' and 'recycle0 = TRUE'
> > should be declared incompatible and error. If going in that
> > direction, I could also see them to give a warning (and
> > continue as if recycle = FALSE).
> >
> >
> > Herve makes a good point about when sep and collapse are both set. That
> > said, if the user explicitly sets recycle0, Personally, I don't think it
> > should be silently ignored under any configuration of other arguments.
> >
> > If all of the arguments are to go into effect, the question then becomes
> > one of ordering, I think.
> >
> > Consider
> >
> > paste(c("a", "b"), NULL, c("c", "d"), sep = " ", collapse = ",",
> > recycle0=TRUE)
> >
> > Currently that returns character(0), becuase the logic is
> > essenttially (in pseudo-cod
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
I understand that this is consistent but it also strikes me as an enormous
'gotcha' of a magnitude that 'we' are trying to avoid/smooth over at this
point in user-facing R space.
For the record I'm not suggesting it should return something other than "",
and in particular I'm not arguing that any call to paste *that does not
return an error* with non-NULL collapse should return a character vector of
length one.
Rather I'm pointing out that it could (perhaps should, imo) simply be an
error, which is also consistent, in the strict sense, with
previous behavior in that it is the developer simply declining to extend
the recycle0 argument to the full parameter space (there is no rule that
says we must do so, arguments whose use is incompatible with other
arguments can be reasonable and called for).
I don't feel feel super strongly that reeturning "" in this and similar
cases horrible and should never happen, but i'd bet dollars to donuts that
to the extent that behavior occurs it will be a disproportionately major
source of bugs, and i think thats at least worth considering in addition to
pure consistency.
~G
On Fri, May 22, 2020 at 9:50 AM William Dunlap wrote:
> I agree with Herve, processing collapse happens last so collapse=non-NULL
> always leads to a single character string being returned, the same as
> paste(collapse=""). See the altPaste function I posted yesterday.
>
> Bill Dunlap
> TIBCO Software
> wdunlap tibco.com
>
>
> On Fri, May 22, 2020 at 9:12 AM Hervé Pagès wrote:
>
>> I think that
>>
>> paste(c("a", "b"), NULL, c("c", "d"), sep = " ", collapse = ",",
>> recycle0=TRUE)
>>
>> should just return an empty string and don't see why it needs to emit a
>> warning or raise an error. To me it does exactly what the user is asking
>> for, which is to change how the 3 arguments are recycled **before** the
>> 'sep' operation.
>>
>> The 'recycle0' argument has no business in the 'collapse' operation
>> (which comes after the 'sep' operation): this operation still behaves
>> like it always had.
>>
>> That's all there is to it.
>>
>> H.
>>
>>
>> On 5/22/20 03:00, Gabriel Becker wrote:
>> > Hi Martin et al,
>> >
>> >
>> >
>> > On Thu, May 21, 2020 at 9:42 AM Martin Maechler
>> > mailto:maech...@stat.math.ethz.ch>> wrote:
>> >
>> > > Hervé Pagès
>> > > on Fri, 15 May 2020 13:44:28 -0700 writes:
>> >
>> > > There is still the situation where **both** 'sep' and
>> > 'collapse' are
>> > > specified:
>> >
>> > >> paste(integer(0), "nth", sep="", collapse=",")
>> > > [1] "nth"
>> >
>> > > In that case 'recycle0' should **not** be ignored i.e.
>> >
>> > > paste(integer(0), "nth", sep="", collapse=",", recycle0=TRUE)
>> >
>> > > should return the empty string (and not character(0) like it
>> > does at the
>> > > moment).
>> >
>> > > In other words, 'recycle0' should only control the first
>> > operation (the
>> > > operation controlled by 'sep'). Which makes plenty of sense:
>> > the 1st
>> > > operation is binary (or n-ary) while the collapse operation
>> > is unary.
>> > > There is no concept of recycling in the context of unary
>> > operations.
>> >
>> > Interesting, ..., and sounding somewhat convincing.
>> >
>> > > On 5/15/20 11:25, Gabriel Becker wrote:
>> > >> Hi all,
>> > >>
>> > >> This makes sense to me, but I would think that recycle0 and
>> > collapse
>> > >> should actually be incompatible and paste should throw an
>> > error if
>> > >> recycle0 were TRUE and collapse were declared in the same
>> > call. I don't
>> > >> think the value of recycle0 should be silently ignored if it
>> > is actively
>> > >> specified.
>> > >>
>> > >> ~G
>> >
>> > Just to summarize what I think we should know and agree (or be
>> > be "disproven") and where this comes from ...
>> >
>> > 1) recycle0 is a new R 4.0.0 option in paste() / paste0() which by
>> > default
>> > (recycle0 = FALSE) should (and *does* AFAIK) not change
>> anything,
>> > hence paste() / paste0() behave completely back-compatible
>> > if recycle0 is kept to FALSE.
>> >
>> > 2) recycle0 = TRUE is meant to give different behavior, notably
>> > 0-length arguments (among '...') should result in 0-length
>> results.
>> >
>> > The above does not specify what this means in detail, see 3)
>> >
>> > 3) The current R 4.0.0 implementation (for which I'm primarily
>> > responsible)
>> > and help(paste) are in accordance.
>> > Notably the help page (Arguments -> 'recycle0' ; Details 1st
>> > para ; Examples)
>> > says and shows how the 4.0.0 implementation has been meant to
>> work.
>> >
>> > 4) Several provenly smart members of the R community argue that
>> > both the implementation and
[Rd] R-devel's ...names() questions
Am am missing something or does the new ...names() in R-devel not work
right?
> a <- function(x, ...) ...names()
> a(a=stop("a"), b=stop("b"))
[1] "a" ""
> a(stop("x"), stop("unnamed"), c=stop("c"), d=stop("d"))
[1] NA "" ""
> version
_
platform x86_64-pc-linux-gnu
arch x86_64
os linux-gnu
system x86_64, linux-gnu
status Under development (unstable)
major 4
minor 1.0
year 2020
month 05
day19
svn rev78492
language R
version.string R Under development (unstable) (2020-05-19 r78492)
nickname Unsuffered Consequences
The following seems to do the right thing
alt...names <- function() evalq(names(substitute(...())),
envir=parent.frame())
However I wonder if it would be better to give the user a function, say
...args_unevaluated(...) to get the unevaluated ... arguments directlly
without having to know about the substitute(...()) trick. Then the user
could get the length, the n'th, or the names using the usual length(), [[,
and names() functions instead of ...length(), ...elt(), and ...names().
Bill Dunlap
TIBCO Software
wdunlap tibco.com
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
Gabe,
It's the current behavior of paste() that is a major source of bugs:
## Add "rs" prefix to SNP ids and collapse them in a
## comma-separated string.
collapse_snp_ids <- function(snp_ids)
paste("rs", snp_ids, sep="", collapse=",")
snp_groups <- list(
group1=c(55, 22, 200),
group2=integer(0),
group3=c(99, 550)
)
vapply(snp_groups, collapse_snp_ids, character(1))
#group1group2group3
# "rs55,rs22,rs200" "rs" "rs99,rs550"
This has hit me so many times!
Now with 'collapse0=TRUE', we finally have the opportunity to make it do
the right thing. Let's not miss that opportunity.
Cheers,
H.
On 5/22/20 11:26, Gabriel Becker wrote:
I understand that this is consistent but it also strikes me as an
enormous 'gotcha' of a magnitude that 'we' are trying to avoid/smooth
over at this point in user-facing R space.
For the record I'm not suggesting it should return something other than
"", and in particular I'm not arguing that any call to paste /that does
not return an error/ with non-NULL collapse should return a character
vector of length one.
Rather I'm pointing out that it could (perhaps should, imo) simply be an
error, which is also consistent, in the strict sense, with
previous behavior in that it is the developer simply declining to extend
the recycle0 argument to the full parameter space (there is no rule that
says we must do so, arguments whose use is incompatible with other
arguments can be reasonable and called for).
I don't feel feel super strongly that reeturning "" in this and similar
cases horrible and should never happen, but i'd bet dollars to donuts
that to the extent that behavior occurs it will be a disproportionately
major source of bugs, and i think thats at least worth considering in
addition to pure consistency.
~G
On Fri, May 22, 2020 at 9:50 AM William Dunlap > wrote:
I agree with Herve, processing collapse happens last so
collapse=non-NULL always leads to a single character string being
returned, the same as paste(collapse=""). See the altPaste function
I posted yesterday.
Bill Dunlap
TIBCO Software
wdunlap tibco.com
On Fri, May 22, 2020 at 9:12 AM Hervé Pagès mailto:hpa...@fredhutch.org>> wrote:
I think that
paste(c("a", "b"), NULL, c("c", "d"), sep = " ", collapse
= ",",
recycle0=TRUE)
should just return an empty string and don't see why it needs to
emit a
warning or raise an error. To me it does exactly what the user
is asking
for, which is to change how the 3 arguments are recycled
**before** the
'sep' operation.
The 'recycle0' argument has no business in the 'collapse' operation
(which comes after the 'sep' operation): this operation still
behaves
like it always had.
That's all there is to it.
H.
On 5/22/20 03:00, Gabriel Becker wrote:
> Hi Martin et al,
>
>
>
> On Thu, May 21, 2020 at 9:42 AM Martin Maechler
> mailto:maech...@stat.math.ethz.ch>
>> wrote:
>
> > Hervé Pagès
> > on Fri, 15 May 2020 13:44:28 -0700 writes:
>
> > There is still the situation where **both** 'sep' and
> 'collapse' are
> > specified:
>
> >> paste(integer(0), "nth", sep="", collapse=",")
> > [1] "nth"
>
> > In that case 'recycle0' should **not** be ignored i.e.
>
> > paste(integer(0), "nth", sep="", collapse=",",
recycle0=TRUE)
>
> > should return the empty string (and not
character(0) like it
> does at the
> > moment).
>
> > In other words, 'recycle0' should only control the
first
> operation (the
> > operation controlled by 'sep'). Which makes plenty
of sense:
> the 1st
> > operation is binary (or n-ary) while the collapse
operation
> is unary.
> > There is no concept of recycling in the context of
unary
> operations.
>
> Interesting, ..., and sounding somewhat convincing.
>
> > On 5/15/20 11:25, Gabriel Becker wrote:
> >> Hi all,
> >>
> >> This makes sense to
Re: [Rd] pbirthday() for larger number of classes
... and one should include the pigeonhole principle:
pbirthday2 <- function(n, classes = 365) {
c <- classes # as pbirthday()
if(n >= 2) {
if(n > classes) 1 else -expm1(sum(log1p(-(1:(n-1))/classes)))
} else 0
}
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] round() and signif() do not check argument names when a single argument is given
Hi,
I was told to send this to the -devel list instead of posting to bugzilla.
When round our signif are called with a single named argument, R does not
check the name and runs the function with that named argument directly as
the first argument, using 0.0 or 6.0 (6 in the case of signif) for the
second argument. Not checking the argument name is at odds with how all
other primitive functions are handled, and so I expect these to trigger an
error like other functions do. I've tested in 4.0.0 code, but this
behavior might go back decades.
The cases are things like this:
#horse is not a legitimate argument
round(horse=3.1235)
[1] 3
#digits is a legitimate argument in round,
#but the value gets used without checking as the first argument.
round(digits=3.1135)
[1] 3
The second case is especially strange to me, because digits is a named
argument of the function. No other functions behave this way as far as I
can tell; the first would normally either trigger a missing x value message
or an unused argument if it is a user function; the second would trigger a
warning about missing x.
Compare to:
> log(base=3)
Error: argument "x" is missing, with no default
These two functions are handled in a handler function in
src/main/arithmetic.c: do_Math2(). The strange cases get handled by the
code around line 1655 in src/main/arithmetic.c. The context is n is the
number of arguments, but symbol names have not yet been checked:
if(n == 1) {
double digits = 0.0;
if(PRIMVAL(op) == 10004) digits = 6.0;
SETCDR(args, CONS(ScalarReal(digits), R_NilValue));
}
Here, 10004 is the opcode symbol for signif and 10001 is for round, but
these are the only two ops handled by this function, so round uses
digits=0.0. The SETCDR creates the argument list to be the current 1-item
list plus the new digits value set here, and then this gets passed to
do_math2. do_math2 looks like it checks the arity of the arguments but not
the names, and calls fround or frpec on the arguments depending on the
opcode.
This case can be guarded against by adding a check for using the wrong
symbol name at this point, which only covers the case of calling these
functions with a single argument. This is essentially the same guard used
in other functions like do_log_bulitin that is in the same file.
if(n == 1 ){
static SEXP R_x_Symbol = NULL;
R_x_Symbol = install("x");
/*This handles single-argument calling*/
/*Make sure we don't call it with a mis-named argument:*/
if(CAR(args)==R_MissingArg ||
TAG(args) != R_NilValue && TAG(args) != R_x_Symbol)
error(_("argument \"%s\" is missing, with no default"), "x");
double digits = 0.0;
if(PRIMVAL(op) == 10004) digits = 6.0;
SETCDR(args, CONS(ScalarReal(digits), R_NilValue));
}
I'm not sure if CAR(args)==R_MissingArg is doing anything here, and
removing it seems to work, but this pattern is used in do_log_bultin.
I've tested this against the cases copied below, and this change will now
cause the error I expect in cases 5 and 6 [like round(digits=5.532) and
round(horse=5.131)], whereas current R 4.0.0 does not. This change
includes some _() text, but I'm not sure whether that means it will impact
internationalization since the strings are identical to other error
messages.
In the R code below, I put these in tryCatch so you can save the text and
do a source() of the file. Both R 4.0.0 and the changed code correctly
cause errors in case 7/8, to demonstrate that these cases are not impacted
by the change.
##This tests various round/signif argument configurations
## Each of these should succeed/fail the same if used in signif
cat("\nCase 1: round(1.12345): " )
cat(round(1.12345),"\n")
cat("\nCase 2: round(x=1.12345,2): ")
cat(round(x=1.12345,2),"\n")
cat("\nCase 3: round(x=1.12345,digits=2): ")
cat(round(x=1.12345,digits=2),"\n")
cat("\nCase 4: round(digits=2,x=1.12345): ")
cat(round(digits=2,x=1.12345),"\n")
cat("\nCase 4b: round(digits=2,1.12345): ")
cat(round(digits=2,1.12345),"\n")
## Current R 4.0 does not produce error but should
cat("\nCase 5: round(digits=x): \n")
tryCatch(
cat("round(digits=99.23456): ", round(digits=99.23456)),
error=function(cond){print(paste("[Error in case]",cond))})
## Current R 4.0 does not produce error but should
cat("\nCase 6: round(banana=x): \n")
tryCatch(
cat("round(banana=99.23456): ", round(banana=99.23456))
,error=function(cond){print(paste("[Error in case]",cond))})
## Error case
##error:
cat("\nCase 7: round(x=1.12345, digits=2, banana=3): ")
tryCatch( { cat(round(x=1.12345, digits=2, banana=3),"\n")},
error=function(cond){print(paste("[Error in case]",cond))})
##error case
cat("\nCase 8 : round(x=1.12345, banana=3): ")
tryCatch( round(x=1.12345, banana=3),
error=function(cond){print(paste("[Error in case]",cond))})
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] paste(character(0), collapse="", recycle0=FALSE) should be ""
> On Friday, May 22, 2020, 6:16:45 PM EDT, Hervé Pagès
> wrote:
>
> Gabe,
>
> It's the current behavior of paste() that is a major source of bugs:
>
> ## Add "rs" prefix to SNP ids and collapse them in a
> ## comma-separated string.
> collapse_snp_ids <- function(snp_ids)
> paste("rs", snp_ids, sep="", collapse=",")
>
> snp_groups <- list(
> group1=c(55, 22, 200),
> group2=integer(0),
> group3=c(99, 550)
> )
>
> vapply(snp_groups, collapse_snp_ids, character(1))
> # group1 group2 group3
> # "rs55,rs22,rs200" "rs" "rs99,rs550"
>
> This has hit me so many times!
>
> Now with 'collapse0=TRUE', we finally have the opportunity to make it do
> the right thing. Let's not miss that opportunity.
>
> Cheers,
> H.
FWIW what convinces me is consistency with other aggregating functions applied
to zero length inputs:
sum(numeric(0))
## [1] 0
>
>
> On 5/22/20 11:26, Gabriel Becker wrote:
> > I understand that this is consistent but it also strikes me as an
> > enormous 'gotcha' of a magnitude that 'we' are trying to avoid/smooth
> > over at this point in user-facing R space.
> >
> > For the record I'm not suggesting it should return something other than
> > "", and in particular I'm not arguing that any call to paste /that does
> > not return an error/ with non-NULL collapse should return a character
> > vector of length one.
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] GCC warning
Adrian, newer compilers are better at finding bugs - you may want to read the full trace of the error, it tells you that you likely have a memory overflow when using strncpy() in your package. You should check whether it is right. Unfortunately we can’t help you more specifically, because I don't see any link to what you submitted so can’t look at the code involved. Cheers, Simon > On May 22, 2020, at 7:25 PM, Adrian Dușa wrote: > > I am trying to submit a package on CRAN, and everything passes ok on all > platforms but Debian, where CRAN responds with an automatic "significant" > warning: > > * checking whether package ‘QCA’ can be installed ... [35s/35s] WARNING > Found the following significant warnings: > /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: > ‘__builtin_strncpy’ output may be truncated copying 12 bytes from a string of > length 79 [-Wstringop-truncation] > See ‘/srv/hornik/tmp/CRAN/QCA.Rcheck/00install.out’ for details. > > > I know the cause of this: using a cursomized version of some external C > library, coupled with in the Description. > > But I do not know hot to get past this warning, since it refers to a builtin > GCC function strncpy. As far as I read, this should be solved by a simple GCC > upgrade to the newest version, but that is something outside my code base, > since GCC resides on the CRAN servers. > > In the meantime, to get the package published, did anyone encountered a > similar problem? If so, is there a workaround? > > — > Adrian Dusa > University of Bucharest > Romanian Social Data Archive > Soseaua Panduri nr. 90-92 > 050663 Bucharest sector 5 > Romania > https://adriandusa.eu > > __ > 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
