Skip to content

Problems with Rcmdr via XQuartz on OSX Mavericks

47 messages · Brian Ripley, Reijo Sund, Jonathan Chapman +7 more

Messages 1–25 of 47

#
Dear Jonathan,

I'm afraid that I don't know why you're experiencing this problem. I upgraded my own Mac to Mavericks and the Rcmdr still appears to work fine. Also, no one else has reported this problem to me, which of course doesn't mean that no one else has experienced it. 

I don't doubt that something is wrong on your system but I don't know what it might be. You've already reinstalled all of the relevant software, which is what I would have suggested.

I'm copying this response to the R Mac OS X email list in case someone who reads the list has a suggestion or, perhaps, has also experienced the problem.

I'm sorry that I can't be of more help at this time.

John

On Wed, 20 Nov 2013 00:19:54 -0600
Jonathan Chapman <petsrme2 at icloud.com> wrote:
------------------------------------------------
John Fox
McMaster University
Hamilton, Ontario, Canada
http://socserv.mcmaster.ca/jfox/
#
Just checking: which version of XQuartz?

Although I have not experienced any problems, people recommended 
updating to 2.7.5 and I got prompted to do that yesterday (it was 
released last week).
On 20/11/2013 11:52, John Fox wrote:

  
    
#
So far I have not had problems with XQuartz, but similar slow-down occasionally happens while using tcltk-applications with the Aqua version of Tcl/Tk (ActiveTcl 8.6.x binary distribution). Unfortunately I have not been able to create a reproducible example. 

Anyhow, if XQuartz update won?t help, maybe it is worth checking if there is any difference while using R.app or command-line R.

- - -
Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
#
Dear Jonathan et al,

First, thank you to all who responded. As I said, I haven't noticed this problem myself, but I'll try again on my Mac later today when I have some time and see whether I can reproduce it. I suspect that this is a tcltk-related issue, not specific to the Rcmdr, but I don't know that for sure.

In the meantime, here are two things to try:

(1) Reijo Sund suggested trying to run R and the Rcmdr from the command line (i.e., in a terminal window), to see whether the problem manifests itself there. The Rcmdr doesn't need R.app. 

(2) It's possible that the slowdown is caused by the way that the Rcmdr handles R Markdown documents. The overhead gets greater as the session proceeds. To test this possibility, you could suppress the R Markdown tab (via the Rcmdr Tools -> Options menu, Output tab -- uncheck the box for R Markdown) and see whether the problem disappears.

Please let me know what happens.

Best,
 John


On Wed, 20 Nov 2013 10:41:28 -0600
Jonathan Chapman <petsrme2 at icloud.com> wrote:
#
Notes inlined below,

-pd
On 20 Nov 2013, at 18:19 , John Fox <jfox at mcmaster.ca> wrote:

            
Affirmative. You can get similar behaviour from library(tcltk); demo(tkfaq) in R.app. It doesn?t seem to be happening with R in a Terminal window.

You can snap out of it temporarily by switching to the R console and back.

So a working hypothesis is that something is "backgrounding" the R process after a while, if it doesn?t have input focus. Since the tcltk event loop runs off the keyboard loop, we have the trouble. My take is that someone needs to take a look at how R.app handles keyboard input, in particular the timeout aspect.
Negative. I see the issue even with an older Rcmdr version without the Markdown stuff.

  
    
#
Dear all,

I was able to reproduce the problem on my Macbook and believe I have a solution, which is to run R and the Rcmdr in a terminal window. When I did this, the Rcmdr behaved normally. I'll investigate further and report my findings back to the list. 

I'm copying this message to Simon Urbanek who maintains R.app in case he has insight into the problem. 

I'm also interested whether running R from a terminal window solves the problem for others who experienced it.

Best,
 John

On Wed, 20 Nov 2013 12:19:04 -0500
"John Fox" <jfox at mcmaster.ca> wrote:
------------------------------------------------
John Fox
McMaster University
Hamilton, Ontario, Canada
http://socserv.mcmaster.ca/jfox/
#
Dear Peter,

Thank you very much for taking a look at this problem and for confirming that the problem is general to tcltk.

I coincidentally just send a message to the list with the same conclusion -- that the problem occurs in R.app but not in a terminal window.

Best,
 John

On Wed, 20 Nov 2013 21:17:40 +0100
peter dalgaard <pdalgd at gmail.com> wrote:
------------------------------------------------
John Fox
McMaster University
Hamilton, Ontario, Canada
http://socserv.mcmaster.ca/jfox/
#
On 20 Nov 2013, at 22:24 , Manuel Sp?nola <mspinola10 at gmail.com> wrote:

            
[Kids these days...]

Just open the Terminal application (it?s in the Utilities subfolder of the Applications folder) and type R at its prompt. Then library(Rcmdr) at the R prompt.

-pd

  
    
#
Dear Peter,

Thank you for fielding this question.

For the time-being, and pending a more general resolution in R.app, I'll add a note to this effect in the Rcmdr installation notes.

Best,
 John

On Wed, 20 Nov 2013 22:53:11 +0100
peter dalgaard <pdalgd at gmail.com> wrote:
#
Dear all,

I've added the following to the Rcmdr installation notes:

---------------- snip -------------

Under Mac OS X 10.9 ("Mavericks"), the R Commander may slow down or
occasionally hesitate to display a menu as your session progresses. This
behaviour appears to be due to a problem general to the tcltk package
running in R.app under Mac OS X 10.9. You can avoid the problem by running R
in a terminal window rather than using R.app:

o Open the Utilities subfolder inside the Applications folder on your Mac.
Click on Terminal.app to open a terminal window.

o At the Unix command prompt in the terminal window, type R and press the
enter (or return) key. On my Mac, the Unix command prompt looks like this:
john-fox-mbp:~ jfox$

o Once R starts up, you'll see the usual initial messages, followed by the R
command prompt, >

o As usual type library(Rcmdr) at the R prompt and press the enter key.

o After you exit from the R Commander, you can safely close the terminal
window, whether or not you have exited from R.

There really is no reason to prefer running the R Commander in R.app, so
using R from a terminal should be perfectly fine.

---------------- snip -------------

And, in the "Mac OS X Trouble-shooting" section:

---------------- snip -------------

If you are using Mac OS X 10.9 ("Mavericks") and the R Commander becomes
slow or unresponsive, you can run R and the R Commander in a terminal window
on your Mac rather than from R.app. See the installation notes above.

---------------- snip -------------

I hope that this helps, at least for the time-being. If and when the
tcltk/R.app problem is solved, I'll remove these instructions.

Best,
John
1 day later
#
On Nov 20, 2013, at 11:41 AM, Jonathan Chapman <petsrme2 at icloud.com> wrote:

            
Please read Peter's response - it has nothing to do with XQuartz versions
#
Like Peter said, this seems due to the aggressive power-saving in Mavericks so I suspect it will depend on your interaction with the app and your power settings...
On Nov 22, 2013, at 10:42 AM, Robert J Goedman <goedman at icloud.com> wrote:

            
#
On 22 Nov 2013, at 16:42 , Robert J Goedman <goedman at icloud.com> wrote:

            
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.

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

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

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: