Presented by Ray Johnson
Ports of Tcl to the Mac and to Windows. Most of the work is making Tcl / Tk more portable even regardless of these specific ports. It already is very portable, runs with most Xservers. But tk tied closely to X features in its C api. Also tied to X in its Tcl interfaces: wm, font... Win & mac users want Tk.
Goals: want to have the native look and feel of the target platform. Tcl/Tk must remain free so we can't use commercial packages. Also scripts should not require conditionals so you'll have to write to the portable subset.
Schedule: win & mac ports are almost done with the motif look & feel, will be released next couple months. Native look & feel early 1996. Third phase: closer integration with native platform (1 yr or more).
Various issues are analysed. Drawing model. Even how a line is drawn is different. Mac has a pen concept which is different from X's. Short term: emulate X calls. Long term: extend the Tk C api so that you don't have to call X flavour calls.
Native look & feel: hard to get right with emulation. Need to track changing OS (Versions of windows look different from each other).
How do you wrap a system widget and get right behaviour? Different methods must be used on Win & Mac. Getting right look & feel for basic widgets is not enough: open file is a prepackaged collection (common dialogs). We must provide a higher level interface to these dialogs and Tcl will call the one for the os it's running on.
Binding to keys is non-portable (the command to paste is different in mac, win, unix), so a layer of indirection is required (bind to "paste", not to "control-V").
Menus are different. Different systems even put them in different places! Tk will have to decide where to place them based on the system.
Font names: too X specific (and ugly!) Solution: create a font object (much like image today). If you change the object, it gets updated wherever it appears. Font requests should never fail, something else should be substituted.
These slides (and paper) are available on the web as ftp://www.smli.com/pub/tcl/doc/portable-tk.ps and portable-tk-slides.ps
John says: the only good errors are dead errors. So let's try to get rid of things like "this font is not available" from the start by not making them possible.
Various questions about slashes for directory separation, size of integers etc.
John: we didn't add native motif widgets. Who would like them? (show of hands: practically nobody) How many people using Tk 4.0 have found major differences with motif? (same) If you find any, let us know.
Exec? Works on NT, nowhere near working yet on mac.
Aim: to make some given C functions (eg those from a C graphics package) accessible from Tcl. Thing to do: write C wrapper to convert the data types from strings, and convert the C function's result into a string. What about complex data types with no correspondence? Struct & unions are easy, arrays harder. Point of the paper: trying to do this interfacing automatically instead of doing it by hand. Examination of prior work: Wafe. A specification file (which is a Tcl script) describes the required conversions.
Simple types (integer, float &c) have direct representation. Enums -> strings. Structs -> assoc arrays. Arrays -> ???
Code generation: a Tcl script specifies the "prototype" of the C function and, when executed, generates the C code which does the conversion of the parameters, does the error checking and, if everything goes well, calls the C function and returns the result to Tcl. It's still a pain to write these Tcl scripts which are the specification files.
So: use the header files to generate the specification files automatically. Use a parser with tables that can be extended for user defined types. Problems with pointer parameters, which could either be pointers or arrays. We use heuristics for these.
C++ classes are mapped to [incr tcl] classes.
They applied this automatic approach to the OO rendering system VISION. All the heuristics guessed right. In another case (OpenInventor) there were 13 ambiguous cases, all resolved correctly by the heuristics. (like interpreting char* as a string).
NB: pointers to functions are hopeless.
Guile is the GNU extension language. Some months ago GNU decided not to use Tcl. So what else? Another extension language - guile. A virtual machine in a C library. Can interoperate with Tcl and Scheme. Example of a scheme function containing Tcl code and how this is evaluated (calling Tcl from scheme). Then example in the reverse direction. Web browser called TkWWW. We took it and turned it into a scheme-extensible web browser. Very small amount of new code (1 short slide). After this, tkwww can be extended in scheme and ctax.
What's mising? Redisplay, low level, event binding.
Another project: mix Guile with Mesa, a sort of graphics/widget library. And with another one compatible with OpenGL. Waiting for a simple C interface to Tk so we use these other widgets in the meantime. From this comes out an interpreter that is suitable for 3D graphics.
Coming soon: native code compilation, networking, threads, debugger, oop, combining mesa/openGl with Tcl/Tk, bytecodes, faster Ctax, integrated programming environment.
Fun projects for Guile hackers: make tkwww into an encapsulated library, mesa/Tk integration, 3D graphics and simulations.
Presented by Forest R. Rouse
A lot more complex than originally estimated. Philosophy: compile to C. Users don't have to modify one single line.
Why a compiler? Parsing is done at run time over and over again. Conversion on demand. Once converted to integer, the number can move around faster.
Why not a compiler? Types are unknown. Cute code fragment with "one" and "1". Cannot statically analyse. So we had to introduce optional declarations. Other problem: lists. Other problem: syntax. Cute examples of weird things.
Some things (like rename) cannot be handled in all cases.
Description of internals of compiler. Lots of cases handled directly, if you can't do it you eventually fall back to the interpreter. for and while: variables in the test expression could change their type from integer to string from one iteration to the next!
Lots of performance figures (but slides too small to read).
Future plans: provide support for incr tcl. Then byte-compiler. Long-term: more friendly API (eg defining the type of variables in Tcl). The way we'd do this is by making "integer" a tcl proc, that would do nothing in the interpreter but that would be recognised by the compiler.
The existing interpreters takes existing Tcl scripts and compiles them with no modification. Speedup between 5 and 15 for existing Tcl apps.
Q: what's missing before you can release it and sell it? A: we already are selling it! Look at our web site.
Support for major extensions (TclX, TclDP, [incr Tcl], expect, BLT) is in the plans and in some cases already available. The problem with extensions is what happens when they access variables.