USENIX - Summaries


Fifth Tcl/Tk Workshop

Boston, Massachusetts
July 14-17, 1997

Summaries by Brian Bailey



Tcl in AltaVista Forum

David Griffin, AltaVista Internet Software Inc.


Dave Griffin presented the first paper of the Fifth Annual Tcl/Tk Workshop on Alta Vista Forum, an award-winning collaboration environment built using the Tcl language. During the initial development of the forum, two main goals were pursued. First, the products built must work within the framework of the World Wide Web. Second, the products built must match the rapid pace of evolution expected in this space. The Tcl language was chosen for the implementation of the forum for the following reasons:

  • Extensibility. Several new commands as well as a "mailbox" object were added to the core Tcl language. The extended language provides a custom scripting language for developing Web-based collaborative applications.
  • Maturity. Tcl has few bugs and is well documented.
  • Portability. Tcl runs under Macintosh, several UNIX variants, and Windows.
  • Rapid development. Ideas could be quickly implemented and tested.

Because Alta Vista Forum is a Web-based application, it needs to interact with hypertext servers as CGI applications and generate results using the HTML language. The forum is controlled by three executables:

  • Dispatcher. A CGI application, essentially an extended Tcl interpreter, that analyzes the request, loads the application, and executes the appropriate Tcl scripts, which ultimately generate the HTML response
  • Butler. Similar to tclsh, but with most of the extensions of the dispatcher.
  • Background. Executes butlers with small Tcl scripts

One of the initial problems with Alta Vista Forum was performance. To overcome the performance problems, two methods were used. First, a new facility called Tcl Package Libraries (TPL) was created. All of the Tcl code was placed in a single, cross-platform archive that can be read in by the various executables as needed. Second, persistent servers were used. Through instrumentation of the CGI process, a great deal of time was being spent creating and initializing the dispatcher process. To reduce this overhead, the idea was to have a dispatcher process resident in memory waiting for a transaction. Once received, the transaction would be analyzed and processed and a result generated. Finally, the dispatcher process would be reinitialized and wait for the next transaction. Because the dispatcher is essentially a Tcl process, a triad of interpreters was used to meet these requirements. The three interpreters used were:

  • Master. Maintains the initialization state of the dispatcher
  • Transaction. A transient slave interpreter created by the master for each new transaction
  • Pristine. Slave interpreter created by the master for each application class

For small transactions, this architecture resulted in a 5x performance increase.

Overall, the developers of Alta Vista Forum were happy with the Tcl language, but they would like to see the following in future releases:

  • Syntax checker
  • Debugging tools
  • Profiling tools

"Dashboard": A Knowledge-Based
Real-Time Control Panel

De Clarke, UCO/Lick Observatory


De Clarke presented the second application-oriented paper on "Dashboard," a user interface for the DEIMOS instrument located at the UCO/Lick Observatory. First, some essential background information was given on how astronomers handle data. Astronomers use a data storage convention known as FITS, essentially a set of keyword/value pairs, for the archival and interchange of image and tabular data.

During the early planning stages for the DEIMOS instrument, the software team realized they would need to manage a large number of new keyword/value pairs. Thus, a relational database was constructed for modeling FITS keywords and storing keyword attributes such as data type, format, read/write access, and semantics. When completed, the keyword database became a powerful resource from which they could generate documentation, sample FITS headers, and certain repetitive sections of Tcl/Tk source code.

Another requirement was a good graphical interface for bench tests, development, and preship qualifications. The goal of the user interface was not a specific, hand-crafted product tailored for DEIMOS, but a generic, "soft" application capable of reading the keyword database and configuring itself accordingly. To do this, each keyword could have an associated set of Tcl/Tk source code. In other words, the database was not merely used as the target of the application, but as an integral part of the software design, configuration, and deployment.

Each keyword in the database can be linked to a global Tcl variable. If the keyword is being monitored, the KTL control software sends out a broadcast message each time the value portion of the keyword/value pair changes. The associated Tcl variable is then updated with the new value. That variable can then be used as the "-textvariable" option available with most Tk widgets (thus, as the database is updated, the widgets reconfigure themselves) or can be associated with an arbitrary Tcl script (presumably through the Tcl trace facility).

The "dashboard" is a single application, with one maintenance cycle and one investment in development, which can be used to provide engineering diagnostic interfaces for any number of instruments sharing the KTL control protocol. Nothing restricts the use of the "Dashboard" application to astronomy. Any keyword/value pair control system could use the "Dashboard" code with little modification.

Caubweb: Detaching the Web with Tcl

