Hi Rob, OK -- thanks. I'll do that in the development version of the package on R-Forge when I have a chance, likely sometime this week. I'll then post a message to this list.
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
