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 ].
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 take send, comm, and dde a bit 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...