On 3/19/07, Jonathan Wang <[EMAIL PROTECTED]> 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. > > 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?
No, it's some weirdness going on with respect to the different "threads" and blocking (and from a Ripley-esque perspective, the intution I'm presenting is technically wrong). Emacs wants to control certain things from the I/O perspective, and some how doesn't do it right, sending Rterm into 100% CPU utilization. So I think I'm still right, that this is more of an design issue, the conflicting suspects being Emacs' design for controlling Microsoft OS subprocesses (emacs inferior process) and R's design as a subprocess with multiple threads (again, I can't help but think that threads is the wrong word here, I'm sure Duncan knows the right one to use), under Microsoft OSs. (Duncan took this as a cynical backslap, and I can't stay that I wasn't partially intending it, but it's also true at face value without historical baggage of peoples opinions). And again, at this point I firmly believe that it's probably more of an ESS/Emacs issue than a pure R one. best, -tony [EMAIL PROTECTED] Muttenz, Switzerland. "Commit early,commit often, and commit in a repository from which we can easily roll-back your mistakes" (AJR, 4Jan05). ______________________________________________ [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.
