similar to: Dealing with xmalloc: out of virtual memory

[some de-capitalization of *SXP done manually by mailing list maintainer ; the originally was caught as potential spam. MM] I have a little R program that crashes with the message xmalloc: out of virtual memory The code has a repeat{} loop that watches the sizes of some files. When there's an increase it updates things by reading the last 65 lines of each file, doing some

I have encountered a problem with merge() that appears to be a bug. Here's an example to illustrate it. > tmp1 <- data.frame(a=letters[1:3],b=LETTERS[2:4],x=1:3) > tmpa <- expand.grid(a=letters[1:4],b=LETTERS[1:4]) > tmpm.1 <- merge(tmpa,tmp1) > tmpm.2 <- merge(tmp1,tmpa) Error in "names<-.default"(*tmp*, value = vnames) : names attribute must

I have found that data imported from SAS using read.xport() in package foreign (installed recently) does not match the original data, when the data consists of character strings that are only one character long. Here is an example. ---- SAS commands to create the data ---- options nocenter; data foo; a='a'; b='bb'; length c d $2; c='c'; d='

I have asked this question before, and received some suggestions for work-arounds that get the job done--and they are much appreciated. But I would still like to find out if I'm missing something, and whether there is a direct way using POSIXt functions (as.POSIXct, as.POSIXlt, strptime, in particular). I have environmental data collected once per minute. Here is a subset of 3 input

I'm trying to figure out how to get out of this situation: > source('monit.r') Error in file(file, "r") : All connections are in use > showConnections() description class mode text isopen can read can write > help.search('connection') Error in file(file, "r") : All connections are in use > q() Save workspace image? [y/n/c]: y Error

I have plots that were stored using recordPlot() in a fairly recent but pre-1.6.0 version of R that will not replayPlot() in R 1.6.0. The error message is Error in replayPlot(x) : invalid hex digit in color or lty The plots were stored in June (2002-6-14), each as an element of a list named 'rpl'. The version of R that was current then is what I used. At that time I was able to

It appears that julian() is in R-base, but julian.default() is in the chron package. > search() [1] ".GlobalEnv" "package:ctest" "Autoloads" "package:base" > julian(1:3,4:6,1991:1993) Error in julian(1:3, 4:6, 1991:1993) : no applicable method for "julian" > find('julian') [1] "package:base" >

For certain values, round.POSIXt(tm,'day') does not round to midnight as documented. The reason is that trunc.POSIXt() does not adjust the value of the isdst element. Assuming my assessment of the reason is correct, I have a potential solution to offer. Additional discussion is in bug report #1543. -Don > x <- c(as.POSIXct('2001-4-1 3:15'),as.POSIXct('2001-5-2

I decided my earlier email on this topic was rather long and wordy; here's a condensed version. I am sitting at a Solaris computer in the US/Pacific timezone. I have a file of data having times that includes the following three values 2002-4-7 1:30:00 GMT 2002-4-7 2:30:00 GMT 2002-4-7 3:30:00 GMT I have not been able to find a way to correctly convert these to either of the POSIX

I have written a set of functions for POSIXt objects that I would like to offer for consideration for use in base R. They augment and extend existing functions. Briefly, ## pretty.ct function(x,specs=pretty.ct.specs) ## round.ct function(x, tstr='1 min' ) ## axis.ct function(side,x,specs=NULL,...) ## parse.timeint function(dv) ## parse.tstr

I was surprised when seq.POSIXt() returned a single value rather than a vector, from inputs that I thought were reasonable. Here's an example to illustrate: > t0 <- ISOdatetime(2002,6,24,0,0,10) ## expected a sequence of 16 times 1 second apart > seq.POSIXt(from=t0,to=t0+15,by='1 sec') [1] "2002-06-24 00:00:10 PDT" ## traces to this call >

Hi, I do have it installed on 2 Macs as well (OS X 10.2.8 and 10.3.7) and what I need does work, however if you do the command check routine some problems will likely be revealed. At least there were problems for me. Denis Le 08 févr. 2005, à 12:23, r-help-request@stat.math.ethz.ch a écrit : > De: Don MacQueen <macq@llnl.gov> > Date: 07 février 2005 16:05:14 GMT+01:00 > À:

> From: Don MacQueen [mailto:macq at llnl.gov] > > At 5:29 PM +0100 4/30/03, Luke Whitaker wrote: > > > >At the risk of starting a religous war, isn't java the obvious choice > >for a platform independent GUI ? I know java suffered a lot from > >early over hypeing when it wasn't really ready, but in the last year > >or two I've seen some very

I am wondering if there is a CRAN package that includes a utility function that will "rotate" file names, in the same sense that operating systems sometimes rotate log files. Or maybe there's something in base R. That is, we have a set of file names, say file1, file2, file3, and when the function is called, file3 is deleted, file2 is renamed file3, file1 is renamed file2, and

I'm also having trouble installing R 1.3.1 on Solaris and getting png and jpeg support. It looks like perhaps the png and jpeg libraries I installed weren't built with all the support R needs. If that's the case I'd appreciate confirmation. Or perhaps there's something else I can do? (with all the details I've included this message is rather long) Thanks -Don I did

Begin forwarded message: > From: Dan Kelley <Dan.Kelley at Dal.Ca> > Date: March 19, 2004 12:00:01 PM AST > To: Don MacQueen <macq at llnl.gov> > Subject: Re: [R] osx/fink: cannot do "R INSTALL" (library mixup) > > That works perfectly! THanks. I did > 524 export PKG_LIBS="-L/usr/local/lib -L/sw/lib" > 525 R INSTALL pspline > and

This is not a bug, and has nothing to do with times. For example: > round(1.03,1) [1] 1 Formatting is not the same as rounding. Perhaps you are assuming R formats numbers according to the concept of significant digits, but it doesn't. See the help page for the format function to get started with understanding R's rules for formatting numbers when it displays them. Maybe also some

This looks like a bug? Unable to use scan(pipe()) while profiling. I have no idea whether this version of R violates the "do not use `Rprof' in an executable built for profiling" warning in ?Rprof. Thanks -Don > version _ platform powerpc-apple-darwin1.4 arch powerpc os darwin1.4 system powerpc, darwin1.4 status Patched major 1 minor 3.1 year

Hi Don, wow, you are so right. I picked that piece up from the bloggers tutorial and since I am R naive yet, I thought it was all one step moving_average = forecast(ma(tdat[1:31], order=2), h=5) Truly, I usually print and check at every step I can, as painful as it is sometimes. Great lesson for this novice usR. So the first and last values are NA in each case? Do you know why? Should I replace

It's not unusual for R users (like me!) to think they've found a bug, when in fact it's their own error. I would like to ask, however, about the situation where a user has studied the situation enough to be very confident they've found a bug. In that case, what procedure would the R core team like users to follow: 1) post to r-help, then wait for a confirmation and request