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. 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.
