4 ms·

For a bit of context, in the Tcl ecosystem there's the concept of "Starkits" which are executable scripts which contain a stub loader which mounts a virtual fil

For a bit of context, in the Tcl ecosystem there's the concept of "Starkits" which are executable scripts which contain a stub loader which mounts a virtual filesystem archive (which contains all the files the actual script needs to run). Typically this has been either a Metakit database or a Zip file, but they both have disadvantages when compared to SQLite and we've been wanting to move to SQLite for a while but it didn't support being appended to things, so we couldn't. At the most recent Tcl Conference DRH agreed to fix this and with this change it looks like he has done it. Expect an SQLite-backed Starkit soon ! Also, and unrelated, Starkits can be converted to "Starpacks" which replace the script-based stub loader with a native executable, so you can distribute Tcl-based scripts as a single file.

oblio 8y ago
Tcl has so many amazing ideas. I just wish it had higher adoption and everything about it wouldn't feel so... old. Look at the wiki for example. It should really be an actual wiki à la Wikipedia not some sort of strange Wikipedia discussion page masquerading as documentation.
- btreecat 8y ago
  But where else would you find gems like this? https://wiki.tcl.tk/9832 https://wiki.tcl.tk/9832
  - pasbesoin 8y ago
    FINALLY, someone actually defined -- in practice -- what "(E)nterprise ready" means. Best definition yet, that I've seen.
- srean 8y ago
  I like the quirky feel of Tcl'ers wiki. It gives it an unique playful character. I would like it to stay that way.
- teraflop 8y ago
  > Look at the wiki for example. It should really be an actual wiki à la Wikipedia not some sort of strange Wikipedia discussion page masquerading as documentation. You can complain about it looking "old" if you want, but it's hardly fair to complain that it's not an "actual wiki". It follows the style of the original WikiWikiWeb which predates Wikipedia by a number of years.
  - ionforce 8y ago
    Expectations change. Scotsmen change.
- rkeene2 8y ago
  For general style improvements to the Wiki there's progress on moving the Wiki to "Nikit": https://nikit.tcl-lang.org/ https://nikit.tcl-lang.org/
- rkeene2 8y ago
  You can help improve adoption by using Tcl in your next project -- there's no reason not to, right ? :-) P.S. We just setup a Slack interface to the Tcl'ers Chat, so now all you Slackers can join in to the hundreds of other Tcl'ers. https://slack.tcl-lang.org/ https://slack.tcl-lang.org/
- deleted 8y ago
  [deleted]
- rkeene2 8y ago
  On a related note, if you love Tcl but want a different syntax there's Little, which is driven by Tcl, but has a C/Perl/awk syntax: http://www.little-lang.org/ http://www.little-lang.org/
