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

[John Fox]

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 <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.
> 
> 
> 
> 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
> 
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

------------------------------------------------
John Fox
McMaster University
Hamilton, Ontario, Canada
http://socserv.mcmaster.ca/jfox/