MacPython Logo from __future__ import *

buy music albums Silver Apples buy mp3 albums Tarrus Riley buy tracks mp3 Kravits buy Reaper albums mp3 buy Kravits albums music buy music Evita CD online albums mp3 Silver Apples download Madonna CD music buy tracks music Kravits download music albums Silver Apples

2005-04-17

Twisted and foreign event loops

Filed under: PyObjC, pygame, python, wxPython — bob @ 8:24 am

There's a new reactor in Twisted svn: threadedselectreactor. This reactor blocks on select() in a worker thread, so that it is easy to integrate with a foreign event loop without having to completely separate your Twisted code into its own thread. This is awesome, and mostly eliminates the need to have specific reactors for each useful foreign event loop (cfreactor, wxreactor, etc.). Especially when the existing integration reactor sucks -- wxreactor is more or less a worst-possible implementation, and the others aren't a whole lot better.

In order to integrate with foreign event loops, threadedselectreactor sports an extension to the reactor interface: interleave(waker). waker is a callable that takes a callable as an argument. Its job is to call this callable from the thread of the main event loop. So, whatever you're integrating with needs to be able to send messages from an arbitrary thread to the main thread. All of the event loops worth the fairy dust their bits are encoded on are designed to do this easily.

Other than that, the only other thing that needs to be considered is shutdown (if it matters to shut down cleanly). To do that, you can simply replace your "quit" function with an implementation that:

  • Sets up an "after shutdown" reactor system event that will call "quitRightNow" when the reactor is dead
  • Calls reactor.stop() to commence the self destruct sequence

wxPython already has wxCallAfter that works perfectly well as the waker argument for interleave, so you can Twistify a wxPython application in about six lines. Here's a full demo: doc/examples/core/threadedselect/wxdemo.py.

PyObjC has a PyObjCTools.AppHelper.callAfter that also serves as a too-trivial-to-be-true waker (coincidence? no -- I just added it). You can check out the demo from: doc/examples/core/threadedselect/Cocoa/SimpleWebClient/. The examples in PyObjC's Examples/Twisted/ have also been refactored to use this (instead of cfreactor, which should be considered dead weight).

pygame is more low-level and doesn't provide any conveniences beyond getting and posting events. So your waker should be some function that posts a USEREVENT to pygame, which you need to pick up and do something with. A minimal example of this is here: doc/examples/core/threadedselect/pygamedemo.py.

This reactor should trivially integrate with just about any event loop, including PyQt, GTK, etc. However, the margins of my blog aren't big enough to fit them all.

2005-03-11

pygame 1.7.0 for Mac OS X 10.3

Filed under: PyObjC, macosx, packman, pygame, python — bob @ 3:43 am

Pygame is a set of Python modules designed for writing games. It is written on top of the excellent SDL library. This allows you to create fully featured games and multimedia programs in the Python language. Pygame is highly portable and runs on nearly every platform and operating system.

Although the official sdist tarball isn't cut yet, I've packaged what should be pygame 1.7.0 for Mac OS X 10.3 (Panther) users. It is available from pythonmac.org packages.

This installer ships with:

pygame:
Installed to /Library/Python2.3/
pygame headers:
Installed to /System/Library/Frameworks/Python.framework/Versions/2.3/include/python2.3/
pygame examples and documentation:
Installed to /Developer/Python/pygame/
SDL with my AltiVec patches, SDL_mixer, SDL_ttf, SDL_image, smpeg:
Installed to /Library/Frameworks/

To use pygame, you will need PyObjC 1.2 or later, and you will probably want Numeric, PIL and PyOpenGL installed. All of these are also available from pythonmac.org packages.

The following improvements are especially relevant to Mac OS X:

  • Calls into nasty private Apple SPI (CPSEnableForegroundOperation) to grab GUI access if it doesn't already have it (read: no pythonw required)
  • Can now read the default font and icon out of any PEP 302 get_data compliant loader (read: py2app 0.1.8 can put pygame entirely in the site-packages.zip, and it works!).
  • Includes newer versions of all dependencies (it sure has been a long time since 1.6.0!)
  • Most surface operations should be significantly faster on G4 and G5 computers due to my AltiVec patches to SDL