John R. LoVerso and Murray S. Mazer, Open Group Research Institute


John R. LoVerso presented the third and final paper of the first Applications session. This paper deals with the problem of providing Internet resources to the user even when the user is not currently connected to the World Wide Web (e.g., on an airplane). The problem is complicated by the need to provide the user with both read and update access to disconnected information. Caubweb is the system developed to address these issues.

One of the main goals of the Caubweb system was to be browser independent (i.e., not to be tied to any off-the-shelf browser such as Netscape or Internet Explorer). As a result, Caubweb was designed as middleware, sitting between the local browser client and the hypertext server. Users simply start the Caubweb system, configure their client browser to proxy through Caubweb, and browse the Web as usual. Caubweb acts as a transparent "middleman" in the browsing activity by caching all information that passes through it. However, the user may also explicitly declare other information to be cached by defining "weblets," connected subsets of Web content meeting user-defined criteria. Weblets are specified through qualification predicates that Caubweb applies to documents. The application of the qualification criteria to the documents occurs asynchronously so as not to interrupt the user's normal browsing.

Once disconnected, Caubweb impersonates those servers on which the cached information actually resides, thus seemingly providing Web access even though the user is currently disconnected. Once reconnected, published pages are written to their proper location, and any missed information is retrieved and cached for the next disconnection period.

The entire Caubweb system was built using the Tcl language. Tcl was chosen for the following reasons:

  • Ease of programming. The learning curve for developers to produce good, usable code is short.
  • Portability. Tcl code runs under several UNIX variants, Windows, and Macintosh.
  • Extensibility. Shared libraries can extend the language.

However, Tcl did have its shortcomings:

  • Event-driven architecture. Caubweb used an internal architecture of asynchronous execution with callbacks. Any operation that has a long computation time appears to "block" the application. In other words, the application is nonresponsive until the callback finishes and control is returned to the main event loop.
  • Performance. The interpreted environment of Tcl proved too slow in some situations.
  • Extensions. Many were not portable to other platforms and did not support some basic language operations.
  • No standard library. Tcl is missing a rich, cohesive, organized, and standard extension library.

The latest version of Caubweb is available from http://www.opengroup.org/RI/www/dist_client/caubweb

Jacl: A Tcl Implementation in Java

Ioi K. Lam and Brian C. Smith, Cornell University


Ioi Lam was the recipient of the Best Student Paper award for the Fifth Annual Tcl/Tk Workshop. Ioi Lam began the Implementation Issues session with his presentation on Jacl. Simply stated, Jacl is a Tcl implementation in Java. Imple-menting the Tcl interpreter using Java provides several benefits:

  • Portable extensions. Currently, Tcl extensions are written in C, which makes them difficult to port to different platforms. If extensions were written in Java, they would automatically be portable to any platform with a Java Virtual Machine running.
  • Robust Java scripting language. According to the authors, Java needs a scripting language as powerful as Tcl. Other scripting languages, such as JavaScript and VBScript, are proprietary, nonportable, and tied to specific browsers.

The current status of the project is that all core Tcl commands have been implemented and tested, and work on the Tk widgets is under way. Although little Tk support is currently available, a short animation showing text scrolling across several buttons was demonstrated. Writing the Jacl interpreter and extensions in Java creates an embeddable, universal scripting language for Java.

A Typing System for an Optimizing Multiple-Backend Tcl Compiler

Forest Rouse and Wayne Christopher, IECM CFD Engineering


Forest Rouse presented the typing system used within the ICE 2.0 Tcl compiler. One of the advantages of using Tcl is the lack of type declarations (everything is a string), but for a Tcl compiler, lack of typing makes optimization very difficult. The ICE compiler was first designed to emit only C code, but now it has been extended to emit either Tcl 8.0 bytecodes or C code. The approach taken is that the compiler first translates the Tcl code into an intermediate language representation and from this representation generates either Tcl 8.0 bytecodes or C code.

The typing system can be thought of as a set of attributes whose values at any point in the program represent the current Tcl type that is associated with every recognized Tcl variable. Unfortunately, this is a difficult task due to the inherent side effects allowed by the Tcl language. Thus, the typing system must not only maintain the type of the variable, but also its locality (global, local, upvar, uplevel, or argument), whether the variable has been unset, current traces, and more. Essentially, the typing system assumes the worst case scenario and recomputes these attributes upon every state change of the system. However, users can constrain the effect of statements through the user of "promises." Promises are made regarding the possible side effects of certain Tcl commands.

