Problems with Rcmdr via XQuartz on OSX Mavericks

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?)

Wouldn't it be better to handle this issue in R.app or even in tcltk, however?

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]]

list

R-SIG-Mac at r-project.org

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]]

-- 
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