R ESS X11 issue possibly related to R tcltk crash under Mavericks...
On Jan 15, 2014, at 7:02 AM, Blair Christian <blair.christian at gmail.com> wrote:
This is probably obvious to somebody with more knowledge than myself,
but I lost an hour or so to this problem. This is description of an
odd Xquartz/R/ESS problem and resolution. It's odd because what
seemed like an ESS problem was resolved by reinstalling Xquartz.
Hopefully it will help somebody else out.
Background:
I have installed R+ESS on 4 machines (2008-2013) running 10.8 and 10.9
in the last couple months, several of them identical on the software
side (matching versions of OS X (10.9.1), R (3.0.2), Emacs (24.3), ESS
(13.09) and Xquartz (2.7.5). I just wiped a 2008 macbook air
yesterday, reinstalled R, ess, emacs for mac, Xquartz (all newest
versions- only difference was that I git cloned the dev version of
ESS) and observed the following behavior:
Problem:
When invoked from the terminal command line, R behaved "normally" when
invoking X11()/plot/capabilities(). However, when any of those
commands were issued in an ESS session in R/emacs, R would close
without invoking X11 (not segfault crash, just close gracefully, as if
I had issued q('yes')). I started going back to previous versions of
ESS because R functioned normally from the command line and I had git
cloned the dev version of ESS (13.09-01) and thought that it was the
culprit, but that didn't work.
Resolution:
I spent some time searching, and ran across Claudia's post here on
r-sig-mac and couldn't tell if the problem I had was identical, but it
was related enough for me to give it a shot. I went to reinstall
Xquartz (2.7.5, fresh download) and afterwards the problem was
resolved.
Possibly Useful Notes/Confounding Issue:
On this old laptop (macbook air 2008/os x 10.9.1/1.86 GHz intel core 2
duo/2Gb ram) the reinstall of Xquartz would say "Install time
remaining: about one minute", but in reality there was a fontconfig
process (fc-cache) that took about 7-8 minutes to complete. Possibly
related to this Xquartz 2.7.5 fontconfig cache rebuild issue?
http://comments.gmane.org/gmane.os.apple.xquartz.devel/723
In previous attempts to reinstall Xquartz, I had killed the fc-cache
process after 4-6 minutes.
That would do it ;). FC is necessary and you have to let it run through so it builds the font database - it doesn't work without it. It can take a while depending on the disk speed, machine, FS fragmentation etc. The lesson is to never interrupt an install process in the middle - not a good idea. (BTW: the "about one minute" is simply a bad UI - Apple has no way of knowing how long it will take since the postflight script doesn't provide any way for tracking the progress).
I read up on it some more and from the command line viewed installed fonts sudo /opt/X11/bin/fc-cache -v -s and all installed fonts were valid, it just took a while and being patient paid off. So I have no idea if this fc-cache command is causing me alone problems or if others are affected. In a fit of desperation in the middle of the troubleshooting, I had removed the font cache, so that confounded my description above. sudo atsutil databases -remove atsutil server -shutdown atsutil server -ping
That has nothing to do with the above. Here you're messing with ATS cache, which has nothing to do with fontconfig and its cache. ATS is the OS X native font handling while FC is the parallel world devised for other unix systems. Cheers, Simon
If anybody knows definitively if this was appropriate/inappropriate, I would be interested in hearing about it. Hopefully this helps somebody else out.
_______________________________________________ R-SIG-Mac mailing list R-SIG-Mac at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-mac