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

Simon Urbanek simon.urbanek at r-project.org
Fri Nov 29 16:35:01 CET 2013 

On Nov 28, 2013, at 8:38 AM, John Fox <jfox at mcmaster.ca> wrote:

> Dear Peter,
> 
> On Thu, 28 Nov 2013 12:00:31 +0100
> peter dalgaard <pdalgd at gmail.com> wrote:
>> 
>> On 28 Nov 2013, at 01:46 , John Fox <jfox at mcmaster.ca> 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:goedman at icloud.com]
>>>> Sent: Sunday, November 24, 2013 11:50 AM
>>>> To: John Fox
>>>> Cc: r-sig-mac at r-project.org
>>>> 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
>>>> goedman at icloud.com
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Nov 24, 2013, at 8:30 AM, John Fox <jfox at mcmaster.ca> 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:goedman at icloud.com]
>>>>>> Sent: Sunday, November 24, 2013 10:32 AM
>>>>>> To: John Fox
>>>>>> Cc: r-sig-mac at r-project.org
>>>>>> 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
>>>>>> goedman at icloud.com
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Nov 23, 2013, at 10:31 PM, Robert J Goedman <goedman at icloud.com>
>>>>>> 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
>>>>>> 	goedman at icloud.com
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 	On Nov 23, 2013, at 9:06 PM, John Fox <jfox at mcmaster.ca> 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 <goedman at icloud.com> 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
>>>>>> 			goedman at icloud.com
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 			On Nov 23, 2013, at 5:43 AM, John Fox
>>>>> <jfox at mcmaster.ca>
>>>>>> 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 <goedman at icloud.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> 					Thansk Peter,
>>>>>> 
>>>>>> 					Now I can reproduce it!
>>>>>> 
>>>>>> 					Rob J. Goedman
>>>>>> 					goedman at icloud.com
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 					On Nov 22, 2013, at 1:00 PM, peter
>>>>> dalgaard
>>>>>> <pdalgd at gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 						On 22 Nov 2013, at 16:42 ,
>>>>> Robert J
>>>>>> Goedman <goedman at icloud.com> 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
>>>>>> 							goedman at icloud.com
>>>>>> 
>>>>>> 
>>>>>> 							On Nov 22, 2013, at
>>>>> 7:29 AM, Simon
>>>>>> Urbanek <simon.urbanek at r-project.org> wrote:
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 								On Nov 20,
>>>>> 2013, at 11:41 AM,
>>>>>> Jonathan Chapman <petsrme2 at icloud.com> 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
>>>>>> 
>>>>> R-SIG-Mac at r-project.org
>>>>>> 
>>>>>> 	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: pd.mes at cbs.dk  Priv:
>>>>>> PDalgd at gmail.com
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 					[[alternative HTML version deleted]]
>>>>>> 
>>>>>> 
>>>>>> 	_______________________________________________
>>>>>> 					R-SIG-Mac mailing list
>>>>>> 					R-SIG-Mac at r-project.org
>>>>>> 
>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-
>>>>>> mac
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 	_______________________________________________
>>>>>> 	R-SIG-Mac mailing list
>>>>>> 	R-SIG-Mac at r-project.org
>>>>>> 	https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>> 
>>> _______________________________________________
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac at r-project.org
>>> 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: pd.mes at cbs.dk  Priv: PDalgd at gmail.com
>> 
> 
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>

More information about the R-SIG-Mac mailing list