similar to: Feature request: names(someEnv) same as ls(someEnv)

I am currently puzzled by a passage in the R Extensions manual, section 5.10: SEXP lapply(SEXP list, SEXP expr, SEXP rho) { R_len_t i, n = length(list); SEXP ans; if(!isNewList(list)) error("`list' must be a list"); if(!isEnvironment(rho)) error("`rho' should be an environment"); PROTECT(ans = allocVector(VECSXP, n));

Inside of the anyNA() function, it will use the legacy any(is.na()) code if x is an OBJECT(). If x is a vector of POSIXct, it will be an OBJECT(), but it is also TYPEOF(x) == REALSXP. Therefore, it will skip the faster ITERATE_BY_REGION, which is typically 5x faster in my testing. Is the OBJECT() condition really necessary, or could it be moved after the switch() for the individual TYPEOF(x)

I found a bug in one of the fourteen speed patches I posted, namely in patch-vec-subset. I've fixed this (I now see one does need to duplicate index vectors sometimes, though one can avoid it most of the time). I also split this patch in two, since it really has two different and independent parts. The patch-vec-subset patch now has only some straightforward (locally-checkable) speedups for

Full_Name: Barry Rowlingson Version: 1.5.0 OS: linux-gnu Submission from: (NULL) (130.95.16.114) Comparison of a data frame with a list fails with an error that looks to be due to a typo in Ops.data.frame: > d <- data.frame(1:10) > d > list(5) Error in Ops.data.frame(d, list(5)) : Object "scalar" not found Code has: rscalar <- length(e2) <= 1 if

Hi all, The "ls" function wears two hats. It allows users to inspect an environment interactively and also serves deeper in code as the accessor for an environment's names/keys. I propose that we separate these two conflicting goals, keeping ls for interactive use and adding names for a quick listing of the hash keys. This involves adding two lines to do_names in attrib.c. The

I'm noticing some interesting behavior in `match.call` in some corner-ish cases that arise when you try to use `match.call` to match a "grandparent" function and there are dots involved: fun0 <- function(a, ...) fun1(...) fun1 <- function(b, ...) fun2() fun2 <- function() match.call( fun1, sys.call(sys.parent()), expand.dots=FALSE,

I'd like to propose a change to the R language so that calling 'parent.env<-' on a package namespace or package imports is a runtime error. Currently the documentation warns that it's dangerous behaviour and might go away: The replacement function ?parent.env<-? is extremely dangerous as it can be used to destructively change environments in ways that violate

>>>>> Harvey Smith >>>>> on Wed, 1 May 2019 03:20:55 -0400 writes: > Inside of the anyNA() function, it will use the legacy any(is.na()) code if > x is an OBJECT(). If x is a vector of POSIXct, it will be an OBJECT(), but > it is also TYPEOF(x) == REALSXP. Therefore, it will skip the faster > ITERATE_BY_REGION, which is typically 5x

I think ls(, sort=FALSE) would be more explicit and thus clearer. There is much precedent for having arguments that request less work to be done e.g. unlist(use.names=FALSE). Yes, the extra typing is a bit painful, but there is no intuitive reason why names() would be unsorted, while ls() would be sorted. While it is tempting to use an existing function for this, the word "names" is

In S, NULL and list() are not the same. In R they are (I think). --------------------------------------------------- At least, is.list(NULL) #-> 'F' in S; 'TRUE' in R Yes: I had an instance where this broke correct S code: match(c("xlab","ylab"), names(list(...))) when '...' is empty, gives an error in R, but gives c(NA,NA) in S.

1. Is there some way to copy a promise so that the copy has the same expression in its promise as the original. In the following we y is a promise that we want to copy to z. We want z to be a promise based on the expression x since y is a promise based on the expression x. Thus the answer to the code below is desired to be z=2 but its 1, 1 and y in the next three examples so they are not the

Since the contract of ls() is to sort, there is nothing wrong with programmers depending on it. And there are many functions that could be made 60X faster, but is it worth it? But I did notice that as.list.environment has a sorted=FALSE argument already, so I guess identical(names(x), names(as.list(x))) could be made to be TRUE, assuming the order is at least persistent, if undefined, so that is a

eapply() works on most environments, but not on baseenv(). For example, > x <- 1 > eapply(globalenv(), function(x) x) $x [1] 1 > eapply(baseenv(), function(x) x) list() I'm probably not going to have time to work on this before 2.3.0, but I don't think it's really urgent; if no one else fixes it first I'll do it after the release. Duncan Murdoch

I was thrilled to see this in the change log: > match.call() gains an envir argument for specifying the environment from which to retrieve the ... in the call, if any; this environment was wrong (or at least undesirable) when the definition argument was a function. This was an issue I ran into a few years ago.? I ended up writing my own version that allows specification of the environment, but

Hi Sri, I haven't really elaborated on it having other stuff to prepare first, but as far as I got you first assign data to a vector: #include <R.h> #include <Rinternals.h> #undef R_INTERFACE_PTRS #include <Rembedded.h> #include "Rcpp.hpp" #include <R_ext/Parse.h> #include <Rinternals.h> #include <Rdefines.h> //assigning a vector SEXP

>>>>> Peter Haverty <haverty.peter at gene.com> >>>>> on Sun, 25 Jan 2015 12:21:04 -0800 writes: > Hi all, > The "ls" function wears two hats. It allows users to inspect an > environment interactively and also serves deeper in code as the > accessor for an environment's names/keys. I propose that we separate

Unlink files, symlinks, FIFOs, devices etc. (except directories) before writing them when extracting CPIOs. This stops weird behaviour like: 1) writing through symlinks created in earlier CPIOs. eg foo->bar in the first CPIO. Having foo as a non-link in a subsequent CPIO, results in bar being written and foo remaining as a symlink. 2) if the first version of file foo is larger

I think that the "sorted" and "all.names" arguments are really only appropriate for pretty printing to the screen. I think it is a bit unfortunate that environments have a names accessor that is 60X slower than all the other types. This is likely due to the history of environments, which were originally just for behind-the-scenes tasks. Now that users can use environments as

Hello, I submit a patch for review that implements code coverage tracing in the R interpreter. It records the lines that are actually executed and their associated frequency for which srcref information is available. I perfectly understands that this patch will not make its way inside R as it is, that they are many concerns of stability, compatibility, maintenance and so on. I would like to have

>>>>> Michael Lawrence <lawrence.michael at gene.com> >>>>> on Tue, 27 Jan 2015 07:59:59 -0800 writes: > Since the contract of ls() is to sort, there is nothing wrong with > programmers depending on it. And there are many functions that could be > made 60X faster, but is it worth it? But I did notice that > as.list.environment