hat0 writes [the brick engine]. hat0 has also written a simple [ssh launcher] and a [pure-tcl BMP reader/writer]. Here is a link to a page about a new packaging system called [Ultimate Package Blast-o-rama]. And here is a link to a little package which can be used to preload DLLs on a Windows-based machine: [dllfix] ---- [AMG]: Happy belated birthday! [hat0]: thank you very much!! ---- It's March of 2010. I've been asking around today, what sort of vision people have for Tcl, five years out. Alex Ferrieux says, "freeze as perfect, like /bin/sh" Colin says, "if I have any vision at all, it's about making Tcl smaller by making its innards more introspective and able to be implemented in Tcl. If you can generate bytecode from Tcl, then you can write all (or some, or many) of the compilation of Tcl commands to Bytecode *in* Tcl." Benefit is an advantage in speed of writing/improving the standard library. Drawback is a period of lack of stability in the core. [SEH]: Are you soliciting further comment? [hat0] Heck yeah! Please, speak your mind, I'd love to hear your thoughts/ideas. ---- **A five-year plan for Tcl** These are my thoughts about things that could improve tcl, or various different directions tcl could go, so that it is not just another language in 2015, but a language of growing importance/relevance. ''Note to anyone who sees this page: this isn't supposed to be another cloverfield or "tcl 9"-styled effort. I'm not interested in telling anyone what to do, or trying to force my ideas onto anyone. This is my own personal brainstorm, and all are welcome to add to it.'' * some syntax- or command-level concurrency (e.g. a foreach that parallelizes the body?) * some syntactic sugar on "expr"? * extend the {*} operator in various discussed ways ({n} as sugar for "lindex", etc) * deprecate now and eventually remove arrays (confusing, unnecessary, dicts are better, etc) * improve error reporting in bad "expr" expressions * improve error reporting in general * fix the unbalanced brace issue * modularization of the core (e.g. easily-discarded timezones, etc) * some sort of script-level marker that code block X has no traces/doesn't redefine commands and can therefore be more heavily optimized * some sort of JIT compilation? * work alongside or replace javascript as an in-browser DOM-manipulation language? * why is Jim so small? what does it lack that is a deal-breaker? * qt/gnome integration for Tk * printing for Tk * Tk gui builder * how can tcl/Tk be improved for new developers? how can this be a more developer-friendly system? [AMG]: I have a question about removing support for arrays. Arrays support traces on individual elements, whereas dicts do not. Do you have any thoughts on this? Do we need a means for attaching traces to dict elements? That can get really hairy really fast. I'll summarize the difference between arrays and dicts: an array is a quasi-variable that is a collection of variables, whereas a dict is a value which is itself a collection of values. (I say "quasi-variable" because arrays don't have all properties of variables; for instance, they don't have values.) [hat0] Agreed, traces on arrays/array elements are useful. I'd suggest extending traces to work on dicts/dict elements. <> Person