[R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX Mavericks
pdalgd at gmail.com
Sat Nov 30 16:00:05 CET 2013
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
> '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"]])
 5.853 3.607 3.118 3.037 3.012 2.983 2.962 2.978 2.949 2.956
 2.957 19.882 24.386 26.441 25.563 27.452 21.195 20.823 3.012 2.976
 2.965 2.966 2.969 2.945 3.057 2.958 2.942 2.971 2.976 2.936
 2.978 2.960 2.991 2.991 2.994 3.021 2.991 2.974 3.005 2.985
 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
Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
More information about the R-SIG-Mac