Performance measurements on the final version of the ICE 1.0 compiler have shown a factor of 7.5x speedup, whereas the Tcl 8.0 bytecode compiler from Sun has shown a factor of 4 speedup on the same benchmark. To get even better performance increases, other optimization techniques are necessary and will require an advanced typing system.

TCLOSAScript ­ Exec for MACTcl

Jim Ingham, Lucent Technologies and Raymond Johnson, Sun Microsystems


Jim Ingham presented the final paper of the Implementation Issues session on an exec mechanism for the Macintosh. On UNIX systems, parent processes can communicate with spawned processes by redirecting the child's stdin and stdout channels to channels of the parent. The "exec" Tcl command leverages this capability to invoke system commands, e.g., the UNIX date command. Unfortu-
nately, Macintosh computers do not have an equivalent concept of a command line or stdin and stdout. Thus, an alternative method for implementing the exec command must be realized. That was the focus of this presentation.

Macintosh provides the Open Scripting Architecture (OSA) for interprocess communication. Essentially, every OSA-compliant application adheres to a standard set of "events" (e.g., get, set, and create) as well as a set of application-specific events (e.g., select in a word processor). These events are very low level, and incorporating them into a higher level language such as OSA is beneficial. The good news is that OSA can be used to implement the Tcl "exec" command.

Three main steps are required to fit Tcl into the OSA architecture:

  • Allow Tcl to use the services offered by other OSA-compliant components installed on the system. This is the function of the TclOSAScript extension that has been completed. In fact, TclOSAScript will be included in the 8.0 release of MacTcl.
  • Provide a Tcl command to build and dispatch Apple Events. This step has not yet been completed.
  • Install Tcl/Tk as an OSA-compliant component in its own right so that Tcl would be available to other components. This step has also not yet been completed.

This work should allow Tcl to take advantage of and offer its own services to other OSA-compliant applications.

Redesigning Tcl-DP

Mike Perham, Brian C. Smith,
Tibor Janosi, and Ioi K. Lam,
Cornell University


Brian C. Smith started off the Retrospective session with his work on redesigning Tcl-DP. The original Tcl-DP implementation was released four years ago, but upgrading it to newer Tcl releases was increasingly difficult, plus several of its features had already been incorporated back into the Tcl core. Thus, a new Tcl-DP version (4.0) has been rewritten from scratch. Tcl-DP 4.0 includes communication support for serial links, IP-multicast, TCP, UDP, email, RPC, and also allows for filters.

Generally speaking, filters transparently modify data received on a channel before the application sees it. Two types of filters are available:

  • Plugin filters are designed for the common case where the data are modified using a functional interface. An example of a plugin filter is the encryption/
    decryption of data.
  • Filter channels allow the creation of modified network stacks (e.g., datagrams over a streamed channel) simulate UDP over a TCP connection.

The new RPC mechanism includes the following enhancements:

  • Recursive and out-of-order calls. DP creates activation records for each RPC sent. The activation records provide a convenient mechanism for tracking which RPCs have been received and which are still outstanding and processing them in the correct order.
  • Multiple channel support. RPCs can be made over any Tcl channel as long as it has been registered with the dp_admin command.

In previous versions of DP, "peeking" was allowed on socket reads. Peeking enables returning a portion of the data waiting to be received on a socket, without actually consuming any of the data. During the development of DP 4.0, Tcl's buffering of all channel input made peeking on channels impossible. Dp 4.0 provides a workaround through the dp_recv command. This command allows direct, unbuffered access to a channel's input procedure.

Tcl-Dp 4.0 is freely available and can be obtained from http://simon.cs.cornell.edu/Info/Projects/zeno/Projects/Tcl-DP.html.

Writing a Tcl Extension
in Only Seven Years

Don Libes, NIST


Don Libes was the recipient of the Best Paper award for the Fifth Annual Tcl/Tk Workshop. The award paper was a retrospective on Expect, one of the first extensions ever built for the Tcl language. Expect is an excellent candidate for a retrospective because of its long history and popularity. (Expect is used by hundreds of thousands of companies and institutions around the world.) Don described his experiences (both good and bad) resulting from maintaining this extension throughout several years of Tcl evolution.

