Problems with Rcmdr via XQuartz on OSX Mavericks

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

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

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

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

wrote:



				Dear Rob et al.,

				I'm glad that there's progress in

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

<pdalgd at gmail.com> wrote:




						On 22 Nov 2013, at 16:42 ,

Goedman <goedman at icloud.com> wrote:



							Not sure how long it

the lagging (a few minutes someone reported), but I've not been able to
reproduce this problem.



						For me, library(tcltk);

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

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

Urbanek <simon.urbanek at r-project.org> wrote:



								On Nov 20,

Jonathan Chapman <petsrme2 at icloud.com> wrote:



									I

2.7.5, but it still lags.




								Please read

- it has nothing to do with XQuartz versions




							[[alternative HTML

deleted]]

Business School
						Solbjerg Plads 3, 2000

Denmark
						Phone: (+45)38153501
						Email: pd.mes at cbs.dk  Priv:
PDalgd at gmail.com




					[[alternative HTML version deleted]]

mac

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

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

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

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.

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

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?

-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

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

On 28 Nov 2013, at 14:38, 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?)

Look at svMisc::isAqua(), which uses indeed .Platform$GUI returning "Aqua" on R.app or "X11" on R under a terminal. I am not sure, however, that R on a terminal returns *always* "X11".
Best,

Philippe

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

[

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

On Nov 28, 2013, at 6:21, peter dalgaard <pdalgd at gmail.com> wrote:

On 28 Nov 2013, at 14:38 , 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?) Wouldn't it be better to handle this issue in R.app or even in tcltk, however?

I suspect that this particular option also affects people running simulations from R.app, so that the natural state really should be "disabled" and you need not have qualms about tampering with it. Presumably, we could do the disabling on install. If people have strong reasons to aggressively preserve battery power, they could just turn it back on. 

I think Rob put on his todo list to figure out whether/how you change the setting in an active process, which would open up other possibilities.

-pd 

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

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

Hi, and Happy Thanksgiving for those that celebrate it!

If Peter is right (and I expect he is, but will experiment a bit more if the setting can be updated while R.app is running and take effect immediately), I would suggest for now folks just use 'defaults ...' from a terminal window if they encounter these issues.

Once we understand better what might be affected by allowing the sleep mode we can possibly refine that approach.

Regards,
Rob


Sent from Rob Goedman's iPad ...

On Nov 28, 2013, at 6:21, peter dalgaard <pdalgd at gmail.com> wrote:

On 28 Nov 2013, at 14:38 , 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?) Wouldn't it be better to handle this issue in R.app or even in tcltk, however?

I suspect that this particular option also affects people running simulations from R.app, so that the natural state really should be "disabled" and you need not have qualms about tampering with it. Presumably, we could do the disabling on install. If people have strong reasons to aggressively preserve battery power, they could just turn it back on. 

I think Rob put on his todo list to figure out whether/how you change the setting in an active process, which would open up other possibilities.

-pd 

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

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

-----Original Message-----
From: Robert J Goedman [mailto:goedman at icloud.com]
Sent: Thursday, November 28, 2013 10:33 AM
To: John Fox
Cc: peter dalgaard; r-sig-mac at r-project.org
Subject: Re: [R-SIG-Mac] Problems with Rcmdr via XQuartz on OSX
Mavericks

John,

I apologize for suggesting to you to do extra work. As I said, I'll do
some more testing. The thing that threw me off was that this is an
addition to an existing API (NSProcessInfo) and hence I assumed it was
all runtime ...

Regards,

Rob J. Goedman
goedman at icloud.com




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


	Dear Rob and Peter,

	Thanks for the latest clarifications.

	I think that I'll modify the Rmcdr installation notes to suggest
either using the Rcmdr from R in a terminal window or setting the
NSAppSleepDisabled key permanently in a terminal window -- and hope
that in the longer term the problem is solved generally for R.app.

	Best,
	John

	On Thu, 28 Nov 2013 06:35:12 -0800
	Robert J Goedman <goedman at icloud.com> wrote:


		Hi, and Happy Thanksgiving for those that celebrate it!

		If Peter is right (and I expect he is, but will experiment a
bit more if the setting can be updated while R.app is running and take
effect immediately), I would suggest for now folks just use 'defaults
...' from a terminal window if they encounter these issues.

		Once we understand better what might be affected by allowing
