During the last year I was too busy to update my PHP distribution for compatibility with Mac OS X 10.6. Now my friends at local.ch and liip fixed this situation and started a new easy to install PHP distribution, which I recommend for PHP development on Mac OS X 10.6 and hopefully beyond. Check out their announcement:

http://blog.liip.ch/archive/2011/04/13/php-5-3-for-os-x-10-6-one-line-installer.html

If the stock PHP module on Mac OS X doesn’t have all the features you need, check out this distribution.

Thanks to the local.ch and liip folks for their work!

I updated Album Artwork Assistant, my album cover artwork search tool. Version 3.0 fixes some longstanding Snow Leopard compatibility issues (Quick Look is back!) and cleans up the user interface a bit.

If you haven’t used Album Artwork Assistant, here’s what people say about it:

• macupdate.com
• iusethis.com

Here are the minor UI changes:

Old:

New:

XML View Plugin has been updated. This version adds a new “View Original” option to the plugin’s menu that temporarily disables all plugins for the current page. This provides a workaround for viewing sites that use XSLT stylesheets, such as http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml.

Thanks to Stefan for his clever implementation of this useful feature.

Ever since I released my XML View Plugin for improved XML display in Safari/WebKit, people have asked for JSON support in addition to XML. I’m happy to announce that version 1.9, released today, adds this feature.

Juan Germán Castañeda Echevarría did all the work, all I had to do was to take it and integrate it into my master version, which was easy thanks to Git and GitHub.

If you already have an older version installed, the update check should pick it up. If you don’t have the plugin installed, you can get it here.

Let me know how JSON support works for you. Here’s a test link.

I’m assessing the impact of dropping 10.5 support in one of the next versions of Album Artwork Assistant. I’m basing this decision on system profile data included in the application’s software update check requests (courtesy of the awesome Sparkle framework).

About 50% of the users who enabled automatic software update checks also allowed the application to send along this anonymous system profile data. If you’re curious, it looks like this:

osVersion=10.5.8
cputype=7
cpu64bit=1
cpusubtype=4
model=iMac7,1
ncpu=2
lang=en
appName=Album Artwork Assistant
appVersion=2.7
cpuFreqMHz=2800
ramMB=2048

The data I analyzed indicates a 50/50 split between 10.5 and 10.6 systems, so dropping 10.5 support affects a fair number of people. However, the data also indicates that the split between Intel and PPC systems is 93/7, which means that the vast majority of people who still run 10.5 have computers that could run 10.6, and in my opinion they really should to get the most out of their Macs.

So I’ll make Album Artwork Assistant 10.6-only in one of the next versions, because I want to take advantage of new development technologies in Mac OS X 10.6 that make my life easier and the application better. Without support for 10.5, 7% of the users won’t be able to upgrade to future versions, but for them the current version will continue to work just fine, and the program pretty much does what it needs to do in its current form. Plus, Album Artwork Assistant is free, so nobody gets to complain anyway :-)

By the way, looking at the update request data I was surprised to see how many requests were from the AppFresh update tracking application, it seems to be very popular. I tried it too a while a go and liked it. Give it a try...

I updated my small Mac OS X application for calculating file checksums (SHA-1, MD5):

http://www.entropy.ch/software/macosx/#checksum

The new version contains a few bug fixes as well as user interface improvements, specifically new user interface elements added in Leopard.

The PHP group recently released the final version of PHP 5.3.0 and I just finished a first release of my PHP module package for Apache 2 in Mac OS X 10.5. The download link is in this forum post:

http://www.entropy.ch/phpbb2/viewtopic.php?t=4000

Try it out and let me know if there are problems.

For me, PHP 5.3 finally brings the language closer to the level of others such as Perl, Python or Ruby, where these features have been available for a long time. I really missed them in PHP, and the language sucks less now that it has them :-)

A long time ago, after Mac OS X 10.5/Leopard came out, I tried to update my PHP distribution for the new OS, but I ran into difficulties building the Apache module as 4-way universal binary, which is required on Leopard. I never found the time to resolve these issues and my PHP package was practically abandoned after some betas.

Now my friend Joachim Fornallaz, sponsored by Straumann AG, did all the work of updating my build system, many of the libraries needed for the extensions, and the PHP sources. The result is an up to date 5.2.9 package with most, but not all, of the usual extensions present (PDFLib lite is currently missing, for example).

Read the details in this longer announcement in the user forum:

http://www.entropy.ch/phpbb2/viewtopic.php?t=3937

It includes some thoughts on how to prevent the long delays between releases of this distribution in the future.

The download link to the latest release of the package is in this posting:

http://www.entropy.ch/phpbb2/viewtopic.php?p=12985#12985

The PHP group will soon release the next version of PHP, 5.3, which adds many exciting new features to the PHP language. It’s currently in Release Candidate status and for those of you who would like to experiment with this version on Mac OS X 10.5, I built a different package. The details are here:

http://www.entropy.ch/phpbb2/viewtopic.php?t=3949

I would appreciate lots of testing (and feedback in the forum), especially of the installer package, because that is all new for Leopard. Please read the forum threads linked above thoroughly and make sure you’re running the latest version of the packages before reporting problems.

I just published a free new Mac OS X application. Say Hello to Album Artwork Assistant :-)

Album Artwork Assistant finds album cover artwork on the Internet and adds it to music track files in iTunes. Other tools like it exist, but none of them worked the way I wanted, or they cost too much.

Feel free to try it out if you need something like this, and let me know if you find any bugs.

