Earlier quoted context omitted.
Tcl is widely used in EDA automation in general - it's not just an Intel thing. Xilinx, Synopsys, Cadence, and Mentor all use Tcl extensively, for example.
Super interesting, what's the rationale behind its use there?
Tcl 9.0
71–80 of 247 posts
Re: Tcl 9.0
#72The only time I’ve dealt with Tcl in recent memory was for some MacPorts portfile stuff. Anybody using it for something else and can speak to why you’d use it today? Genuinely curious; I don’t hate the language but can never bring myself to enjoy it either.
I use it for "expect" because it just works.
Re: Tcl 9.0
#73Earlier quoted context omitted.
i once managed to create a directory named ~ using the mirror tool written in perl. then i naively tried to remove it using "rm -r ~" and started wondering why removing an empty directory would take so long, until it dawned on me... i learned a few new habits since then. i almost never use rm -r and i avoid "*" as a glob by itself. instead i always try to qualify "*" with a path, remove files first: "rm dir/*"; and t…
I've long fantasized about a tool I call "expect" that safeguards against crazy stuff like that. It has a syntax of your expectations, functionally existing as a set of boundaries, and you can hook it to always run as a wrapper for some set of commands. It essentially stages the wrapped command and if none of the boundaries are violated it goes through. Otherwise it yells at you and you need to manually override it.…
Re: Tcl 9.0
#74Re: Tcl 9.0
#75I can't overstate my love for Tcl, yet I had only a little chance to use it when writing XiRCON IRC scripts back in the late 90's. Such an elegant language: simple, easy to learn, flexible. I call it Lisp for humans. I wish it were more popular. So glad to see that it's still alive and kicking.
Re: Tcl 9.0
#76Earlier quoted context omitted.
I've long fantasized about a tool I call "expect" that safeguards against crazy stuff like that. It has a syntax of your expectations, functionally existing as a set of boundaries, and you can hook it to always run as a wrapper for some set of commands. It essentially stages the wrapped command and if none of the boundaries are violated it goes through. Otherwise it yells at you and you need to manually override it.…
For sql specifically, “limit 2” is my default way to write “expect 1”; if it affects two rows, I know that I have screwed up, whereas “limit 1” can be wrong without my noticing.
I actually know postgres people. I should probably ask them
Re: Tcl 9.0
#77Earlier quoted context omitted.
i once managed to create a directory named ~ using the mirror tool written in perl. then i naively tried to remove it using "rm -r ~" and started wondering why removing an empty directory would take so long, until it dawned on me... i learned a few new habits since then. i almost never use rm -r and i avoid "*" as a glob by itself. instead i always try to qualify "*" with a path, remove files first: "rm dir/*"; and t…
I've long fantasized about a tool I call "expect" that safeguards against crazy stuff like that. It has a syntax of your expectations, functionally existing as a set of boundaries, and you can hook it to always run as a wrapper for some set of commands. It essentially stages the wrapped command and if none of the boundaries are violated it goes through. Otherwise it yells at you and you need to manually override it.…
Re: Tcl 9.0
#78Re: Tcl 9.0
#79Earlier quoted context omitted.
I've long fantasized about a tool I call "expect" that safeguards against crazy stuff like that. It has a syntax of your expectations, functionally existing as a set of boundaries, and you can hook it to always run as a wrapper for some set of commands. It essentially stages the wrapped command and if none of the boundaries are violated it goes through. Otherwise it yells at you and you need to manually override it.…
just to clarify, this has nothing to do with the "expect" that is the other major application of tcl other than tk?
I was just reminded of a good idea I never implemented
Re: Tcl 9.0
#80> New Notifiers: The central event handling engine in Tcl is now constructed on top of the system calls epoll or kqueue when they are available. The select based implementation also remains for platforms where they are not. This is huge! A big portion of why concurrency in Tcl was so dated and why the language was considered so non-performant was because it relied on `select` despite `epoll` and `kqueue` being availa…
another reason is that we don't know how to write fast tcl, as i inadvertently demonstrated in that thread