On 3/19/2007 10:17 AM, Jonathan Wang wrote: > On 3/16/07, Richard M. Heiberger <[EMAIL PROTECTED]> wrote: >> I can't imagine using Windows without Emacs. >> In particular, the Windows ports of Emacs are very aware >> of the operating system and usually make the right assumptions. >> >> The type of behavior you are noticing can probably be cured by typing C-g in >> the >> *R* buffer in emacs. The most likely cause is that the R process in Emacs >> is waiting for the plot to finish and is querying the plotting device. >> Most of that excess CPU usage is from the query loop. The C-g tells Emacs >> and R >> to stop waiting. >> >> If C-g doesn't stop the 100% CPU utilization, then it is most likely >> something >> about the specific plot you are drawing. We will need to see a reproducible >> example to say more. > > The behavior I'm seeing is different from what you've described. It's > reliably reproducible and occurs whenever a plot window is visible, > whether using ESS & Rterm or Rterm directly. Something as simple as > plot(1:10, rnorm(10)) will trigger this behavior.
Could you give the steps to reproduce outside of ESS? What version, what shell, what command line options, etc.? If I can reproduce it I may be able to fix it. I've just tried a couple of times with no problems. Duncan Murdoch > > The Windows task manager shows that it's the Rterm process that's > spinning and not emacs. I've previously observed the behavior you > mention, where ESS gets stuck in a busy loop waiting for the next > command prompt from Rterm. This is also (obviously) suboptimal, but > isn't the particular issue I'm having. > > Perhaps it's a graphics driver conflict of some sort? > > Jonathan ______________________________________________ [email protected] mailing list https://stat.ethz.ch/mailman/listinfo/r-help PLEASE do read the posting guide http://www.R-project.org/posting-guide.html and provide commented, minimal, self-contained, reproducible code.
