similar to: PATCH: Avoiding extra copies (NAMED bumped) with source(..., print.eval=FALSE) ...and with print.eval=TRUE?

Sorry to intervene. Argument passed to 'eval' is evaluated first. So, eval(x <- 2) is effectively like { x <- 2; eval(2) } , which is effectively { x <- 2; 2 } . The result is visible. eval(expression(x <- 2)) or eval(quote(x <- 2)) or evalq(x <- 2) gives the same effect as x <- 2 . The result is invisible. In function 'eval2', res <-

R-team, The $value element of the return value of *withVisible* does not agree with the return value of *eval* when *withVisible* is passed a variable (symbol) containing an expression object or anonymous code/expressions which generates an expression object when evaluated (such as calls to *parse* or * expression*). I have attached a patch against the svn trunk which addresses this. Example

Would it be possible to have the value of eval() preserve the "visibility" of the value of the expression? "PROBLEM": # Invisible > x <- 1 # Visible > eval(x <- 2) [1] 2 "TROUBLESHOOTING": > withVisible(x <- 1) $value [1] 1 $visible [1] FALSE > withVisible(eval(x <- 2)) $value [1] 2 $visible [1] TRUE WORKAROUND: eval2 <-

On Fri, 5 Aug 2016, Winston Chang wrote: > My understanding is that R will not make copies of lists if there is > only one reference to the object. However, I've encountered a case > where R does make copies, even though (I think) there should be only > one reference to the object. I hope that someone could shed some light > on why this is happening. > > I'll start

My understanding is that R will not make copies of lists if there is only one reference to the object. However, I've encountered a case where R does make copies, even though (I think) there should be only one reference to the object. I hope that someone could shed some light on why this is happening. I'll start with a simple example. Below, x is a list with one element, and changing that

Hi there, I seek your expert opinion on the following memory related questions. The output below was gotten from R-2.6.2, compiled with --enable-memory-profiling on Ubuntu Linux. ======================================================================= >>> Code and output 1: > gc( ) used (Mb) gc trigger (Mb) max used (Mb) Ncells 131180 7.1 350000 18.7 350000 18.7

Hi All, i have a problem in understanding what the assignment operator '<-' really is doing. If i create two numeric arrays in R and copy one into the other with '<-' and afterwards change one array by calling a C function, both arrays are changed! The problem I am facing can easily be seen in the following example: (The following R code and the C function is attached and

Hi, I've noticed that as.vector() always allocates a new object, e.g. > x <- 1:10; > x <- as.vector(x); > tracemem(x); [1] "<0x0000000005622db8" > x <- as.vector(x); tracemem[0x0000000005622db8 -> 0x0000000005622ec0]: as.vector > x <- as.vector(x); tracemem[0x0000000005622ec0 -> 0x0000000005622f18]: as.vector > x <- as.vector(x);

Hi all, I've been trying to get a better handle on what manipulations lead R to duplicate a vector, creating small experiments and using tracemem to observe what happens (all in 2.15.1). That's lead me to a few questions, illustrated using the snippet below. x <- 1:10 tracemem(x) # [1] "<0x1058f8238>" x[5] <- 5 # tracemem[0x1058f8238 -> 0x105994ab0]: x[11] <-

Hi, $ R --vanilla R version 2.14.1 (2011-12-22) Platform: i686-pc-linux-gnu (32-bit) > DF = data.frame(a=1:3,b=4:6) > DF a b 1 1 4 2 2 5 3 3 6 > tracemem(DF) [1] "<0x8898098>" > names(DF)[2]="B" tracemem[0x8898098 -> 0x8763e18]: tracemem[0x8763e18 -> 0x8766be8]: tracemem[0x8766be8 -> 0x8766b68]: > DF a B 1 1 4 2 2 5 3 3 6 > Are those 3

Is putting a variable into a list a deep copy (and is tracemem the correct way to confirm)? warmstrong at krypton:~/dvl/R.packages$ R > x <- rnorm(1000) > tracemem(x) [1] "<0x3214c90>" > x.list <- list(x.in.list=x) tracemem[0x3214c90 -> 0x2af0a20]: > Is it possible to put a variable into a list without causing a deep copy (i.e. if you _really_ want the

Hi Lille, Is it possible you're looking for tracemem() or inspect() ? > x <- data.frame(z = 1:10)> tracemem(x)[1] "<0x55aa743e0bc0>" > x[1] <- 2Ltracemem[0x55aa743e0bc0 -> 0x55aa778f6ad0]: tracemem[0x55aa778f6ad0 -> 0x55aa778f6868]: [<-.data.frame [<- tracemem[0x55aa778f6868 -> 0x55aa778f5b48]: [<-.data.frame [<- >

Hi Expert I want to use dtrace to monitor the content change of one file. I made following scripts, #!/usr/sbin/dtrace -s inline int MYPID = $1; syscall::write:entry /pid == MYPID/ { tracemem(arg1, arg2); printf("\n"); } It always has an following error bash-3.00$ sudo dumpFIFO.dtrace 3836 dtrace: failed to compile script ./dumpFIFO.dtrace: line 19: tracemem( ) argument #2

I was trying to use tracemem to look at mblk contents. First, I tried to use mblk->b_wptr - mblk->b_rptr as the size, and was told that it had to be a constant. Foo. (RFE #1). Then, I tried to use 8 as the size, and kept getting decimal numbers printed. Stumbled on #pragma D option rawbytes=true (is the =true necessary, btw?) and that didn''t help. Then, in desperation, I

Contrary to, say, Sys.setenv(), Sys.setlocale() returns it's value visibly. This means that if you for instance add: Sys.setlocale("LC_COLLATE", "C") to your .Rprofile file, it will print: [1] "C" at startup. The workaround is to wrap the call in invisible(), but I'd argue that any "setter" function should return invisibly. Some more details:

N_conreq:entry { self->x=1; calledaddr=(struct xaddrf *)arg3; callingaddr=(struct xaddrf *)arg4; trace(calledaddr->link_id); tracemem(calledaddr->DTE_MAC.lsap_add, 80); trace(callingaddr->link_id); tracemem(callingaddr->DTE_MAC.lsap_add, 80); } 0 -> N_conreq 255

The build system has rolled up R-2.15.1.tar.gz (codename "Roasted Marshmallows") at 9:00 this morning. This is a maintenance release; see the list below for details. You can get it from http://cran.r-project.org/src/base/R-2/R-2.15.1.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team Peter

The build system has rolled up R-2.15.1.tar.gz (codename "Roasted Marshmallows") at 9:00 this morning. This is a maintenance release; see the list below for details. You can get it from http://cran.r-project.org/src/base/R-2/R-2.15.1.tar.gz or wait for it to be mirrored at a CRAN site nearer to you. Binaries for various platforms will appear in due course. For the R Core Team Peter

Hi, I am using tracemem() to dump some memory contents. When the contents of the memory contain a mix of binary and ascii, the output looks like: 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 0: 2f 79 2e 20 2e 9e 2e fc fe 2e 2e 38 2e 0a 34 38 /y. .......8..48 10: 34 32 35 2c 20 72 65 6d 6f 74 65 20 69 70 3a 20 425,

Hi, in R-3.1.0 (Linux), traceback() does not show the source file line number for the truncated calls, when limiting the number of lines output for each call with argument max.lines. See sample code, output and session info below (in particular, output for call number 5). I guess this is not intended. Thank you. Bests, Renaud #################### ## File: traceback.R a <- function(...){