November 2008

AmpChat WxPython support

Stephen Waterbury added a WxPython client to my AmpChat example program. (Mentioned earlier in this post.)

His Mercurial repository is here.

This is still just example code, but now it's an example of multiple things:

  • how to use Twisted AMP
  • how to use Twisted with PyGTK (trivial because gtk2reactor rocks)
  • how to make WxPython's mainloop run in parallel with Twisted's using threads
  • how to write the same simple GUI program in both PyGTK and WxPython
  • how to use Mercurial to contribute to a project without commit rights in the original repo

Anyone want to contribute a PyQT or Tk version?

Programming
Python

Comments (0)

Permalink

Frustrating Python 2.6 warnings

I've been running Python 2.6 (released October 1) as the only Python on my Gentoo desktop for a few weeks. In most ways, it's the Best Python Ever. It's got per-user site-packages. It's got the multiprocessing module so you can use lots of CPU cores without thinking too hard. It's got abstract base classes. It's got binary literals. It's got ast.literal_eval, so you can safely evaluate static dicts without worrying about security. It's got other cool stuff that you can read about here.

But it constantly spews annoying deprecation warnings like this:

dripton@al ~/src/Slugathon/slugathon $ ./Connect.py
/usr/lib/python2.6/site-packages/twisted/internet/_sslverify.py:4: DeprecationWarning: the md5 module is deprecated; use hashlib instead
import itertools, md5

Or this:
dripton@al ~/src/projecteuler $ py.test test_euler86.py
===================================== test process starts =====================================
executable: /usr/bin/python (2.6.0-final-0)
/usr/lib/python2.6/site-packages/py/process/cmdexec.py:27: DeprecationWarning: The popen2 module is deprecated. Use the subprocess module.
import popen2
using py lib: /usr/lib/python2.6/site-packages/py

or even this:
dripton@al ~/src/Colossus-git/Colossus $ ant
/usr/lib/python2.6/site-packages/java_config_2/EnvironmentManager.py:15: DeprecationWarning: the sets module is deprecated
from sets import Set
/usr/lib/python2.6/site-packages/java_config_2/EnvironmentManager.py:15: DeprecationWarning: the sets module is deprecated
from sets import Set
/usr/lib/python2.6/site-packages/java_config_2/EnvironmentManager.py:15: DeprecationWarning: the sets module is deprecated
from sets import Set
/usr/lib/python2.6/site-packages/java_config_2/EnvironmentManager.py:15: DeprecationWarning: the sets module is deprecated
from sets import Set
Buildfile: build.xml
...
BUILD SUCCESSFUL
Total time: 5 seconds

If you're reading carefully, you'll notice one important fact: none of those warnings were in my code. I imported twisted, and got warnings because twisted used md5. I ran py.test, and got warnings because py.test used popen2. I ran ant, which last time I checked was a Java program, and got warnings because some Python script wrapped around the Java used sets.Set.

Of course, there's a good reason for these warnings. Python 3.0 is coming, and many of the features that trigger deprecation warnings in 2.6 will be gone in 3.0. (Well, no important functionality will truly go away, but where there are two ways to do something, sometimes they'll pick one and axe the other.) This is useful and important, but will cause pain. And the pain has already started.

Of course, I know how to silence the warnings. Temporarily:
dripton@al ~/src/Slugathon/slugathon $ python -Wignore Connect.py

Or permanently:
$ sudo vim /usr/lib/python2.6/sets.py
#import warnings
#warnings.warn("the sets module is deprecated", DeprecationWarning,
# stacklevel=2)

But it's annoying to have to do that. Especially when you didn't even realize you were running a Python program, as in the ant example above.

I predict lots of whining about this when 2.6 goes more mainstream (say, when it becomes default in Ubuntu).

Python

Comments (0)

Permalink

I'm no longer maintaining Colossus

I started Colossus in December 1997, almost 11 years ago. Yesterday I turned over leadership of the project to Clemens Katzer. That's a long time to maintain a software project, and it feels weird to me that I finally quit.

Colossus was my first large game project, my first large Java program, my first large GUI program, my first experience working on a complex game AI, and my first time managing a significant multi-programmer software project. Somehow it worked out pretty well, for the first few years. We had a pretty full-featured, stable Titan game, with somewhat dumb but working AI, and support for lots of cool variants. We had a rotating team of up to half a dozen developers at a time working on the game, and it was fun.

But then I added network play, and I didn't do a very good job. At the time there were no Java remote method libraries that had the features we needed, so I wrote everything myself with a simple string socket protocol, with lots of receiver threads. But I wasn't rigorous enough with thread synchronization, which meant walking the line between deadlock and corrupted game data. And gaining acceptable performance meant that a lot of logic that existed on the server side needed to be reproduced on the client side, but excessive coupling in the code base meant this couldn't be done cleanly and a lot of code got duplicated. I tried and tried to fix the mess, but couldn't put Humpty-Dumpty together again.

I finally decided to start over, in a better programming language (Python), with a better networking framework (Twisted), with a better overall design paradigm (game events flowing from the server to the client, using the Observer pattern to reduce coupling and allow complete reuse of the core game logic between the client and server) and with safe sane single-threaded code. Thus was born Slugathon. Unfortunately, as a new father I didn't have nearly as much free time as I did back when I started Colossus, and so Slugathon still isn't finished.

With Slugathon unfinished I felt obligated to keep maintaining Colossus, but I didn't really have my heart in it. I figured my job was to keep the project alive until a successor showed up to take it over. We had several guys on the team who were technically qualified to take over, but none seemed likely to put in the necessary amount of time on a consistent basis. Then Clemens joined, and not only submitted code for his pet features (the fun part that everyone wants to do) but started watching the bug tracker like a hawk, and talking to users about their bugs, and making special test builds so that users could test that their obscure hard-to-reproduce bugs were fixed, and adding documentation of which features went into which releases, and all the other not-fun crap that 90% of small volunteer open source projects can't find anyone to do. Around the same time, longtime contributor Peter Becker did a giant refactoring that reduced the amount of code duplication from disgusting to merely gross. And Clemens switched the server side from listener threads to NIO, reducing the total thread count from insane to merely scary.

Which meant I was no longer needed on Colossus. So I'm committing to releasing a stable, network-playable version of Slugathon by the end of 2008. And hoping that the Colossus team can continue cleaning up the mess I left them. Hopefully someday soon we'll have two stable networked Titan games instead of zero.

(By the way, I played a couple of four-human 2-AI networked Abyssal6 Colossus games this morning. It was great fun, even though both games had technical difficulties.)

Games
Programming
Python

Comments (0)

Permalink