Skip to content

Starting tcltk without Tk

8 messages · Philippe GROSJEAN, Simon Urbanek, Dirk Eddelbuettel +1 more

#
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
1 day later
#
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:

            
#
On Mon, 5 May 2008, Simon Urbanek wrote:

            
That's my fault. Only a --with-aqua build of R tries to call Tk_Init if 
there is no DISPLAY set, so what he wants to do is MacOS-specific, AFAICS.

I had already told him (on R-devel) I think his 2.6.2 is a 
non-CRAN-binary.

Brian

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

            
#
On Mon, May 05, 2008 at 02:22:03PM -0400, Simon Urbanek wrote:
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
#
Simon Urbanek wrote:
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.
I vote for the second option.
Many thanks,

Philippe
#
Returned to just R-sig-mac.
On Tue, 6 May 2008, Philippe Grosjean wrote:

            
'Tolerated' would be more accurate.  It is there to cope with packages 
that loaded tcltk during installation, which is often done headless.
The intention is that the package would load, not that it would do usefule 
things.

The 'bug' was that this worked at all on MacOS --with-aqua builds.  That 
line was not intended to be used in that case.  Simon did state that 
clearly in his next para.
Only those who do the work have votes.  There is another possibility, that 
tcltk on MacOS always attempts to load Tk and warns on error.

  
    
#
On May 6, 2008, at 3:06 AM, Philippe Grosjean wrote:

            
Philippe, you missed the one important line - please read the whole  
code - there is

#if !defined(Win32) && !defined(HAVE_AQUA)

before that and that is the crucial part.

Cheers,
Simon