Re: "I have a dream"
From: Donal K. Fellows (donal.k.fellows_at_man.ac.uk)
Date: 08/18/04
- Next message: Donal K. Fellows: "Re: No tk_chooseFont or tk_choosePrinter?"
- Previous message: Michael Schlenker: "Re: Tcl Plugin Question"
- In reply to: USCode: ""I have a dream""
- Next in thread: lvirden_at_gmail.com: "Re: "I have a dream""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.
- Next message: Donal K. Fellows: "Re: No tk_chooseFont or tk_choosePrinter?"
- Previous message: Michael Schlenker: "Re: Tcl Plugin Question"
- In reply to: USCode: ""I have a dream""
- Next in thread: lvirden_at_gmail.com: "Re: "I have a dream""
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|