Peter,
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).
Best,
Philippe
.......................................................<?}))><....
) ) ) ) )
( ( ( ( ( Prof. Philippe Grosjean
\ ___ )
\/ECO\ ( Numerical Ecology of Aquatic Systems
/\___/ ) Mons-Hainaut University, Pentagone
/ ___ /( 8, Av. du Champ de Mars, 7000 Mons, Belgium
/NUM\/ )
\___/\ ( phone: + 32.65.37.34.97, fax: + 32.65.37.33.12
\ ) email: [EMAIL PROTECTED]
) ) ) ) ) SciViews project coordinator (http://www.sciviews.org)
( ( ( ( (
...................................................................
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Peter Dalgaard
Sent: Monday, 26 July, 2004 07:26
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [Rd] tkStartGUI fails under RW1091 (PR#7101)
[EMAIL PROTECTED] 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
~~~~~~~~~~ - ([EMAIL PROTECTED]) FAX: (+45) 35327907
______________________________________________
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
______________________________________________
[EMAIL PROTECTED] mailing list
https://www.stat.math.ethz.ch/mailman/listinfo/r-devel
