Tclkick downloads for Win32 working again

Just recognized that the downloads for Tclkick-Win32 were not working over the past 2 days… This was due to a file renaming issue I did on Saturday (extracting from the .zip files and wrapping in .tar.gz).
I refreshed the builts to resemble the latest CVS sources and created .zip files as usual. The links are now working again.

Tclkick is born

Sometimes the best idea is not the first one, respectively the first idea is not the best one. This happens to me from time to time… and when I rethink it later, I sometimes have to refactor some things to get the real good idea to work. Well, many things in life are a process ;-).

Previously I wrote that Tclkit can not be named Tclkit any more and introduced Tclstarter. This is a not-too-bad name for what it is supposed to be, but there is really a better name – and this name is actually for sure not used otherwise:

Tclkick

I like it. Sounds like Kick off Tcl programs. Nice. Fits the concept very well. I wonder why JCW didn’t name it so… Oh well, now it’s too late – most people know the official version as Tclkit.

Sorry for the confusion though…

Tclkit renamed to Tclstarter

According to a comment from Larry W. Virden on the Tloona page, Tclkit must be distributed under a different name if the functionality inside has changed.

I didn’t know this, although the reason for this policy is obvious… Simply said If it is declared as Tclkit, then there should be Tclkit inside. Sorry for my ignorance of this fact – I am about to rename Tclkit now to Tclstarter. Most of the work has been done, the binary files themselves will be renamed soon and the links too (it is a bit hairy to rename links because of pages that link from outside and people’s bookmarks…)

MS Firefox

There is a hilarious article and product presentation on http://www.msfirefox.com/. If you need some distraction, I’d recommend to read it – especially the features page and the job offers :-))!

I wonder how many people out of 100 really believe what this website writes…

Photo

Don’t be frightened… that’s just me ;-)

Tcl and debugging (TIP 280 + 290)

In case somebody is not following the discussions on the Tclcore mailinglist ;-)… – I have submitted a TIP (Tcl improvement proposal) for running a custom handler on exceptional return.

The handler is run immediately after an exception occured, in the same call frame. This is what makes it special: it has complete access to the variables and everything else in the callframe where the error came up. The handler command runs on every exception, the command itself can filter out what exceptions to handle and how they are processed. An example and possible uses are on the TIP page.
Main purpose of this TIP is debugging. It makes it possible to debug a program out of the box and out of itself – and this is very helpful. The debugger can be practically built into the program, and this is enabled by the language. Only Smalltalk and LISP have this feature yet, as far as I know (both languages are not very popular for one or the other reason…).

Assuming you are developing a cool Tcl application for someone or yourself – and register the [breakpoint] procedure (see example usage on the TIP page) on uncaught errors via trace set exception -uncaught breakpoint. Then you run the program with tclsh or tclkit(sh), and suddenly an uncaught error appears. Now, [breakpoint] is entered, which in fact stops execution and enables you to evaluate typed in commands. You can use normal Tcl commands to inspect and change variables, switch callframes with [uplevel] etc… everything at the position where the error occured. The error is even quelled if [breakpoint] returns normal, so that the program resumes normal operation afterwards. All that comes built in with the language, without extra tools, debuggers or chinning the bar. Nice, isn’t it :-)?

I hope that the TIP gets accepted and is included in Tcl (maybe even in 8.5). Until then, you can download the Tclkits from here to have a sneak preview. Test it and feel how it is to have the Mercedes of programming functionality under your seat. I’ve applied the reference implementation patch for TIP 290, the debug package with [breakpoint] is part of Tloona (as lib/debug).
Also, I applied the patch for TIP 280, which enables better stacktrace inspection capabilities via [info frame]. Binaries are available for Linux and Windows, as usual.

The debugging via [breakpoint] works currently only from within the command line (shell on Linux), where you have normal stdin/stdout. On windows, with tclkit it is not possible to register the [breakpoint] procedure… well it is possible, but since you don’t have stdin, the program will just hang in an error case. This can be solved with a Tk console that pops up, but I have not investigated into this so far (help is welcome). Until this is done, please use the feature only with tclkitsh on windows.