- simias 8y ago
  Do you think it's an actually good language though? I only tinkered around with Tcl (long ago when writing eggdrop bots and more recently while messing around with FPGA and ASIC build scripts) and while it's serviceable it never struck me as a particularly interesting or elegant scripting language. When given the choice I'll always pick Python or Perl over Tcl. Am I wrong? What did I miss?
  - qznc 8y ago
    I don't think Tcl is in competition with Python or Perl. It is in competition with bash, PowerShell, etc. Its syntax is quicker to type which is good for interactive (REPL) use. Sometimes I'm thinking about a simple build system which is very much like Make but uses Tcl to be cross-platform and scales better to advanced uses. Tcl could also work well in Jupyter notebooks. Once you think about functions, classes, and modules, you better use Python.
    - deleted 8y ago
      [deleted]
  - rkeene2 8y ago
    I think it's a good language. It has simple syntax (only 13 syntax rules), great documentation for the API, the language, core commands, and all the packages shipped with the core release. It's very flexible so it can be used in a lot of situations: Embedded into a program as a domain-specific language (DSL), scripting engine in its own right with very complex software written in many different styles, evaluating untrusted code (with Tcl Safe Interpreters). Really the only reason to pick Python over Tcl is that more people have picked Python over Tcl in the past.
  - eridius 8y ago
    I think Tcl is incredibly elegant. It's got a set of very simple syntax rules that compose together to govern everything. You can use Tcl to create your own keywords that are used exactly like the built-in ones and your caller won't ever tell the difference (well, unless they inspect an error backtrace). For example, a try/catch syntax was proposed as TIP 89¹. And many many years ago, as part of the MacPorts project, I implemented the entirety of TIP 89 in pure Tcl. The TIP was proposing actual Tcl keywords, but I implemented exactly the proposed syntax and semantics without a single keyword. I have no idea if that code exists in any form anymore (I haven't been involved with the project in something like a decade), but I'm pretty sure the only observable difference between that and TIP 89 is error backtraces² that cross a frame involving try/catch. Also, virtually every type³ in Tcl can be expressed as a string, and so you can model the entire language mentally as if every value was in fact a string. If you wanted to write your own Tcl interpreter it would be pretty easy to actually implement it this way, though obviously performance would suffer quite a lot. ¹Later superseded by TIP 329 in response to the error options dictionary in Tcl 8.5. ²And FWIW I believe there's no actual spec for what error backtraces look like anyway, I think it's implementation-defined, though don't quote me on that. ³The only type I know of offhand that can't be expressed this way is an array (which is distinct from a list, that is a fundamental building block of Tcl and can absolutely be expressed as a string)
microtherion 8y ago
If your database is readonly after being appended, you could also use memvfs. I've used that on mmapped files to support similar archive ideas: https://www.sqlite.org/src/file/ext/misc/memvfs.c https://www.sqlite.org/src/file/ext/misc/memvfs.c
derefr 8y ago
These sound a lot like Erlang escripts as well.

oblio 8y ago

Tcl has so many amazing ideas. I just wish it had higher adoption and everything about it wouldn't feel so... old. Look at the wiki for example. It should really be an actual wiki à la Wikipedia not some sort of strange Wikipedia discussion page masquerading as documentation.

btreecat 8y ago
But where else would you find gems like this? https://wiki.tcl.tk/9832 https://wiki.tcl.tk/9832
- pasbesoin 8y ago
  FINALLY, someone actually defined -- in practice -- what "(E)nterprise ready" means. Best definition yet, that I've seen.
srean 8y ago
I like the quirky feel of Tcl'ers wiki. It gives it an unique playful character. I would like it to stay that way.
teraflop 8y ago
> Look at the wiki for example. It should really be an actual wiki à la Wikipedia not some sort of strange Wikipedia discussion page masquerading as documentation. You can complain about it looking "old" if you want, but it's hardly fair to complain that it's not an "actual wiki". It follows the style of the original WikiWikiWeb which predates Wikipedia by a number of years.
- ionforce 8y ago
  Expectations change. Scotsmen change.
rkeene2 8y ago
For general style improvements to the Wiki there's progress on moving the Wiki to "Nikit": https://nikit.tcl-lang.org/ https://nikit.tcl-lang.org/
rkeene2 8y ago
You can help improve adoption by using Tcl in your next project -- there's no reason not to, right ? :-) P.S. We just setup a Slack interface to the Tcl'ers Chat, so now all you Slackers can join in to the hundreds of other Tcl'ers. https://slack.tcl-lang.org/ https://slack.tcl-lang.org/
deleted 8y ago
[deleted]
rkeene2 8y ago
On a related note, if you love Tcl but want a different syntax there's Little, which is driven by Tcl, but has a C/Perl/awk syntax: http://www.little-lang.org/ http://www.little-lang.org/
simias 8y ago
Do you think it's an actually good language though? I only tinkered around with Tcl (long ago when writing eggdrop bots and more recently while messing around with FPGA and ASIC build scripts) and while it's serviceable it never struck me as a particularly interesting or elegant scripting language. When given the choice I'll always pick Python or Perl over Tcl. Am I wrong? What did I miss?
- qznc 8y ago
  I don't think Tcl is in competition with Python or Perl. It is in competition with bash, PowerShell, etc. Its syntax is quicker to type which is good for interactive (REPL) use. Sometimes I'm thinking about a simple build system which is very much like Make but uses Tcl to be cross-platform and scales better to advanced uses. Tcl could also work well in Jupyter notebooks. Once you think about functions, classes, and modules, you better use Python.
  - deleted 8y ago
    [deleted]
- rkeene2 8y ago
  I think it's a good language. It has simple syntax (only 13 syntax rules), great documentation for the API, the language, core commands, and all the packages shipped with the core release. It's very flexible so it can be used in a lot of situations: Embedded into a program as a domain-specific language (DSL), scripting engine in its own right with very complex software written in many different styles, evaluating untrusted code (with Tcl Safe Interpreters). Really the only reason to pick Python over Tcl is that more people have picked Python over Tcl in the past.
- eridius 8y ago
  I think Tcl is incredibly elegant. It's got a set of very simple syntax rules that compose together to govern everything. You can use Tcl to create your own keywords that are used exactly like the built-in ones and your caller won't ever tell the difference (well, unless they inspect an error backtrace). For example, a try/catch syntax was proposed as TIP 89¹. And many many years ago, as part of the MacPorts project, I implemented the entirety of TIP 89 in pure Tcl. The TIP was proposing actual Tcl keywords, but I implemented exactly the proposed syntax and semantics without a single keyword. I have no idea if that code exists in any form anymore (I haven't been involved with the project in something like a decade), but I'm pretty sure the only observable difference between that and TIP 89 is error backtraces² that cross a frame involving try/catch. Also, virtually every type³ in Tcl can be expressed as a string, and so you can model the entire language mentally as if every value was in fact a string. If you wanted to write your own Tcl interpreter it would be pretty easy to actually implement it this way, though obviously performance would suffer quite a lot. ¹Later superseded by TIP 329 in response to the error options dictionary in Tcl 8.5. ²And FWIW I believe there's no actual spec for what error backtraces look like anyway, I think it's implementation-defined, though don't quote me on that. ³The only type I know of offhand that can't be expressed this way is an array (which is distinct from a list, that is a fundamental building block of Tcl and can absolutely be expressed as a string)

microtherion 8y ago

If your database is readonly after being appended, you could also use memvfs. I've used that on mmapped files to support similar archive ideas: https://www.sqlite.org/src/file/ext/misc/memvfs.c https://www.sqlite.org/src/file/ext/misc/memvfs.c

derefr 8y ago

These sound a lot like Erlang escripts as well.