the sleep mode we can possibly refine that approach.

		Regards,
		Rob


		Sent from Rob Goedman's iPad ...




			On Nov 28, 2013, at 6:21, peter dalgaard
<pdalgd at gmail.com> wrote:




				On 28 Nov 2013, at 14:38 , 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 ,

<jfox at mcmaster.ca> wrote:

						Hi Rob,

						I had some time today and so

to implement this solution in the
						Rcmdr. I first tested

						system("defaults write

NSAppSleepDisabled -bool yes")

						fixes the problem; I

						system("defaults read

NSAppSleepDisabled")

						that the key was in fact set

						I'm afraid that even with
NSAppSleepDisabled set, the Rcmdr still freezes
						periodically. Whatever is

probably more complicated than
						power-saving.




					Hmm. The tkfaq issue seems to have

for me. You did remember to restart R.app after setting the key?




				I didn't "remember" to restart R.app because

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

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?



			I suspect that this particular option also affects
people running simulations from R.app, so that the natural state really
should be "disabled" and you need not have qualms about tampering with
it. Presumably, we could do the disabling on install. If people have
strong reasons to aggressively preserve battery power, they could just
turn it back on.

			I think Rob put on his todo list to figure out
whether/how you change the setting in an active process, which would
open up other possibilities.

			-pd




				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


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




	------------------------------------------------
	John Fox
	McMaster University
	Hamilton, Ontario, Canada
	http://socserv.mcmaster.ca/jfox/

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

-----Original Message-----
From: Simon Urbanek [mailto:simon.urbanek at r-project.org]
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 <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 ...'

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

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

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

disable App Nap or just to provide the check box?

		If App Nap isn't disable by R.app by default, would

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

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

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

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

					Thansk Peter,

					Now I can reproduce it!

					Rob J. Goedman
					goedman at icloud.com




					On Nov 22, 2013, at 1:00 PM,

dalgaard

<pdalgd at gmail.com> wrote:




						On 22 Nov 2013, at

Robert J

Goedman <goedman at icloud.com> wrote:



							Not sure how

takes to see

the lagging (a few minutes someone reported), but I've not been

able

to

reproduce this problem.



						For me,

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

wonder if anyone

has seen this behavior after rebuilding R.app on Mavericks (from

the

R.app sources).

							Regards,
							Rob J.

							On Nov 22,

7:29 AM, Simon

Urbanek <simon.urbanek at r-project.org> wrote:



								On

2013, at 11:41 AM,

Jonathan Chapman <petsrme2 at icloud.com> wrote:

upgraded to XQuartz

2.7.5, but it still lags.

Peter's response

- it has nothing to do with XQuartz versions

version

deleted]]

list

R-SIG-Mac at r-project.org

						Center for

Copenhagen

Business School
						Solbjerg Plads 3,

Frederiksberg,

Denmark
						Phone: (+45)38153501
						Email: pd.mes at cbs.dk

