from __future__ import *

Kailash and Friends Kailash Kher Kaipa

I remember hearing about YAML quite some time ago, but it seems to have completely disappeared from the Python radar. However, it has become quite popular in Perl (where it's used by Module::Build for metadata) and Ruby (it's a standard feature, even). What's up with that?

I can't even find a complete YAML parser/serializer for Python. The stuff on python.yaml.org looks broken and old, and I haven't seen anything anywhere else.

The only reason I really care is that the JSAN distribution format mirrors CPAN in many ways, META.yml included, and I have to drop down to Perl or Ruby if I want to generate it programmatically! That's not right. Wasn't the progenitor of YAML a Python guy? I remember seeing him on the Twisted lists years ago. What happened?

We've (finally) updated talkingpanda.com today with a fresh new look and a new product: iBar.

iBar turns your iPod (any iPod with a screen and a dock connector) into an "ultimate bartending tool" with over a thousand drink recipes, mixing techniques, and even a couple history lessons. Like any good bar should be, it's stocked. Altogether, the Notes content adds up to over 3 megabytes (yes, that's text!) with more than 40 minutes of original, professionally recorded, audio.

Like its sibling iLingo, iBar ships with installers for Mac OS X and Windows XP/2000 (everywhere iTunes is supported) that make installation painless.

And for relevance, here's a little bit about how it's all put together:

• The Mac OS X installer was developed with Python 2.3, PyObjC 1.2, and bundled up with py2app.
• The Win32 installer was developed with Python 2.4, win32all, Tkinter, PIL and is bundled up with py2exe and then made self-contained with NSIS.
• The build scripts for the installer application actually use even more open source stuff. We use JExcelAPI to convert Excel spreadsheets to XML, and Win32::Exe to swap out the ICO resource out of win32 executables -- but no Java or Perl makes it into the redistributable :)

We're also blogging updates and podcasting some of our content, so point your NetNewsWire or Safari RSS over to Talking Panda News!

I've updated my Mac OS X port of Frozen Bubble. I updated all of the dependencies to the latest I could find (SDL_perl 1.20.3a, SDL 1.2.8 with my AltiVec patches, etc.), and now it embeds a DarwinPorts-built Perl rather than links to the /System Perl. I rewrote the port such that the Mac OS X specific changes were isolated, so the same source should run on other platforms.

The interesting part is the new build system. I'm leveraging a Makefile to do (most) everything, rather than using an Xcode project and a series of manual steps (that I don't even remember). The biggest change to the build process is that it now embeds rather than links to Perl, so it needs to create a "standalone" Perl environment. I wrote a script, scan_and_copy.pl, that throws the main script of Frozen-Bubble over Module::ScanDeps to get the list of files that it requires. It simply copies these into the Resources folder of the application bundle, along with everything else. The bootstrap code now removes everything from @INC except for '.', so it does the right thing if the dependencies are in that location. Normally, this wouldn't be enough, because there is no explicit step for bringing in all of the libraries that this depends on. However, I simply leverage macho_standalone, which copies in all dependent libraries and strips the files.

I should submit the Makefile to CPAN and call it perl2app. It wouldn't be much worse than most of the other garbage I've found in there ;)

Now I just need to figure out how to suppress that nasty feeling you get when you touch Perl again after mostly avoiding it for several years...

#macpython quote of the day:

endo: so whats python like i do have knowlege of some programming languages just wonderin what its used for, is it software?

This is painfully old news, but it seems that Tels had forked SDL_perl and released SDL_perl 1.20.3. This distribution is a hybrid of SDL_perl 2.0b2, with a mostly compatible SDL_perl 1.19 interface. Thomas Tongue forked this as SDL_perl 1.20.3a which integrates some of the Mac OS X build patches I had made when I ported Frozen Bubble.

I say mostly compatible, because it almost works unchanged with Frozen Bubble (as far as I can tell). It seems that SDL_perl 1.19 stored SDL::Surface objects as a hash reference, where they are scalar references in SDL_perl 1.20.3a. So, I had to change several lines of code that looked like this:

$surface_reference->{-surface}

To this:

${$surface_reference}

Mirroring of Subversion repositories isn't very well supported at this point. It seems that the only way to do it without filesystem access to the server is with a perl package, SVN::Mirror.

