Our Keynote Speaker is Christian Werner.

He is a self-employed software engineer and consultant living and working in Southern Germany. He developed open source ODBC and JDBC drivers for the popular SQLite engine and an ODBC binding for the Ruby programming language. He frequently uses Tcl/Tk in his paid work (mainly automation and communication) since the mid-nineties and recently started the AndroWish project, a native port of Tcl/Tk on the Android platform.

Tcl has been available on the Android platforms for years, but porting Tk is a major advance for rapid prototyping on that platform.

Come and get details on just what was done and how you can use his work to develop Android apps in hours instead of weeks.

TclOO is a useful building block for designing software. When designing large applications, more than blocks are needed. Developers need scaffolding and architecture. In addition, there are techniques specific to Tcl and TclOO that can be exploited to do things that would be impossible (or at least impractical) in other object oriented languages. It's major focus is breaking large problems into layers. Each layer tailored to a specific task.

This paper will expand on the concepts of TAO, presented at the 20th Tcl Conference. However, the concepts are equally exploitable in any TclOO environment.

This paper will discuss leveraging the new Zlib capabilities of the Tcl core with previous efforts (including TOBE, and zipkits) to provide a means for attaching Zipfiles to normal Tcl shells. This work would be of interest to embedded software developers, as well as makers of system utilities.

Many casual developers can leverage the power of tclkits and the teapot to assemble self-contained executables. But for the makers of niche software, those who need to combine off the shelf software with custom (or even proprietary) tools, and those who need to build all software from source for business or regulatory requirements, building Tcl/Tk and all of it's packages from first principles can be a messy affair. This paper describes ODIE, an environment for performing automated builds of Tcl/Tk and it's assorted packages. Included in this environment is Sherpa, a package management tool that combines a kit building tool, automated documenter, and package retriever.

