There are a few Tcl packages (udp, in particular) that I use in some of my programs, but are not in the collection that is normally included with ActiveState Tcl. I have tried to build the extension using MinGW for x86_64 under msys2, but when I install the extension, the Tcl interpreter crashes when I go to open a socket. I do not know if this is a compiler incompatibility or a problem with the extension. I’ve used the same sources with the BAWT Tcl distribution (it’s included there) but the interpreter is amazingly slow to start on my system (sometimes close to a minute before I see the window), whereas ActiveState is quite fast.
Is there a topic or web page somewhere that details the steps to build additional packages to work with the ActiveState Tcl/Tk distributions?
The approach depends on the version of Tcl you have, but in the end, there isn’t a way to add that module right now.
If you’re using any 8.4, or 8.5 version, or any version of 8.6 prior to 8.6.5, you can’t add to it at all now. The old TEA mechanic required pre-built binary packages served over a connection running SSL v3 or TLS 1.0. That connection is no longer secure, and the servers hosting the downloads will no longer allow the remote clients to connect. 8.6.6 to 8.6.10 have no mechanism to add packages. If you have an old version that doesn’t include a module you need as part of the installer, there is no way to add it now.
For 8.6.11, the mechanism to add packages is to fork a private copy, request the additional modules, and rebuild. https://docs.activestate.com/platform/projects/fork/
However, we need to have source code and working recipes established in order for modules to be added in this manner, and TclUDP is not available. None of the modules listed at UDP for Tcl are available yet. At some point in the future, they might be.
I was hoping to build locally using the extension source downloaded from the BAWT archives, since that does work with the BAWT build of Tcl 8.7 (beta) and 8.6.10 (and perhaps 8.6.11). I wrote my own UDP extension a few years back, but it was not well integrated into the event system, and I had a succession of drive failures that took out both my working source and the backup copies.
The application I have controls a number of network connected microcontrollers (both wired and wireless) that have various doodads attached to them (LEDs, motors, buzzers, etc.) and receives data from sensors on those devices. The desire is to trigger a script that coordinates a response to a given stimulus or set of stimuli.
The original concept is what I think of as a “Feline pinball machine”, but I have since come up with better things to do with it than to torture my cat.
If you want to build locally, you’re best to build the entire interpreter stack locally so that you have consistent tooling throughout. The consistent stack top to bottom is what The Platform offers, but your tooling and the tooling used by The Platform will be different. There are no documented processes for using a local compiler with any builds done on The Platform in a mix-n-match environment, and we don’t support that.
Is the TclUDP package available or in the pipeline for a future release? I’d vote to add it to the development queue if it’s not there already. Thanks!
There are no additional Tcl modules being worked on at the moment. That will likely happen, but not until Tcl/Tk has joined Perl, Python, and Ruby on the current generation of build servers. Moving to the newer builders will mean that Tcl can be installed using the State Tool.
I have been writing and maintaining manufacturing software framework in tcl/tk software for many years and signed up for an account with you since you closed down the teacup service. What makes Tcl/TK a good fit for this application is its native support for Expect and the ability to tie into other interfaces easily. I use the following packages for WIN32 0x86 but none of them come up in your package configuration tool:
tclodbc
tcom
math::statistics
Plotchart
Expect
mysqltcl
wpcap
smtp
Is there a way for us to work together, or will I need to compile locally like filker0?
If you are tied to Expect and tied to Windows, none of our current offerings are going to work for you.
Expect is not native to Windows. It’s best if you can cross over to using Linux or OS X if you need Expect.
The source code for the Windows port of Expect was released a decade ago. It only works on a 32-bit Windows, and needs Windows 7 or older. There has been some discussion in the Tcl community about re-implementing a new port of Expect with modern Windows tooling, but I’m not aware if that has gone further than discussions.
Yes, my point is that Tcl/TK has been the best way to run Expect on Windows, which is how a lot of Telecom equipment is manufactured. I disagree with your Windows 7 assertion. ActiveState ActiveTcl 8.6.0.0 beta-5 (32-bit) is running Expect quite well on my Windows 11 Pro version 22H2 laptop and a number of Windows 10 desktops I oversee.
Has Expect moved to Python? Maybe instead of rolling my own Tcl distribution I should convert my framework to run on Python.
Expect is Tcl. It would only move to Python if there’s a Tcl/Tk library available to Python, and indeed there are some Python modules that take the approach of requiring Expect. On Linux this is a reasonable thing to do. The native Tcl/Tk that many Linux distros include often provides an executable expect command that the Python can run. Windows does neither.
Many Pythons, no matter which operating system, also include an embedded Tcl/Tk binary library to power GUI applications (the Python Tkinter module). Normally the embedded Tcl/Tk library doesn’t include Expect code, so Python also has a “work-alike” tool called pexpect that is implemented in pure Python code. https://pexpect.readthedocs.io/en/stable/
If 8.6.0.0 beta 5 is working for you, then your code isn’t hitting the cases where there is breakage. Most are introduced by changes MSoft made in cmd.exe. Since Expect relies an off-label use of a Windows debugging library, MSoft has no duty to retain the key cmd.exe functionality as it was, and every major new version of Windows has taken the opportunity to rework cmd.exe.
WSL is Ubuntu, and probably the simplest way to get Tcl/Tk into WSL without causing conflicts is to use the Ubuntu package manager to get the Ubuntu native Tcl/Tk 8.6. You can also do “sudo apt install expect” to get the prepared Ubuntu Linux executable for expect, and that if it needs Tcl/Tk, apt install will know about the dependency.
You can’t really run a Windows version of Tcl/Tk from inside Ubuntu, but any Tcl scripts you have should be portable and run on the Linux Tcl/expect. They might need some changes, since the Windows “expect” forked away from the reference version of “expect” a long time ago, but the standard reference materials for Tcl/expect are for the current Linux version so there’s guidance available if you need it.
