RE: [Rd] tkStartGUI fails under RW1091 (PR#7101)

From: Philippe Grosjean <>
Date: Mon 26 Jul 2004 - 19:54:20 EST


I think it should be possible to find a different solution to completelly replace the R console by a Tcl/Tk console. The basic idea is to redirect inputs and outputs of the R console in Rgui (SDI mode), and then hide R console itself, thus without touching to the event loop(s). There are some parts of such an implementation in John Fox's Rcmdr (redirection of output to a Tcl/Tk window), and for the input (it is the way SciViews-R communicates with external programs, but in this case, it is the Tcl/Tk window that is hidden, not the original R console). Indeed, I just reworked some code in the air for a simple code editor in tcltk (you present it in your R-news paper about tcltk, isn't it).

Moreover, under Windows, the program that spawns a console can specify different channels for input, output and error before spawning the console (this works with Rterm only, of course). I use this in the SciViews R plug. Indeed, R is driven by the R plug in --ess mode by redirecting input, output and error to pipes. Under Windows NT/2000/XP, it is possible to specify named pipes. Those are very convenient, because they can be handled as files, including through the net. However, Windows 9X/Me/Millenium can only connect to existing named pipes, but cannot create new ones. So, a solution that works with any Windows platform should not use names pipes. This is a different approach we could use. However, in this case, the solution would be Windows-specific, I imagine. So, it means we would end up with a different mechanisms under Unix/Linux, and under Windows.

Please, note that in both solutions, I have code capable to interrupt calculation in R. I think this is a required feature, but it is not easy to implement with all mechanisms.

I plan to replace totally my Visual Basic code by platform-independent code in SciViews in the future. Using a Tcl/Tk console window may be a solution, so I *may* further develop the concept. However, I am still looking at potentially interesting alternatives, like James Wettenhall's wxPython, or some improved Tcl/Tk solution based on your tcltk package, supplemented with Tile and other supplemental widgets (I find the basic Tk widgets too limited to implement the GUI I want to build with them).



 ) ) ) ) )
( ( ( ( ( Prof. Philippe Grosjean
\ ___ )
 \/ECO\ ( Numerical Ecology of Aquatic Systems  /\___/ ) Mons-Hainaut University, Pentagone / ___ /( 8, Av. du Champ de Mars, 7000 Mons, Belgium  /NUM\/ )
 \___/\ ( phone: +, fax: +

       \ ) email:  ) ) ) ) ) SciViews project coordinator ( ( ( ( ( (


-----Original Message-----
[]On Behalf Of Peter Dalgaard Sent: Monday, 26 July, 2004 07:26
Cc:; Subject: Re: [Rd] tkStartGUI fails under RW1091 (PR#7101) writes:

> > library(tcltk)
> > tkStartGUI()
> Error in .C("RTcl_ActivateConsole", PACKAGE = "tcltk") :
>         C function name not in DLL for package tcltk

Yes. The source code for that function sits inside #ifndef Win32, so it's hardly a bug, except that the documentation might be clearer (or the R wrapper could throw a more explicit error). The whole thing is quite experimental, on Unix too -- really just a proof of concept thing at present.

The fundamental issue is that the way Tk takes over R's event loop involves redefining ptr_R_ReadConsole and friends. This is quite Unix-specific and the relevant declarations are lifted from src/unix/devUI.h.

I don't know what the equivalent would be on Windows (a platform I use reluctantly myself), and I kind of suspect that it can only work from Rterm, not Rgui. Contributions from knowledgeable Windows programmers would be welcome.

   O__  ---- Peter Dalgaard             Blegdamsvej 3
  c/ /'_ --- Dept. of Biostatistics     2200 Cph. N
 (*) \(*) -- University of Copenhagen   Denmark      Ph: (+45) 35327918
~~~~~~~~~~ - (             FAX: (+45) 35327907

______________________________________________ mailing list

______________________________________________ mailing list
Received on Mon Jul 26 19:59:33 2004

This archive was generated by hypermail 2.1.8 : Fri 18 Mar 2005 - 08:59:12 EST