Purpose: to discuss this Tk introspection tool. The purpose of this tool is the allow one to inspect the contents of variables, arrays, and procs of a running Tk application that permits one to communicate via send (or potentially comm).
Tkinspect [L1 ] has quite a history in the Tcl/Tk environment. Created by Sam Shen, tkinspect provides the ability to examine and modify the procs and variables of any Tcl/Tk application with a working "send" command.
Later, Sam moved on and a few other people have since made modifications. John Robert LoVerso [L2 ] modified tkinspect so that it used comm instead of send. This allowed one to run tkinspect under any operating system which supports sockets.
Paul Healy then wrote a patch so that tkinspect knows about Tcl 8 namespaces [L3 ].
Tako Schotanus wrote a patch for TkInspect so it worked with incr Tcl [L4 ].
Mike Clarkson overhauled its GUI and included it in TixApps.
Tkinspect is currently in need of an adoptive parent who could integrate the various fixes and modifications into a great tool.
PT writes: I've created a CVS repository with tkinspect-5 and the above patches applied plus a number of other update, enhancements and bug fixes. The application is now being hosted as a module in the SourceForge tkcon project [L5 ] You can checkout the current CVS working files by executing
cvs -d:pserver:[email protected]:/cvsroot/tkcon login cvs -d:pserver:[email protected]:/cvsroot/tkcon co tkinspect
The current file release (March 2002) is 5.1.6p7 which incorporates support for use under windows (using dde or comm instead of send ), support for incr Tcl 3.2 and a number of bug fixes.
Bug reports, patches and feature requests all to be submitted to the tkcon project tracker please [L6 ]
JCW 7-4-2002: Pat, would there be a way to generalize things further? I'm looking for a way to streamline cross-platform work, especially ad-hoc, interactive work. There's a lot of flexibility in using TkInspect and TkCon to run in one's preferred environment, and having it connect to instances of Tcl elsewhere. You've already taken send, comm, and dde further, which seems like a great way forward.
First to add one more option: Matt Newman at one point wrote a "rexec" daemon, which I've been using occasionally - it lets you run a server on any platform, and then use standard "rexec" on Unix to execute commands in it, Tcl commands that is. The code is now in SDX (in sdarchive, [L7 ]) - type "sdx help rexec" to get a brief blurb.
There may also be a telnetd emulation somewhere, which does the same (and run tcl commands, as opposed to shell commands). Not sure, I couldn't find it anymore last time I looked.
But what if one were to decouple transport mechanisms from functional use? A sort of ODBC for network requests. What RPC and Corba do, and SOAP, and email for that matter. The point is not to create yet another layer, and simply add to the clutter, but to do this in terms of "interfaces", i.e. if you initialize with one package you get comm, initialize another and you get rexec, etc.
Not sure TkInspect is the right vehicle, but with such a general mechanism, one could do all sorts of things. I'd build a bridge to drive Windows builds running as VMware task on my Linux box, and totally rethink the Tequila shared array server, to name a few things I'm involved in...
LV It seems to me that an ideal situation would be to have one one interface to which people wrote, then somehow have the package underneath take a crack at determining what protocol to use, with of course a method of providing the package some concrete guidelines if the programmer so desired. This would allow one to just get on with the programming (one of the common attributes of Tcl related packages) but also provide the expert who knows better the means to fine tune, etc.
PT I'm not sure what we are after here. The interface here consists of two parts: first the send app cmd ?arg arg ...? method which is the client side of Tk's RPC; second the registration and inquiry methods winfo interps and tk appname There is also something needed that provides the server end of send.
Could we arrange for client code to do package require send and then just do send ... and not worry about the transport? Difficult I should think. We can happily map the send functionality over various transports. dde, X protocol, and comm (TCP sockets) are available, winsend provides this using Microsoft's COM and I could very easilly do the same using SOAP and that rexecd code. Some of these require user intervention to specify the available servers while others (dde, X protocol and winsend) can provide a list of interpreters. hmmmmmm.... I dunno - I'm thinking aloud really - send is an extremely useful capability. I don't really know how you'd generalise it though. I note that doing send over comm is quite a bit slower than over dde or COM.