Expect is a tool for automating interactive applications such as Telnet, FTP, passwd, rlogin, etc. Much of the flexibility of Expect is due to the Tcl language. Tcl provides the basic infrastructure for variables, procedures, and expressions, thus allowing Expect to focus specifically on its function: automating interactive processes. However, even though Tcl at first appeared to fit well with Expect, it did have its drawbacks:

  • Lack of null string support. Tcl strings have never supported the null character, but some interactive programs (e.g., curses) actually do send and receive nulls. Thus, Expect had to provide this support itself. Fortunately, Tcl 8.0 will support nulls; unfortunately, seven years have passed since the initial request.
  • Pattern strings. One of the difficulties with Tcl is learning the quoting conventions. However, compared to other scripting languages, Tcl quoting is easy to learn and a pleasure to use. Another interesting aspect of Tcl is the expr command. The current expr command is now much more like a traditional programming language, but unlike anything else in Tcl.
  • Name collisions. The first release of Tcl had no file I/O and therefore no open or close commands. Because these command names were not already taken, Expect used them. Once Tcl added file I/O and used these names for its own purposes, name collisions resulted. Unfortunately, Tcl provides no clean solution, and extension writers must deal with this problem themselves.
  • Event notification. Not until Tcl 7.5 did the Tcl core provide event management. Thus, whenever Tk was not present in Tcl versions prior to Tcl 7.5, Expect had to provide its own event handling. Once Tcl did provide its own event handling, Expect had to make a few (to put it mildly) changes.
  • Portability. Tcl is portable; thus, Tcl extensions must also strive for portability, but this is not always a trivial task. Most people think POSIX has solved all of the portability problems, but it hasn't. Don pointed out that POSIX doesn't do any good on pre-POSIX systems and that POSIX does not standardize everything. Ptys, or pseudoterminals, are a good example of something POSIX does not cover, but was needed in Expect.
  • Configuration. Tcl provides its own configuration mechanism, but leaves the extension writers essentially on their own.
  • Documentation. Extension writers are encouraged to document their work through man pages, online documents, classes, papers, and books.

At the end of his presentation, Don was asked whether or not he would use Tcl if he had to write Expect all over again. Don replied that he would have to think about it.

Simple Multilingual Support for Tcl

Henry Spencer, SP Systems


Henry Spencer began the second day of the workshop with his presentation on how to retrofit multilingual support into existing Tcl applications. Even though an application may be portable across different computers, this doesn't mean that it is also portable across national, linguistic, or cultural boundaries. One of the obvious problems is the language hard-coded inside the application, including the user interface, error messages, and command prompts.

Most applications needing multilingual support use the concept of a message catalog. Inside the application, hard-coded words are replaced with message identifiers that are used as an index into the message catalog. Multilingual support is then achieved by creating different message catalogs, one for each language.

The system designed by the author, called Transit, works in a similar, but unique, way. Transit provides a wrapper around the familiar puts command as the primary programming interface. This new wrapper translates anything sent to stdin, stdout, or stderr and leaves everything else alone. The identifier, or key, used to index the message catalog is the original text used in the program. Benefits of this method include the following:

  • It eliminates the need to define a new key space. No set of identifiers needs to be created.
  • It provides a message of last resort. If the key lookup fails, the original message, even though it may be in the wrong language, can still be printed. The argument is that a message in the wrong language is still better than no message at all.
  • It makes the program easier to read, write, and test.

Thus, the Transit equivalent of

puts "hello, world"

is

puts "hello, world"

However, the author pointed out that it is not always this easy. Tcl programmers tend to build up strings from multiple parts, and sometimes only a portion of the final string should actually be translated. For example, consider an error message that includes the message text itself and a filename; everything but the filename should be translated. The solution was to mark substrings within the overall string and parse the markings at translation time. Literals, such as filenames, are marked with single quotes, and translated substrings are marked with double angle brackets.

The author pointed out that experience with Transit has been limited, but so far the method developed seems to be working and is easy to retrofit into existing applications.

Assertions for the Tcl language

Jonathan E. Cook, New Mexico State University


In general, assertions help programmers write robust code by offering dynamic checking of program properties and enhancing testability. The Tcl assertion package, called AsserTcl, provides the following Tcl commands:

  • Assert allows point assertions to be specified about the computation state of the program. These assertions can be placed anywhere in the code.
  • Assume allows requirements for procedure input values to be made. Because parameter variable values can be changed anytime in a procedure, new variables of the form param_in, where param stands for the parameter name used, are created. These variables are initialized to the values of the parameters when the procedure is invoked and should be used within the assume assertion. This method allows the assume assertion to be placed anywhere in the procedure body, but convention says that the assertions should be the first command of the procedure body.
  • Assure allows requirements for the return value of a procedure to be specified. Analogous to the assume assertion, a variable, named return_val, will be set to the return value just before the procedure returns. Thus, programmers can use this variable, return_val, inside the assure assertion.
  • Always allows guarantees about part of the variable space of the program to be specified. Always takes a list of variables and an expression to be evaluated anytime one of the variables change value.

