similar to: Change in lapply's missing argument passing

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)],

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

From: Daniel Kaschek <daniel.kaschek at physik.uni-freiburg.de> > ... When I evaluate this list of functions by > another lapply/sapply, I get an unexpected result: all values coincide. > However, when I uncomment the print(), it works as expected. Is this a > bug or a feature? > > conditions <- 1:4 > test <- lapply(conditions, function(mycondition){ >

On Thu, 26 Jul 2018, G?bor Cs?rdi wrote: > On Thu, Jul 26, 2018 at 12:25 PM Barry Rowlingson > <b.rowlingson at lancaster.ac.uk> wrote: >> >> On Thu, Jul 26, 2018 at 12:22 AM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote: >>> I am trying to control a background R session, connected via a fifo / >>> named pipe. >> >> Is the fifo

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

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);

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

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),

Hello everyone, I have a C++ program that calls R using R_tryEval, very similarly to what package RInside does. It used to work with R.3.4.3 and R.3.4.4. However, since I updated it to R.3.5.1, R sends an error message: "*Error in < My command > : the base graphics system is not registered*" for any command related to the graphics package. I made a ticket on stackoverflow about

Thank you Luke. That is why I don't use Rf_inherits but INHERITS which does not allocate, provided in the email body. I cannot do similarly for S4 classes, thus asking for some API for that. On Fri, Nov 1, 2019 at 5:56 PM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > > On Fri, 1 Nov 2019, Jan Gorecki wrote: > > > Dear R developers, > > > > Motivated by

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) {

Thank you Luke for prompt reply. Is it possible then to request a new function to R C API "message" that would equivalent to R "message" function? Similarly as we now have C "warning" and C "error" functions. Best, Jan On Sun, Sep 15, 2019 at 5:25 PM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > > On Sun, 15 Sep 2019, Jan Gorecki wrote:

I think the following rather wierd expressions show a problem in how some of the .Primitive functions evaluate their arguments. I haven't yet thought of a way that a nonabusive user might run into this problem. In each case the first argument, x, is modified in the course of evaluating the second argument and then modified x gets used as the first argument: > x<-as.integer(1:5); y

I have committed a change to R-devel that addresses this. To be on the safe side I need to run some more extensive tests before deciding if this can be ported to the release branch for R 3.5.0. Should know in a day or two. Best, luke On Tue, 27 Mar 2018, luke-tierney at uiowa.edu wrote: > This has nothing to do with printing or dispatch per se. It is the > result of an internal register

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

This Index: src/main/altrep.c =================================================================== --- src/main/altrep.c (revision 79385) +++ src/main/altrep.c (working copy) @@ -275,10 +275,11 @@ SEXP psym = ALTREP_SERIALIZED_CLASS_PKGSYM(info); SEXP class = LookupClass(csym, psym); if (class == NULL) { - SEXP pname = ScalarString(PRINTNAME(psym)); + SEXP pname =

I am not using the C API from a package but with an embedded R. Why have it declared in the include/ if it cannot be accessed then? Best, Laurent On Sun, Sep 8, 2019, 8:27 AM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > On Sat, 7 Sep 2019, Laurent Gautier wrote: > > > Hi, > > > > > > The function `Rf_findFun3` is declared in > > `$(R CMD CONFIG

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

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