On Mar 11, 2015, at 6:07 PM, David Dobolyi <dd...@virginia.edu> wrote:
> I can confirm the problem does not occur in 3.1.1 and only started with > 3.1.2. The R.app GUI version in 3.1.1 was 6784 and in 3.1.2 was 6833, so it > seems like some regression was possible between builds within GUI version > 1.65? No, the SVN revisions are shared with other R packages that why the revisions change even if the sources don't (see svn diff -r 6784). > Build 6912 in 3.1.3 for Mavericks still exhibits the behavior as Yan > mentioned. > That is odd - the only explanation I can think of would be changes in Xcode versions, i.e. in the toolchain. I'll check when I'm back on a Yosemite machine. Thanks, Simon > Best, > > David > > On Wed, Mar 11, 2015 at 5:58 PM, Simon Urbanek <simon.urba...@r-project.org> > wrote: > > > On Mar 11, 2015, at 5:17 PM, ALPEROVYCH Yan <alperov...@em-lyon.com> wrote: > > > > Hi Simon, > > > > It may be a silly question but shouldn’t this Yosemite bug affect the the > > 3.1.1 version as well? > > > > Yes it should, since the code didn't change since 3.1.1. > > > > I tried also to run R from the terminal and found no rendering issues there, > > That has nothing to do with it - R is not using any Cocoa for text on the > command line - and Terminal is not likely to use NSTextView. > > > > which points on the GUI - Yosemite related bug as you say. The R 3.1.1 > > version that I have (and in which this rendering problem is not present) > > runs with R.app GUI 1.65 (6784) x86_64-apple-darwin13.1.0. Does it make > > sense / is it possible to run R 3.1.3 with this particular version of GUI? > > > > Are you saying the 3.1.1 binary didn't exhibit the behavior? That would be > odd - I'll check tomorrow when I'm back at a Yosemite machine. > > Cheers, > Simon > > > > > Cheers, > > Yan > > > >> On Mar 11, 2015, at 9:21 PM, Simon Urbanek <simon.urba...@r-project.org> > >> wrote: > >> > >> On Mar 11, 2015, at 2:11 PM, David Dobolyi <dd...@virginia.edu> wrote: > >>> > >>> Hello Yan, > >>> > >>> I was curious if the new R update would fix this as well, so thanks for > >>> clarifying that it sadly does not. > >>> > >> > >> There were no code changes on our end. > >> > >> AFAICT this seems to be an issue in Apple's NSTextView Cocoa > >> implementation in Yosemite. Pretty much all the time is spent in > >> [NSTextView drawRect:] so Apple must have added some rather bad > >> inefficiency to drawing text area in Yosemite. As you fill the console, > >> the response time goes down as the text filed takes longer and longer to > >> render. You can also see it in the editor if you add many lines. When you > >> clear the console, it's responsible again since you don't have that many > >> lines in the text view. > >> > >> It seems like a serious bug in Yosemite. We don't control the rendering - > >> it's all in Apple's code, so I don't see immediately how we can work > >> around that bug. > >> > >> Cheers, > >> Simon > >> > >> > >> > >>> Best, > >>> > >>> David > >>> > >>> PS. Simon, regardless of this bug, all of your hard work is very much > >>> appreciated on an invaluable program! > >>> > >>> On Wed, Mar 11, 2015 at 5:44 AM, ALPEROVYCH Yan <alperov...@em-lyon.com> > >>> wrote: > >>> Hi Simon & David, > >>> > >>> Just for the record, I've tried the new 3.1.3 version (on the same > >>> Yosemite machine) and the issue is still there. > >>> > >>> Best, > >>> > >>> Yan Alperovych, Ph.D. > >>> Associate Professor of Finance > >>> EMLYON Business School > >>> Tel.: +33 4 72 18 29 11 > >>> E-mail: alperov...@em-lyon.com<mailto:alperov...@em-lyon.com> > >>> LinkedIN: > >>> fr.linkedin.com/in/yanalperovych/<http://fr.linkedin.com/in/yanalperovych/> > >>> > >>> On Feb 24, 2015, at 7:28 PM, Simon Urbanek > >>> <simon.urba...@r-project.org<mailto:simon.urba...@r-project.org>> wrote: > >>> > >>> Thank you both, I'll look into this as soon as I get back from travels. > >>> Simon > >>> > >>> > >>> On Feb 23, 2015, at 4:23 PM, David Dobolyi > >>> <dd...@virginia.edu<mailto:dd...@virginia.edu>> wrote: > >>> > >>> Dear Simon, > >>> > >>> Thank you for your reply. I am using the Mavericks build (running on > >>> latest Yosemite), and have noticed this issue ever since I upgraded to > >>> 3.1.2: > >>> > >>> <Screen Shot 2015-02-23 at 4.12.35 PM.png> > >>> > >>> As an aside, I occasionally see errors in the GUI like this, and they > >>> seem to come from other apps (e.g., Dropbox): > >>> > >>> <Screen Shot 2015-02-23 at 4.13.09 PM.png> > >>> > >>> More importantly, I wrote Yan about a workaround, which involves changing > >>> the max.print option from the default and limiting it to 1000. This > >>> reliably stops R from slowing down over time (although how long, I don't > >>> know). However, I can replicate the basic issue easily in R with the > >>> following code: > >>> > >>> options(max.print=99999) > >>> temp <- data.frame(1:100000, 1:100000) > >>> temp > >>> > >>> This should eventually turn up on screen, and after try typing anything > >>> in the console. Typing will be extremely delayed (e.g., type hello and it > >>> will take several seconds for each letter to show up, one at a time). > >>> > >>> It's even possible to crash the GUI if you print something in a function > >>> called in a bootstrap, and then invoke a progress bar (e.g., the pROC > >>> package). Progress will be steady and then suddenly R will lock up. The > >>> moment you remove the print statement (which isn't actually printing > >>> since the progress bar is present), the same call works perfectly. > >>> > >>> I'd love to have a real fix for this other than reducing max.print. I'd > >>> dig into the source myself but can't commit the time at the moment. > >>> > >>> Best, > >>> > >>> David > >>> > >>> > >>> > >>> On Mon, Feb 23, 2015 at 4:00 PM, Simon Urbanek > >>> <simon.urba...@r-project.org<mailto:simon.urba...@r-project.org>> wrote: > >>> Are you using the Mavericks build of R? The SL build will do that, > >>> because SL has no AppNap support - but then you can also disable AppNap > >>> (see the corresponding threads here). > >>> > >>> Cheers, > >>> S > >>> > >>> > >>> On Feb 14, 2015, at 12:43 AM, David Dobolyi > >>> <dd...@virginia.edu<mailto:dd...@virginia.edu>> wrote: > >>> > >>> Dear Yan, > >>> > >>> Are you still seeing this issue? It has been bothering me for months now, > >>> and I even found an instance where using progress_bar with underlying > >>> output to the GUI will cause so much slowdown as to crash R given > >>> sufficient time (i.e., as hidden printed output piles > >>> up in the background, the whole process slows to a crawl). > >>> > >>> Best, > >>> > >>> David > >>> > >>> _______________________________________________ > >>> R-SIG-Mac mailing list > >>> R-SIG-Mac@r-project.org<mailto:R-SIG-Mac@r-project.org> > >>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac > >>> > >>> > >>> > >>> > >>> > >>> -- > >>> David Dobolyi, M.A. > >>> PhD Candidate > >>> Cognitive Psychology > >>> University of Virginia > >>> 434-535-6073 > >>> dd...@virginia.edu<mailto:dd...@virginia.edu> > >>> > >>> _______________________________________________ > >>> R-SIG-Mac mailing list > >>> R-SIG-Mac@r-project.org<mailto:R-SIG-Mac@r-project.org> > >>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac > >>> > >>> > >>> > >>> ---- > >>> Ce message electronique et tous les fichiers attaches qu'il contient sont > >>> confidentiels et destines exclusivement à l'usage de la personne à > >>> laquelle ils sont adresses. Si vous avez reçu ce message par erreur, > >>> merci de le retourner à son metteur. Les idees et opinions presentees > >>> dans ce message sont celles de son auteur, et ne representent pas > >>> necessairement celles de l'institution ou entite affiliee dont l'auteur > >>> est l'employe. La publication, l'usage, la distribution, l'impression ou > >>> la copie non autorisee de ce message et des attachements qu'il contient > >>> sont strictement interdits. > >>> > >>> This email and any files transmitted with it are confidential and > >>> intended solely for the use of the individual or entity to whom they are > >>> addressed. If you have received this email in error please return it to > >>> the sender. The ideas and views expressed in this email are solely those > >>> of its author, and do not necessarily represent the views of the > >>> institution or company of which the author is an employee. Unauthorized > >>> publication, use, distribution, printing or copying of this e-mail or any > >>> attached files is strictly forbidden. > >>> > >>> > >>> > >>> > >>> -- > >>> David Dobolyi, M.A. > >>> PhD Candidate > >>> Cognitive Psychology > >>> University of Virginia > >>> 434-535-6073 > >>> dd...@virginia.edu > >> > > > > > > ---- > > Ce message electronique et tous les fichiers attaches qu'il contient sont > > confidentiels et destines exclusivement à l'usage de la personne à laquelle > > ils sont adresses. Si vous avez reçu ce message par erreur, merci de le > > retourner à son metteur. Les idees et opinions presentees dans ce message > > sont celles de son auteur, et ne representent pas necessairement celles de > > l'institution ou entite affiliee dont l'auteur est l'employe. La > > publication, l'usage, la distribution, l'impression ou la copie non > > autorisee de ce message et des attachements qu'il contient sont strictement > > interdits. > > > > This email and any files transmitted with it are confidential and intended > > solely for the use of the individual or entity to whom they are addressed. > > If you have received this email in error please return it to the sender. > > The ideas and views expressed in this email are solely those of its author, > > and do not necessarily represent the views of the institution or company of > > which the author is an employee. Unauthorized publication, use, > > distribution, printing or copying of this e-mail or any attached files is > > strictly forbidden. > > > > > -- > David Dobolyi, M.A. > PhD Candidate > Cognitive Psychology > University of Virginia > 434-535-6073 > dd...@virginia.edu _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
