This post is about US encryption controls on open source software and what programmers need to do to comply with those regulations.
I must start with a caveat because I know practically nothing about the subject! Treat it as one person's understanding of the matter, not legal advice. I am not a lawyer, don't play one on TV or even actually know a real lawyer. I am writing this as an aid to others writing open source software in the hope it will make them aware of the concerned regulations.
A previous blog post described the representation command and its use for introspecting Tcl's internal structures for storing data. I promised a follow-up post that talked about Tcl's compiled byte code and the disassemble command for inspecting it. Well, only two years later, here is that post as promised.
In a prior post I had illustrated the use of the Tcl promise package for asynchronous computing with some examples. There we had ignored the possibility of errors and exceptions and how they are handled in promise-based code. In this post, we build on the examples in that post to illustrate how promises greatly simplify handling of errors in async code.
I had previously described an experimental implementation of promises for Tcl. On re-reading my earlier post, I was somewhat dissatisfied with the treatment there in that I did not feel it fully reflected the value of the promise abstraction, getting somewhat caught up in the details. This post takes a somewhat different approach, concentrating more on examples and refraining from going into detail about each command or method. Here I am more interested giving you a flavor of programming with promises and motivating you to explore further.
This post is obsoleted by the promise package (based on the code is this post) and by newer posts on the topic. Nevertheless it may still hold some tutorial benefit.
Other languages, from Python and Scala to C#, C++ and Java, have implementations of promises in various flavors (sometimes separated into promises and futures). Not finding one for Tcl (we cannot let Tcl lag!), I started on an experimental implementation described in this post.
Tcl has some commands that are undocumented because they are liable to change, or even be removed, at any time, even in a patch release. Nevertheless, these commands can be very useful in exploring and understanding the inner workings of Tcl and in some cases, dealing with issues related to performance or interaction with external systems like COM on Windows.
Tcl 8.6 shipped with the Tcl Database Connectivity (TDBC) API for accessing disparate SQL database implementations in a standard manner. I happened to need it for the first time recently and collected my notes into an introductory article for the benefit of those who, like me, prefer to be spoon fed.
There is no shortage of hotkey programs for Windows, many of them of high quality. And of course Windows itself allows you to define hotkeys. However, a hotkey program in Tcl is not only very simple to write, it offers the full flexibility and power of Tcl behind it. Meaning what exactly? Read on.
There are times during software development when you want to run in interactive mode with maximum privileges on a system, be God as it were. One might think running as Administrator would do it but it doesn't. To be truly omnipotent on Windows, you have to run under the LocalSystem account. It is easy enough with Tcl and this post shows you how. As a side bonus, it also describes how to inject processes into the interactive user's desktop to run under the user's account as well.
One of the strengths of Tcl is the ease of integration with other software, whether they be COM components, libraries or even executable programs that are not designed for interaction with other programs. Here we look the facilities Tcl offers related to the last of these -- running external programs and optionally interacting with them using standard I/O mechanisms.