Code by Kevin, Programming, code, business, and other pursuits
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
Site design: Skeleton
I must update my previous entry about the limitations of Python and Tkinter as a programming environment. I'm not just going to limit my future work with Python. I've decided to chuck it altogether.
Although downloads of PacketStream--which is written in Python--have been pretty good, it hasn't sold any copies yet. While sales of any brand-new product are often slow, some users have reported problems--as in, PacketStream doesn't work. They press the buttons they are supposed to press and nothing happens. That's definitely a problem.
Unfortunately, I couldn't reproduce the problem, let alone figure out how to fix it--until tonight.
I decided to go ahead and start adding a big new feature to PacketStream--one that lets you filter the network traffic you monitor to a specific port. For example, if you just want to monitor web traffic, then you can set the port to 80, the standard http network port. This feature will make PacketStream more useful in looking at specific types of network traffic.
So I got the code written for the new features, started PacketStream, pressed the button I am supposed to press, and nothing happened--just like other users have reported.
Needless to say, I found myself becoming frustrated. I tried all sorts of variations to get the program working, or at least isolate the problem, but nothing worked. PacketStream just sat there, chugging away, but not outputting any data or any error messages, either.
Finally, out of desperation, I dusted off the old prototype of PacketStream that I wrote last fall in Tcl, my main programming language. I made the same tweaks to the old prototype that I did to the Python version of PacketStream, started the program, and pressed the button.
Bingo. Beautiful network data flowing across PacketStream's main window.
Python version: doesn't work. Tcl version: works.
I'm baffled as to why one version works and the other one doesn't; both make use of similar programming techniques (specifically, opening a pipe to the external network monitoring process and reading the data in a non-buffered mode, then writing the data to the text display). The only difference I'm aware of is that the Python version uses threads--a progarmming method that runs processes in parallel--and the Tcl version doesn't. Perhaps it's some subtle bug with threading that is causing the problem; threading can be complicated, I'm told, and I'm not an expert with threads.
But I don't really care what the problem with the Python version is. I don't need to care: I have a functioning Tcl prototype that already works better than the commercially-released Python version.
Guess what version 1.1 of PacketStream will look like? Hint: It won't be written in Python.
Mind you, this is surely more a reflection on my reasonably high level of proficiency in Tcl (and lack of same in Python) than a verdict on the merits of Tcl vs. Python as languages. Nonetheless, this is the final straw in my frustration with Python. I'm going to stick with Tcl from now on, period. And that means going back and releasing PacketStream as a Tcl application.
In most cases, rewriting an application from scratch is not recommended; in fact, some programmers say it's the worst mistake a software company can make. There's definitely wisdom in that. However, in my case, the Python version of PacketStream was actually the rewrite. The prototype was done in Tcl. In re-writing PacketStream in Python, I mapped what I had already done in Tcl--what I already knew about the program's design and structures--into a different programming language.
Well, enough of that. I can do everything that I need to do, and then some, in Tcl. It will take very little time to get the Tcl version of PacketStream up to release quality. And I'm not looking back after that.