similar to: type="message" possibility for capture.output() ?

Dear Rs: Hi, I am trying to read a big text file (nrows=243440, ncols=144). It seems the computational time of all the read methods (scan,readtable,read.delim) is not linear to the number of rows I want to read in: things became really slow once I tried to read in 100000 lines compare to 10000 lines). If I am reading the profiling result right, I guess scan wouldn't help either. My

I've noticed that the processing time for the default capture.output() grows exponentially in the number of characters outputted/captured. The default settings sinks to a temporary textConnection(). When instead sinking to a rawConnection(), the processing time becomes linear. See below example and attached PNG figure [also at

Full_Name: Philippe Grosjean Version: 2.6.1 OS: MacOS X; Windows XP Submission from: (NULL) (81.243.237.235) Last output from capture.output() is truncated if it does not end with a carriage return: > capture.output(cat("text\n")) # Fine [1] "text" > capture.output(cat("text")) # Missing output! character(0) >

This only happens if 'file' is a text connection, and is the expected behaviour in that case: you cannot capture an incomplete line to a text connection. There seems no reason to break the documented behaviour in other cases to change something that you consider to a bug when file=NULL and the user does not produce complete output. It would be possible to make use of isIncomplete()

Is there any way to capture output (both stdout and stderr) from install.packages? Solutions like sink and capture.output don't work because the install.packages calls out to system2 which is executed in a separate process: test <- capture.output(install.packages("MASS")) The system2 function does have arguments stdout and stderr but afaik these cannot be controlled via

printf capture Dear All, I'm running R-2.4.1 on WindowsXP. I wrote a small C++ DLL using Rprintf() and all works fine dyn.load(), is.loaded('f1'), Rprintf(), .C(), all is ok. Now, the worry : I use also a 3rd party piece of C++ program which was not designed for R and uses printf(). I though on sink(...) before .C('f1'), but it doesn't work. I call

Running R.app on Mac OS X 10.4 > version _ platform powerpc-apple-darwin8.6.0 arch powerpc os darwin8.6.0 system powerpc, darwin8.6.0 status major 2 minor 3.1 year 2006

Running R.app on Mac OS X 10.4 > version _ platform powerpc-apple-darwin8.6.0 arch powerpc os darwin8.6.0 system powerpc, darwin8.6.0 status major 2 minor 3.1 year 2006

Dear useRs and wizaRds, I am currently developing a set of functions using S4 classes. On the way I encountered the problem exemplified with the code below. For some reason the 'validity' method does not seem to work, i.e. does not check for errors in the specification of the slots of the defined class. Any hints? My understanding of the whole S4 system was that validity checks are made

I'd like to learn the process of revising R functions & packages and then submitting proposed patches to the R Core team. Would someone be willing to mentor me through one example? For starters, consider an example. I'd like to revise the t.test function to return the stderr value to the user. We only need to change the "rval" in the third-from-the end line of

I have an application where I need to preserve object attributes across calls to 'lapply'. The current definition is: lapply <- function (X, FUN, ...) { FUN <- match.fun(FUN) if (!is.list(X)) X <- as.list(X) rval <- .Internal(lapply(X, FUN)) names(rval) <- names(X) return(rval) } Would it make sense to replace names(rval) <- names(X)

This is a simple SSA code generation 101 question. If I follow the IR code generation techniques in the Dragon book the statement x = y + z would translate into something like this in SSA/LLVM %0 = add %y, %z %x = %0 Obviously "copy instructions" like %foo = %bar are senseless in SSA since %foo and %bar are immutably fixed to the same value and there is no need for two aliases

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

Hi! I've noticed the ecdf() R code (R ver. 2.5.0) contains two call to sort: --- [R-code] --- ecdf <- function(x) x <- sort(x) n <- length(x) if (n < 1) stop("'x' must have 1 or more non-missing values") vals <- sort(unique(x)) rval <- approxfun(vals, cumsum(tabulate(match(x, vals)))/n, method

On Fri, Apr 22, 2011 at 10:40 AM, Wayne Cochran <wcochran at vancouver.wsu.edu> wrote: > This is a simple SSA code generation 101 question. > > If I follow the IR code generation techniques in the Dragon book the > statement >  x = y + z > would translate into something like this in SSA/LLVM >  %0 = add %y, %z >  %x = %0 > Obviously "copy instructions"

I am trying to figure out why 'biglm' can handle large data set... According to the R document - "biglm creates a linear model object that uses only p^2 memory for p variables. It can be updated with more data using update. This allows linear regression on data sets larger than memory." After reading the source code below? I still could not figure out how 'update'

It is my understanding, the alloca memory routines are used for forcing variables to be allocated on the stack frame -- which you would want for source level debugging. When SSA registers are used, LLVM will decide what goes into registers and what will spill over to the stack frame. I want the latter. --w Wayne O. Cochran Assistant Professor Computer Science wcochran at vancouver.wsu.edu

I am using an example posted in this help forum to work with a file. the head of the file looks like: 988887 2007-03-05 2007-06-01 90 3 5.450 205500.00 999.00 999.000 0.000 0 0 988887 2007-03-06 2007-06-01 90 3 5.450 205500.00 999.00 999.000 0.000 1 0 988887 2007-03-07 2007-06-01 90 3 5.450 205500.00 999.00 999.000 -0.100 2 0 988887 2007-03-08 2007-06-01 90 3 5.450 205500.00 999.00 999.000 -0.100

> On Feb 24, 2015, at 10:50 AM, <luke-tierney at uiowa.edu> wrote: > > The documentation is not specific enough on the indented semantics in > this situation to consider this a bug. The original R-level > implementation of lapply was > > lapply <- function(X, FUN, ...) { > FUN <- match.fun(FUN) > if (!is.list(X)) > X <-

Hey listmembers, I am desperately trying to write a data frame to a file. Not in CSV, but as they "appear" on the screen (nice, easy to read tables). I've read that the sink function is the way to go. I have tried the following code inside a function. sink("ABC.txt") MyFrameA MyFrameB sink() It gives the result I need when I use it outside a function, but when I use it