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

[peter dalgaard]

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.

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