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.
It was better looking than Athena or OpenLook, which were your other two free options back then. GTK+ wasn't around, QT was mostly unknown and had license issues anyway, and Motif cost money.
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.
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 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.
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.
I am probably going to have to break down and learn/work with QT or something similar for the graphical project I am planning out and have been searching for an environment for.
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.
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.
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.
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.
Sorry, missed this at the time. But I did say I can't speak for other scripting languages. All I can say is that it was much easier than I was expecting!
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.