> 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 confi...{{dropped:9}} _______________________________________________ R-SIG-Mac mailing list R-SIG-Mac@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac
