Dear Brian, Keeping R.app visible should deal with the case of a long computation as long as users are conscious of the problem, but it's likely that users of the Rcmdr will normally cover up the R.app window or minimize it.
Best, John On Sat, 30 Nov 2013 11:37:19 +0000 Prof Brian Ripley <[email protected]> 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 visibleif all of an apps 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. > > > > On 30/11/2013 10:59, peter dalgaard wrote: > > > > On 29 Nov 2013, at 16:35 , Simon Urbanek <[email protected]> > > 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, [email protected] > 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 > > _______________________________________________ > R-SIG-Mac mailing list > [email protected] > https://stat.ethz.ch/mailman/listinfo/r-sig-mac ------------------------------------------------ John Fox McMaster University Hamilton, Ontario, Canada http://socserv.mcmaster.ca/jfox/ _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
