If you want to play with reading/recreating a very small Tcl interpreter, recently I put Picol (a 500 lines of C code Tcl interpreter) on Github. It was still on the web, but a bit more "hidden". I had a chance to re-read the code, and it is not in the category of code I regret writing :D Still relatively useful for newcomers, I hope.
Thanks for that effort. Some time ago, I got Picol working on an Arduino-compatible microcontroller board with minimal effort. I was working towards making my own programmable calculator, and test-drove a number of simple interpreters, including yours and a couple others.
Project languished due to my attention span running out, but I still have my adaptations of those codes on my drive, in case I ever pick it up again.
Thanks for Picol! I saw it as a young engineer, and found the simplicity inspiring. It inspired me to write Tcl interpreters as starter projects in the next languages I was picking up, and I learned a lot by trying to push performance , functionality, and correctness.
Your little project ended up inspiring cumulative months of joyful hacking.
In the 1990s, an awful lot of Linux apps were Tk/Tcl. People complained then about them not being "native", but they were slimmer and better performing than the typical Java or Electron app of today.
MacPorts has far more packages than Homebrew and was implemented by the creator of the original FreeBSD ports system, who was also an employee on Apple’s UNIX team. MacPorts is the standard macOS package manager.
I have always preferred BSD-style ports trees, which emphasize building the packages from source code. Easier to patch the source when needed, when adapting (porting) the package to a new environment.
This made it easier to adapt large collections of packages to new versions of macOS. Or to adopt the latest version of a package. Easier for integration testing for my application.
It doesn't surprise me at all that MacPorts has a larger collection of packages than HomeBrew.
I like MacPorts, but most macOS using developers I’ve conversed with over the past 12+ years never heard of it, while all of them used Homebrew. Maybe it depends on what developer circles one inhabits.
I have only ever used macports, but my first and only MacBook was salvaged from bigcorp IT, and is a 2009 model so homebrew is too new for it.
I’ve dabbled in BSD before and I can definitely see the correspondence between Macports and freeBSD ports. I assume homebrew tries to be more similar to apt or yum.
But, by all measures, MacPorts is more standard than Homebrew. Such as being implemented by an Apple employee who also created the official (source-based) package manager for the most popular BSD.
Homebrew definitely has a lot more market share though, much to my chagrin. The only other MacPorts users I’ve met in person are people I convinced to switch.
I like Tcl a lot, especially the Expect module. If you've ever wanted an Autohotkey for your terminal (I promise that phrase actually makes sense) it's well worth your time to look into either Expect itself or Python's `pexpect` module.
Package owner: "These configuration choices are so important that a human must be present at the keyboard every time, without exception. Woe would befall us all were the will of the ancients ignored. So it was written, so it shall be done."
Yeah, I just wish there was a nice/supported/reasonably capable GUI designer.... (and I'd love to be directed to one, having been unsuccessful in searching for one).
There are quite a few half finished GUI designers for it but I suspect they all remain half finished because the people who start in on them realize that such a tool will not get Tcl/Tk onto the level of QT or GTK and fights against what makes Tcl/Tk such a great tool. It is not about slick and highly refined UIs, it is about quickly and easily making functional UIs. You learn the sense and quirks of pack and grid and for applications which those simple containers work well for, nothing will be as fast or as easy as Tcl/Tk despite the lack of a GUI designer. Tcl/Tk is not for big complex UIs, it can do them but generally you will be better served by other toolkits for those.
tkcon gets you reasonably close to a GUI designer, it is text mode but instantaneous, and quite simple to configure the widgets to allow you to configure them with your mouse if you really want to do that.
This, when I wanted to try tcl, it was so difficult to find ! Somehow I was able to find a tcl executable in my distro.
I challenge anyone to download an executable in less than 2 clics from the page "Binary distribution" of tcl official website [0].
Why is there so much difficulty to provide a binary for TCL ?
[0] : https://www.tcl-lang.com/software/tcltk/bindist.html
Tcl offers a unique combination of embeddability and power, often underappreciated outside specific domains. While its general-purpose usage might be less prominent, its dominance in Electronic Design Automation (EDA) is undeniable.
What I would recommend right off the bat is installing the handy tool `rlwrap` and starting `tclsh` using the command `rlwrap tclsh`. This wraps it with readline which imo is a better experience (especially if one is used to the readline keyboard shortcuts).
I use TCL often (forced to) since it's Cloverleaf Integration Engine's official scripting language and it works very well, but it is different from other languages in that its syntax is not modern, though, it's not difficult to learn if you really need to.
It's an older language that's fallen out of favor mostly for other scripting languages (Javascript, Python, etc) and understandably so. I'm by no means an TCL, but do consider myself an expert when using it with Cloverleaf.
So many fond memories of building eggdrop bots with Tcl scripts in the good old days of IRC. Trivia games, quote dbs, channel management, nick squatting, all sorts of shit.
Tcl is more-or-less required if you're involved with the physical design of silicon (most EDA tools only provide a Tcl interface). It's a good fit for that purpose. If you need a language which is easy to embed and you want non-programmers to be able to use it, Tcl is a good choice, though I've heard that Lua has supplanted Tcl for that purpose.
Our flow is thousands of lines of Tcl code around all the cadence and synopsys tools. Then we write more Tcl to create the power grid, create blockages, etc.
In the silicon industry it’s definitely tcl only. Zero Lua. But every tcl script I have seen is extremely simple, often just a bunch of commands to the EDA tool that reads like a list of bash commands.
Tcl scripting gets more interesting when you want to talk to a design running in an FPGA over JTAG. I have a toy CPU project which I've so far tested on Altera/Intel, Xilinx and Lattice FPGAs, and a debug interface where a C-based ncurses debugger connects over TCP/IP to a Tcl bridge which talks to the appropriate JTAG interface for the particular type of chip.
I'm also a big fan of the full-fat Tk-capable Tcl in Altera's SignalTap / Virtual JTAG - I used it recently to plot histograms on-demand for profiling RAM / Cache accesses.
I dropped Perl for TCL decades ago, after I realized that I could read and understand my TCL code months after I’d written it, but my Perl code was totally opaque.
I first encountered Tcl when trying to use the network simulator, ns2. Any language that lends itself to such hideous code can't be good, I thought, and stayed clear of it ever since.
I can't speak for other scripting languages, but it's absurdly easy both to embed Tcl as an interpreter in a larger project, and to create a Tcl extension which implements your own commands.
But to be honest, while I feel like Perl has a lot of advantages (full perlre, full access to POSIX APIs, slightly better performance), I still can't look at it and keep my last meal down. Tcl having an event loop and Tk being native are pretty nice too.
If you want to play with reading/recreating a very small Tcl interpreter, recently I put Picol (a 500 lines of C code Tcl interpreter) on Github. It was still on the web, but a bit more "hidden". I had a chance to re-read the code, and it is not in the category of code I regret writing :D Still relatively useful for newcomers, I hope.
https://github.com/antirez/picol
Thanks for that effort. Some time ago, I got Picol working on an Arduino-compatible microcontroller board with minimal effort. I was working towards making my own programmable calculator, and test-drove a number of simple interpreters, including yours and a couple others.
Project languished due to my attention span running out, but I still have my adaptations of those codes on my drive, in case I ever pick it up again.
Thanks for Picol! I saw it as a young engineer, and found the simplicity inspiring. It inspired me to write Tcl interpreters as starter projects in the next languages I was picking up, and I learned a lot by trying to push performance , functionality, and correctness. Your little project ended up inspiring cumulative months of joyful hacking.
I wonder how this relates to Jim Tcl which you also originally authored?
The once-ubiquitous open-source package manager for macOS, MacPorts, is basically a Tcl app.
That is to say, its packages are Tcl.
I haven't used it in many years, as is has been largely replaced by Homebrew, which uses Ruby.
(I once maintained a MacOS port of a good-sized scientific analysis package. Hundreds of MacPorts packages, I have debugged.)
https://www.macports.org/
In the 1990s, an awful lot of Linux apps were Tk/Tcl. People complained then about them not being "native", but they were slimmer and better performing than the typical Java or Electron app of today.
It’s only because TK was so butt-ugly
Agreed, but you can stylize them now with ttk (https://tkdocs.com/tutorial/styles.html and https://wiki.tcl-lang.org/page/Ttk). There are other ways, too, but I do not have the source code at hand at the moment (as I have done this before).
Tk’s look was based directly on the Motif widget toolkit that was dominant on UNIX workstations at the time it was created.
Yes, unfortunately, though Tk wasn't quite as bad as the dystopian Brutalist Soviet horror of Motif.
You should see Windows {10,11} or Android. /s
TCL modules are still pretty widely used in HPC-like environments unfortunately:
https://modules.readthedocs.io/en/stable/modulefile.html
Though there is a replacement that uses Lua which is somewhat better than TCL:
https://lmod.readthedocs.io/en/latest/index.html
TCL is also pretty universally used in EDA scripting. It's pretty bad, though I guess it is better than all the Bash that EDA devs tend to use too.
I don't think homebrew has replaced MacPorts. I suspect that MacPorts has more ports.
MacPorts has far more packages than Homebrew and was implemented by the creator of the original FreeBSD ports system, who was also an employee on Apple’s UNIX team. MacPorts is the standard macOS package manager.
I have always preferred BSD-style ports trees, which emphasize building the packages from source code. Easier to patch the source when needed, when adapting (porting) the package to a new environment.
This made it easier to adapt large collections of packages to new versions of macOS. Or to adopt the latest version of a package. Easier for integration testing for my application.
It doesn't surprise me at all that MacPorts has a larger collection of packages than HomeBrew.
My other ride is Gentoo Linux. :-)
> MacPorts is the standard macOS package manager.
No, it's not. macOS does not have a standard package manager.
https://www.gnu.org/fun/jokes/ed-msg.en.html
Worth noting https://developer.apple.com/documentation/packagedescription...:
>:(What do you mean by “standard”?
I like MacPorts, but most macOS using developers I’ve conversed with over the past 12+ years never heard of it, while all of them used Homebrew. Maybe it depends on what developer circles one inhabits.
I have only ever used macports, but my first and only MacBook was salvaged from bigcorp IT, and is a 2009 model so homebrew is too new for it.
I’ve dabbled in BSD before and I can definitely see the correspondence between Macports and freeBSD ports. I assume homebrew tries to be more similar to apt or yum.
Yes, one of several nice things about MacPorts is the continued support for older macs, macOS/OSX versions.
MacPorts is a godsend on older Macs.
Takes forever to compile stuff on a G3 though :)
How did people compile emacs on 2 cores in the old days? :O
Just a play on “ed is the standard text editor”.
But, by all measures, MacPorts is more standard than Homebrew. Such as being implemented by an Apple employee who also created the official (source-based) package manager for the most popular BSD.
Homebrew definitely has a lot more market share though, much to my chagrin. The only other MacPorts users I’ve met in person are people I convinced to switch.
I like Tcl a lot, especially the Expect module. If you've ever wanted an Autohotkey for your terminal (I promise that phrase actually makes sense) it's well worth your time to look into either Expect itself or Python's `pexpect` module.
I love Expect.
Package owner: "These configuration choices are so important that a human must be present at the keyboard every time, without exception. Woe would befall us all were the will of the ancients ignored. So it was written, so it shall be done."
Me: "Yeah, nah."
I thought with the rise of chatbots tcl/expect would see a big resurgence. It's definitely been on my to-do list in the last few months.
I tought expect is a test framework
Expect is an automation framework. Automating tests is just one use for it.
Expect was born out of TCL, and its original syntax worked really well with TCL's.
Its popularity led it to being ported to other languages, Perl & Python being the big ones, but TCL Expect is the og
SQLite has the same origin story. (That's the reason for SQLite's confusing type system: it makes perfect sense as a Tcl type system.)
Wait, didn't Tcl/TK 9 just launch?
https://www.tcl-lang.com/software/tcltk/9.0.html
Any word on a nice binary release of it?
it's worth noting for those unfamiliar, tcl/tk 8.0 came out in 1997. So this isn't a normal thing, this is a 27 years in the making kind of thing.
Yeah, I just wish there was a nice/supported/reasonably capable GUI designer.... (and I'd love to be directed to one, having been unsuccessful in searching for one).
There are quite a few half finished GUI designers for it but I suspect they all remain half finished because the people who start in on them realize that such a tool will not get Tcl/Tk onto the level of QT or GTK and fights against what makes Tcl/Tk such a great tool. It is not about slick and highly refined UIs, it is about quickly and easily making functional UIs. You learn the sense and quirks of pack and grid and for applications which those simple containers work well for, nothing will be as fast or as easy as Tcl/Tk despite the lack of a GUI designer. Tcl/Tk is not for big complex UIs, it can do them but generally you will be better served by other toolkits for those.
tkcon gets you reasonably close to a GUI designer, it is text mode but instantaneous, and quite simple to configure the widgets to allow you to configure them with your mouse if you really want to do that.
https://github.com/wjoye/tkcon
I remember using one in the late 90s ... it was pretty sweet. Probably doesn't hold up to modern expectations.
This, when I wanted to try tcl, it was so difficult to find ! Somehow I was able to find a tcl executable in my distro. I challenge anyone to download an executable in less than 2 clics from the page "Binary distribution" of tcl official website [0]. Why is there so much difficulty to provide a binary for TCL ? [0] : https://www.tcl-lang.com/software/tcltk/bindist.html
Tcl offers a unique combination of embeddability and power, often underappreciated outside specific domains. While its general-purpose usage might be less prominent, its dominance in Electronic Design Automation (EDA) is undeniable.
Cool!
What I would recommend right off the bat is installing the handy tool `rlwrap` and starting `tclsh` using the command `rlwrap tclsh`. This wraps it with readline which imo is a better experience (especially if one is used to the readline keyboard shortcuts).
Nice, a TCL post!
I use TCL often (forced to) since it's Cloverleaf Integration Engine's official scripting language and it works very well, but it is different from other languages in that its syntax is not modern, though, it's not difficult to learn if you really need to.
It's an older language that's fallen out of favor mostly for other scripting languages (Javascript, Python, etc) and understandably so. I'm by no means an TCL, but do consider myself an expert when using it with Cloverleaf.
Thanks!
So many fond memories of building eggdrop bots with Tcl scripts in the good old days of IRC. Trivia games, quote dbs, channel management, nick squatting, all sorts of shit.
I skipped Tcl in favor of Perl. Is there any reason to reconsider nowadays?
Tcl is more-or-less required if you're involved with the physical design of silicon (most EDA tools only provide a Tcl interface). It's a good fit for that purpose. If you need a language which is easy to embed and you want non-programmers to be able to use it, Tcl is a good choice, though I've heard that Lua has supplanted Tcl for that purpose.
That's been my job for the last 30 years.
Our flow is thousands of lines of Tcl code around all the cadence and synopsys tools. Then we write more Tcl to create the power grid, create blockages, etc.
In the silicon industry it’s definitely tcl only. Zero Lua. But every tcl script I have seen is extremely simple, often just a bunch of commands to the EDA tool that reads like a list of bash commands.
Tcl scripting gets more interesting when you want to talk to a design running in an FPGA over JTAG. I have a toy CPU project which I've so far tested on Altera/Intel, Xilinx and Lattice FPGAs, and a debug interface where a C-based ncurses debugger connects over TCP/IP to a Tcl bridge which talks to the appropriate JTAG interface for the particular type of chip.
I'm also a big fan of the full-fat Tk-capable Tcl in Altera's SignalTap / Virtual JTAG - I used it recently to plot histograms on-demand for profiling RAM / Cache accesses.
That's one of the benefits of tcl, having a bunch of commands require as little syntax as possible.
I'd say python starts to make some strides, likely due to the AI hype train. But it's still mostly Tcl.
I dropped Perl for TCL decades ago, after I realized that I could read and understand my TCL code months after I’d written it, but my Perl code was totally opaque.
I like both Perl and TCL. If I need an executable for Windows, I choose TCL, because I can easily make one with freewrap.
I remember such wrappers for Perl and even for PHP.
Perl and Python have a myriad of similar tools that work well with projects with no dynamic imports.
I first encountered Tcl when trying to use the network simulator, ns2. Any language that lends itself to such hideous code can't be good, I thought, and stayed clear of it ever since.
https://www.isi.edu/websites/nsnam/ns/
TCL is embeddable (in another program). In fact that's how it started.
That means it's a good language to extend your program. I don't know how it compares to Lua, which seems to have replaced it in that space.
I like TCL a lot more for this use case, and I don’t care for Lua at all; but Lua might be a better match for embedding in an OO language.
Lua is simple to bolt on to your project.
Perl is a nightmare to interop! They should have won an award for that. It took effort.
Python is slightly cleaner than perl, but not much.
You mean, the interpreter is available as a library with bindings in many languages?
But then - isn't that the case for other scripting languages these days? Or are they too complex and with "strings attached"?
I can't speak for other scripting languages, but it's absurdly easy both to embed Tcl as an interpreter in a larger project, and to create a Tcl extension which implements your own commands.
One can leverage Lua in PHP, I think it's handy for user-supplied logic (eg: business rules)
You're using the same words. What is "easy" about embedding TCL that is "difficult" about embedding Perl or Python? Can you spell this out?
Looks like this post I made can serve again: https://world-playground-deceit.net/blog/2024/10/why-tcl.htm...
But to be honest, while I feel like Perl has a lot of advantages (full perlre, full access to POSIX APIs, slightly better performance), I still can't look at it and keep my last meal down. Tcl having an event loop and Tk being native are pretty nice too.
You mention Tcl’s lack of language server support - just a shameless plug for my own project that’s working on fixing this: https://github.com/nmoroze/tclint/blob/main/docs/lsp.md
It’s not quite “complete” with respect to all the usual LSP features (just does linting and formatting for now), but it’s a starting point!
Well, thank you and good luck!
I don't use language servers myself personally but wanted to give you a kudos for attempting something.
Nice. Tcl scripts are widely used in wireless communication,especially base station testing.
Tcl is such fun. except for using expr to do math. i mean in other languages
a + b
in Tcl its
expr $a + $b
thats my only beef.
Then switch to using "LISP like" math in Tcl:
I haven't used TCL in a few decades and I don't miss it, but that is likely due to running it on storyserver. Worst web platform ever.
The syntax looks similar to that of fish shell