During development, assertions are a valuable programming tool, but once the application is finalized, assertions may hinder performance. Thus, AsserTcl also allows for the disabling of assertions at the global, procedural, or variable level.

The commands assert, assume, and always were fairly straightforward to implement, but assure was more difficult, primarily because of the semantics of the Tcl return command. To implement the functionality of assure, the procedure body is first parsed, and all return statements not beginning on their own line are replaced with an additional procedure call. The problem is that return is also a mechanism for generating exceptions, which must be passed to the caller of the procedure. If the original return statements are replaced with an additional procedure call, the behavior of an exception has been changed (it's now passed to the caller, when it should be passed to the caller's caller). However, as long as return is used simply to return a value, assure works without any pitfalls.

Finally, a few suggestions for Tcl were given:

  • Extend the exception-generating mechanism of the return command so that it is possible to throw the exception up to a specified level.
  • Extend the info command to include more context about the current execution point (e.g., the current line number, procedure name, and filename).

Extending Traces with OAT: An Object Attribute Trace Package for Tcl/Tk

Alex Safonov, Joseph A. Konstan, John V. Carlis, and Brian Bailey, University of Minnesota


Alex Safonov presented his work on extending the Tcl trace facility to Tk widgets and other Tcl extensions. The Tcl trace mechanism allows Tcl programmers to have scripts executed when a variable is read, written, or unset. Using traces has proven to be useful for several applications the presenter has written, but unfortunately, traces currently work only on Tcl variables and do not apply to objects resulting from other Tcl extensions. The following are the goals of this work:

  • Extend the current Tcl trace facility to Tk widget attributes.
  • Provide a general mechanism for extension writers to allow their objects and associated attributes to be traced.
  • Separate change detection from constraint management.
  • Make the extended trace facility easy to integrate with existing Tcl/Tk installations.

Alex illustrated the usefulness of both traces and constraints involving Tk widgets with a short demo. The demo showed the programming ease in which one can keep circles and lines connected on a Tk canvas.

Alex stated that two types of users should benefit from this work:

  • Tcl script programmers. By using the extended trace facility, script programmers' resulting code will be more compact and easier to maintain.
  • Tcl extension writers. By adding their objects to the extended trace facility, extension writers can allow script programmers to set traces on their own objects in a consistent and well-defined manner.

As a result of having two sets of potential users, the OAT protocol consists of two parts:

  • Tcl API, used by Tcl script programmers for creation, deletion, and querying of extended traces
  • C API, used by extension writers to extend the trace facility to their own objects

Because traces are essentially a low-level change detection method, they lack higher-level expression mechanisms. Thus, TclProp has been extended to take advantage of the new OAT interface. Together, constraint formulas can easily include Tcl variables, Tk widgets, CMT clocks, and any other Tcl extension that has been OAT-enabled.

A Tk OpenGL Widget

Unfortunately, the presenter of this paper was unable to attend the conference. No summary is available as a result.

The ImageTcl Multimedia Algorithm Development System

Charles B. Owen, The Dartmouth Experimental Visualization Laboratory


Charles Owen began the Multimedia and Graphics session with his presentation on ImageTcl, a multimedia algorithm development system. Multimedia algorithm development can be described as a five-step process:

  • Devise a theoretical algorithm.
  • Implement a prototype.
  • Devise test procedures for the prototype.
  • Test algorithm performance and effectiveness on large data sets.
  • Develop user interfaces to support interaction.

The primary goal of the ImageTcl system is to simplify steps 2 through 5. Other multimedia development environments have also focused on providing high-level scripting tools to eliminate the modifycompilelinktest cycle. However, these systems assume that a complete set of tools can be provided without compromising performance, whereas the approach taken in the ImageTcl system is that this is difficult, if not impossible.

The design of ImageTcl can be divided into an execution structure and a development structure. The execution-processing structure is a data flow graph consisting of objects and associated modules. Objects can be thought of as generic processing steps that must be performed, and modules can be thought of as the specific algorithm employed to perform that processing step. The power of ImageTcl is leveraged when several modules (algorithms) exist to perform the same generic processing step. These modules can easily be substituted for one another, tested, and compared. To further facilitate testing of the algorithms, ImageTcl also provides a media database useful for accumulating standard test data for a particular development site. Construction of the graph and all control is implemented in Tcl.

