Re: "I have a dream"

From: Donal K. Fellows (donal.k.fellows_at_man.ac.uk)
Date: 08/18/04


Date: 18 Aug 2004 02:13:14 -0700

USCode wrote:
> - Modularization: Would it be possible to further modularize Tcl and Tk into
> many seperate shared libraries. Then when I wrap my executable, it only
> contains the parts I actually need. For example, perhaps each control (or
> related controls) in Tk could be a seperate library. Or the networking code
> in Tcl could be seperated out. If you don't use a specific control or have
> any networking in your app, no reason to package it along for distribution.

The networking itself doesn't take a vast amount of space; more hungry
is the generic I/O infrastructure but you're much more likely to need
that. There's been a few other efforts to trim down the core, but
they aren't helped by the other people working on the core who tend to
integrate new features right throughout the whole system... :^)

In terms of removing Tk widgets, you'll find if you actually try it
that you'll need almost all of them. The big gains would be had by
removing the canvas and text widgets, and the photo image
infrastructure, but many core Tk scripts depend on those things (the
background error dialog requires [text], and the other standard
dialogs require the [canvas] and photo images on some platforms).

IOW, There's less fat there than there appears to be at first glance.

> - Bytecodes only interpreter: A version of the Tcl interpreter that
> executes bytecodes only. No compiler needed, your bytecodes only are
> wrapped into the executable.

ActiveState sell this sort of thing.

> I see 2 benefits (others?) to these 2 suggestions:
> 1) Reduce the size of the executable that you distribute/wrap, no
> unnecessary bloat.

I've already mentioned that this is difficult. I also wouldn't worry
about it too much; broadband is the wave of the future. :^)

> 2) Speed up startup time as you eliminate the compilation step and have a
> smaller executable to load.

Did you know that Tcl's compilation phase is actually *faster* than
the bytecode loader? :^D There are two problems with bytecode
loading:
  1) Bytecodes are not designed to be quick to read and decode since
     they are used for obfuscation of commercial code.
  2) When you've loaded bytecodes, it's a *really* good idea to
     conduct an integrity check before executing them. This is not
     necessary with the built-in compiler...

It turns out that Tcl/Tk's slow loading is due to other problems
(especially filesystem handling and the search for loadable packages)
which are being addressed in 8.5.

Donal.



Relevant Pages

  • "I have a dream"
    ... I've been evaluating Tcl/Tk to possibly use it for a database application ... resources into a single executable for distribution. ... executes bytecodes only. ...
    (comp.lang.tcl)
  • Add Webpart to MySite from a own control
    ... I created a custom control that is embedded on the MySite private view ... The control just executes some code, ... Updates are currently disallowed on GET requests. ...
    (microsoft.public.sharepoint.portalserver.development)
  • RE: System Timer Puzzle
    ... > that created the control, this is not happening in your case, which could be ... > System.Windows.Forms.Timer which executes inside the main UI thread - but can ... >> I'm building a WinForms app that is a companion to a Pocket PC app. ... >> WinForms app initiates a separate thread that calls a Notification window. ...
    (microsoft.public.dotnet.languages.csharp)
  • RE: System Timer Puzzle
    ... that created the control, this is not happening in your case, which could be ... System.Windows.Forms.Timer which executes inside the main UI thread - but can ... "Robert W." ... > WinForms app initiates a separate thread that calls a Notification window. ...
    (microsoft.public.dotnet.languages.csharp)
  • Prevent a record being saved after an error occurs
    ... "cmdSaveRecord" sub which, amongst other things, executes this command: ... Within here, some validation is ... If the control fails ... Cancel = True ...
    (microsoft.public.access.formscoding)