[R-SIG-Mac] R ESS X11 issue possibly related to R tcltk crash under Mavericks...

[Simon Urbanek]

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
>