similar to: problem quitting

The call to system() probably is an internal call used to delete the session's tempdir(). This sort of failure means that a potentially large amount of disk space is not being recovered when R is done. Perhaps R_CleanTempDir() could call R_unlink() instead of having a subprocess call 'rm -rf ...'. Then it could also issue a specific warning if it was impossible to delete all of

On 11/24/20 11:27 AM, Jan Gorecki wrote: > Thanks Bill for checking that. > It was my impression that warnings are raised from some internal > system calls made when quitting R. At that point I don't have much > control over checking the return status of those. > Your suggestion looks good to me. > > Tomas, do you think this could help? could this be implemented? I think

Dear R-developers, Some of the more fat scripts (50+ GB mem used by R) that I am running, when they finish they do quit with q("no", status=0) Quite often it happens that there is an extra stderr output produced at the very end which looks like this: Warning message: In .Internal(quit(save, status, runLast)) : system call failed: Cannot allocate memory Is there any way to avoid this

On Tue, 24 Nov 2020, Jan Gorecki wrote: > As for other calls to system. I avoid calling system. In the past I > had some (to get memory stats from OS), but they were failing with > exactly the same issue. So yes, if I would add call to system before > calling quit, I believe it would fail with the same error. > At the same time I think (although I am not sure) that new allocations

Hello, I thought I'd add this to the mailing list, in case it could be handled smoother in a future release of R. > q() Save workspace image? [y/n/c]: n *** caught segfault *** address (nil), cause 'unknown' Possible actions: 1: abort (with core dump, if enabled) 2: normal R exit 3: exit R without saving workspace 4: exit R saving workspace Selection: 3 Error: no graphics

** save image Error in loadNamespace(i[[1]], c(lib.loc, .libPaths()), keep.source) : There is no package called 'class' Using 30 May 2004 developer version of R-1.9.0 trying URL `http://cran.r-project.org/src/contrib/e1071_1.4-0.tar.gz' Content type `application/x-tar' length 325388 bytes opened URL .......... .......... .......... .......... .......... ..........

Colleagues, I am writing scripts that run on both Windows (Vista) and Linux (RedHat 9). The scripts will be used in both S-Plus (version 8) and R (2.6.0). I am trying to use the "status" portion of the quit command: ------------------------------------------------------------------------ ----------------------------------------------------------------------- > quit

Thanks Bill for checking that. It was my impression that warnings are raised from some internal system calls made when quitting R. At that point I don't have much control over checking the return status of those. Your suggestion looks good to me. Tomas, do you think this could help? could this be implemented? On Mon, Nov 23, 2020 at 7:10 PM Bill Dunlap <williamwdunlap at gmail.com>

As for other calls to system. I avoid calling system. In the past I had some (to get memory stats from OS), but they were failing with exactly the same issue. So yes, if I would add call to system before calling quit, I believe it would fail with the same error. At the same time I think (although I am not sure) that new allocations made in R are working fine. So R seems to reserve some memory and

(On Unix/Linux) Is it possible to set the --no-save command line option as an option in the .Rprofile file. I have looked in the sources and do not see any obvious (user initiated) ways of changing the command line defaults, but I am hoping I have missed something. I *know* I can write my own shell script wrapper that calls R with whatever arguments I want (and I do that). However there

Use all.equal instead of identical if you want to gloss over integer/numeric class differences and minor floating point differences (and a host of others). Bill Dunlap TIBCO Software wdunlap tibco.com On Mon, Apr 11, 2016 at 5:25 PM, Paulson, Ariel <apa at stowers.org> wrote: > Hi Jeff, > > > We are splitting hairs because R is splitting hairs, and causing us > problems.

> -----Original Message----- > From: bgunter.4567 at gmail.com > Sent: Mon, 11 Apr 2016 19:18:39 -0700 > To: murdoch.duncan at gmail.com > Subject: Re: [R] [FORGED] Re: identical() versus sapply() > > "The documentation aims to be accurate, not necessarily clear." > > !!! > > I hope that is not the case! Accurate documentation that is confusing > is

"The documentation aims to be accurate, not necessarily clear." !!! I hope that is not the case! Accurate documentation that is confusing is not very useful. I understand that it is challenging to write docs that are both clear and accurate; but I hope that is always the goal. Cheers, Bert Bert Gunter "The trouble with having an open mind is that people keep coming along and

On 11/04/2016 10:18 PM, Bert Gunter wrote: > "The documentation aims to be accurate, not necessarily clear." > > !!! > > I hope that is not the case! Accurate documentation that is confusing > is not very useful. I don't think it is ever intentionally confusing, but it is often concise to the point of obscurity. Words are chosen carefully, and explanations are

On 11/04/2016 8:25 PM, Paulson, Ariel wrote: > Hi Jeff, > > > We are splitting hairs because R is splitting hairs, and causing us problems. Integer and numeric are different R classes with different properties, mathematical relationships notwithstanding. For instance, the counterintuitive result: The issue here is that R has grown. The as() function is newer than the as.numeric()

Hi Jeff, We are splitting hairs because R is splitting hairs, and causing us problems. Integer and numeric are different R classes with different properties, mathematical relationships notwithstanding. For instance, the counterintuitive result: > identical(as.integer(1), as.numeric(1)) [1] FALSE Unfortunately the reply-to chain doesn't extend far enough -- here is the original

On 11/21/20 6:51 PM, Jan Gorecki wrote: > Dear R-developers, > > Some of the more fat scripts (50+ GB mem used by R) that I am running, > when they finish they do quit with q("no", status=0) > Quite often it happens that there is an extra stderr output produced > at the very end which looks like this: > > Warning message: > In .Internal(quit(save, status,

Indeed! Slightly simplified to emphasize your point: > class(as(1:2,"numeric")) [1] "integer" > class(as.numeric(1:2)) [1] "numeric" whereas in ?as it says: "Methods are pre-defined for coercing any object to one of the basic datatypes. For example, as(x, "numeric") uses the existing as.numeric function. " I suspect this is related to

Hypothesis regarding the thought process: integer is a perfect subset of numeric, so why split hairs? -- Sent from my phone. Please excuse my brevity. On April 11, 2016 12:36:56 PM PDT, Bert Gunter <bgunter.4567 at gmail.com> wrote: >Indeed! > >Slightly simplified to emphasize your point: > >> class(as(1:2,"numeric")) >[1] "integer" > >>

Hi, I'm running R v1.9.0 on WinXP Pro. I noticed that R.exe and Rterm.exe behave differently on Ctrl-C. Starting a Windows Command prompt (cmd.exe) you get from running Rterm.exe: C:\Program Files\R>rw1090\bin\Rterm.exe --vanilla --quiet > ^C > ^C > 1+1 [1] 2 > Sys.sleep(100) # Ctrl-C after a few seconds > ^C > ^C > 1+1 [1] 2 > q() C:\Program Files\R>