On Jul 18, 2014, at 5:17 AM, Kasper Daniel Hansen <[email protected]> wrote:
> On Thu, Jul 17, 2014 at 2:05 AM, Simon Urbanek <[email protected]> > wrote: > On Jul 15, 2014, at 3:01 PM, Kasper Daniel Hansen > <[email protected]> wrote: > > > Prof Ripley and other people involved with tcltk, > > > > You could have the tcltk building routine leave some evidence behind re. > > how it was build. > > > > For example, in Rgraphviz we used to grapple with something similar at the > > abstract level - was the Graphviz version used to build a binary > > distributed version of Rgraphviz, the same as the Graphviz installed by the > > user (if there was a version mismatch on Windows, there was a high chance > > of an arcane error time). As part of running configure, we save the > > Graphviz version at build time into a variable kept in a file in /R. > > Specifically we have a file > > R/graphviz_build_version.R.in > > which contains something like > > graphviz_build_version=@GRAPHVIZ_BUILD@ > > configure does the usual transformation (code here is from memory). > > > > This was then checked in .onLoad before the Rgraphviz dynamic library was > > loaded. Now the code is different, because we bundle Graphviz with > > Rgraphviz. > > > > Something similar should not be too hard to introduce for tcltk to keep a > > record of how it was build. > > > > We see a lot of noise about this issue, so it may be worthwhile to solve > > robustly. > > > > Well, but the above is entirely irrelevant to the discussion at hand > (AFAICT). The problem here is that we are talking about *binary* distribution > - so the build process was indeed created in a fully working environment, but > the user failed to re-create the environment and thus the assumptions at > build time are broken. The assumptions are directly at the linking level, and > the dependency that fails is not even under our control - X11 installation - > so it's not something we can modify > > It seems that Prof. Ripley has fixed this, but I still want to reply to this. > > As I can tell, this is exactly the same as with tcltk: The binary version of > Rgaphviz build on the Bioconductor Windows machines used a specific version > of Graphviz, which (it used to be) was the user's responsibility to create. > If the user failed to do so, the package would throw an error when loaded. > Yes, but in our case it's *not* the direct dependency - i.e. we do control Tcl/Tk which we build and we could check that it's missing, but the thread here is about X11 missing which is not a direct dependency and thus not something we have control over. Also this is not about versions - it's about availability. Moreover, the actual X11 binary can be very different - it can be anything from Apple's X11 to Xquartz or even a custom build (however unlikely). Cheers, Simon > Best, > Kasper > > > > Brian did indeed describe quite precisely the various issues involved here. > > IMHO the other contributions are a bit off track - I would argue that this is > only about CRAN binary so adding a very specific extra check in R along the > lines of what Brian proposed is the most robust and relevant way forward > (note that the check may be identical for the X11 device). We're certainly > not talking about a cross-platform solution but rather a very specific > solution for the CRAN binary. > > Cheers, > Simon > > > > > Best, > > Kasper > > > > > > On Tue, Jul 15, 2014 at 4:16 PM, Prof Brian Ripley <[email protected]> > > wrote: > > > >> 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 > >> > > > > [[alternative HTML version deleted]] > > > > _______________________________________________ > > 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