Update: As noted in the comments, I should mention that the program requires Mac OS X 10.5.

Now that getting the Address Book data is so fast, I decided to add autocompletion to my hispeedSMS widget using Autocompleter.Local from script.aculo.us:

I wrote a small Perl script to convert the Address Book database sqlite3 query result into JSON. From the widget I run the script with widget.system() and feed its output to eval(). This gives me an array of items exactly the way Autocompleter.Local needs it.

One annoying thing which is still broken on Leopard is that widget.system() sometimes truncates the output of commands at around 4000 bytes. That’s not a lot if you have an Address Book with many entries. As a workaround I had to send the Perl script’s output to a file and read that file with an XmlHttpRequest and a file:// URL.

My hispeedSMS Widget, which is now at version 1.13, needed yet another fix for full Leopard compatibility.

One of my users reported that the Address Book metafiles with people’s mobile phone numbers were in a different location on his machine.

The old location was $HOME/Library/Caches/com.apple.AddressBook/MetaData. On the users’s machine, the metafiles were in $HOME/Library/Application Support/AddressBook/Metadata. It turns out that that’s also where they are on my machine, but mine had a symbolic link in the old location pointing to the new directory. This is why it worked for me but not for him.

I first wanted to fix it by changing the path in the widget code to the new directory. While looking at that directory I found a better, much faster way to read the Address Book contents from my widget. Previously I parsed the metafiles which Address Book stores for each contact. Address Book does this so that Spotlight, which operates on the granularity of entire files, can present single contact search results. These metafiles are in Apple’s plist format, they used to be in the XML variant but now they are stored as binary plists. To get at the information I used to run them through plutil and then transform them to HTML with XSLT. This process was rather slow. It took a few seconds to build the contact list popup menu.

There is of course a faster way to get this data. Address Book’s primary data store is an SQLite database and SQLlite has a command line utility for running SQL queries. I can get a list of all mobile phone numbers plus the contact’s first and last name like this:

sqlite3 $HOME/Library/App*Sup*/Add*B*/Add*B*-v22.abcddb \
"SELECT pn.zfullnumber, r.zfirstname, r.zlastname \
FROM ZABCDPHONENUMBER pn \
JOIN ZABCDRECORD r ON pn.zowner = r.z_pk \
WHERE pn.zlabel LIKE '%<Mobile>%' \
ORDER by r.zfirstname, r.zlastname;"

This produces a list:

+41 76 123 45 67|John|Doe
+41 76 111 22 33|Nom|De Plume
+41 79 444 55 66|Fix|Foxy

sqlite3’s -html output option produces HTML table rows:

<TR><TD>+41 76 123 45 67</TD><TD>John</TD><TD>Doe</TD></TR>
<TR><TD>+41 76 111 22 33</TD><TD>Nom</TD><TD>De Plume</TD></TR>
<TR><TD>+41 79 444 55 66</TD><TD>Fix</TD><TD>Foxy</TD></TR>

A bit of XSLT code converts this to the <SELECT>/<OPTION> code I need in the widget.

If you want to learn more about the Address Book database structure, you can get a full SQL dump with this command:

sqlite3 $HOME/Library/App*Sup*/Add*B*/Add*B*-v22.abcddb .dump

Here’s a package for the recently released version 8.3.0 of PostgreSQL.

Download link in the forum post.

PostgreSQL has always been a fantastic database server, and release 8.3 adds some great features. My favorites are two new data types, one for UUIDs and one for XML data. The new XML features are part of the larger goal of implementing the SQL/XML standard in PostgreSQL.

Here’s an example that uses both UUID and XML columns in a table:

CREATE TABLE foo (id uuid, data xml);

INSERT INTO foo VALUES (uuid_generate_v1(), '<items><item color="red">one</item></items>');
INSERT INTO foo VALUES (uuid_generate_v1(), '<items><item color="blue">two</item></items>');
INSERT INTO foo VALUES (uuid_generate_v1(), '<items><item color="yellow">three</item></items>');

SELECT * FROM foo;
                  id                  |                       data                       
--------------------------------------+--------------------------------------------------
 5e8a8901-afd2-4a34-b5d4-a89852e4e82e | <items><item color="red">one</item></items>
 5e8a8901-afd2-4a34-b5d4-a89852e4e82e | <items><item color="blue">two</item></items>
 5e8a8901-afd2-4a34-b5d4-a89852e4e82e | <items><item color="yellow">three</item></items>


SELECT id, XPATH('//item/@color', data) FROM foo;
                  id                  |  xpath   
--------------------------------------+----------
 5e8a8901-afd2-4a34-b5d4-a89852e4e82e | {red}
 5e8a8901-afd2-4a34-b5d4-a89852e4e82e | {blue}
 5e8a8901-afd2-4a34-b5d4-a89852e4e82e | {yellow}

Another fix was required for the hispeedSMS Widget to run on Leopard after my first update.

You can find the new version 1.12 here:

For the technically minded:

It turns out that Leopard’s XMLHttpRequest setRequestHeader() method is broken and cannot be used to set Cookie headers. The HTTP request is sent with Cookie header values from Safari instead of the ones I set.

I just updated my hispeedSMS widget for compatibility with Leopard. Actually William Harris did all the work and sent me a fix which I just had to integrate :-)

This is of interest to customers of the Swiss cable ISP cablecom.

Here’s a package for the recently released version 8.2.5 of PostgreSQL.

Download link in the forum post.