THC: Tight Home Control, automation framework in Tcl(github.com)
github.com
THC: Tight Home Control, automation framework in Tcl
https://github.com/Drolla/thc
29 comments
once you recognize it, you may start to catch it in use in applications all over the place. if you ever use xilinx tools, ECAD, etc, you will see reams of tcl handling builds and project definitions
This is a blast from the past. All the SCO Open Server 5 sys admin tools are tcl, both the curses and gui front ends. I haven't touched it since then. I had no strong opinion about it either way at the time.
My impression was that Tcl used to be very popular for that sort of thing, but that it was supplanted by Lua, Python, and JavaScript.
What makes Tcl compelling for those applications?
What makes Tcl compelling for those applications?
Network effects. John Ousterhout invented tcl in part to script/implement the Magic VLSI layout tool. So it's not surprising it's spread to other EDA applications.
that I couldn't tell you. I'd personally pick lua (or damn near anything else) first. maybe just entrenched knowledge/tooling in certain industries monster codebases.
Personally, I'd pick Tcl long before Lua... but I'd pick almost anything before Lua; which I find frustrating to work with. There's a _lot_ of personal preference and "feeling" that goes into what each person likes in a language.
Also, Cisco IOS scripting.
TCL is quasi-religious. You either appreciate the simplicity and elegance of the 12 clearly ordered rules, or you think the nutbag scruffie programmer is talking to a burning bush.
I learned TCL for adding an embedded scripting language to a company's command line in 2005. I originally cast derision, but have learned to appreciate its beauty after a wrote a couple API frameworks in it. I think it has a little less magic now that lambdas and other shorthand notations are commonplace.
I learned TCL for adding an embedded scripting language to a company's command line in 2005. I originally cast derision, but have learned to appreciate its beauty after a wrote a couple API frameworks in it. I think it has a little less magic now that lambdas and other shorthand notations are commonplace.
It's still highly used in the EDA industry - almost every EDA tool is scriptable with Tcl. There are even IEEE formats that are actually Tcl dialects, e.g. UPF (Unified Power Format) for describing power related features of circuits.
Another anecdote: the MacPorts package definition files [1] are actually TCL programs. MacPorts itself is built on TCL [2]
[1] Example portfile: https://github.com/macports/macports-ports/blob/master/shell...
[2] Macports source: https://github.com/macports/macports-base/tree/release-2.7/s...
[1] Example portfile: https://github.com/macports/macports-ports/blob/master/shell...
[2] Macports source: https://github.com/macports/macports-base/tree/release-2.7/s...
[deleted]
Side effects may include dry mouth, red eyes, and core dumps.
In all seriousness, naming your product after something established and in existence ensures I am going to never be able to find it again thanks to modern SEO practices. I remember in the 90s and early 2000s everyone named their product after a non English word as a rule to make it easy to trademark your product and for customers to search it out against common words. Today, everything is just some random clever English word. There is even a restaurant in my neighborhood called "Milk" now, the madness is overwhelming.
FYI if anyone’s interested, there’s a network login hacking tool called THC Hydra that’s been around forever.
I'd agree with you, but searching for "thc github" right now on Google at least shows me this project on 7th place in the search results, even if the repository is relatively young.
I'm sure you can do something similar by adding "Milk + $city" or "Milk + $street-name" to your other example.
I'm sure you can do something similar by adding "Milk + $city" or "Milk + $street-name" to your other example.
There's a pretty good Danish music group who called themselves "The White Album", which sounds like a decent band name.
They've been operating since 2011. https://en.wikipedia.org/wiki/The_White_Album_(band)
They are incredibly difficult to find online because when you search for them the first who knows how many results are for, you guessed it, The Beatles' White Album.
They've been operating since 2011. https://en.wikipedia.org/wiki/The_White_Album_(band)
They are incredibly difficult to find online because when you search for them the first who knows how many results are for, you guessed it, The Beatles' White Album.
Just curious, why this instead of eg. home assistant?
I have not used this (yet), but there are a lot of problems with Home Assistant, with the main advantage being that it has all the integrations already written and it works for most things almost all the time.
Issues with Home Assistant as a developer of integrations:
- internal inconsistent politics slow adding new developers
- documentation is in sparse in many cases
Issues with Home Assistant as an administrator:
- The JSON database periodically corrupts itself
- The two "core" and App Daemon components can't live in the same system, must use Python venvs
Issues with Home Assistant as a user:
- There are two ways to configure integrations: via config file and via DB, which is really obtuse and difficult to version control, also sometimes the same integration is configured twice, once in each method, and sometimes parts of the integration are split
- Scripts in Home Assistant are linear steps, no branching. This is useful only in basic scenarios. There are three main ways of dealing with this with various trade-offs, and two of them are just moving the logic out of Home Assistant (python scripts, which run in a "safe" environment, and App Daemon which is unconstrained, but much heavier), with the third being using the templating system that's bolted onto the configuration system to generate dynamic conditional resolutions.
- If there is an error in your script (because, e.g., a device is offline temporarily) the script will abort instead of continuing, which means for example if your air purifier stops working due to the cloud, your local A/C stops getting set - this is not resilient
- The dashboard config (Lovelace) can be configured by the UI or config file (see above about integrations), but again it cannot be very dynamic in either scenario since the templating system cannot produce all possible configuration results, so for Lovelace's UI to be dynamic you need to write another tool to read the Home Assistant config and generate the resulting config (App Daemon can't directly do it)
- Upgrading between versions of Home Assistant generally breaks things and you have to spend time fixing them
That's most of the big issues that I can think of right now.
Issues with Home Assistant as a developer of integrations:
- internal inconsistent politics slow adding new developers
- documentation is in sparse in many cases
Issues with Home Assistant as an administrator:
- The JSON database periodically corrupts itself
- The two "core" and App Daemon components can't live in the same system, must use Python venvs
Issues with Home Assistant as a user:
- There are two ways to configure integrations: via config file and via DB, which is really obtuse and difficult to version control, also sometimes the same integration is configured twice, once in each method, and sometimes parts of the integration are split
- Scripts in Home Assistant are linear steps, no branching. This is useful only in basic scenarios. There are three main ways of dealing with this with various trade-offs, and two of them are just moving the logic out of Home Assistant (python scripts, which run in a "safe" environment, and App Daemon which is unconstrained, but much heavier), with the third being using the templating system that's bolted onto the configuration system to generate dynamic conditional resolutions.
- If there is an error in your script (because, e.g., a device is offline temporarily) the script will abort instead of continuing, which means for example if your air purifier stops working due to the cloud, your local A/C stops getting set - this is not resilient
- The dashboard config (Lovelace) can be configured by the UI or config file (see above about integrations), but again it cannot be very dynamic in either scenario since the templating system cannot produce all possible configuration results, so for Lovelace's UI to be dynamic you need to write another tool to read the Home Assistant config and generate the resulting config (App Daemon can't directly do it)
- Upgrading between versions of Home Assistant generally breaks things and you have to spend time fixing them
That's most of the big issues that I can think of right now.
I've been running HA for 4 years and I've never had it corrupt, it's been the same install as well. That said, I agree the integration configuration is a bit messy, although recent updates have made this better.
For automations and scripts, I use the built in automations for simple tasks (turn X off after Y minutes), and Javascript + Home Assistant JS + Generators for more complex automations.
For automations and scripts, I use the built in automations for simple tasks (turn X off after Y minutes), and Javascript + Home Assistant JS + Generators for more complex automations.
I had corruption problems until I bought a high quality SD card for my raspberry pi. Then, I switched to an Intel NUC with an SSD and have never had any corruption in the 2 years I have used it heavily.
The issue appears to be that it updates that JSON file isn't re-written in atomic way
Any Tcl experts here that have opinions about CI tools, specifically code formatters (like `go fmt` or python's `black`) and other testing tools for use with Tcl?
I can't find documentation on how to add a TCL wrapper for an interface to the sensors. Is this abstracted somehow?
I wasn't expecting this to happen.
Why not perl?
Niiiice, thc.
Kudos!