Lively TclTk

Lively-Kernel meets Tcl/Tk?

My latest install of Tcl/Tk 8.5 from Activestate left a link in Windows to Tk demos.  One is named "A Celebration of Rube Goldberg" and should impress Self-as-JavaScript  fans of Sun LivelyKernel or Avocado.

Regardless of the grief in getting Tcl with OO out of 8.6 beta, the demos are a great presentation.  I continue to use Html Viewer 3 (Tcl/Tk's hv3 browser) as a light-weight browser when my laptop's sole-core is over-loaded with a few of today's greedy app's wildly swapping in and out (and no, the worst offender happens not to be from Microsoft.)

Btw, Squeak Smalltalk is working to get their base image down to about 10Mb.  Remember when shared DLL's were to keep us all happy below 640K ?  Gates' Hades, Hades' Gates.

PS: I have added a label/tag for Pharo Smalltalk - now the preferred ST for Seaside?

PPS: here is the Avocado blog: there.

---

Tcl 8.6

The manual page is at http://www.tcl.tk/man/tcl8.6/ but TclOO may not be final yet for 8.6 ?

A default O-O package for Tcl 8.6: TclOO

 
While the link for O-O Tcl looks to be dated, the page for Tcl 8.6 releases is current.

I have a bias for XOTcl, but I will try to be open-minded when 8.6 gets out of beta.

TclOO is intended to offer classes and objects as a Tcl package rather than as an ad hoc extension to Tcl and Tk.  Some "patterns" folks will like the hiding of new in class in favour of create as the class declaration idiom - but instances are created via a command block substitution with the new word as in

set obj [MyClass new]

A google of TclOO and Tcl failed to get me past beta1 links to Tcl8.6b2 links.

But the link to the PDF on the new engine looked interesting.

This link at tcl.tk may be the final URL for core TclOO.

Over at activestate.com Tcl remains at 8.5.8 with a release number of 8.5.8.2 as of today.

Tcl 8.5.9 added the ttk::spinbox command.

A google on "Tcl 8.6" gives some useful links such as that to Mark Roseman's 8.6 page (he is the author of the tutorial for Ttk or Tile/Themed Tk.)

Tcl browser plugin v3 (from ActiveState)

There are some discrepancies in info about embedding Tcl/Tk since the change to plugin v3.

I tested against up-to-date Chrome, Opera, Safari, IE8, FireFox 3.5 and Amaya

My result is that given some script XYZ.tcl ONLY the following worked across all:

<OBJECT
ID="PluginHostCtrl"
CLASSID="CLSID:14E78123-A693-4F27-B6EE-DDDE18F93D3A"
WIDTH="400"
HEIGHT="220"
>
<PARAM name="type" value="application/x-tcl"/>
<PARAM name="pluginspage" value="http://www.tcl.tk/software/plugin/"/>
<PARAM name="src" value="XYZ.tcl"/>
</OBJECT>

Getting the plugin recognized by each browser was slightly problematic: IE 8 appeared to just ignore the XPI.

Windows and the Tea Shell

The Tea shell for the JVM has been available as version 3.2.2 for some months now.

There is no problem running the shell under Windows if you had Tea 3.1.0 up and running.

The first problem is that 3.2.2 includes no TEA.BAT in the tgz file. Just get the old 3.1.0, extract the bat file and update it to suit your install.

Tea must find a GNU jar for regexp and a Xerces jar for XML parsing. I reference them explicitly in a temp CLASSPATH in that BAT, e.g.,

set CLASSPATH=%TEA_BASE_DIR%;%TEA_BASE_DIR%\xerces-1.4.4.jar;%TEA_BASE_DIR%\gnu-regexp-1.0.8.jar;%CLASSPATH%

Tea is intended to bring multi-paradigm programming to the JVM. It is a java-based functional langauge with extensions for procedures and classes. This is another language intended to be component 'glue'. The selling point is that it is in java.

Other multi-paradigm languages either have their own compiler written in C or are using libraries implemented in C. Tea is java so one positive is that you get javadocs. The tea reference javadoc lists about 20 functions as the language core.

As a functional language Tea is intended to make the use of closures easy: functions are first-class objects as in JavaScript. In many respects the object system is like Smalltalk: members are private; methods are public. Code blocks in {} come with their contexts as closures. Every statement is at least a word which invokes a function. Lists are like Smalltalk collections: they can contain objects of mixed types. Unlike JavaScript, there is no literal notation for functions, but they can be loaded at will from jars or from raw source files using the source word.

Variables are not pre-typed, but they must first be declared with a define. The define word is over-loaded 3-fold: define a variable; declare a variable to have a value; define a variable to be a function as declared. The define word returns what it defines (it, too, is a function.) The set! function is used to re-assign a variable and anonymous functions can be had using the lambda function. Much like Smalltalk's collect: there is a map function to iteratively apply a function to a list. For lists of lists there is the function map-apply. Unassigned vars are returned with the value null. But note this sigil use:

define nativeParser $null

The syntax is very simple. Statements end at end-of-line. Comments start with octothorpe. You get variable values with a prefixed $ sigil. Other scripters will feel comfortable. The type tests use function? string? symbol? int? pair? which is extended to boolean tests as same? not-same? null? and not-null?. Lists use parentheses and, thankfully, no commas.

Lists are very much Scheme, as in

define testPair [cons "first" "last"]

where [car $testPair] gives "first and [cdr $testPair] give "last".
List are built from such pairs; the last pair in the list references a pair where both slots are null. With syntactic sugar our test list can be declared as

define testPair ( "first" "last" )

The Smalltalk procedural style is made possible by using the $ sigil.
For example, if you have a database connection in variable conn then

define sqlStmt [$conn statement]

returns a statement. The difference from Smalltalk can be seen when the query is created: there is no need for a colon, as in

define dataSet [$sqlStmt query "SELECT client_id FROM new_customers"]

but what is different is the use of [...] and not as a code-block { expression }. What is happening, of course, is a command substitution as in Tcl. The {} are used to defer evaluation as in a while loop.

The load function is rather like Jython: it gives access to java classes including Tea functions in those java jars.

But why would you use Tea? One possiblity is that you already know Scheme and Tcl or need a rapid way to work with closures in the JVM. But why not simply use JavaScript? One curiousity is that Tea is promoted as a language for rapid-prototyping, but in Lisbon it has been used for major banking and telco systems. But was it used only as glue code? Not at over a million lines according to Tea's own 'whitepaper'.

One observation: Tea is almost the opposite of Curl and Rebol. It is only now adding GUI and networking. But why add them if this is a scripting language for the JVM? It must be irresistable. Some people spoil their kids; some people spoil something else. And most of us seem to bloat if we are not kept on track ... and reminded that what we leave out can be as important as what we put in.

In Tea you get a hint of what the future holds if we shift away from 'C' and the OS to life with a VM.

Likely Tea will never have the momentum to break into North American markets unless it is embraced by a major player. It does have an advantage over Jython: there is no shifting Python beneath it. Then again, functional may becoming fashionable... even at Microsoft.

If you are a secret Schemer masquerading in Java or someone who can't thrive without a little Tcl, you may want to have some Tea... and lemon? Ah, right. They already added the syntactic sugar ...

PS There is another TEA which is the Tiny Encryption Algorithm and yet another Tea that is a strongly-typed templating language for managing servlets from the Disney TeaServlet project at what was once GO.COM Green tea. Black tea. Chá, anyone?

XOTclIDE: the IDE that is almost Smalltalk

I copied XOTclIDE82.kit into my \kits directory for ActiveState Tcl/Tk for Windows.
A double click on the kit ( I already had Tclkit in the PATH for Tcl\bin ) and I was politely asked whether to launch Simple or with Version Control. Simple was fine for now.

The result was a Transcript, a ClassBrowser and I was one click from a WorkSpace.

If you have ever used Smalltalk, this will sound very familiar.

And if you have never used Tcl with the GUI Tk you deserve to take an hour or two and see what simple GUI-driven control of admin tasks can be like.

XOTcl is extended MIT OTcl. There had been a few GUI extensions to Tcl rather as there have been for Python. But these extensions are principled: they do not simply provide a wrapper to a GUI library. The Mozart-Oz system is very much built on principle and exploits Tcl/Tk in its QTk, but lacks an IDE (SICStus Prolog also has a Tcl interface.). Tcl upvar and uplevel are not a replacement for the Mozart implementation of Oz, so my question becomes: does this rich environment impede or foster useful Tcl scripting?

An IDE as rich as that found with most Smalltalk implementations tends to be only as useful as its GUI layout tools and/or GUI specification framework. If it is awkward to tie event handlers and callbacks to widgets and worse to edit or maintain them, then little is gained by having object inspectors and dynamic workspaces. Tcl/Tk itself is marvelously simple (Jython comes to mind by way of comparison - or Rebol or Curl RTE's.)

The XOTcl documentation presents a very flexible, dynamic object framework, but the XOTcl components are file-based Tcl packages which must be registered with Tcl. Tcl is about component integration, but it's own integration of packages is a weak point, which is not to say that packaging and load dependencies cannot also be a headache in Smalltalk.

If I find the learning curve not too steep ( if Curl, the MIT web content language, has a gentle curve then Rebol is like learning to surf: anyone can paddle out ... ) then I will add a header page at eclectic-pencil and see if I can't put up a few useful markers across the terrain.

If you have a favorite language with no non-commercial IDE and are not in love with Eclipse, XOTclIDE does show what a mature IDE can offer a developer in a dynamic language. The only development environment to interest me as much as this was the outline-browser of Strongtalk.

PS Eclipse, of course, evolved from IBM VisualAge Smalltalk ...

Win32 NamedPipes and "All pipe instances are busy"

When I began using named piped with the excellent Win32 implementation of Smalltalk from http://www.object-arts.com/ called Dolphin Smalltalk. I was convinced that Windows XP named pipes had been abandoned for sockets.
I would open a pipe, receive

All pipe instances are busy

so I would try with Perl. No problem. Then the real evil: open a named pipe with Perl and Perl could write and read. Open a named pipe with Perl and then try to write or read with Tcl and

resource temporarily unavailable

yet again.

What was infuriating was that even with the disconnect issues noted in my last blog, Perl would reconnect clients to my pipe in a single shot. Tcl could not even read that pipe.

Had I been using the screen utility under Cygwin, the answer might have come earlier. It required 4 CMD sessions to be open on my left monitor. The top 2 opened the same pipe with Perl. Perl began writing to an instance of the pipe in screen 3 and screen 1 dutifully echo'd the output. Now amazement: in screen 4 I simply redirected my bothersome buffered interpreter to dump pages of docs to that same pipe and PRESTO screen 2 was dumping that output from an instance of the named pipe.

Now more evil. I close everything. Open one instance of that same named pipe. Now anyone can read and write to the pipe. Including Tcl.

No, I do not have any anti-virus software running: I suspect that this is a gift from Microsoft security upgrades.
Now when I want a pipe for the console of my choosing, I create it, close it, create it again. No problem. The 'one instance' accepts the first client.
There is a commercial ACL utility which could no doubt pin down the access issue.
Now just wait until I upgrade to Vista ...

Now to get a utility pkg written for Dolphin Smalltalk to allow read and write streams to interact correctly with a Win32 named pipe as if it were a file.

Tcl, fork, CommandShell and Squeak Smalltalk

Something rather Tcl-ish is available to Squeak Smalltalk based on the OSProcess classes: CommandShell. And of course it is only fully implemented on a Linux installation of Squeak.

But in Win32 where you cannot fork, you can likely get by using a socket on the child process, and there Squeak shines. And sockets are a definite alternative to messing with NamedPipes on Windows.

CommandShell detects whether it is being passed code to interpret or commands to execute, rather like a Tcl shell or any other scriptable shell. But scripting with Smalltalk is almost always a pleasure.

tbc at http://www.eclectic-pencil.com/