search for: applydefin

...64/libc.so.6 #1 0x0000003294e31bf0 in abort () from /lib64/libc.so.6 #2 0x00000000004184f5 in R_gc_internal (size_needed=0) at ../../../R/src/main/memory.c:761 #3 0x000000000041b121 in Rf_cons (car=0x1b2ec088, cdr=0x1a3436d8) at ../../../R/src/main/memory.c:1755 #4 0x0000000000578472 in applydefine (call=<value optimized out>, op=0x1a3617a8, args=0x1ad47590, rho=0x1b2ea428) at ../../../R/src/include/Rinlinedfuns.h:153 #5 0x0000000000575a42 in Rf_eval (e=0x1ad47558, rho=0x1b2ea428) at ../../../R/src/main/eval.c:461 #6 0x0000000000576d50 in do_begin (call=0x1ad48450, op=0x...

...he following works: x = 1 base::is.na(x) = TRUE However, the following fails: x = 1 b = baseenv() b$is.na(x) = TRUE The error message is "invalid function in complex assignment". Grepping the R code for this error message reveals that this behaviour seems to be hard-coded in function `applydefine` in src/main/eval.c: the function explicitly checks for `::` and :::` and permits those assignments, but has no equivalent treatment for `$`. Am I overlooking something to make this work? And if not ? unless there?s a concrete reason against it, could it be considered to add support for this synt...

...gt; > However, the following fails: > > x = 1 > b = baseenv() > b$is.na(x) = TRUE > > The error message is "invalid function in complex assignment". Grepping the > R code for this error message reveals that this behaviour seems to be > hard-coded in function `applydefine` in src/main/eval.c: the function > explicitly checks for `::` and :::` and permits those assignments, but has > no equivalent treatment for `$`. > > Am I overlooking something to make this work? And if not ? unless there?s a > concrete reason against it, could it be considered to...

...=9370== by 0x4B69961: Rf_classgets (in /usr/lib64/R/lib/libR.so) ==9370== by 0x4B68DC1: Rf_setAttrib (in /usr/lib64/R/lib/libR.so) ==9370== by 0x4B69A40: do_classgets (in /usr/lib64/R/lib/libR.so) ==9370== by 0x4BE908E: Rf_eval (in /usr/lib64/R/lib/libR.so) ==9370== by 0x4BEB6FD: applydefine (in /usr/lib64/R/lib/libR.so) ==9370== by 0x4BEBAE3: do_set (in /usr/lib64/R/lib/libR.so) ==9370== by 0x4BE8E5E: Rf_eval (in /usr/lib64/R/lib/libR.so) ==9370== Address 0x10 is not stack'd, malloc'd or (recently) free'd [[alternative HTML version deleted]]

...gn.c:113) ==5420== by 0x4D91146: do_subassign2_dflt (subassign.c:1568) ==5420== by 0x4D92012: do_subassign2 (subassign.c:1451) ==5420== by 0x4CD940D: Rf_eval (eval.c:469) ==5420== by 0x4CDBEB6: do_set (eval.c:1724) ==5420== by 0x4CD940D: Rf_eval (eval.c:469) ==5420== by 0x4CDB91B: applydefine (eval.c:1680) ==5420== by 0x4CD940D: Rf_eval (eval.c:469) ==5420== by 0x4CDAC21: do_begin (eval.c:1420) ==5420== by 0x4CD940D: Rf_eval (eval.c:469) ==5420== by 0x4CDCA27: do_for (eval.c:1294) ==5420== ==5420== HEAP SUMMARY: ==5420== in use at exit: 16,030,517,919 bytes in 13,235 b...

Dear R-developers I came across the following issue, which I find strange: setClass("A", representation(a = "numeric")) B <- list() myA <- new("A", a = 1) B$otherA <- myA B$otherA at a <- 2 myA at a Assigning a new value to slot 'a' in the _copy_ of myA stored in B$otherA changes the original value of myA -- this was surprising to me, and I

...l.c:418) #13 0x00057614 in Rf_applyClosure (eval.c:609) #14 0x00057200 in Rf_eval (eval.c:453) #15 0x00058810 in do_begin (eval.c:1055) #16 0x00056fcc in Rf_eval (eval.c:418) #17 0x00057614 in Rf_applyClosure (eval.c:609) #18 0x00057200 in Rf_eval (eval.c:453) #19 0x00058bcc in applydefine (eval.c:1178) #20 0x00056fcc in Rf_eval (eval.c:418) #21 0x00058810 in do_begin (eval.c:1055) #22 0x00056fcc in Rf_eval (eval.c:418) #23 0x0005832c in do_for (eval.c:950) #24 0x00056fcc in Rf_eval (eval.c:418) #25 0x00058810 in do_begin (eval.c:1055) #26 0x00056fcc in Rf_eval...

...c) at eval.c:338 #31 0x5bba4 in Rf_evalList (el=0x9d1bec, rho=0x2d36ec) at eval.c:1087 #32 0x5a244 in Rf_eval (e=0x9d1bd0, rho=0x2d36ec) at eval.c:338 #33 0x5bba4 in Rf_evalList (el=0x9d1a64, rho=0x2d36ec) at eval.c:1087 #34 0x5a244 in Rf_eval (e=0x9d1a48, rho=0x2d36ec) at eval.c:338 #35 0x5b5dc in applydefine (call=0x9d19f4, op=0x1c6304, args=0x9d1a10, rho=0x2d36ec) at eval.c:924 #36 0x5ba68 in do_set (call=0x9d19f4, op=0x1c6304, args=0x9d1a10, rho=0x2d36ec) at eval.c:1041 #37 0x5a114 in Rf_eval (e=0x9d19f4, rho=0x2d36ec) at eval.c:317 #38 0x5b300 in do_begin (call=0x9d1644, op=0x1c6294, args=0...

...3a45f4 do_set + 980 37 libR.dylib 0x003a14dc Rf_eval + 1244 38 libR.dylib 0x003a2b08 do_begin + 104 39 libR.dylib 0x003a14dc Rf_eval + 1244 40 libR.dylib 0x003a4f58 Rf_applyClosure + 728 41 libR.dylib 0x003a13f0 Rf_eval + 1008 42 libR.dylib 0x003a3cdc applydefine + 60 43 libR.dylib 0x003a14dc Rf_eval + 1244 44 libR.dylib 0x003a2b08 do_begin + 104 45 libR.dylib 0x003a14dc Rf_eval + 1244 46 libR.dylib 0x003a4f58 Rf_applyClosure + 728 47 libR.dylib 0x003a13f0 Rf_eval + 1008 48 libR.dylib 0x003a62c8 forcePromise...

For reasons which I'll spare you, I'm writing a program to analyse R source code. This has led me to probe some of the darker corners of R syntax to find out what is supposed to happen. Now, from reading the R documentation (and the New S book &c) I know perfectly well that f(a, b, etc) <- x is supposed to turn into a <- "f<-"(a, b, etc, value=x) Except,

If anyone has a few extra CPU cycles to spare, I'd appreciate it if you could verify a problem that I have encountered. Run the code below and tell me if it crashes your R before completion. library(lme4) data(bdf) dump<-sapply( 1:50000, function(i) { fm <- lme(langPOST ~ IQ.ver.cen + avg.IQ.ver.cen, data = bdf, random = ~ IQ.ver.cen | schoolNR); cat("