John, Thanks very much for the feedback.
Which version of R.app are you using? I have tried some of your steps on MAC OS X 10.4.5 with R 2.2.1 and R.app v 1.14 (2298). > * The R internal editor rails the cpu to 100% when open, even when it > is just sitting in the background -- probably is using polling. On my system, with menumeters on, typically the load is 10%/5% when the system is idle with just R running. If I open, say through open file in the menu, an (internal) editor window, the load goes up for a second or so ( e.g. 36%/18%) and than falls back to above numbers. Same for the next set of additional edit windows (I've tried up to 10 simultaneous windows this morning). If I open the internal editor using fix or edit(functionname) the load will stay up higher (e.g., I've seen 60%/14%) while R is kept 'waiting'. My system is a powerbook G4, guess above numbers will be slightly different for other systems, but on my G5 they are similar. > * Editing via external editor does not seem to work. The fix() call > invokes the external application, but returns immediately. Which is the documented behavior for the external editor (section 4.4.6 of the FAQ for R on Mac OS). How I use it is to source the file back to R after I make edits (using AppleScript). For fix() and edit() you will have to insert the 'functionname <-' before sourcing it back to R. Which I think is ok, usually I end up saving the edited file anyway. I think the 1st step should be to compare the cpu usage and then look into the memory issues. In your examples below, do you start/stop the editor using edit/fix 10s, 100s or 1000s of times before you see a noticeable difference? Rob On Feb 16, 2006, at 7:45 PM, JBThiel wrote: > R 2.2.1 on OS X 10.4.3 (also seen on OS X 10.3.9) > via the Cocoa GUI: > > > * The R internal editor rails the cpu to 100% when open, even when it > is just sitting in the background -- probably is using polling. > > * There appears to be a memory leak with the internal editor, whereby > every time the editor is loaded and exited, the R app consumes at > least 1.2MB of additional memory, and fails to release it. A simple > cycle of: > loop: > fix(abc) > close the edit window > > will apparently increase the R real memory allocation without bound. > > > * Possibly related to the above, as the internal editor is invoked > repeatedly over time, it takes increasingly longer to load the edit > window. > > > * We have also observed a condition where simply mouse-click > switching between the Rconsole window and another R window containing > a displayed graph - but not actually doing anything other than > clicking back and forth, increases the R real memory usage by > 10-20KB on each series of clicks. > > * Editing via external editor does not seem to work. The fix() call > invokes the external application, but returns immediately. The > external editor starts up fine, and sees the tempfile, but any > editing done to it is never seen (since the fix() has already > returned). Tested with editors like TextWrangler, Smultron, > TextEdit. > > > These bugs make it problematic to run long R sessions with heavy > editing, as the R session starts to drag more and more (and can > induce other application (possibly even system) crashes as other apps > fail to run in the diminishing memory space). > > Thanks for your great work on the Cocoa R, which is extremely useful > to us. > > Best regards, > > John > > _______________________________________________ > R-SIG-Mac mailing list > [email protected] > https://stat.ethz.ch/mailman/listinfo/r-sig-mac _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
