Dear Simon, > -----Original Message----- > From: Simon Urbanek [mailto:[email protected]] > Sent: Friday, November 29, 2013 10:35 AM > To: John Fox > Cc: peter dalgaard; R-SIG-Mac > Subject: Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX > Mavericks > > > 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). >
Well, I was proposing to ask for the user's consent (I thought that was clear from my message), but, as I said, it would be better to fix this in either tcltk or R.app, depending upon the nature of the problem. So I think that we're in agreement. Also, I mentioned in a subsequent message that, for the time-being, I'll simply put a note about NSAppSleepDisabled in the Rcmdr Mac OS X installation notes. Best, John > > > 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