ImageTcl components can be divided into three sets:

  • Core ­ components necessary for system operation
  • Standard ­ components included in the published system.
  • User ­ one of the more important features of ImageTcl. Users create new commands, objects, or modules through a set of fill-in forms built using Tk. Once described to the system, template header and source files are automatically generated, and the user must fill them in. Once filled in and compiled, the component can immediately be used in the system.

ImageTcl has been or is currently being used in the following projects:

  • Functional Magnetic Resonance Imaging data analysis
  • Text-to-speech alignment.
  • Cut and pause detection

Nsync ­ A Constraint-based
Toolkit for Multimedia

Brian Bailey and Joseph A. Konstan, University of Minnesota


Brian Bailey presented on a multimedia synchronization toolkit written entirely in Tcl. In general, multimedia applications can be partitioned along three axes:

  • Media. The audio, video, animation, or text used within the application
  • Synchronization. The "glue" one uses to assemble the different media components
  • Interaction. The control the user exercises over both media and interaction

The Nsync toolkit focuses on providing synchronization and interaction while reusing an existing toolkit, the Con-
tinuous Media Toolkit from Berkeley, to provide media content. The designers set the following goals for the Nsync toolkit:

  • Application neutral. Nsync is not limited to a specific application domain (e.g., hypermedia or slide presentations). The idea is to provide a basic mechanism so that these types of applications can easily be built using the toolkit.
  • User interaction incorporation. The toolkit directly allows user interaction to be specified.
  • Programming effort minimization. Toolkits should reduce the complexity of tasks that are normally difficult, like defining coordination of events through time.
  • Useful for nonmultimedia applications. Because the toolkit controls media streams through the logical time system of CMT, any application using that same notion of time can also benefit from the Nsync constraint mechanism.

Within the toolkit, media are assembled by first defining a temporal expression and then associating an action along with it. Whenever the temporal expression becomes true, the associated action is invoked. At first this seems very simple, but because one or more logical clocks (i.e., variables representing the current logical time) can be included in the expression, standard expression evaluators are useless. Nsync provides its own temporal logic evaluator, which can evaluate both temporal and nontemporal expressions and, for temporal expressions only, predicts when and if any logic transitions will occur. By making the correct predictions and invoking the associated actions at the appropriate times, the toolkit keeps applications "in-sync."

In order to better understand how one uses the toolkit, Brian presented an example that dealt with a timed slide sequence of a virtual house tour. The essence of the example was that the user should be able to exercise some control over the transitioning of the slides, rather than only letting the system perform the transitions at the predefined times. Through the use of a button, the user could "hold" any slide in place and not allow a slide transition to occur. Brian showed how two simple temporal expressions, along with their associated actions, could implement all the necessary requirements.

At the end of the presentation, Brian gave a Tcl wish list:

  • Multithreaded core. Because media playback is implemented as a set of callbacks for the main event loop, anytime the event loop goes off to handle other events (e.g., button presses), media playback must be discontinued. These interruptions may be very noticeable, depending on the length of time the event loop is off handling other callbacks.
  • Realtime after queue. Although the predictions made by the temporal logic evaluator are fairly accurate, the Tcl after command makes no guarantees about the requested versus actual invocation times.
  • Variable type identification. Sometimes it's necessary to know the "type" of object that a variable contains. (e.g., whether the variable represents a logical time line or just an integral value).

Nsync can be obtained from http://www.cs.umn.edu/Research/GIMME/Nsync.html

Managing Tcl's
Namespaces Collaboratively

Don Libes, NIST


Don Libes, who also won the Best Presenter of the Fourth Annual Tcl/Tk Workshop, started off the Development session by presenting a method for collaboratively managing Tcl's namespace. In all programming languages, identifiers are used to identify things (e.g., procedures, variables, or tags.) Choosing an identifier is easy; choosing an identifier that no one else has already chosen is much more difficult. With its single, global namespace, Tcl is very susceptible to namespace collisions (developers choosing the same command or variable name). Extension writers have little or no knowledge about identifier choices made by other extension writers. In the past, the solution to this problem was for extension writers to simply prefix all commands and global variables with a string derived from the extension being written. This reduces the possibility of a namespace collision, but does not completely solve the problem. The solution presented here is to use NICS (NIST Identifier Collaboration Service), a Web-based collaborative registry service designed specifically for identifiers. NICS provides the following features:

  • Identifier registration. Users (extension writers) may register identifiers well before the extension is actually shipped. During registration, users would include a brief description of the identifier, current status, and more.
  • Identifier comments. Users may privately or publicly comment on other identifiers.
  • Instantaneous availability. Because the information is maintained in an online database, access is immediate.
  • Conflict notification. If requested, conflicts and comments can be sent to the registered owner of the identifier.

