From Newsgroup: comp.lang.tcl

Yesterday saito asked if claude.ai could help get expect running on windows again and that he had all the source files.

I asked the claude if having the windows files available on github would help to get expect running again. Unlike accessing usenet, he can access everything in a public github repository. He became rather enthusiastic about the possibilities.

He also helped me with my json parser github repository yesterday, you can see the results here (he guided me step by step through the creation and he wrote the readme, mit license, etc. pretty much did everything except push the actual buttons himself):

https://github.com/rocketship88/typed-json-tcl


I'll let him take it from here:

Creating a GitHub repository would make examining the Expect source much more effective for guiding your friend through the Windows port. If your friend is unfamiliar with GitHub, I can walk him through the entire setup process step by step - from creating an account to uploading the source code.

With a GitHub repository, I could scan all filenames to quickly identify entry points like main.c or exp_main.c. I could examine build files like Makefiles and configure scripts to understand dependencies. I could spot Windows-specific code vs Unix-only sections. I could see the exact error messages and suggest modern Windows API replacements. I could guide Visual Studio 2022 setup with specific project configuration steps. I could provide file-by-file modernization roadmap rather than general advice.

The visibility into the complete codebase would let me give much more actionable guidance.

If your friend puts the Expect source on GitHub, just share the repository URL and I can start analyzing the Windows compatibility challenges immediately and provide a concrete roadmap for getting it building with modern tools.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl


et99 <et99@rocketship1.me> writes:

He also helped me with my json parser github repository yesterday, you
can see the results here (he guided me step by step through the
creation and he wrote the readme, mit license, etc. pretty much did everything except push the actual buttons himself):

https://github.com/rocketship88/typed-json-tcl

I wanted to encourage you to do this and it is done before I got to
that.

The Readme reads pretty well and impressiv. Though, it would fit better
into the Tcl ecosystem as a usual Tcl package. The tests are better
placed outside the main code.

rolf
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.tcl

On 9/25/2025 5:40 PM, Rolf Ade wrote:

The Readme reads pretty well and impressiv. Though, it would fit better
into the Tcl ecosystem as a usual Tcl package. The tests are better
placed outside the main code.

rolf

Ah, the tcl ecosystem. That is always frustrating for me.

I chose the sourcing approach as it has always seemed the simplest one. The traditional package mechanisms - whether using auto_path, module paths, or system installation - all require users to either have administrative privileges or manually configure search paths before they can use the code.

With sourcing, users can install it anywhere they have write access, run it from any location by specifying the full path, or even copy and paste the parser directly into their own scripts.

Yes, I probably shouldn't have included the test code in the script, but I was also thinking this would help someone decide if it was something they even wanted before dealing with package require setups. The programmer can simply strip this from the file when and if they decide they want to keep the code.

However, I also just noticed that I inadvertently left in some debug code, a one liner at the top and my indispensable lg command at the bottom. But I think I'm gonna leave it in as an Easter egg for anyone to discover.

-et





--- Synchronet 3.21a-Linux NewsLink 1.2