(cc'ing ESS mailing list to which this belongs) 
 
I have been using Emacs, ESS, and R on Windows for several years now. It works 
all together to allmost full satisfaction. Thanks to all people providing these 
tools.
 
I haven't noticed this specific problem, but I guess it is related to what I 
see from time to time when using R, Emacs and ESS to do graphics. I am not 
really into all the details to how Emacs and R communicates through ESS (using 
ddeclinet) but here is something that perhaps can provide useful information to 
more skilled persons.
 
I think it has to do with the way that R og Emacs communicates through 
ddeclient. Normally Emacs waits for R to finish by looking for the next command 
prompt from R indicating that R is finished with the commands submitted to R by 
Emacs/ESS. This means that Emacs can be busy waiting for R to finish which is 
most noticeable when submitting chunks of commands using e.g. C-c C-r (submit a 
region). Emacs/ESS then waits for R to finish each command in the region 
waiting for a signal on a clear command prompt before submitting the next 
command. This can be overriden by using C-c A-r (A = meta (unix) or Alt 
(windows)).
 
What I have noticed is that when I have made a plot and R creates the graphics 
windows. Then R og and the graphics windows from time to time hang (not being 
updated) when I want to focus on the graphics window (to put in front) 
subsequently. In this situation it helps to go to the buffer with the inferior 
ESS process and do a carriage return, which immediately frees the graphics 
windows and now it is getting updated when put in front.
 
This behaviour which I believe is due to the way that Emacs and R communicates 
over ddeclient is not persistent and until now I have hesitated to report it 
because I couldn't provide a small reproducable example. I have noticed this 
over several versions of Emacs (21.2 - 22.1), ESS (< 5 - 5.4) and Windows 
98/NT/XP. 
 
 
Frede Aakmann Tøgersen
Forsker / Scientist


        
         AARHUS UNIVERSITET / UNIVERSITY OF AARHUS      
Det Jordbrugsvidenskabelige Fakultet / Faculty of Agricultural Sciences 
Forskningscenter Foulum / Research Centre Foulum        
Genetik og Bioteknologi / Dept. of Genetics and Biotechnology   
Blichers Allé 20, P.O. BOX 50   
DK-8830 Tjele   
        
Tel:     +45 8999 1900  
Direct:  +45 8999 1878  
Mobile:  +45    
E-mail:  [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>   
Web:     www.agrsci.dk 
<https://djfpost.agrsci.dk/exchweb/bin/redir.asp?URL=http://www.agrsci.dk/>     
 

________________________________

Fra: [EMAIL PROTECTED] på vegne af Duncan Murdoch
Sendt: lø 17-03-2007 00:37
Til: Jonathan Wang
Cc: r-help@stat.math.ethz.ch
Emne: Re: [R] CPU usage on Windows



On 3/16/2007 6:56 PM, Jonathan Wang wrote:
> I'm using R with emacs & ESS on Windows. When I create a plot, sometimes R
> will seem to get stuck in a busy loop, i.e. it will use 100% of my CPU.
> However the system is still somewhat responsive, and the problem usually
> goes away if I create a new device with windows(). If I then close this
> device, making the first device active again, sometimes R will get stuck in
> the busy loop again.
>
> Has anybody heard of this behavior, or, better yet, have a solution?

I've heard of a number of problems with Emacs on Windows.  I wouldn't
recommend using it.  As far as I can see, it makes a number of
assumptions about the OS that just aren't true about Windows.

If you can reproduce the behaviour outside of Emacs, I'll investigate.

Duncan Murdoch

______________________________________________
R-help@stat.math.ethz.ch 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.

______________________________________________
R-help@stat.math.ethz.ch 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.

Reply via email to