My two weeks off from work have come to an end. I didn’t go anywhere, as I like to do on my vacations, due to various (uninteresting) concerns (which I will not relate here). I did do a bit of programming for fun, though.
Twisted has had a telnet protocol implementation forever. It is pretty lame, though. It makes you format outgoing IAC and such yourself, it doesn’t handle \r\0 properly, it’s got all kinds of abstraction leaks, and it has no unit tests. So I wrote a new one. And tests for it. Actually I wrote the tests, then the protocol. Hooray test driven development. The new code is still in my sandbox until the backwards compatibility issues get worked out.
This provides a moderately high-level API for manipulating a vt102-compatible terminal. For example, the cursor can be positioned, scroll regions can be defined, the character set can be changed, etc. Together with the improved telnet implementation, this gives a server a convenient way to manipulate the display of a dumb client.
Twisted has had a subpackage named “manhole” for a long time. A manhole in a Twisted application gives you an interactive Python prompt inside that application, as it runs. The state of the program can be inspected and modified using arbitrary Python code. This is quite powerful, and worked pretty well. One could connect to it via PB using the Gtk client, or via telnet. Unfortunately, the Gtk client is not conducive to shared debugging, and the telnet version was uncomfortable to use, since it lacked line editing features. Using the improved telnet implementation and the vt102 protocol, I wrote a replacement for the telnet part of this that supports line editing, line history, and syntax coloring. All using just a telnet client. It can also be hooked up to stdin, making a reactor-friendly readline-replacement. Since Twisted includes an SSH server, this can all be hooked up to that, too.
I’ve been trying to write a particular game for a number of years now. It involves some amount of space travel, so of course I need a way to model bodies moving through space with some accuracy. This involves handling gravitational effects. I’ve written n-body gravitation simulations before, but they were all in crummy languages I’d rather not use any more, or dead slow. This time, I used the opportunity to learn a few things about Numarray, and implemented the simulation with no Python loops. It’s probably still not fast enough to use, but it’s a lot closer than any of my other Python attempts. (Also it’s just a dumb geometric solution instead of a smart integral solution, oh well).
A simple little octree implementation. radix has been fiddling with 3d graphics lately. He wanted an octree to speed up visibility culling. So I wrote one. It was fun struggling to remember high school geometry. Since I’d just finished playing with numarray, I threw in some uses of it here, too. One thing that was frustrating was that I couldn’t find a cross product function in numarray. I know I must be missing something. How could there not be a cross product function?