similar to: reference counting problem in .Primitive's?

It looks like the 'seq' variable to 'for' can be altered from within the loop, leading to incorrect answers. E.g., in the following I'd expect 'sum' to be 1+2=3, but R 2.10.0 (svn 48686) gives 44.5. > x = c(1,2); sum = 0; for (i in x) { x[i+1] = i + 42.5; sum = sum + i }; sum [1] 44.5 or, with a debugging cat()s, > x = c(1,2); sum = 0; for (i in x) {

One of our R users here just showed me the following problem while investigating the return value of a while loop. I added some information on a similar bug in for loops. I think he was using 2.9.0 but I see the same problem on today's development version of 2.10.0 (svn 48703). Should the semantics of while and for loops be changed slightly to avoid the memory buildup that fixing this to

Baring any unforeseen issues R-devel will switch in about a week from the NAMED mechanism to reference counting for determining when objects can be safely mutated in base C code. This is expected to have minimal impact on packages not using unsupported coding practices in their C code. The transition to reference counting has been in progress for a number of years. Some older notes on this are

This is very exciting news. Luke, thank you for all your work on this - I know it's been a long journey. All the best, Henrik On Tue, Dec 3, 2019 at 8:04 AM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > > R-devel has been switched to use reference counting by default with > r77508. Building with -DSWITCH_TO_NAMED goes back to the NAMED > mechanism. > > Best,

In R versions 2.10.1 and "2.11.0 Under development (unstable) (2010-03-07 r51225)" on Windows I get the following if I type the commands at the start of the session. Note how the attribute attached to the name "Response" by the initial call to structure() seems to get tied to that name for the remainder of the session: > z <- structure(quote(Response),

The following example involves a function whose on.exit() expression both generates an error and catches the error. The body of the function also generates an error. When calling the function wrapped in a tryCatch, should that tryCatch's error function be given the error from the body of the function, since the one from the on.exit has already been dealt with? Currently the outer tryCatch

Hi all, When S4 methods are defined on base function (say, "match"), the function becomes a method with the body "base::match(x,y)". A call to such a function often spends more time doing "::" than in the function itself. I always assumed that "::" was a very low-level thing, but it turns out to be a plain old function defined in base/R/namespace.R. What

I was looking for all the glm-related 'family' functions in stats using the following predicate that returns TRUE for any function whose first argument is called "link". is.family <- function(object) is.function(object) && identical(names(as.list(object))[1], "link") It threw an error when applied to SSfol > is.family(SSfol) Error in

Would introducing the new frame, with the call to local(), cause problems when you use frame counting instead of <<- to modify variables outside the scope of lapply's FUN, I think the frame counts may have to change. E.g., here is code from actuar::simul() that might be affected: x <- unlist(lapply(nodes[[i]], seq)) lapply(nodes[(i + 1):(nlevels - 1)],

I left out the warning - it's still there. The output object is malformed but either +.factor should prevent this or match() should check. Hadley On Mon, Mar 30, 2015 at 3:50 PM, William Dunlap <wdunlap at tibco.com> wrote: > Did you leave out the warning from "+", which should be an error, > as it produces an illegal ordered factor in this case and factor+factor >

Shouldn't the following 4 ways to alter an object in a locked environment either all work or all fail? (All working would be nice, I think.) E <- new.env() assign("var", c(1,2,3,4), envir=E) lockEnvironment(E, bindings=FALSE) E$var[1] <- 101 ; E$var #[1] 101 2 3 local(var[2] <- 102, envir=E) #Error in eval(expr, envir, enclos) : # cannot add

Consider the following expression, in which we pass 'i=', with no value given for the 'i' argument, to lapply. lapply("x", function(i, j) c(i=missing(i),j=missing(j), i=) >From R-2.14.0 (2011-10-31) through R-3.4.4 (2018-03-15) this evaluated to c(i=TRUE, j=FALSE). From R-3.5.0 (2018-04-23) through R-4.0.0 (2020-04-24) this evaluated to c(i=FALSE, j=TRUE). Was

I'm not sure if this is a bug or expected behavior, but I don't see anything in the documentation that explains it, so I thought I'd mention it: ~ michaelweylandt$ R -q --vanilla library(compiler) enableJIT(3) `+` # Throws an error `+` # Throws a warning `+` # Prints the primitive as expected sessionInfo() R version 2.14.1 (2011-12-22) Platform: i386-apple-darwin9.8.0/i386

On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: > I'm not convinced that how to make :: faster is the right question. If > you are finding foo::bar being called often enough to matter to your > overall performance then to me the question is: why are you calling > foo::bar more than once? Making :: a bit faster by making it a > primitive will remove

Does R have a function like the S/S++ unset() function? unset(name) would remove 'name' from the current evaluation frame and return its value. It allowed you to safely avoid some memory copying when calling .C or .Call. E.g., suppose you had C code like #include <R.h> #include <Rinternals.h> SEXP add1(SEXP pX) { int nProtected = 0; int n = Rf_length(pX);

On Thu, Jan 22, 2015 at 11:44 AM, <luke-tierney at uiowa.edu> wrote: > > For default methods there ought to be a way to create those so the > default method is computed at creation or load time and stored in an > environment. We had considered that, but we thought the definition of the function would be easier to interpret if it explicitly specified the namespace, instead of

R lets one lock an environment with both an R function, base::lockEnvironment, and a C function, R_LockEnvironment, but, as far as I can tell, no corresponding function to unlock an environment. Is this omission on principle or just something that has not been done yet? I ask because several packages, including the well-used R6 and rlang packages, fiddle with some bits in with SET_ENVFLAGS and

I don't think it is reasonable to change the parser this way. This is currently valid R code: a <- "foo" "bar" and with the new syntax, it is also valid, but with a different meaning. Or you can even consider a <- "foo" bar %>% func() %>% print() etc. I like the idea of string literals, but the C/C++ way clearly does not work. The Python/Julia way

Hi, thx for the reply. Unfortunately that is not a simplified version of the problem. You have a function, call it and get the result (numeric in, numeric out in that case). For simplicity lets use the "return" case: ## foobar<-function(x) { return(sqrt(x)) }(2) ## which is a function (numeric in, numeric out) which is defined, then gets called and the return value is a function

Dear List, I found a documentation on the web that mentions things like 'R references' (http://www.stat.uiowa.edu/~luke/R/simpleref.html). However, I could not find the R_MakeReference and friends in R... Does anyone knows more about that ? Thanks, L.