|
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.
|