John talked to me about this a month ago and after some sick
leave/vacation I had just got around to thinking into it.
Minor points:
1) The usual way to check for OS X in the R sources is
grepl("darwin", R.version$os)
2) It is perfectly possible to build R on Linuxen without X11
headers/libraries.
3) There are three branches to the Tk code, X11, Aqua and Windows. So
apart from on Windows and OS X you either use X11 or do not have Tk.
4) It is possible to build R without Tcl/Tk, in which case you get a
stub tcltk package. Then capabilities('tcltk') tells you that you have
the stub.
5) Just so we are all understand, it is possible (and documented in the
manuals) for tcltk to be built using the Aqua Tk branch, and then Rcmdr
works well (in my opinion much better) without X11 present. So we do
not want Rcmdr checking unconditionally for X11 being present.
My understanding is that the main problem is that if someone installs
one of the CRAN binary packages for OS X and does not have X11 installed
then library(tcltk) will fail with a message that they do not
understand, e.g.
https://stat.ethz.ch/pipermail/r-sig-mac/2014-July/010954.html .
For the future, probably the best thing to do is for the tcltk startup
code to try to trap that case and suggest that X11/XQuartz needs to be
installed. The problem is accurately identifying 'that case'.
If a package has tcltk in the imports of its NAMESPACE, there is nothing
it can do about a broken tcltk as the namespaces it imports will be
processed before any of the code in the package. So the other
possibility is to not have tcltk in the imports but to load its
namespace via Rcmd::.onLoad. I figured out how to to do that but it
would be rather fragile.
There is another possible problem which is that X11 is installed but a X
server is not running. That's what capabilities('X11') checks, and on
modern OS X it ought to launch the X server as required. However, I do
not think we have a way to telling which Tk branch package tcltk was
built against. Since that is only an issue on OS X (no other OS can use
more than one branch) you could use something like
Tk_is_X11 <- function()
{
DLL <- system.file("libs", "tcltk.so", package = "tcltk")
out <- system2("otool", c("-L", shQuote(DLL)), stdout = TRUE)
length(grep("libX11[.][0-9]+[.]dylib", out)) > 0L
}
and then
if (.Platform$OS.type == "unix") {
if (!grepl("darwin", R.version$os) || Tk_is_X11())
if(!capabilities("X11"))
stop("Rcmdr requires a running X server")
}
On 15/07/2014 13:05, Marc Schwartz wrote:
John,
First, apologies for my narrow focus on the solutions that I proposed yesterday. I
suffered from tunnel vision on the OS X issue and as Gabor has noted, it would not be
sufficiently portable. There can be potential variations on where X11 is installed on OS
X, depending upon the use of Xquartz, the original Apple distribution of X11 and
presumably could further vary if one installs from source, is using Homebrew, Macports or
similar, which are package management systems for OS X. Thus, as Gabor pointed out,
capabilities("X11") is the most portable approach.
With respect to Linux, to the best of my knowledge, X11 (for some time X.org)
is still a requirement for tk (but not tcl). In checking at least the current
Fedora repos, X11 is still listed as a dependency for tk. So if one is using
the common package management systems, X11 will be installed if not already,
when installing tk, unless one overrides the defaults.
Also, at least for Fedora and perhaps other Linuxen, X11 is listed as a
dependency for R itself, so if one is installing R on Fedora, X11 will be
installed as well, if not present.
Thus, between the common Linux package management systems and that Linux users
tend to be more technically saavy, you do not see many reports.
You likely already know this, but you could utilize a more generic approach to
testing the platform by using:
if (.Platform$OS.type == "unix")
...
which would cover Linuxen, Unixen and OS X and then run your X11 checks,
secondarily perhaps testing for OS X, if you wish to give a more specific error
message for OS X users and point them to XQuartz.
Regards,
Marc
On Jul 14, 2014, at 11:37 PM, John Fox <[email protected]> wrote:
Hi Gabor,
Thanks for the clarification.
I agree that it would be best to intercept the problem on Linux/Unix as well as
on Mac OS X. Do you know that X11 is necessary for the tcltk package to work on
Linux/Unix systems (or is there possibly a non-X11 Tcl/Tk there that's
compatible with the tcltk package)?
As a practical matter, the problem occurs with some regularity on Mac OS X (I'm
aware that the availability and default installation of X11 varies by version
of the OS), but I've not seen a report of it on Linux, so my immediate concern
was to solve the problem on Mac OS X.
Best,
John
On Mon, 14 Jul 2014 21:37:54 -0400
Gábor Csárdi <[email protected]> wrote:
Hi John,
On Mon, Jul 14, 2014 at 8:12 PM, John Fox <[email protected]> wrote:
Dear Gabor,
As I just explained, the problem isn't testing for X11, which I know how to do -- though
capabilities("X11") is a bit better than what I suggested. The issue is
specific to Mac OS X because the Windows implementation of R includes a Tcl/Tk that
doesn't use X11, and I've never seen the problem on Linux.
actually, what I am saying is, that it is not specific to OSX. Some
(older, before 2012) OSX versions do include an X11 server, and some
Linux or other Unix installations do not.
I am not saying tcltk should not test for an X11 server, all I am
saying is that the test suggested below (based on the os and the
existence of a certain file) is not the best one.
If it turns out that there is no X11 server, and the os is OSX, then
indeed a dialog box could be displayed, see e.g. the one at
http://www.macrumors.com/2012/02/17/apple-removes-x11-in-os-x-mountain-lion-shifts-support-to-open-source-xquartz/
Best,
Gabor
Best,
John
-----Original Message-----
From: Gábor Csárdi [mailto:[email protected]]
Sent: Monday, July 14, 2014 6:37 PM
To: Marc Schwartz
Cc: John Fox; [email protected]; R-SIG-Mac
Subject: Re: [R-SIG-Mac] Mac OS X tcltk/X11 issues
What's wrong with capabilities("X11")?
I am not sure if teting for the OS, and especially for a particular X
server, installed in a particular directory, is a good idea, even if
it covers most of the _current_ installations.
Gabor
On Mon, Jul 14, 2014 at 6:13 PM, Marc Schwartz <[email protected]>
wrote:
On Jul 14, 2014, at 4:53 PM, Marc Schwartz <[email protected]>
wrote:
On Jul 14, 2014, at 4:13 PM, John Fox <[email protected]> wrote:
Dear Simon and list members,
As many of you are aware, when X11 isn't installed on Mac OS X,
loading the
tcltk package produces an error, with a message that many users
find
cryptic. There was yet another instance of this problem reported to
the list
today.
I'm interested in the issue because the Rcmdr package uses tcltk
and thus
fails to load when X11 is absent. Rcmdr users tend to be
inexperienced and
so, unless they find their way to the Rcmdr installation webpage,
where
detailed installation instructions are provided, they tend to be
stymied by
the problem.
If I could, I'd intercept the problem by checking
capabilities()["X11"] in
the Rcmdr .onLoad() or .onAttach() function, but because the Rcmdr
package
imports the tcltk namespace, the error occurs before these startup
functions
are executed -- a chicken-and-egg problem.
It occurs to me that tcltk could fail more gracefully on Mac OS X
when X11
is absent, perhaps popping up a webpage in a browser with
instructions and a
link for installing XQuartz. I'd do this myself in the Rcmdr
package if I
could. Or tcltk could check for the presence of X11 and not try to
start it
if it's absent, reporting a warning rather than throwing an error.
Alternatively, I'd be grateful if someone could suggest how I might
detect
the problem in the Rcmdr package before loading fails. The only
thing that I
could think of was writing a separate RcmdrInstall package that
bypasses
tcltk, but that would be awkward and would only help users who
discovered
that RcmdrInstall exists.
Thanks,
John
John,
Is there someplace in your startup process where you could run code
along the lines of:
if (grepl("apple", R.version$platform) &
length(list.files("/opt/X11/bin", pattern = "Xquartz")) == 0) {
cat("X11 is required. Please visit http://xquartz.macosforge.org
to download and install Xquartz.")
stop()
}
The above code will check to see if the user is running R on OS X
and also if the Xquartz binary is present in the default location.
Not sure if this is helpful.
A possible correction in the above code relative to detecting OS X:
if ((Sys.info()["sysname"] == "Darwin") &
length(list.files("/opt/X11/bin", pattern = "Xquartz")) == 0) {
cat("X11 is required. Please visit http://xquartz.macosforge.org
to download and install Xquartz.")
stop()
}
I believe that Sys.info()["sysname"] == "Darwin" is preferred for
detecting the OS that R is running on versus the OS that it was built
upon according to the help files, if I read correctly. This could be
important if someone is building R from source versus installing
Simon's CRAN binary, I presume.
Regards,
Marc
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--
Brian D. Ripley, [email protected]
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