The paper will discuss the tools used in migrating the TclHttpd project from SourceForge to Fossil. The tools that migrated the code repository were the same as those that migrated Tcl/Tk and friends. The issue tracking (bugs and enhancement requests) migration was done from the "new" SourceForge REST based API to Fossil using a new conversion utility (the Tcl/Tk and friends had been migrated from the "old" SourceForge bug database.

The paper will discuss a TclOO class library for a client OData implementation. An overview of what OData is and why we might be interested in it. Then I will discuss the actual implementation of the class library, including what I thought were non-obvious features of TclOO. I will also discuss alternative implementation paths that were considered and/or tried.

This paper is about a Website framework built around html5/CSS and tclhttpd.

While Tclhttpd has a low cost-of-entry and provides a great set of low-level tools for building websites, it requires every website designer to start from scratch to construct a site.

Conversely something like Ars Digita/Open ACS provides a high-level set of tools for building database backed websites, yet has a very steep learning curve.

Tcl On Tracks provides mid level tools for building websites.

Tcl is known as a language suitable for simple text processing. As such, it's also useful for developing written documents.

This paper will discuss a number of small writer's tools including Keith Vetter's epub generator, Clif Flynt's "plotter" program, simple scripts to improve a document including histogramming word usage and finding words that are repeated within a given distance, and finally tweaking text into html for epub or LaTex for pdf and using Tk to create a cover.

Leiningen is a sophisticated build system for the Clojure programming language, used by both novices and skilled developers. Leiningen creates new skeleton project trees, acquires and manages external dependencies (including Clojure itself), provides build and test services, and deploys projects into the larger Clojure ecosystem. This paper examines Leiningen and describes Quill, an attempt to begin to create a similar tool for Tcl/Tk development.

The Space Applications Centre, ISRO develops sensors for Indian Remote Sensing (IRS) program, Inter-planetary missions and Airborne imaging requirements. The sensors are of various types, complexities and their development has a typical develop-test-use cycle. A centralized system for characterization and evaluation named XSCoPE, provides an end to end solution for Data acquisition, Parametric evaluation, Visualizations and Archival. A set of in-house developed tools called 'Arsenal' meet the parametric evaluation requirement. A pure Tcl shell around the tools called ASH! (Arsenal Shell) glues them with the standard Unix tools to meet the specific requirements. An ASH!Server has been built using Tcl on Linux based systems to facilitate communication with the client applications. Tcl/Tk has been chosen because of its simplicity in building the server applications, package based architecture, gluing, error handling, GUI and output processing. With the help of Tcl's simplified data structures, the server could be designed in such a way that the cluster of similar servers, meet the load balancing requirements to support multiple and simultaneous sensor development. Sensor specific requirements and common requirements are met with the help of 'macros' which provide abstraction. The paper describes how various Tcl features have been used to realize complex scientific software applications, exhaustively used in various programs such as Mars Orbiter Mission (MOM) to meet the overall objectives of sensor development.

Future plans for aggressive optimization of the Tcl language require making assumptions about the behaviour of Tcl scripts with respect to the predictability of their operations. For example, non-local side effects from traces, modifying the core language, and variable aliasing will defeat many optimization schemes. Determining the safety of optimizations requires, in effect, proving theorems about scripts.

This paper describes a deductive database - an in-memory relational database whose values all belong to finite domains with total ordering - intended to support this effort. The database is implemented atop a library for Binary Decision Diagrams (BDD's), a compact data structure representing expressions in first-order logic. This library is used to implement multiway finite-domain decision diagrams, which represent the relations of the database. The database is in turn manipulated in a 'little language' called Datalog, a limited dialect of Prolog that allows for recursive operations impossible in a traditional programming language such as SQL. This language has been used to prototype limited versions of certain critical program analyses, such as dead code elimination, calculation of reaching definitions, and data type inference.

In our tool framework we use Tcl as the command language. Users write rule decks in Tcl to perform complex electrical and design rule checks. Large rule decks can take several hours to days to run; due to the interpreted nature of Tcl, it is difficult for the deck writer to debug simple but fatal errors in the Tcl rule deck, such as invalid variable usage, invalid global variable usage across different interpreter scopes, illegal use of commands and other scoping errors. To mitigate these mistakes we wanted to extend a Tcl static analyzer to identify these errors before they are encountered in the field. In our paper we will describe how we identify these problems by static analysis.

This paper presents a novel method of how enhanced TCL/TK widgets can be used to create self-explanatory widgets for users.

Providing a GUI for a tool which has hundreds of possible and completely unrelated options is a challenging task. The task becomes more complex if more options can be added in future and the aim is that those should be supported in the GUI seamlessly. A dynamic GUI, which can be configured at runtime by the backend server, can serve the purpose nicely. This paper talks about such a GUI which can be scaled, tweaked, modified by the backend tool without any change needed on the GUI side.

Most of the tools can either be invoked in GUI or non-GUI mode but not both at the same time. However, with DFTVisualizer we have been able to make the non-GUI shell and DFTVisualizer co-exit bringing about significant advantages to a customer, especially when the GUI is used for debugging purposes. However, such a change in user interaction methodology brings with it a set of challenges of interaction with the console and managing data through TCL interpreters. This paper will analyze such issues and present an approach to accomplish the co-existence well.

After more than four years of development, the TyCL compiler/interpreter has evolved into a state where it can stand by itself and (even though it's not production ready yet) be used to run tests and evaluate the performance of the code that it generates. This paper presents the current state of TyCL in terms of its functions and features such as the active-macros-system, compile-time-syntax-morphing and compile-time-application-specific system modifications, besides some performance analysis and comparisons with other compilers and the Tcl/Tk interpreter.

FlightAware, unlike most sites its size, typically does dozens of sql queries to make a webpage. It used to be far more. Along with standard techniques for improving the performance of SQL queries and recognizing the effective-but-unseemly use of adhoc caching techniques in frequently called procedures, we leveraged speedtables. ability to construct schema for memory-resident tables (including indexes) by querying PostgreSQL's table schema and also using its ability to rapidly import PostgreSQL results into those tables.

We extended speedtables to support shared memory and have hundreds of httpd processes sharing that memory and performing high performance in-memory speedtable queries for simple requests to frequently accessed tables and views, often avoiding the database entirely. Today FlightAware runs tens of gigabytes of shared memory caches on many webservers with hundreds of processes sharing the caches and directly searching them within their own address space.

This paper delves into the technology, describes some of the problems we encountered, provides some performance comparisons, and describes the current use of Superbird at FlightAware

You have a program that's supposed to run for weeks, months or years at a time yet it's suddenly not doing anything and you'd like to know why. You'd like to update some procedures in a long-running program but it takes minutes to shut it down and start it up again and you don't want it to not be doing whatever it's supposed to normally be doing while it's doing that. You'd like to be able to interactively inspect some variables and change a setting or two on the fly.

For programs that run with event loops, IpConsole provides a TCP listening socket that you can telnet into and interact with the Tcl interpreter. You can telnet in, look at and set variables, source in files that redefine procs, restart connections... really anything you can do from the Tcl command line except that your application is running and processing data or whatever while you're doing it.

IpConsole has a few little security measures, since it can be kind of dangerous to the health of your application to let random people from the Internet type stuff into your Tcl interpreter.

In the paper we will explain IpConsole, show a bit of the code, and give some use examples. At the conference we.ll demo it live in within a production application.

tcllauncher, an open source tool for making binary-looking Tcl apps on UNIX systems while retaining packaging freedom appropriate for a server

Developers writing large server-side Tcl apps are faced with a dilemma: They can run their Tcl programs using the using the #! idiom (or the tclsh command), but all such programs show up as tclsh in standard system monitoring tools such as ps and top.

starkits solve that problem, but their approach of putting the entire application into one executable file, so useful for creating portable, self-contained "no install" applications, feel too constricting on one's own servers.

tcllauncher strikes a happy medium, making Tcl applications appear under their own names under the monitoring tools while retaining flexibility in how the program finds and loads all its pieces. Over almost a decade of use we have developed and extended tcllauncher with new functions that support operation of server-side apps such as being able to require (or become) a certain user and group, to detach from the controlling terminal (daemonize), to use pidfiles to ensure that only one copy of an app is running, and so forth.

This paper describes tcllauncher, what it does, how it works, and shows its use within a simple application.

This talk is about the FX application, a wrapper around the fossil SCM's command line interface. Born out of perceived limitations of said interface, it allows for easy extension and experimentation.

Solidified parts provide generation and delivery of mail notifications for repository changes, and the management of multiple peers (including 1-way mirroring to git repositories).

Still in flux are features for hopefully easier management of the fossil's ticket system, and of its skin.

The attending members of the Tcl Core Team assemble to answer your questions.

The attending members of the Tcl Core Team discuss Tcl 9 with the audience.

This talk will cover the Tcl integration capabilities of Fossil. It will show the steps necessary to enable the "full" Tcl integration subsystem (at both compile-time and runtime) and how to customize key aspects of Fossil using combinations of Tcl, TH1, HTML, CSS, and JavaScript.

The new (and fairly dangerous) ability to evaluate TH1 scripts within embedded documentation files will also be discussed and demonstrated.

Finally, use of TH1 command and web page hooks will be demonstrated.

Conference Committee

Contact Information