Usenix 1996 - Tcl Bof Jan 24
These are the notes I took at the Tcl Bof at the Usenix Technical
Conference 22-29 Jan 1996 in San Diego.
At best they paraphrase my understanding of what was said and
its likely that I got some of it wrong...
John Ousterhout chaired the Bof with both Brent Welch and Stephen
Uhler helping. We had a quite small room and filled it up 30-50
people..
Usenix had two tutorial sessions on Tcl - John did his Tcl Introductionon
Monday, Brent and Stephen did an Advanced Tcl/Tk Tutorial on Tuesday.
New Features ( Tcl 7.5)
PC Implementations of Tcl/Tk - MS-Windows and Mac
The Win 3.1 implementation also requires the Win32s library (DLL)
Currently Tk has Motif Look and Feel on all platforms - this is
obviously unacceptable for the long term and
they will support the Native Look and Feel in the next Release
(Tk4.2).
John encouraged those who are interested in the PC ports to use
them and report any stability and robustness Problems ASAP. He's
been impressed with the current level of stability ( expected a whole
lot more problem reports) and hoped that wasn't a reflection of
the lack of people thrashing on it..
Shared Library Support
- Tcl + Tk built as shared libs (configure built)
- Tcl command to support loading extensions as dynamic libs
Package Command
- Used to support dynamically loading extensions and src libraries
- similar to Perl require cmd/directive
package provide Foo 3.1 ;# describe a package (module + ver )
package require Foo ?3.1? ;# load package
pkg_mkindex ~/tcllib *.so *.tcl ;# make index of DLLs and
src files in given dir
export TCLLIBPATH=~/tcllib # say where to search for DLLs
Tk as a DLL
Tk will be built/provided as a dynamically loadable package. Johns
still debating whether there should be a separate wish interp
or just allow tclsh to act as the Tk interp.
Tk Event Loop
The Tk Event Loop and associated commands will move from Tk into
the Tcl core
New I/O subsystem internal to Tcl
Done mainly for portability - no use of stdio - Provides :
- Nonblocking event driven I/O - this is very fast and has capability
of allowing such things as Web Servers in Tcl that have comparable
I/O performance as those in Native compiled code
- newline conversion - defaults to the right thing for the platform
but can be overridden
- extensible channel driver mechanism
- Allows mapping variable content access to file access
- Has a Tcl C API similar to stdio
Socket Support
- Currently TCP only - others not hard to add.
- Single new command for both server and client
socket -server callbackProc ?port? ;# server
socket hostname ?port? ;# client
socket -server newConnCallBack 4040
proc newConnCallback { fd host } { ... }
socket foo.bar.com 4040
Portable Pathnames
- support for platform specific names
- Network names work everywhere ('/' separated ??)
- glob works everywhere
Safe-tcl
- embedded in core
- new interpreter command to create interpreters - safe or not
Time support
- Taken from tclx
- clock and ??
Extended foreach command
foreach i $list1 { j k l } $list2 { ... }
foreach {name age ssn phone salary } $record { }
Exit Handlers
- C API Level
- invoke at process exit ( after Tcl exit cmd )
- Use to cleanup Tk resources used on MS-Windows
Simple File operations
- Needs addressing in core - portability
- copy, remove, mkdir, rmdir
Tk New Features (4.1)
New Geometry Manager
- grid
- Similar to Table Geometry manager in BLT
- Will be basis for SpecTcl
- Code base is from Java - (slightly )improved code
Text Widget Improved
- Faster tags
- Easier to extract all info from widget( text and tags )
SpecTcl GUI Builder
- Drag and Drop Interface for creating Tk Layouts
- Similar to Vbasic with a different layout Model ( stretchable
grid vs fixed Pixel position )
- Output is Tcl or Java or Perl
- Automatically handles finding widget commands and generating
property sheets
Java
Characterised by the Question - Whats the relationship between
JAVA and Tcl ?
"Siblings in a family of networking solutions"
- John said hes learnt marketSpeak since hes been at Sun
Tcl/Tk is for
- Rapid development
- Easy Glueing
- Compatibility with existing C world
Java is for system Programming
- eficient implementation
- Better program structureing mechanism
- Multi threading
Interesting logical next step is to reimplement Tcl in JAVA (assuming
can get Java and Tcl together and Java can be compiled to native
Machine code ).
Beauty of Visual Basic
- Easy to use for casual Programming
- Drag and Drop, Property Sheets, Specify behaviour in Basic
- Rich Library of extensions - implemented in C/C++ , scripted
in Basic
- 2 Languages gives best of both posible worlds
Wrong with Visual Basic
- Platform challenged
- GUI Builder and VBX's on PC only - 3rd party versions of Basic
- No Strategy for a heterogeneous environment
- Not embeddable (even with VBA)
- Scripts aren't first class objects
- Not generated on the fly
- No eval capability
- No Security
- Not Suitable for Internet/Enterprise apps (yet)
Tcl/Tk as VBasic for the Internet
- Tcl/Tk for scripting
- Java for Extensions
- Work to be Done
- Java and Tk to work together ( Tk as GUI toolkit for Java)
- Create GUI Builder
- Both projects now underway at Sun
- Tcl/Tk in Java VM devt version now (John's group)
- "Embrace Everything"
Current Projects
- Tk Native Look and Feel
- New Font Object - Request for fonts never fail, may not get
exactly what ask for
- Symbolic Events - 'Select' vs MB1 - exact bindings will vary
depending on Platform and GUI
- New Color Management
- Aim 3-6 months - assume 6-9 months ( conservatively)
- Integration with Java
- SpecJava visual builder (prefer 'Visual Java')
- Use full power of Tk wth Java: AWTk - make a plug in replacement
for AWT,
- AWT needs more functionality
- Will have side effect of making Tk more language neutral
- Tcl/Tk plug in for Netscape on all major platforms (Safe Tcl)
- Safe-Tk, Small amount of work to enforce resource limits
- Application embedding - Put Tk windows in an existing window
and allow Tk to make and provide a window for other apps to draw in.
- Mega Widgets - Additions to frame to support treating compound
widget combinations as a single widget
- Binary I/O - Read/Write values for sockets, Read and Write
Binary Blocks
- Drag and Drop - Cross platform portable paradigm
- WebEdit - WYSIWYG HTML editor - Brent had a version of this
running on a PC which he hgave a quick demo of :
- Developed on Unix - transferred code and run on PC for Bof
- Also a browser
- Popups for filling Images and anchors
- Tag rendering shown/controlled by buttons and toolbar
- Cut and paste into clipboard as markup, cut and paste images
The Current team is 8 people including John ( which is about
the max it should get and still be a single team ).
The books should be updated with info for the PC+Mac ports but
eventually forthcoming compiler will change or augment the C API's
which will need some more writing up - Don't know when is right time to
create a new version of the books.
Long term Projects (6-18 Months )
- On the fly Byte compiler
- Byte Code generator
- Development underway - some portions done
- 6 months to a year before accessible
- Should get 10-20x speedup for slowest parts ( those entirely
in Tcl code )
- Question - Provide Static compiler also
- Ship byte code, run across platform
- Would cause freezing of the API so guess not provide at first
- probably later
- Language Neutral Tk
- For Perl/Python/ML...
- Talk about, decide at Sun Workshop
- probably something avail in ~ 6 months
- Internationalisation
- Unicode clean, multibyte
- Problem - regexp parser - need new I18N unencumbered regexp
parser Implementation
- Been pushed back so far by Java support and ports
- Images
- JPEG support
- Better color handling - not always dither for small color
spaces
- Namespace Mechanism for Tcl
- Natural to add as part of compiler implementation
I seem to remember we got into feature requests from the floor
that he hadn't covered
- Tk canvas dashed lines ( patch) into core - probably other
patch feature additions as well
- HTTP server side support - John deprecated doing this in
favor of choosing his wars more carefully, Concentrate on Tcl
core functionality - considered a better solution to provide really
efficient socket I/O capability. The infrastructure will exist
with the redone I/O internals.
- MD5 support - 128 bit checksum
- Will Post his current feature Laundry list with each release
- eqn support in Text widget (cf eqn preprocessor)
- Monochrome stippling support where color challenged
- Standard dialogs and Forms ( e.g File Selection box, Tabbed
container, .. )
- Multiple source/sinks for text widgets so can allow multiple
views on same data set
- "after" comand with absolute times
- character interface (port ?) for Tk ( see Ctk )
- OLE support ( or OpenDoc ) on platforms that support it
- Access and use OCX's/ VbX's
- support creation of scripts as OLE servers
- Create GIF from a canvas
- Automatic endianness support in binary I/O
Want to defer large API changes until a central time and then
do all at once. Probably 'break' everything with the compiler
- hope there will be no API incompatibilities but there may be some
due to changes that no longer
- treat lists only as string pointers
- less lazy list parsing - where succeeds now may fail (earlier)
in compiler
Existing C code should continue to work with compiler but will
probably want to reimplement the extensions to get full performance
benefit.
The compiler will be extensible - Use of dual ported objects internally
( string and whatever ) and will extend the object support in
some fashion
Probably modify the regexp parser to understand
\n \t
itself rather than rely on the tcl parser for translation - perhaps also
some other syntax sugar similar to the perl regexp parser
- should alleviate some backslash quoting hell.
Mentioned in passing that If you want to provide contrib code
and maximise your chances of getting it into the core :
- Read the coding style doc and format the code that way
- Provide a man page
- Provide a test suite
- Closer to the current code base it is and the least convoluted
the more likely it is to get in.
Hops
(hops@sco.com)
$ Last Modified: $Date: 1996/02/05 17:57:45 $: