It turns out that the behavior of starting just Tcl was actually a bug. Apparently the intention was to attempt to start Tk regardless of the DISPLAY variable, because some TclTk implementation such as Aqua Tcl/Tk don't require DISPLAY and thus would not be loaded. Due to a bug (HAVE_AQUA was not included in Rconfig.h before R 2.7.0), though, this was not the case. I'll leave it to tcltk users/maintainers to decide the right way forward. Essentially I see two options: 1) status quo: tcltk always attempts to load Tk and fails on an error 2) allow some (possibly cross-platform) way of specifying that it is ok to not load Tk - essentially make failure to load Tk non-fatal. Right now there is no (semantically correct) way to inhibit the loading of Tk (DISPLAY is a sort of abuse and not a solution). Cheers, Simon (CC to R-devel where this started...) On May 5, 2008, at 9:12 AM, Simon Urbanek wrote:> Philippe, > > I'm not quite sure why you are asking on a Mac list, but the error > comes from Tcl/Tk. I'd suggest asking on R-devel, the Tcl/Tk used in > the R binary is the same for R 2.6.x and 2.7.0 so it must be a > change in tcltk. > > Cheers, > Simon > > > On May 4, 2008, at 7:01 AM, Philippe Grosjean wrote: > >> Hello, >> >> Up to R 2.6.2, I used to start Tcl *without Tk* (I need only Tcl >> for some part of my work, like a socket server written in Tcl only, >> for instance) with this code under Mac OS X (particularly on this >> system, because I don't want to start X11 just to use Tcl code, >> which is required for Tk!): >> >> > Sys.unsetenv("DISPLAY") >> > library(tcltk) >> >> I got then the message "no DISPLAY variable so Tk is not >> available", but could work with Tcl without problems. >> >> Now, with R 2.7.0, I got the following and Tcl failed to load: >> Loading Tcl/Tk interface ... Error in fun(...) : no display name >> and no $DISPLAY environment variable >> Error : .onLoad failed in 'loadNamespace' for 'tcltk' >> Error: package/namespace load failed for 'tcltk' >> >> I try to locate the message "no display name and no $DISPLAY >> environment variable" in the code but I cannot find it. Could >> someone help me please? >> >> I understand that starting Tcl without Tk from R is not an intended >> behaviour, but would it be possible to include an option to do so? >> >> > sessionInfo() >> R version 2.7.0 Patched (2008-04-22 r45460) >> i386-apple-darwin8.10.1 >> >> locale: >> en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 >> >> attached base packages: >> [1] stats graphics grDevices utils datasets methods base >> >> Many thanks, >> >> Philippe Grosjean >> -- >> ..............................................<?}))><........ >> ) ) ) ) ) >> ( ( ( ( ( Prof. Philippe Grosjean >> ) ) ) ) ) >> ( ( ( ( ( Numerical Ecology of Aquatic Systems >> ) ) ) ) ) Mons-Hainaut University, Belgium >> ( ( ( ( ( >> .............................................................. >> >> _______________________________________________ >> R-SIG-Mac mailing list >> R-SIG-Mac at stat.math.ethz.ch >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> >> > > _______________________________________________ > R-SIG-Mac mailing list > R-SIG-Mac at stat.math.ethz.ch > https://stat.ethz.ch/mailman/listinfo/r-sig-mac > >
On Mon, May 05, 2008 at 02:22:03PM -0400, Simon Urbanek wrote:> It turns out that the behavior of starting just Tcl was actually a bug. > Apparently the intention was to attempt to start Tk regardless of the > DISPLAY variable, because some TclTk implementation such as Aqua Tcl/Tk > don't require DISPLAY and thus would not be loaded. Due to a bug > (HAVE_AQUA was not included in Rconfig.h before R 2.7.0), though, this > was not the case. I'll leave it to tcltk users/maintainers to decide the > right way forward. Essentially I see two options: > > 1) status quo: tcltk always attempts to load Tk and fails on an error > 2) allow some (possibly cross-platform) way of specifying that it is ok > to not load Tk - essentially make failure to load Tk non-fatal. > > Right now there is no (semantically correct) way to inhibit the loading > of Tk (DISPLAY is a sort of abuse and not a solution).FWIW this requirement was also biting Debian's automated builders in the tail. A hack remedy was to just remove tcltk from lazy-load. A slightly better fix is to run 'R CMD INSTALL ...' with a prefix of 'xvfb-run' which uses the virtual framebuffer x11 driver to make tcl/tk (or any other user of x11; I think gtk2 may fall in the same camp) happy whether or not the box is actually headless. Dirk -- Three out of two people have difficulties with fractions.
Simon Urbanek wrote:> It turns out that the behavior of starting just Tcl was actually a bug.Not completely. At least, loading of tcltk was correct when the "bug" was there, but I totally agree that the mechanism used (according to the presence or not of the DISPLAY variable is not the best one). It is not true that there was no intention to allow loading tcltk without Tk. Otherwise, why would you have this (tcltk.c, tcltk_init(), line 643 in the R 2.7.0 source): warning(_("no DISPLAY variable so Tk is not available")); This message strongly suggests that starting tcltk without Tk is allowed, and it also suggests the mechanism: by eliminating the DISPLAY environment variable before starting tcltk. It is certainly undocumented, most probably underused, and certainly requires a better way to specify that the user does want to load Tk,... but at least, it worked for me up to now.> Apparently the intention was to attempt to start Tk regardless of the > DISPLAY variable, because some TclTk implementation such as Aqua Tcl/Tk > don't require DISPLAY and thus would not be loaded. Due to a bug > (HAVE_AQUA was not included in Rconfig.h before R 2.7.0), though, this > was not the case. I'll leave it to tcltk users/maintainers to decide the > right way forward. Essentially I see two options: > > 1) status quo: tcltk always attempts to load Tk and fails on an error > 2) allow some (possibly cross-platform) way of specifying that it is ok > to not load Tk - essentially make failure to load Tk non-fatal.I vote for the second option. Many thanks, Philippe> Right now there is no (semantically correct) way to inhibit the loading > of Tk (DISPLAY is a sort of abuse and not a solution). > > Cheers, > Simon > > (CC to R-devel where this started...) > > On May 5, 2008, at 9:12 AM, Simon Urbanek wrote: > >> Philippe, >> >> I'm not quite sure why you are asking on a Mac list, but the error >> comes from Tcl/Tk. I'd suggest asking on R-devel, the Tcl/Tk used in >> the R binary is the same for R 2.6.x and 2.7.0 so it must be a change >> in tcltk. >> >> Cheers, >> Simon >> >> >> On May 4, 2008, at 7:01 AM, Philippe Grosjean wrote: >> >>> Hello, >>> >>> Up to R 2.6.2, I used to start Tcl *without Tk* (I need only Tcl for >>> some part of my work, like a socket server written in Tcl only, for >>> instance) with this code under Mac OS X (particularly on this system, >>> because I don't want to start X11 just to use Tcl code, which is >>> required for Tk!): >>> >>> > Sys.unsetenv("DISPLAY") >>> > library(tcltk) >>> >>> I got then the message "no DISPLAY variable so Tk is not available", >>> but could work with Tcl without problems. >>> >>> Now, with R 2.7.0, I got the following and Tcl failed to load: >>> Loading Tcl/Tk interface ... Error in fun(...) : no display name and >>> no $DISPLAY environment variable >>> Error : .onLoad failed in 'loadNamespace' for 'tcltk' >>> Error: package/namespace load failed for 'tcltk' >>> >>> I try to locate the message "no display name and no $DISPLAY >>> environment variable" in the code but I cannot find it. Could someone >>> help me please? >>> >>> I understand that starting Tcl without Tk from R is not an intended >>> behaviour, but would it be possible to include an option to do so? >>> >>> > sessionInfo() >>> R version 2.7.0 Patched (2008-04-22 r45460) >>> i386-apple-darwin8.10.1 >>> >>> locale: >>> en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8 >>> >>> attached base packages: >>> [1] stats graphics grDevices utils datasets methods base >>> >>> Many thanks, >>> >>> Philippe Grosjean >>> -- >>> ..............................................<?}))><........ >>> ) ) ) ) ) >>> ( ( ( ( ( Prof. Philippe Grosjean >>> ) ) ) ) ) >>> ( ( ( ( ( Numerical Ecology of Aquatic Systems >>> ) ) ) ) ) Mons-Hainaut University, Belgium >>> ( ( ( ( ( >>> .............................................................. >>> >>> _______________________________________________ >>> R-SIG-Mac mailing list >>> R-SIG-Mac at stat.math.ethz.ch >>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >>> >>> >> >> _______________________________________________ >> R-SIG-Mac mailing list >> R-SIG-Mac at stat.math.ethz.ch >> https://stat.ethz.ch/mailman/listinfo/r-sig-mac >> >> > >