[R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks

[peter dalgaard]

On 30 Nov 2013, at 12:37 , Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:

> This does not happen for me provided R.app is visible.  From
> 
> https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_9.html
> 
> 'An app is considered to be a candidate for sleep if:
> 
>    It is not visible—if all of an app’s windows are either hidden by other windows or minimized in a hidden dock, and the app is not in the foreground
> 
> (other necessary conditions)'.
> 
> which if accurate indicates that keeping the R.app console unhidden should suffice.
> 
> 

Some experimenting indicates that R.app will nap  with a partially exposed window, if there is no change to the exposed part of the window. If the top right corner is obscured by the Activity Monitor and I change the test command to not generate output, I see

> r <- replicate(50, system.time(replicate(1e4, t.test(rexp(10),mu=1)$statistic))[["elapsed"]])
> r
 [1]  5.853  3.607  3.118  3.037  3.012  2.983  2.962  2.978  2.949  2.956
[11]  2.957 19.882 24.386 26.441 25.563 27.452 21.195 20.823  3.012  2.976
[21]  2.965  2.966  2.969  2.945  3.057  2.958  2.942  2.971  2.976  2.936
[31]  2.978  2.960  2.991  2.991  2.994  3.021  2.991  2.974  3.005  2.985
[41]  3.006  2.991  3.033  3.017  2.978  3.012  2.987  2.997  2.995  3.053

(I got bored and woke it after a couple of minutes, at iteration 18).

It doesn't happen if it is the bottom right corner that is obscured, so that the spinning "I'm working" symbol is visible, so I suppose the logic is tied to window updates.

> 
> On 30/11/2013 10:59, peter dalgaard wrote:
>> 
>> On 29 Nov 2013, at 16:35 , Simon Urbanek <simon.urbanek at r-project.org> wrote:
>> 
>>> 
>>> But let me say that what has been proposed is very heavy-handed to say it mildly - changing user's configuration files is not something that should be done without user's consent (if at all) - and AFAIK you're not allowed to do it if you plan to put this on CRAN. In addition, it's trying to swat the symptom with a hammer, it doesn't solve the problem (which is why doesn't tcltk wake up sleep with its activity).
>>> 
>> 
>> On the other hand, the OS is also acting very heavy-handed here! Try this
>> 
>>> for (i in 1:100) print(system.time(replicate(1e4, t.test(rexp(10),mu=1)$statistic))[["elapsed"]])
>> 
>> and go surf the net or something while you wait. The time per iteration shoots up by a factor of 5-6 as R.app goes into App Nap. I.e., the problem is not confined to tcltk.
>> 
>>> 
>>>> Wouldn't it be better to handle this issue in R.app or even in tcltk, however?
>>>> 
>>> 
>>> Yes, it should be handled in either of the two - if this problem is tcltk-specific then tcltk should wake up the sleep, if it is something that affects other R code as well, then it may need to be handled in the R event loop.
>> 
>> Looks like it is that latter. Until we figure out how to do that, I think we need to prepare to tell users to set NSAppSleepDisabled, if they want to do something computationally intensive (and be able to go for a cup of coffee in the meantime). Of course it is nicer, OS-wise, to leave App Nap enabled, but it reduces the energy footprint of an inactive R.app from only about 1.5 to nearly 0.0, compared to about 100 when R is actually working.
>> 
> 
> 
> -- 
> Brian D. Ripley,                  ripley at stats.ox.ac.uk
> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
> University of Oxford,             Tel:  +44 1865 272861 (self)
> 1 South Parks Road,                     +44 1865 272866 (PA)
> Oxford OX1 3TG, UK                Fax:  +44 1865 272595

-- 
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd.mes at cbs.dk  Priv: PDalgd at gmail.com