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 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).
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.
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.
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).
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.
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.
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.
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.
Readit News
https://github.com/antirez/picol
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.
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/
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. :-)
No, it's not. macOS does not have a standard package manager.
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.
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.
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."
Deleted Comment
Its popularity led it to being ported to other languages, Perl & Python being the big ones, but TCL Expect is the og
https://www.tcl-lang.com/software/tcltk/9.0.html
Any word on a nice binary release of it?
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!
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).
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.
Deleted Comment
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.
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!
https://www.isi.edu/websites/nsnam/ns/
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.
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.
But then - isn't that the case for other scripting languages these days? Or are they too complex and with "strings attached"?