PDalgd at gmail.com




					[[alternative HTML version

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

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

for (i in 1:100) print(system.time(replicate(1e4, t.test(rexp(10),mu=1)$statistic))[["elapsed"]])

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.

On 29 Nov 2013, at 16:35 , Simon Urbanek <simon.urbanek at r-project.org> wrote:

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

On the other hand, the OS is also acting very heavy-handed here! Try this

for (i in 1:100) print(system.time(replicate(1e4, t.test(rexp(10),mu=1)$statistic))[["elapsed"]])

and go surf the net or something while you wait. The time per iteration shoots up by a factor of 5-6 as R.app goes into App Nap. I.e., the problem is not confined to tcltk.

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.

Looks like it is that latter. Until we figure out how to do that, I think we need to prepare to tell users to set NSAppSleepDisabled, if they want to do something computationally intensive (and be able to go for a cup of coffee in the meantime). Of course it is nicer, OS-wise, to leave App Nap enabled, but it reduces the energy footprint of an inactive R.app from only about 1.5 to nearly 0.0, compared to about 100 when R is actually working.

This does not happen for me provided R.app is visible.  From

https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_9.html

'An app is considered to be a candidate for sleep if:

     It is not visible?if all of an app?s windows are either hidden by 
other windows or minimized in a hidden dock, and the app is not in the foreground

(other necessary conditions)'.

which if accurate indicates that keeping the R.app console unhidden should suffice.



On 30/11/2013 10:59, peter dalgaard wrote:

On 29 Nov 2013, at 16:35 , Simon Urbanek <simon.urbanek at r-project.org> wrote:

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

On the other hand, the OS is also acting very heavy-handed here! Try this

for (i in 1:100) print(system.time(replicate(1e4, t.test(rexp(10),mu=1)$statistic))[["elapsed"]])

and go surf the net or something while you wait. The time per iteration shoots up by a factor of 5-6 as R.app goes into App Nap. I.e., the problem is not confined to tcltk.

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.

Looks like it is that latter. Until we figure out how to do that, I think we need to prepare to tell users to set NSAppSleepDisabled, if they want to do something computationally intensive (and be able to go for a cup of coffee in the meantime). Of course it is nicer, OS-wise, to leave App Nap enabled, but it reduces the energy footprint of an inactive R.app from only about 1.5 to nearly 0.0, compared to about 100 when R is actually working.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

This does not happen for me provided R.app is visible.  From

https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_9.html

'An app is considered to be a candidate for sleep if:

   It is not visible?if all of an app?s windows are either hidden by other windows or minimized in a hidden dock, and the app is not in the foreground

(other necessary conditions)'.

which if accurate indicates that keeping the R.app console unhidden should suffice.

r <- replicate(50, system.time(replicate(1e4, t.test(rexp(10),mu=1)$statistic))[["elapsed"]])
r

On 30/11/2013 10:59, peter dalgaard wrote:

On 29 Nov 2013, at 16:35 , Simon Urbanek <simon.urbanek at r-project.org> wrote:

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

On the other hand, the OS is also acting very heavy-handed here! Try this

for (i in 1:100) print(system.time(replicate(1e4, t.test(rexp(10),mu=1)$statistic))[["elapsed"]])

and go surf the net or something while you wait. The time per iteration shoots up by a factor of 5-6 as R.app goes into App Nap. I.e., the problem is not confined to tcltk.

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.

Looks like it is that latter. Until we figure out how to do that, I think we need to prepare to tell users to set NSAppSleepDisabled, if they want to do something computationally intensive (and be able to go for a cup of coffee in the meantime). Of course it is nicer, OS-wise, to leave App Nap enabled, but it reduces the energy footprint of an inactive R.app from only about 1.5 to nearly 0.0, compared to about 100 when R is actually working.

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595

Yes, I've seen that as well and it is likely not limited to tcltk.

Question is, for R.app, do we want to ship with NSAppSleepDisabled? I would be in favor (my $0.02).

If yes I will commit.

Regards,
Rob J. Goedman
goedman at icloud.com


On Nov 30, 2013, at 7:00 AM, peter dalgaard <pdalgd at gmail.com> wrote:

On 30 Nov 2013, at 12:37 , Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:

This does not happen for me provided R.app is visible.  From

https://developer.apple.com/library/mac/releasenotes/MacOSX/WhatsNewInOSX/Articles/MacOSX10_9.html

'An app is considered to be a candidate for sleep if:

 It is not visible?if all of an app?s windows are either hidden by other windows or minimized in a hidden dock, and the app is not in the foreground

(other necessary conditions)'.

which if accurate indicates that keeping the R.app console unhidden should suffice.

On Nov 28, 2013, at 6:35 AM, Robert J Goedman <goedman at icloud.com> wrote:

Hi, and Happy Thanksgiving for those that celebrate it!

If Peter is right (and I expect he is, but will experiment a bit more if the setting can be updated while R.app is running and take effect immediately), I would suggest for now folks just use 'defaults ...' from a terminal window if they encounter these issues.

Once we understand better what might be affected by allowing the sleep mode we can possibly refine that approach.

Regards,
Rob

	[[alternative HTML version deleted]]