Looks like the government put up a website for one of the weirdest community service announcement I’ve seen in a while. I wonder if they intended to make it as funny as it seemed?
A story was posted on FootNotes about the 2.0 release. A number of nice comments. The 2.0.0 package has hit Mandrake cooker, and a Fink package is apparently in the works.
I’ve started work on adding support for the GTK 2.2 APIs, which shouldn’t take very long at all. I’ve updated the .defs files, which covers most of the APIs. There are some others that will require a little more work.
PyGTK 2.2 will be a drop in replacement for 2.0.0 when it is ready, just as GTK 2.2 is.
Only 5 days til I stop receiving bounces from the sobig worm! I had hoped that people would fix their mail servers, to not send out these erroneous bounces, but no such luck 🙁
I wonder when the next one will strike?
The new series of CNNNN started a couple of weeks ago. Been pretty good so far. I don’t think it is the kind of show that they could syndicate overseas though 🙂
Finally got version 2.0 of PyGTK, PyORBit and Gnome-Python out. I sent the announcements a bit further than usual this time (gnome-announce-list, python-announce, etc). Already, it is in Debian, Mandrake Cooker and there is a Win32 installer. PyGTK is also buildable/runnable on MacOS X, provided that you have an X server installed (such as Apple’s one). If you have been holding off from looking at PyGTK 1.99.x, you should definitely take a look now.
This release has been a long time in the making:
- 595 revisions to the ChangeLog (out of 670 revisions on the main branch in CVS) since branching the 1.2 bindings.
- Over 5000 lines in the ChangeLog.
- Over 3 years since branching.
The result is a binding that is a lot nicer to use, and will be much easier to maintain. It does demonstrate that you lose a lot of time when you decide to do a rewrite. At the same time, I don’t know if it would have been feasible to get from the old 1.2 bindings to where we are now in small incremental steps. I am very happy with what we have now though.
Updating the binding for GTK 2.2 (and GTK 2.4 after that) is going to be a lot easier and quicker. All the infrastructure is in place, so it is a simple matter of adding the new APIs. The 2.0 to 2.2 delta is much smaller than the 1.2 to 2.0 delta.
It is a similar story for the Gnome bindings, although we will probably skip to Gnome 2.4, since it is almost out and contains some new APIs that are interesting from a language bindings perspective. I won’t need to rewrite the CORBA bindings this time either 🙂.
Over the weekend, I did a set of releases for pygtk, pyorbit and gnome-python. These releases are pretty much what I want for the 2.0 versions (which have been a long time coming). These releases should fix up the last few remaining bugs related to running with Python 2.3, and bugs related to compiling on MacOS X. If no serious bugs are found, I’ll do 2.0 releases shortly.
Once 2.0 is done and I have branched, I can start looking at moving on to the newer APIs. Some of the things I want to do include:
- Delete the gtk.gl binding, or move it to the gtkglarea package. This library seems pretty much dead, and there is another OpenGL binding for GTK which is being actively developed, and even has a Python binding.
- Add all the new GTK 2.2 APIs to PyGTK. This shouldn’t take too long, as all the infrastructure is there now.
- Move gnome-python on to the GNOME 2.4 libraries. Given the timing of releases, its probably not worth targetting 2.2 separately.
- Delete the gnome.zvt binding. The libzvt library is pretty much dead, and VTE includes a Python binding itself.
There are a few other things I want to look at, such as Python 2.3’s new PyGILState APIs, which could potentially simplify PyGTK’s threading support a lot, and make it interact better with other threaded Python extension modules.
This does have some disadvantages, of course. I have experienced problems with 2.1.x qrunner running away and using all the CPU on occasions (a problem with temporary failures for local delivery being handled by queuing the message for immediate re-delivery). I found that the particular problem I ran into had been fixed on the HEAD branch though, which I am now running on my mail server. It should handle the higher loads though.
If you want to remove some of the intermediate steps you can use my to get mailman to call spamassassin directly. This means that list traffic will only go through MTA, Mailman and Spamassassin. It will also allow mailman to do some moderation decisions based on message scores (ie. discard messages above a particular score without moderation).