Re: [Rd] order function called on a data.frame?
So maybe for now just warning/error? Should be much smaller change then those proposed by William and Michael. Rui, Your example of order list does raise error, but if you remove second argument, it won't raise error anymore. On Mon, May 18, 2020 at 5:27 PM William Dunlap via R-devel wrote: > > do.call(order, df). -> do.call(order, unname(df)). > > While you are looking at order(), it would be nice if ';decreasing' could > be a vector the the length of list(...) so you could ask to sort some > columns in increasing order and some decreasing. I thought I put this on > bugzilla eons ago, but perhaps not. > > Bill Dunlap > TIBCO Software > wdunlap tibco.com > > > On Mon, May 18, 2020 at 8:52 AM Michael Lawrence via R-devel < > r-devel@r-project.org> wrote: > > > I guess we could make it do the equivalent of do.call(order, df). > > > > On Mon, May 18, 2020 at 8:32 AM Rui Barradas wrote: > > > > > > Hello, > > > > > > There is a result with lists? I am getting > > > > > > > > > order(list(letters, 1:26)) > > > #Error in order(list(letters, 1:26)) : > > > # unimplemented type 'list' in 'orderVector1' > > > > > > order(data.frame(letters, 1:26)) > > > # [1] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 > > > #[22] 48 49 50 51 52 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 > > > #[43] 17 18 19 20 21 22 23 24 25 26 > > > > > > > > > And I agree that order with data.frames should give a warning. The > > > result is indeed useless: > > > > > > data.frame(letters, 1:26)[order(data.frame(letters, 1:26)), ] > > > > > > > > > Hope this helps, > > > > > > Rui Barradas > > > > > > > > > Às 00:19 de 18/05/20, Jan Gorecki escreveu: > > > > Hi, > > > > base::order main input arguments are defined as: > > > > > > > > a sequence of numeric, complex, character or logical vectors, all of > > > > the same length, or a classed R object > > > > > > > > When passing a list or a data.frame, the resuts seems to be a bit > > > > useless. Shouldn't that raise an error, or at least warning? > > > > > > > > Best Regards, > > > > Jan Gorecki > > > > > > > > __ > > > > 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 > > > > > > > > -- > > Michael Lawrence > > Senior Scientist, Data Science and Statistical Computing > > Genentech, A Member of the Roche Group > > Office +1 (650) 225-7760 > > micha...@gene.com > > > > Join Genentech on LinkedIn | Twitter | Facebook | Instagram | YouTube > > > > __ > > 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 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi wrote:
[...]
> Btw. why does this affect openssl? That root cert was published in
> 2010, surely openssl should know about it? Maybe libcurl / openssl
> only uses the chain provided by the server? Without trying to use an
> alternate chain?
Yes, indeed it seems that old OpenSSL versions cannot handle
alternative certificate chains. This has been fixed in OpenSSL in
2015, so modern Linux systems should be fine. However, macOS uses
LibreSSL, and LibreSSL never fixed this issue. E.g.
https://github.com/libressl-portable/portable/issues/595
r-project.org can be updated to send the new root certificate, which
will solve most of our problems, but we'll probably have issues with
other web sites that'll update slower or never.
FWIW I built macOS binaries for the curl package, using a static
libcurl and macOS Secure Transport, so these binaries does not have
this issue.
They are at https://files.r-hub.io/curl-macos-static and they can be
installed with
install.packages("curl", repos =
"https://files.r-hub.io/curl-macos-static";, type = "binary")
They support R 3.2 and up, including R 4.1, and should work on all
macOS versions that the given R release supports.
Gabor
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] r-project.org SSL certificate issues
Btw. it would be also possible to create a macOS R installer that
embeds a static or dynamic libcurl with Secure Transport, instead of
the Apple default LibreSSL.
This might be too late for R 4.0.1, I don't know.
Gabor
On Sun, May 31, 2020 at 4:09 PM Gábor Csárdi wrote:
>
> On Sat, May 30, 2020 at 11:32 PM Gábor Csárdi wrote:
> [...]
> > Btw. why does this affect openssl? That root cert was published in
> > 2010, surely openssl should know about it? Maybe libcurl / openssl
> > only uses the chain provided by the server? Without trying to use an
> > alternate chain?
>
> Yes, indeed it seems that old OpenSSL versions cannot handle
> alternative certificate chains. This has been fixed in OpenSSL in
> 2015, so modern Linux systems should be fine. However, macOS uses
> LibreSSL, and LibreSSL never fixed this issue. E.g.
> https://github.com/libressl-portable/portable/issues/595
>
> r-project.org can be updated to send the new root certificate, which
> will solve most of our problems, but we'll probably have issues with
> other web sites that'll update slower or never.
>
> FWIW I built macOS binaries for the curl package, using a static
> libcurl and macOS Secure Transport, so these binaries does not have
> this issue.
>
> They are at https://files.r-hub.io/curl-macos-static and they can be
> installed with
> install.packages("curl", repos =
> "https://files.r-hub.io/curl-macos-static";, type = "binary")
>
> They support R 3.2 and up, including R 4.1, and should work on all
> macOS versions that the given R release supports.
>
> Gabor
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] eval and Calling Frames
I ran into an interesting issue with `evalq` (and also
`eval(quote(...))`):
f <- function() {
list(
sys.parent(1),
evalq(sys.parent(1)),
evalq((function() sys.parent(2))()), # add an anon fun layer
evalq((function() sys.parent(1))())
)
}
res <- f()
str(res)
## List of 4
## $ : int 0 # sys.parent(1)
## $ : int 2 # evalq(sys.parent(1))
## $ : int 0 # evalq((function() sys.parent(2))())
## $ : int 1 # evalq((function() sys.parent(1))())
In order of least to most surprising:
1. `sys.parent(1)` and `evalq(sys.parent(1))` are not the same
2. `evalq(sys.parent(1))` and `evalq((function() sys.parent(2))())`
are not the same
3. `evalq((function() sys.parent(1))())` returns a lower frame number
than `evalq(sys.parent(1))`
The root cause of this is that the `evalq` **closure** sets a context,
but then the C-level `do_eval` it invokes sets another one[1] with the
new `evalq` context as the calling frame (`cptr->sysparent`)[2]. This
then interacts with how `sys.parent` resolves parents when a target
frame appears more than once in the context stack. `sys.parent`
returns the oldest context that matches[3], and in this case `f`'s
frame appears twice because `evalq` adds it via `do_eval`.
One option is to change what `sysparent` of the `evalq` `envir`.
For example, if we set it to be the same as it would be for commands
outside the `evalq` we get:
str(res)
## List of 4
## $ : int 0 # sys.parent(1)
## $ : int 0 # evalq(sys.parent(1))
## $ : int 0 # evalq((function() sys.parent(2))())
## $ : int 1 # evalq((function() sys.parent(1))())
There is precedent for doing this in S3 generics and their methods
where method `sysparent` is set to be that of the generic. Now
`evalq` no longer interferes with the resolution of calling frames.
It seems reasonable to set evaluation environments without affecting
what the calling frame is. Indeed that happens when we do something like
`environment(fun) <- blah` as the calling frame is unaffected when `fun` is
invoked.
I attach a patch that implements this change. The patch is a
hack-job intended solely for illustrative purposes, though it does
pass `make check-all` on a current version of r-devel. I also ran the
`rlang` tests as those probably push the envelope in this area. There
only one failed with 2,613 passing. The failed one is for a
deprecated function that was specifically checking for the repeated
`evalq` contexts[7].
I also attach a document with additional examples and commentary for
those interested.
Best,
Brodie.
PS: for a loosely related issue see #15531[8].
[1]: https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/eval.c#L3329
[2]: https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/context.c#L260
[3]: https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/context.c#L433
[4]: https://github.com/wch/r-source/blob/tags/R-4-0-0/src/main/eval.c#L1815
[5]: https://cran.r-project.org/doc/manuals/r-devel/R-ints.html#Contexts
[6]: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15531
[7]:
https://github.com/r-lib/rlang/blob/v0.4.6/tests/testthat/test-retired.R#L437
[8]: https://bugs.r-project.org/bugzilla/show_bug.cgi?id=15531
Index: src/library/base/R/eval.R
===
--- src/library/base/R/eval.R (revision 78619)
+++ src/library/base/R/eval.R (working copy)
@@ -23,7 +23,7 @@
function(expr, envir = parent.frame(),
enclos = if(is.list(envir) || is.pairlist(envir))
parent.frame() else baseenv())
-.Internal(eval(expr, envir, enclos))
+.Internal(eval(expr, envir, enclos, parent.frame(2L)))
eval.parent <- function(expr, n = 1) {
p <- parent.frame(n + 1)
@@ -33,7 +33,7 @@
evalq <-
function (expr, envir = parent.frame(), enclos = if (is.list(envir) ||
is.pairlist(envir)) parent.frame() else baseenv())
- .Internal(eval(substitute(expr), envir, enclos))
+ .Internal(eval(substitute(expr), envir, enclos, parent.frame(2L)))
new.env <- function (hash = TRUE, parent = parent.frame(), size = 29L)
.Internal(new.env(hash, parent, size))
Index: src/library/base/baseloader.R
===
--- src/library/base/baseloader.R (revision 78619)
+++ src/library/base/baseloader.R (working copy)
@@ -97,7 +97,7 @@
..lazyLoad(basedb, baseenv())
-}), .Internal(new.env(FALSE, baseenv(), 29L)), baseenv()))
+}), .Internal(new.env(FALSE, baseenv(), 29L)), baseenv(), baseenv()))
## keep in sync with R/zzz.R
as.numeric <- as.double
Index: src/main/eval.c
===
--- src/main/eval.c (revision 78619)
+++ src/main/eval.c (working copy)
@@ -3267,7 +3267,7 @@
SEXP attribute_hidden do_eva