Although the Tcl community has pre-announced support for multiple namespaces, which would also directly address the namespace collision problem, these namespaces must also be named. Thus, the problem has once again been reduced, but not eliminated, because extension writers might choose the same name for different namespaces. Further-more, NICS would also be useful to the Tcl community to help manage the following:

  • Package names
  • Tcl completion codes
  • Math function names
  • Library names

Don also briefly described the user interface to NICS. The interface is based on HTML forms, is very straightforward, and is accessible from any Web browser. Of course, the CGI scripting and database service was developed using Tcl.

The NICS system has been prototyped and is available to a few select communities, including the Tcl community. This represents an opportunity for the Tcl community both to manage its identifiers and to impact the development of NICS through feedback.

PtTcl: Using Tcl with Pthreads

D. Richard Hipp, Hwaci Corporation


D. Richard Hipp presented on a multithreaded version of Tcl. Tcl was originally designed to be used in single-threaded applications, but as multithreaded applications become increasingly popular, so too is the need to use Tcl within them. Unfortunately, enabling multiple threads to be active within the Tcl core is extremely complex due to the large number of static data structures and the need for multiple stack support (recall that typical thread models allocate separate stack space for each running thread). PtTcl is an attempt to provide thread support without completely redesigning the Tcl core. The idea behind PtTcl is to allow zero or more interpreters to run in independent threads. The execution model can be summarized as follows:

  • A single thread can have any number of Tcl interpreters.
  • Any one interpreter can have only one thread active within it.
  • Each thread has its own event queue.
  • Threads can communicate back and forth through messages, a new kind of Tcl event.
  • Tcl variables can be shared among the different interpreters.

The PtTcl package implements two new Tcl commands, shared and thread. The shared command is used to designate variables that are to be shared among several interpreters. One of the drawbacks of shared variables is that traces cannot be placed on them. This is a consequence of the fact that an interpreter can be used in only a single thread. For example, if thread A sets a trace on a shared variable and then thread B writes the shared variable, there is no mechanism for thread B to invoke the trace script in thread A. The thread command is used to create and control threads. The thread command can take nine different subcommands, which can be used to create new threads, send and receive messages, or query a thread's state. Each of these commands has both a Tcl and a C interface.

PtTcl was developed under Linux using the MIT Pthreads library. It is currently being used within a multiprocessor industrial controller and has survived extensive abuse testing.

The latest source code for PtTcl can be obtained from http://users.vnet.net/drh/pttcl.tar.gz

A Tcl-based Self-configuring
Embedded System Debugger

Dale Parson, Paul Beatty, and Bryan Schlieder, Bell Labs Innovations for Lucent Technologies


Dale Parson presented on TEEM (Tcl Environment for Extensible Modeling). Dale belongs to a group at Bell Labs responsible for building software generation tools, such as compilers, assemblers, emulators, and debuggers, for a variety of embedded digital signal processors. Some processors vary at the core architectural level; others differ only with respect to I/O circuitry or memory configuration. Tcl provides the mechanism for separating processor-specific details from the debugging environment of the simulation and emulation tools.

TEEM is a Tclsh binary extended with processor modelling commands that fall into the following categories:

  • Model management. The pssr command queries model types, constructs processor instances, and deletes model instances. This command gives access to a dynamically linked library of C++ constructors. Each constructed object returns a unique instance name to Tcl which then becomes a new Tcl command name until the object is destroyed.
  • Model access. These commands initialize, inspect, and modify model instance state (registers, memory, buses, and pins). Model access is provided through the fxpr command. Fxpr syntax is a superset of Tcl's expr command. The ? command includes options for determining the names, types, and properties of user-accessible elements within a model.
  • Model control. Execution and breakpoint commands drive the simulation at the C++ level until a breakpoint or exception occurs. The reset command resets the current processor's state, and the step and resume commands advance its state.
  • Model I/O. This mechanism allows files or callback procedures to be attached to I/O activity. For example, a processor input action from an I/O port can cause a call to a Tcl procedure that returns a value for that port.

TEEM's Tcl interpreter provides an ideal environment for batch execution, procedural extension, and regression testing. Instead of including GUI code, TEEM provides a generic socket interface to allow client applications to submit Tcl queries. Thus, remote GUIs can retrieve and update model state through this socket interface.

