On Nov 28, 2013, at 8:38 AM, John Fox <[email protected]> wrote: > Dear Peter, > > On Thu, 28 Nov 2013 12:00:31 +0100 > peter dalgaard <[email protected]> wrote: >> >> On 28 Nov 2013, at 01:46 , John Fox <[email protected]> wrote: >> >>> Hi Rob, >>> >>> I had some time today and so I started to implement this solution in the >>> Rcmdr. I first tested whether setting >>> >>> system("defaults write org.R-project.R NSAppSleepDisabled -bool yes") >>> >>> fixes the problem; I verified via >>> >>> system("defaults read org.R-project.R NSAppSleepDisabled") >>> >>> that the key was in fact set properly. >>> >>> I'm afraid that even with NSAppSleepDisabled set, the Rcmdr still freezes >>> periodically. Whatever is going on is probably more complicated than >>> power-saving. >>> >> >> Hmm. The tkfaq issue seems to have gone away for me. You did remember to >> restart R.app after setting the key? >> > > I didn't "remember" to restart R.app because I didn't know that it was > necessary to do so. In fact, the code that I wrote, but didn't commit, for > the Rcmdr carefully resets the key to its previous state or deletes it if it > didn't previously exist when the Commander is closed. > > I think that you've almost surely identified my problem, but the solution > also raises a question about what to do. I'm reluctant to have the Rcmdr make > a permanent change to users' OS settings. I guess that I could detect whether > the NSAppSleepDisabled key is set and pop up a dialog box if it isn't, > offering to make the change, and suggesting that the user restart R.app. > (BTW, is there an easy way to check whether R is running in R.app or a > terminal?)
Yes, check for R_GUI_APP_VERSION env var. 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). > 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. Cheers, Simon > If restarting R.app after setting the NSAppSleepDisabled key doesn't work for > me, I'll then pursue Rob's suggestions. > > Thanks for this, > John > >> -pd >> >>> Best, >>> John >>> >>>> -----Original Message----- >>>> From: Robert J Goedman [mailto:[email protected]] >>>> Sent: Sunday, November 24, 2013 11:50 AM >>>> To: John Fox >>>> Cc: [email protected] >>>> Subject: Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX >>>> Mavericks >>>> >>>> Hi John, >>>> >>>> If it's not too much work, I would implement it in Rcmdr because I >>>> don't know if there are other consequences of App Nap, so until the >>>> dust settles using the defaults system might be ok. >>>> >>>> Regards, >>>> Rob J. Goedman >>>> [email protected] >>>> >>>> >>>> >>>> >>>> On Nov 24, 2013, at 8:30 AM, John Fox <[email protected]> wrote: >>>> >>>>> Hi Rob, >>>>> >>>>> You've just answered my next question! I was holding off to give you >>>> a >>>>> chance to address the issue directly in R.app. >>>>> >>>>> Is there any reason for me, at least for the time-being, not to do >>>> this from >>>>> the Rcmdr via system()? I just tried, and that seems to work. If >>>> necessary, >>>>> I could check for the existence and (if it exists) the current state >>>> of this >>>>> key, and restore that when the Commander() exits. Of course, if you >>>> plan to >>>>> address the issue directly soon, it doesn't make sense for me to do >>>> so. >>>>> >>>>> Thanks again for your help. >>>>> >>>>> John >>>>> >>>>>> -----Original Message----- >>>>>> From: Robert J Goedman [mailto:[email protected]] >>>>>> Sent: Sunday, November 24, 2013 10:32 AM >>>>>> To: John Fox >>>>>> Cc: [email protected] >>>>>> Subject: Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX >>>>>> Mavericks >>>>>> >>>>>> Hi John, >>>>>> >>>>>> If you want to play around with NSAppSleepDisabled yourself, you >>>> can, >>>>>> in a Terminal: >>>>>> >>>>>> defaults write org.R-project.R NSAppSleepDisabled -bool yes >>>>>> >>>>>> to check the setting: >>>>>> >>>>>> defaults read org.R-project.R NSAppSleepDisabled >>>>>> >>>>>> or to re-enable AppNap: >>>>>> >>>>>> defaults write org.R-project.R NSAppSleepDisabled -bool no >>>>>> >>>>>> or just delete the key: >>>>>> >>>>>> defaults delete org.R-project.R NSAppSleepDisabled >>>>>> >>>>>> Regards, >>>>>> Rob J. Goedman >>>>>> [email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Nov 23, 2013, at 10:31 PM, Robert J Goedman <[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> Hi John, >>>>>> >>>>>> I'm just starting, but it look likes 'defaults write ...' can be >>>>>> used to manage the setting. Not elegant, but maybe temporarily ok >>>> for >>>>>> tcltk users. >>>>>> >>>>>> Someone from TexShop (Richard Koch) reported that if R.app is >>>>>> compiled against the 10.9 APIs, the 'Prevent App Nap' check box will >>>>>> not appear. The ultimate solution is for R.app to know when App Nap >>>>>> should not kick in, there is a new API for that. >>>>>> >>>>>> So, some more homework... >>>>>> >>>>>> Regards, >>>>>> Rob J. Goedman >>>>>> [email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Nov 23, 2013, at 9:06 PM, John Fox <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Hi Rob, >>>>>> >>>>>> Thanks for the explanation -- that makes sense of the >>>>> current >>>>>> behaviour. I think that you know that I'm not very knowledgeable >>>> about >>>>>> OS X. A couple of follow-up questions: >>>>>> >>>>>> If you make this change to R.app, will the default be to >>>>>> disable App Nap or just to provide the check box? >>>>>> >>>>>> If App Nap isn't disable by R.app by default, would it be >>>>>> possible to disable it under program control, e.g., when the Rcmdr >>>>>> package is loaded? >>>>>> >>>>>> Best, >>>>>> John >>>>>> >>>>>> On Sat, 23 Nov 2013 18:59:12 -0800 >>>>>> Robert J Goedman <[email protected]> wrote: >>>>>> >>>>>> >>>>>> Hi John, >>>>>> >>>>>> Looking at Activity Monitor on my system, R will >>>>> always >>>>>> take up say 2.5% CPU time while R.app will almost go away if it is >>>> not >>>>>> active. This might be because in a terminal the process might not be >>>>>> treated as a pure application but maybe more as a traditional Unix >>>>>> process. But that's just a guess from my side. >>>>>> >>>>>> What surprised me a bit is that we couldn't switch >>>>> off >>>>>> App Nap, as is possible with several other apps (go to the Info >>>> panel >>>>>> of an app and it should show a 'Prevent App Nap' box, e.g. Dropbox). >>>>>> R.app did not show that box, probably a consequence of an older >>>>>> build/project creation? >>>>>> >>>>>> Anyway, on my system I added that property in the >>>>>> info.plist and disabled the App Nap behavior. It seems to be working >>>>>> fine now. I'll do some more testing to see if I can get the check >>>> box >>>>>> on the Info screen show up and check with Simon if it's ok to commit >>>>>> the change. Of course, in that case R.app will also always consume >>>> 2.5% >>>>>> CPU. Under the energy tab of the Activity Monitor you can see which >>>>>> apps allow App Nap. >>>>>> >>>>>> Rob J. Goedman >>>>>> [email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Nov 23, 2013, at 5:43 AM, John Fox >>>>> <[email protected]> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Dear Rob et al., >>>>>> >>>>>> I'm glad that there's progress in >>>>> understanding >>>>>> the source of the problem, but I wonder why the problem doesn't >>>>>> manifest itself -- at least in my experience -- when R runs in a >>>>>> terminal window. >>>>>> >>>>>> Best, >>>>>> John >>>>>> >>>>>> On Fri, 22 Nov 2013 14:42:00 -0800 >>>>>> Robert J Goedman <[email protected]> wrote: >>>>>> >>>>>> >>>>>> Thansk Peter, >>>>>> >>>>>> Now I can reproduce it! >>>>>> >>>>>> Rob J. Goedman >>>>>> [email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Nov 22, 2013, at 1:00 PM, peter >>>>> dalgaard >>>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 22 Nov 2013, at 16:42 , >>>>> Robert J >>>>>> Goedman <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> Not sure how long it >>>>> takes to see >>>>>> the lagging (a few minutes someone reported), but I've not been able >>>> to >>>>>> reproduce this problem. >>>>>> >>>>>> >>>>>> >>>>>> For me, library(tcltk); >>>>> demo(tkfaq), >>>>>> click to focus, then use Fn-Down (i.e. PgDown) to go to the bottom >>>> of >>>>>> the file, Fn-Up to the top, etc. Less than two iteration for me >>>> before >>>>>> the effect kicks in. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Which makes me >>>>> wonder if anyone >>>>>> has seen this behavior after rebuilding R.app on Mavericks (from the >>>>>> R.app sources). >>>>>> >>>>>> Regards, >>>>>> Rob J. Goedman >>>>>> [email protected] >>>>>> >>>>>> >>>>>> On Nov 22, 2013, at >>>>> 7:29 AM, Simon >>>>>> Urbanek <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Nov 20, >>>>> 2013, at 11:41 AM, >>>>>> Jonathan Chapman <[email protected]> wrote: >>>>>> >>>>>> >>>>>> >>>>>> I >>>>> upgraded to XQuartz >>>>>> 2.7.5, but it still lags. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Please read >>>>> Peter's response >>>>>> - it has nothing to do with XQuartz versions >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [[alternative HTML >>>>> version >>>>>> deleted]] >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> R-SIG-Mac mailing >>>>> list >>>>>> >>>>> [email protected] >>>>>> >>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Peter Dalgaard, Professor, >>>>>> Center for Statistics, >>>>> Copenhagen >>>>>> Business School >>>>>> Solbjerg Plads 3, 2000 >>>>> Frederiksberg, >>>>>> Denmark >>>>>> Phone: (+45)38153501 >>>>>> Email: [email protected] Priv: >>>>>> [email protected] >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> [[alternative HTML version deleted]] >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> R-SIG-Mac mailing list >>>>>> [email protected] >>>>>> >>>>> https://stat.ethz.ch/mailman/listinfo/r-sig- >>>>>> mac >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> R-SIG-Mac mailing list >>>>>> [email protected] >>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >>>>>> >>>>>> >>>>> >>>>> >>> >>> _______________________________________________ >>> R-SIG-Mac mailing list >>> [email protected] >>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> >> -- >> Peter Dalgaard, Professor >> Center for Statistics, Copenhagen Business School >> Solbjerg Plads 3, 2000 Frederiksberg, Denmark >> Phone: (+45)38153501 >> Email: [email protected] Priv: [email protected] >> > > _______________________________________________ > R-SIG-Mac mailing list > [email protected] > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > _______________________________________________ R-SIG-Mac mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-mac
