So, PyCon 2005 is winding down. Today, I attended two great talks: the annual state of Python given by Guido, and Philip J. Eby's Writing Efficient Rule-Driven Software in Python on generic functions. It's clear that if anyone's gonna bring Python closer to Lisp, it may be PJE. And not even necessarily intentionally.

Random photos from the past couple of days:

I brought some treats for us, and boy, did we treat. Magnet toys are really cool.

That ListenUp! I wrote last night? Bah. Too limited. So, in about an hour's worth of work today, I reimplemented it.

It registers to listen for all NSNotifications (by declaring an observer without a particular event name or object, it will listen for all events), and provides a nice search box for filtering down the results. Because the contents of the table view are bound to the event array (yay, Cocoa Bindings!), I even get sorting for free.

It will allow for searching on any of the dictionary values (Event Name, Time, or Message). Here's one filtering on 'Thumb':

Here's another, filtering on the time of day:

The underlying search machinery accepts regular expressions:

Days 3 and 4 were a little slower. There were some issues at work that were left in a slightly less than resolved state. So, I divided my time between working on work and Thumbscrew. I finished the internal Thumbnailer module, so it can act as a standalone. It will be communicating back with Thumbscrew via NSNotifications. Unlike Zope 2 or Zope 3 Events, NSNotifications are sent to a name rather than an Interface object, so I wrote another little app, called ListenUp! which takes an Event Name and listens for it, spitting out the contents of the NSNotification's object payload. Here's a screenshot, with Thumbnailer running in the background:

With 50 people in one room (each with a laptop) and 35 people in the other (each with a laptop), sprints can get ... warm. Bring and drink a lot of water. Coffee will dry you right out.

No offense, Yeats:

And what rough beast, its hour come round at last, Sprints towards Bethlehem to be born?

What, indeed? Donovan and I spent part of yesterday (and much of last night) improving our PyObjC app. Here's a sneak preview:

It's called MacGregor [*] and it provides for multi-document searching in saved sets. Clicking on any of the files (either in the source table or the results table) will show the details in the drawer, and double-clicking will open the file in whatever application owns that type. The search widget starts searching as soon as you start typing, and it takes regexp search terms.

I also got to do some more work with Thumbscrew, turning the thumbnailing behavior into a standalone app, with command-line options (many users wanted to be able to use Thumbscrew from the command-line as a script). It will be trivial to make Thumbscrew use it at the other end of an NSTask (so when you accidentally drag your whole iPhoto library onto Thumbscrew, you can stop the thumbnailing without force quitting Thumbscrew).

The first day was very successful. Donovan and I hacked on a PyObjC app that performs multi-document searching and allows for saving of the group of files to be searched over. It's also multi-document, so more than one search can be going on at the same time.

All this work has given me a lot of ideas for Thumbscrew, like:

• Ditch threads. Since they can't be killed cleanly, I'll use a subprocess, which involves...
• Make the Thumbnailer helper class a standalong app that will be called via NSTask to do the work, communicating with Thumbscrew over an NSPipe.
• As a side goal, I've got the Thumbnailer class mostly rewritten in ObjC as an exercise, but I found that the Python bindings for CoreGraphics were heavily simplified (to the point where it's hard to unravel exactly what steps go into CoreGraphics.CGImageImport, for instance). This caused me to consider rethinking the way I do all of my image processing, so that I'd be using all the straight Cocoa wrappers of CoreGraphics. This, heh, actually has another side benefit: Once my app is completely written using Cocoa, I could easily port the application to any language that supports it via a bridge of some kind. Like OpenMCL, or even, ObjC.

The sprinting went on well into the night; several of us came back to the Cafritz Center after dinner, and worked until midnight. The proud few who stayed around were myself, Ted Leung, Kragen Sitaker, Donovan Preston, and Phil Frost. Bob missed his earlier train, so didn't arrive until 1:30 or so.

One thing I noticed in the build output was the following:

Other Features:
  Inhibiting IPv6 canonicalization at startup.
  Compiling in support for dynamic shared object modules.
  Using the new portable dumper.
  Compiling in support for extra debugging code.
  Compiling in support for runtime error checking.
  WARNING: ---------------------------------------------------------
  WARNING: XEmacs will run noticeably more slowly as a result.
  WARNING: Error checking is on by default for XEmacs beta releases.
  WARNING: ---------------------------------------------------------

Boy, were they not kidding. I added --error-checking=none to the configure command inside carbon/build-app.sh, rebuilt, and my experience is noticeably zippier almost immediately.

New binary (47M) still with xemacs-sumo and xemacs-mule-sumo packages inside.

Finally! Thanks a million, Andrew! After rooting through a twisty little maze of online suggestions only to be stymied by the inability of the Carbon version of Emacs to display certain glyphs, and nearly giving up, I see that Andrew Choi has released the notes on building a Carbon XEmacs. Well done. And it handles UTF-8 files beautifully:

Note to self and others: don't try to follow his build instructions inside an Emacs shell buffer - it will fail.

Here's a binary (49M) with xemacs-sumo-package and xemacs-mule-sumo-package installed and interned inside the application bundle. It's had both of Andrew's patches applied as well. All built according to Andrew's notes.

So, I've moved the server over. All in one place. Things were hairy there for about 10 minutes. Sorry for any confusion or hassle.

There's a non-zero possibility I'll be moving this blog off of pyblosxom and back into zope in the near future, but that non-zero possibility is going to be influenced by a host of other factors, not limited to but including: Work on the house, work on Thumbscrew, clearing my backlog of books, clearing my backlog of woodworking projects, and how much I really care.

I don't particularly like the dynamically-run-the-whole-damn-pyblosxom-thing-each-request process (though somehow that irks me less than dynamically-run-the-whole-damn-zope-each-request process; maybe ZEO has something to do with it), and I can't be arsed to figure out the whole statically-render-the-site-but-make-comments-still-work nonsense.