search for: printvaluerec

...uot;$b", not "$a$b" [1] "hello" attr(,"class") [1] "world" This happens because the default print method resets the tag buffer anytime it's called[1], whether by a custom print method, or by internal C code as part of the recursion into objects in `printValueRec`[2]. One possible way to "fix" this is to make it the responsibility of `printValueRec` to reset the tag buffer on exit from the top level, but that would mean always having an active context to catch errors instead of just for win32 as is the case now.? Additionally, print method author...

...; [1] "hello" > > attr(,"class") > [1] "world" > > This happens because the default print method resets the tag buffer anytime > it's called[1], whether by a custom print method, or by internal C code as > part of the recursion into objects in `printValueRec`[2]. > > One possible way to "fix" this is to make it the responsibility of > `printValueRec` to reset the tag buffer on exit from the top level, but that > would mean always having an active context to catch errors instead of just > for win32 as is the case now.? Additiona...

A problem that I've encountered when using do.call a lot is very large stack traces, eg: f <- function(x) stop() do.call(error, mtcars) traceback() f <- function(x) browser() do.call(f, mtcars) I have hacked together my own version of traceback to fix this by limiting the length of each line to 80 characters, but I can't see any way to do something similar for browser. Any

I was trying to create a function with a value computed at creation time, using substitute(), but I got results I don't understand: > this.is.R Error: Object "this.is.R" not found > substitute(this.is.R <- function() X, list(X=!is.null(options("CRAN")[[1]]))) this.is.R <- function() TRUE > # the above expression as printed is what I want for the

...**** --- 610,621 ---- SET_DEBUG(newrho, DEBUG(op)); if (DEBUG(op)) { Rprintf("debugging in: "); + + itmp = asInteger(GetOption(install("deparse.max.lines"), R_BaseEnv)); + if(itmp != NA_INTEGER && tmp > 0) R_BrowseLines = itmp; PrintValueRec(call,rho); + R_BrowseLines = 0; + /* Is the body a bare symbol (PR#6804) */ if (!isSymbol(body) & !isVectorAtomic(body)){ /* Find out if the body is function with only one statement. */

I am having some difficulties using dynamically loaded C functions on a Sparc 10 with R compiled using cc (both R-0.49 and R-0.50). I get sporadic errors with the error message: Error: character variables must be duplicated in .C/.Fortran, with C functions which pass character variables. my C functions look like: anyfunc(char **filename, other variables ) This error message appears about 25%

I am having some difficulties using dynamically loaded C functions on a Sparc 10 with R compiled using cc (both R-0.49 and R-0.50). I get sporadic errors with the error message: Error: character variables must be duplicated in .C/.Fortran, with C functions which pass character variables. my C functions look like: anyfunc(char **filename, other variables ) This error message appears about 25%

Hi all, Can anyone help me understand why an implicit print (i.e. just typing df at the console), is so much slower than an explicit print (i.e. print(df)) in the example below? I see the difference in both Rstudio and in a terminal. # Construct large df as quickly as possible dummy <- 1:18e6 df <- lapply(1:10, function(x) dummy) names(df) <- letters[1:10] class(df) <-

I know I said that I had no further comments on object oriented semantics. However, I found a contradiction in the R documentation. Gabriel Becker wrote: > So, there are implicit classes, but *only when the data object is NOT an "R object" In the R Language Definition: > The R specific function typeof returns the type of an R object. > Lists have elements, each of which can

Consider the following example: # substitute a with b in the indicated function. Seems to work. > z <- substitute( function()a+1, list(a=quote(b)) ) > z function() b + 1 # z is an object of class call so use eval # to turn it into an object of class expression; however, # when z is evaluated, the variable a returns. > eval(z) function()a+1 Why did a suddenly reappear again