Skip to content

R ESS X11 issue possibly related to R tcltk crash under Mavericks...

2 messages · Blair Christian, Simon Urbanek

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

If anybody knows definitively if this was appropriate/inappropriate, I
would be interested in hearing about it.  Hopefully this helps
somebody else out.
#
On Jan 15, 2014, at 7:02 AM, Blair Christian <blair.christian at gmail.com> wrote:

            
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).
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