R for MAC experts: When using the current version of R for MAC, I notice a troublesome behavior. Sometimes I need to build complex regression models (usually using lmer) or simulations that take 10 minutes or more for the computer to compute. While this computing is going on, I would like to be able to take advantage of this "free time" to write more code. But I can't! In my current setup of R for MACs the script editor is frozen while the console is computing. That means that my only recourse is to go for a 10 minute coffee or to the toilet. I don't believe that my windows version of R has this same problem. My question: Is there a way to set R for MAC up so that the script editor window is functional while the console window in chomping away at some calculations? Brant Inman Duke University
Frozen script editor window while R console is computing
2 messages · Brant Inman, Simon Urbanek
On Mar 25, 2009, at 21:04 , Brant Inman wrote:
R for MAC experts: When using the current version of R for MAC, I notice a troublesome behavior. Sometimes I need to build complex regression models (usually using lmer) or simulations that take 10 minutes or more for the computer to compute. While this computing is going on, I would like to be able to take advantage of this "free time" to write more code. But I can't! In my current setup of R for MACs the script editor is frozen while the console is computing. That means that my only recourse is to go for a 10 minute coffee or to the toilet. I don't believe that my windows version of R has this same problem. My question: Is there a way to set R for MAC up so that the script editor window is functional while the console window in chomping away at some calculations?
The current GUI is running in the same event loop as R in order to allow R to use UI elements directly. This implies that if some C code in R hogs the CPU without allowing UI events to be processed, it will block the whole UI including the editor. "Good" packages won't do that since R provides R_CheckUserInterrupt() call to prevent this from happening, but apparently some still do. Although there is a draft of a GUI that runs R on a separate thread from the GUI, but it opens up a whole can of worms since all access to system libraries needs to be scheduled on the main thread. Since R has no provision for that, it would make it likely that packages will violate this rule thus making R unstable, especially since it's OS- specific. Unfortunately UIs on OS X have to run on the main thread, so we cannot run R on the main thread and the GUI on a separate thread. Therefore the best we can currently do is to rely on packages to check events during long computations in C code. Note that this is not an issue in pure R code because R makes sure the check are done. Cheers, Simon