As it has been quite a long time since the last release, there are pages full of bug fixes and feature enhancements. When pygame.org updates for the 1.7 release, check WhatsNew.

Note that I will not be making a Mac OS X 10.2 (Jaguar) compatible release for Python 2.3. When Python 2.4.1 is out (and probably not until there is an official distribution of it), I may build a pygame release for that.

UPDATE: I built PyOpenGL, with some ugly hacking and lots of compiling. If there was an award for having a crappy build process, I would nominate PyOpenGL, twice.

2005-02-24

Altivec Kicks Ass

Filed under: c, macosx, pygame, python — bob @ 5:07 am

I started screwing around with enhancing Ryan Gordon's AltiVec patch for SDL last weekend. I ended up spending more time on it than I should've, but I think I've optimized all of the 32bit-32bit blits. Even though my AltiVec is probably pretty naive, I'm seeing a ~3-4x speed increase over the scalar code. And the scalar code is probably about as optimized as it's going to get, with duffs, etc.

Another thing I noticed is that my G5 really, really, really beats the snot out of my G4 powerbook for this stuff. For some of the blits, the 2ghz G5 runs about 5.65x faster than the 1ghz G4. That's nearly three times as much work per cycle! This is probably due to the bus speed and memory bandwidth more than anything else, but it's impressive nonetheless.

Now I really want a G5 powerbook. Even if it were clocked at 1ghz like my current G4, it seems like there would still be a large difference in performance.

Once I clean up the patch and do some more testing (read: hopefully this weekend), I'll do a release of pygame that will include this enhanced version of SDL. pygame is overdue for an update, anyway.

2005-01-07

from __future__ import packman

Filed under: PyObjC, packman, py2app, pygame, python — bob @ 6:44 am

For quite some time I've been neglecting my packman repository. I find it hard to make time and the infrastructure for maintainers and users alike are quite archaic.

Ideally I would like to move everything over to using Apple's installation tools with .mpkg based distributions. That, along with replacing some ugly distribution scripts in PyObjC, were why I wrote py2app's bdist_mpkg command. This opens up several doors and has a few immediate advantages:

  • Installer can authenticate. packman can't. Several packages need this, especially those requiring headers. The current PackageManager UI requires the user to drop to shell and change permissions on these folders in a very obnoxious and unintuitive way.
  • Installer creates receipts.
  • Installer packages are standard. Other things use them. For example, SDL, a dependency of pygame, is already available in .pkg format from the source. That means less maintenance and more accountability.
  • Installer (as of Mac OS X 10.3, anyway) can safely detect certain kinds of dependencies, where packman runs arbitrary code (uh oh!).
  • Some people don't like the PackageManager UI. These people could download the packages themselves and simply double-click to install (though they would have to manage dependencies themselves).
  • Installer can allow the user to customize an installation (to disable installation of scripts or documentation, for example). bdist_mpkg already organizes packages in a manner suitable for this.
  • Installer will show important information such as the License and ReadMe before installation.
  • installer can alternatively be used (but this does require authentication) for a hassle-free installation, or when installing by command-line (think ssh).
  • Installer is understood by Apple's tools. Think custom installation DVDs, Mac OS X Server, Apple Remote Desktop, Apple's internal build process, etc.
  • Installer may be improved in future versions of Mac OS X, which means that the packman infrastructure would get an upgrade for free (well, cheap).
  • Using bdist_mpkg, packman could "record" (not perform) an installation so that it may be performed later or elsewhere. For a given package, packman would download it and all of its dependencies and create a self-contained .mpkg for simple installation and transport. People who have broadband at work or school and dial-up at home would probably be particularly fond of this feature.

... Of course, even after this is developed, it's no promise that I'll have a long-term interest in maintaining my own repository. However, with this kind of infrastructure and the right tools, I think that someone else (hopefully several others) will!

2004-01-09

SolarWolf 1.4 on OS X

Filed under: pygame, python — bob @ 9:12 pm

I've packaged up Pete's latest version of SolarWolf for OS X. It should work on 10.2 and 10.3 and should not have any external dependencies (even Python). This version adds some new items, mines, and all new graphics. It also seems like the starting position of your ship is less deterministic, but maybe I was just distracted by the new sprites :)

Until the SolarWolf page is updated: SolarWolf-1.4.dmg (4.3mb)

Powered by WordPress