In some situations, the context in which a Tcl_Eval is executing must be maintained. One such situation is when a model initializer encounters a step or resume command. Unfortunately, if Tcl_Eval is allowed to return, the context in which it was executing is lost. Thus, in these situations, Tcl must not be run as a subroutine, but as a coroutine peer of the host simulator. The coroutine method runs the Tcl interpreter in its own thread, while the simulator thread is blocked. Whenever a step or resume command is encountered by the Tcl interpreter, the Tcl thread is blocked and the simulation thread is resumed.

GeNMSim - The Agent Simulator

Udi Margolin, Ilana Gani-Naor, and Raz Rafaeli, Milestone Software & Systems, Ltd.


Udi Margolin presented GeNMSim, a Tcl/Tk-based multiplatform SNMP agent simulator. First, some background information was given on network management systems. A network management system provides the functionality and tools to centrally manage a communication network. Any new equipment added to the network needs a management application that communicates with the management system that is already in place. Thus, a network vendor usually provides the new network equipment, a management application to manage the new network equipment, and a software agent that communicates with the management application. An important part of building a new network device is the design of the management information that will be available for this device. SNMP, the most prevalent management protocol, defines a syntax for this management information called MIB.

In order to develop a management application for a new network device, one needs the device's MIB definition and a working agent. Because a networking device cannot be shipped without a management application, starting the application development only after the agent is already functional causes a substantial delay in the availability of the equipment with its management application.

Using an agent simulator can help reduce this delay by turning the development process of the network device and the management application into concurrent processes. Using an agent simulator can also help catch bugs in the MIB early in the development cycle, when the problems are easier to fix.

Tcl was used for this project for the following reasons:

  • Portability. GeNMSim is designed to be a portable product for UNIX and Windows platforms.
  • Ease of development. Using Tcl saves substantial R&D time. Without the standard compilation cycle of compiled languages, Tcl code changes can be tested and integrated very quickly.
  • End-user customization. End-users can customize the simulator using Tcl callbacks.

The Tycho User Interface System

Christopher Hylands, Edward A. Lee, and John Reekie, University of California, Berkeley


John Reekie gave the final presentation of the Fifth Annual Tcl/Tk Workshop on Tycho, a user interface system for the Ptolemy project at Berkeley. Ptolemy is a large C++ software package used to design, simulate, and generate signal-processing and communication systems. Ptolemy was started in 1990, and version 0.7 is slated for 1997. Just as Ptolemy supports the creation of multiple semantic models, Tycho aims to support the rapid construction of user interfaces to support those semantic models or to visualize application-specific design information. More broadly, the goal of Tycho is to be an extensible framework in which tasks such as documentation generation, indexing, font management, color management, and dialogs with the user are built using a shared, common infrastructure.

One of the features of the Tycho user interface system is it model-view architectural pattern. Tycho has a model class that provides a publish-and-subscribe mechanism, unbounded history, and a simple external file format called TIM (Tycho Information Model). The model class can be subclassed to provide application-specific models such as storing user preferences.

TIM is a meta-data format intended to encourage clean representations of data both in memory and in an external file format. Because the model supports an unbounded history, user interfaces can easily support multilevel undo/redo operations. Each method that changes a model is required to return a script that will undo that change.

Another pattern used in Tycho is the Displayer-View pattern in which one or more views can place themselves in a particular top-level window. This pattern allows the creation of widgets that can be placed into Displayers in new combinations.

Although Tycho was originally intended to serve only as a user interface to the Ptolemy project, it has become much more. Tycho already includes the following:

  • Collection of mega widgets, including file browsers, font and color selection, and alert boxes. Iwidgets (widgets built from [incr Tcl]) were not used because the Tycho project started before Iwidgets were robust enough for heavy use in the Tycho system.
  • HTML browser widget
  • Finite-state machine editor
  • Class hierarchy viewer
  • Interface to the Tcl profiler from the TclX package
  • Hierarchical canvas items
  • Interactors (capture patterns of interaction)

Integration of Tycho with Java is also being explored by this group. The Tycho-Java interface is based on Sun's experimental Tcl-Java interface. The goal of this effort is to use [incr Tcl] / [incr Tk] for the user interface and Java for the back-end processing. The argument for this split is that Tk has a much more mature and flexible user interface package than does Java. Based on experience with the Tycho system, the most important efforts of the Tcl community should be:

  • Provide adequate support for object-oriented extensions to Tcl, such as [incr Tcl]
  • Provide a seamless and efficient interface to Java

Tycho is freely available at http://ptolemy.eecs.berkeley.edu/tycho.


webster@usenix.org
Last changed: Jul 30, 1997 efc
Summaries Index
Tcl/Tk Index
Proceedings Index
USENIX home