Installing SVN::Mirror was a bit troublesome. Basically you need to:

• Install Subversion >= 1.0.4
• Install the Subversion Perl bindings (make install-swig-pl)
• Install SVN::Simple from CPAN (an unlisted dependency)
• Install SVN::Mirror from CPAN (say no if it asks you about VCP)

After that, you should have a svm utility, which you can mirror your repository with. There is a documentation bug in the current version where it says that that init takes a skip_to argument. It does not. sync does, however.

In order to get the mirror going, you need to do something like this

$ setenv SVMREPOS ~/svm
$ svm init mirror/bob http://svn.red-bean.com/bob
$ svm sync mirror/bob 2

The 2 is important, because it's the skip_to argument that allows your mirror's revisions to match your repository. Don't ask. In an earlier version of svm, this number used to be 3.

To check it out, you do:

$ svn co file://$SVMREPOS/mirror/bob bob

And to update the mirror:

$ svm sync mirror/bob

I've been working on some automation scripts to take data out of excel and do useful things with it, and I hit a big stumbling block with Spreadsheet::ParseExcel. Unicode SUCKS in Perl, and Spreadsheet::ParseExcel does nothing at all to help you with that. Each cell gets its own encoding ('ucs2', '_native_' which I haven't seen, or it's simply undef.. which seems to be latin-1). Anyway, it's completely bogus, so I started shopping around for another implementation.

Andy Khan's JExcelApi does the trick and is light-years more correct and faster than the alternatives I have tried (other than the time it takes a JVM to start). Not only that, but by default the jar does exactly what I want it to do. It gets the unicode right, and everything worked perfectly the first time. My dealings with Excel files have been reduced to the following:

java -jar -Djxl.encoding=latin1 jxl.jar -xml EXCELFILE.xls

And the Python code to parse the workbook xml document from jxl looks roughly like this:

from xml.dom import minidom

def parseDocRows(doc):
    for row in doc.getElementsByTagName(u'row'):
        rowdata = [
            u''.join([x.nodeValue for x in col.childNodes])
            for col in row.getElementsByTagName(u'col')]
        if rowdata:
            yield rowdata

if __name__ == '__main__':
    import sys
    for row in parseDocRows(minidom.parse(file(sys.argv[1]))):
        print row

Thanks!

The current build procedure for Talking Panda involves taking two stub applications (Mac OS X, Win2K/XP) and replacing their resources. This is extremely easy for the Mac installer, because it's just a bunch of folders. It's actually so convenient that I use the Mac application bundle to house the majority of resources that the Windows installer uses. Unfortunately, I do have to change one in-exe resource for the Win32 installer: the application's icon.

The Win32 application icons are still created "by hand" using Axialis IconWorkshop, which I highly recommend. It understands the Mac OS X icns format and does everything in a few shortcut keystrokes. Eventually I hope to write a script to generate the Windows icons on the fly with PIL, but I had a bit of trouble trying to find updated specs for the Windows XP additions to the ICO format.

I did some research into the Microsoft Portable Executable File Format, but was unable to find any portable C or Python libraries that could create a new executable using an existing one as a template. py2exe does this, but it uses a non-portable C library. Whenever this happens, I generally turn to Perl. CPAN is pretty good about having modules to read/write various file formats (the only other Perl I've used in the past few years is for reading/writing Excel spreadsheets).

Unsurprisingly, CPAN did indeed have what I needed in a module called Win32::Exe, which has a pretty painless API. And here it is, my most recent Perl monstrosity. It takes 3 arguments, the source executable, the new icon, and the destination executable. If someone wrote an equivalent Python module, I'd love to switch, but this does the job quite nicely for now.

#!/usr/bin/perl

use Win32::Exe;
use strict;
my $exe = Win32::Exe->new(shift());
$exe->update(icon => shift());
$exe->write(shift()); 

I've ended up using Perl in a few of my otherwise Python programs just to get Excel spreadsheets (via Spreadsheet::WriteExcel).

Never again, apparently Evgeny Filatov (who must hate Perl a little more than I do) did the hard work for us by porting it from Perl: pyXLWriter. Currently, it sports all the same features as Spreadsheet::WriteExcel, except for BigFile support (7 MB+), because of the OLE::Storage_Lite dependency.