<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	xmlns:series="http://unfoldingneurons.com/"
	>

<channel>
	<title>Tom Gidden &#187; perl</title>
	<atom:link href="http://gidden.net/tom/tag/perl/feed/" rel="self" type="application/rss+xml" />
	<link>http://gidden.net/tom</link>
	<description></description>
	<lastBuildDate>Sun, 01 May 2011 10:35:37 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>MySQL and PDO on OS X Leopard, Intel</title>
		<link>http://gidden.net/tom/2008/06/30/mysql-and-pdo-on-os-x-leopard-intel/</link>
		<comments>http://gidden.net/tom/2008/06/30/mysql-and-pdo-on-os-x-leopard-intel/#comments</comments>
		<pubDate>Mon, 30 Jun 2008 14:35:05 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Techie]]></category>
		<category><![CDATA[apache]]></category>
		<category><![CDATA[dbd::mysql]]></category>
		<category><![CDATA[dbi]]></category>
		<category><![CDATA[leopard]]></category>
		<category><![CDATA[Mac-OS-X]]></category>
		<category><![CDATA[OS-X]]></category>
		<category><![CDATA[pdo]]></category>
		<category><![CDATA[pdo_mysql]]></category>
		<category><![CDATA[perl]]></category>
		<category><![CDATA[php]]></category>
		<category><![CDATA[universal]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/?p=53</guid>
		<description><![CDATA[(NOTE: Make sure you read the comments for this post, as there's a better way to get around the 64-bit/32-bit problem without having to compile things. --Tom)

I don't know if I'm missing something big, but getting Perl, Apache, PHP, PDO and MySQL to play nice on my Mac OS X 10.5 install on my Intel Core 2 Duo (Penryn) MacBook Pro hasn't been easy.  This is partly thanks to Apache being compiled with x86_64 support, and Perl with i386 only.
Anyway, Googling about, I notice that others have tried this arrangement with varying degrees of success.  The easy answer is to install something like MAMP or replace the Apache and PHP installation with a custom build.
However, I prefer to keep my installation as stock as possible, and I'm not a huge fan of proprietary packaging systems like MacPorts and Fink.  Don't get me wrong: those systems do what they're meant to do, and as a long-time FreeBSD user, I appreciate the approach.  However, they don't fit into the Mac mindset too well, plus I'm too lazy to keep them up-to-date.
In other words, I want Apple to do it all for me, via Software Update where possible.  The aim is to keep the stock Apache, PHP and Perl in place, and just add stuff.
The 10.5.3 Apache install does include PDO, but it's fairly crippled: the only drivers are the SQLite ones, even though standard "mysql" support is included.  So, "pdo_mysql" will need to be installed... no problem: just install it as a module.  But which architecture?
Since 10.5.3 Apache is compiled for i386 and x86_64, it'll run by default as 64-bit, requiring the 64-bit MySQL client libraries.
However, the included 10.5.3 Perl build is compiled only for i386, so if you want to build DBD::mysql for Perl as well, you'll need 32-bit MySQL client libraries.
The MySQL 5.1 official Leopard binary isn't currently a universal build, so right now if you download a binary distribution, you have to pick either 32-bit i386, or 64-bit x86_64.  This will knacker either PHP/PDO (64-bit) or Perl/DBI (32-bit)  So, assuming we don't want to replace -- or otherwise mess with -- the stock Apache, Perl and PHP, recompiling MySQL seems the way to go: we need to build a fat MySQL with both architectures.
To do this, download the MySQL source (I'm using 5.1.25), unzip and compile with something like:

MACOSX_DEPLOYMENT_TARGET=10.5 \
CFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \
LDFLAGS='-O3 -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \
CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \
./configure \
'--disable-dependency-tracking' \
'--prefix=/usr/local/mysql' \
'--localstatedir=/usr/local/mysql/data' \
'--libexecdir=/usr/local/mysql/bin' \
'--with-comment=MySQL Community Server (GPL)' \
'--enable-thread-safe-client' \
'--enable-local-infile' \
'--with-big-tables'

make

sudo make install

You'll then probably want to do something like:

sudo -s

cd /usr/local

export MYSQL_VERSION=mysql-`mysql/bin/mysql_config --version`-osx10.5-universal

mv mysql $MYSQL_VERSION

ln -s $MYSQL_VERSION mysql

chown -R _mysql:staff $MYSQL_VERSION

cd mysql

ln -s share/mysql support-files

ln -s var data

bin/mysql_install_db --user=_mysql

I'm not sure whether this is the right procedure, but it works for me.  A lot of this will change depending on your requirements and circumstances, so don't blame me if it kills your pets.
Next up is to install the PDO_mysql module.  This is easy. Firstly, download the PHP source.  As of Mac OS X 10.5.3, the current PHP is 5.2.5, but I downloaded 5.2.6 and it seemed fine.  Unzip it, and go into the distribution directory (ie. php-5.2.6)
Then:

cd ext/pdo_mysql

phpize

MACOSX_DEPLOYMENT_TARGET=10.5 \
CFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \
LDFLAGS='-O3 -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \
CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64 -arch ppc7400 -arch ppc64' \
./configure --prefix=/usr --with-pdo-mysql=/usr/local/mysql

make

sudo make install

You might need to add the following line to /etc/php.ini (creating that file, if necessary):

extension=pdo_mysql.so

Then, restart Apache and you should have a working PDO_mysql driver.
Installing DBD::mysql for the stock Perl is a different matter.  If you just do a CPAN install, then the multiple -arch tags that the mysql_config from your new Universal build of MySQL will return are going to foul it up.  So instead, you can just build DBD::mysql for i386, as Perl is going to be running in 32-bit mode anyway.
There are probably better, easier ways of doing this, but I resorted to just doing a manual DBD::mysql build, stating the flags by hand:

perl Makefile.PL \
 --cflags="-I/usr/local/mysql/include/mysql -Os -arch i386 -fno-common" \
 --libs="-L/usr/local/mysql/lib/mysql -lmysqlclient -lz -lm"

make

sudo make install
]]></description>
		<wfw:commentRss>http://gidden.net/tom/2008/06/30/mysql-and-pdo-on-os-x-leopard-intel/feed/</wfw:commentRss>
		<slash:comments>32</slash:comments>
		</item>
		<item>
		<title>Transferred from GoDaddy to Dreamhost</title>
		<link>http://gidden.net/tom/2007/03/12/transferred-from-godaddy-to-dreamhost/</link>
		<comments>http://gidden.net/tom/2007/03/12/transferred-from-godaddy-to-dreamhost/#comments</comments>
		<pubDate>Mon, 12 Mar 2007 19:09:02 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Techie]]></category>
		<category><![CDATA[dreamhost]]></category>
		<category><![CDATA[godaddy]]></category>
		<category><![CDATA[hook]]></category>
		<category><![CDATA[hooks]]></category>
		<category><![CDATA[perl]]></category>
		<category><![CDATA[post-commit]]></category>
		<category><![CDATA[postcommit]]></category>
		<category><![CDATA[subversion]]></category>
		<category><![CDATA[svn]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2007/03/12/transferred-from-godaddy-to-dreamhost/</guid>
		<description><![CDATA[I finally got sick enough of GoDaddy to buy a Dreamhost account and transfer (nearly) everything over to that account.  Although I've only been using it for a few hours, I know I'm going to be far happier with it... especially the Subversion support.  Setting up a post-commit hook as described below has made maintenance a lot easier.

Writing off the $50 or so I spent on my GoDaddy account doesn't make me cry, and thanks to a handy coupon code, the new account only cost me about $90 for two years.
My main reasons for transferring over are:

Subversion support
SSH shell access
rsync support

I am so sick of running a slow and crappy ftp mirror to update my files, and a tedious process to upgrade WordPress and other packages.  With the above features, this is going to be a lot easier.
Dreamhost's web admin interface could be a bit quicker, but it's cleanly organised and full-featured.  Everything operates as expected, and it didn't take me long to get set up.
The only thing that took me more time than I would have liked is getting post-commit hooks set up on Subversion, so my web projects are kept up-to-date.  All I wanted was a simple svn update run in a few directories of the web tree whenever a commit is performed.  As this seems to be a frequently asked question, here's what I encountered:

Errors don't seem to be logged, so it's mainly just fumbling in the dark.
When accessed through http: (rather than file: or svn+ssh:), the hooks are run as dhapache, the web server user.
Simply tweaking the permissions of the checkouts to 777 doesn't seem to help that much.
The hook is going to be chown'ed to you, rather than to dhapache.  You could rename post-commit.tmpl, but then you'd have trouble chmod'ding it +x.
Running setuid (yick!) would get around that problem...
...if you could run scripts (as opposed to binaries) setuid'ed. (Yep, I forgot that one)
...or if you could be bothered to write them in C, or at least wrapper them with C.
It's all a moot point, because Dreamhost seem to be undoing setuid flags on a cron, or something similar.  Possibly on some form of pre-execution check by dhapache.  Not sure.

I tried putting the updates in post-commit itself, but found instead that it's far easier to put them in a CGI script and just use curl inside the post-commit instead.  I suspect the post-commit execution has a bogus environment in some way, so I hand it off to the CGI, which is easier to debug.

#!/bin/sh
/usr/bin/curl -O http://mywebhost.dreamhosters.com/_svn_update.cgi

The CGI is going to run as you, rather than as dhapache, so the setuid isn't necessary.  My CGI looks something like:

#!/bin/zsh
set -f
echo Content-type: text/plain
echo
foreach f (/home/mywebhost/svn/_live/*) {
        /usr/bin/svn update $f
}

Now all I need to do is put a bunch of checkouts into ~/svn/_live, and symlink them into my web directories where necessary.  I've also thrown in my zshrc file for luck.
I've chosen to use file:/// checkouts rather than http:// for performance, so it's probably best not to try to use them as read-write checkouts... mixing protocols when using hooks is not fun in my experience. Currently, this updates all checkouts if one of them changes, which isn't particularly efficient.  I'm going to rewrite it using $1 instead.
I'm sure there's probably a better way of doing all of this, without the intermediate kerfuffle, but this works fine for now.
UPDATE (March 16, 2007):  I had another play with it.  I think it's possible to get the apache user (dhapache) to correctly perform an svn update on a checkout owned by dhapache, but it doesn't do exactly what I want... I really want the checkouts executed by my user, for various reasons.  I also tried some other approaches.
Anyway, I reverted back to the old idea: that of using CGIs, and using $1 to determine the repository in question.  I've rewritten the script in Perl (and the corresponding hook), so I can use regular expressions to untaint the parameters.  I'd usually pick Perl for an obvious scripting job like this, but PHP would work fine too.
The real overhead is filesystem performance, rather than the CGI call.  As DreamHost uses an (obviously overloaded) NFS setup internally, Subversion updates are slowwww (at least this week), even when using file:///.  So, fixing the script to only update the specific repository has sped it up a bit.
Incidentally, this script could easily fail dirtily if run at the same time as other stuff going on.  I've had to manually run 'svn cleanup' on the _live checkouts.  Maybe locking will help...]]></description>
		<wfw:commentRss>http://gidden.net/tom/2007/03/12/transferred-from-godaddy-to-dreamhost/feed/</wfw:commentRss>
		<slash:comments>-171</slash:comments>
		</item>
		<item>
		<title>iPhoto, Flickr and EXIF munging using Perl</title>
		<link>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/</link>
		<comments>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/#comments</comments>
		<pubDate>Wed, 27 Dec 2006 18:21:00 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[albumdata.xml]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[cocoa]]></category>
		<category><![CDATA[exif]]></category>
		<category><![CDATA[flickr]]></category>
		<category><![CDATA[flickr::api]]></category>
		<category><![CDATA[geocoding]]></category>
		<category><![CDATA[geotag]]></category>
		<category><![CDATA[geotagging]]></category>
		<category><![CDATA[iphoto]]></category>
		<category><![CDATA[iptc]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[mac::iphoto]]></category>
		<category><![CDATA[metadata]]></category>
		<category><![CDATA[OS-X]]></category>
		<category><![CDATA[perl]]></category>
		<category><![CDATA[PerlObjCBridge]]></category>
		<category><![CDATA[picasa]]></category>
		<category><![CDATA[scripting]]></category>
		<category><![CDATA[xmp]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/</guid>
		<description><![CDATA[EXIF/IPTC/XMP tagging of GPS coordinates, folksonomy tags, and other goodness is a nice idea, but unfortunately, iPhoto and Flickr don't play too well together.  Couple this with the fact that any decent support those products now have is not included for photos already imported into them.  So, here are some notes resulting from some experimentation, along with the Perl code I wrote along the way.

(Note: for the rest of this post, I'll refer to all metadata stored in the image file itself such as EXIF, IPTC, XMP, etc. as "EXIF" data.  This isn't strictly correct.  However, using the term "metadata" could be confused with such data held in other files, such as iPhoto's own database.)
For Christmas, my dad bought my mum a decent photo printer: the Canon PIXMA iP5200R.  Very nice piece of kit, with good printouts, and most importantly, easy setup, with no CUPS and Windows -v- Mac issues.  Anyway, as an upshot of this, my dad wants some of my photos for building a Picasa library for her to print stuff from.  Specifically, the photos from the Caribbean holiday we had earlier in the year.
I've been playing with Picasa a bit, and I must say I love it.  It's what iPhoto should be.  It's a good deal faster for a start.  That's comparing my iBook G4 1GHz against my mum's Compaq Deskpro Pentium III 733MHz, which is a few years older.  Secondly, it doesn't use a horrible non-scalable monolithic database like iPhoto does.  Thirdly, it seems to deal with metadata a bit more sensibly.
On the downside, neither iPhoto or Picasa handle collaboration functions very well.  Both have publishing functions, and iPhoto has a read-only "sharing" function, but I mean the true sharing of photo libraries.  My mum and dad have separate computers, but they share a camera, so it would be incredibly useful to have a shared photo library which either could use.  On this count, Picasa wins slightly, because although it has no true sharing ability, there doesn't seem to be anything wrong with two copies of Picasa working on the same directory on a shared drive.  I'm not sure how it would handle conflicts though, due to the lack of locking.  For now, I'll advise my parents not to run it at the same time.
I usually manage all of my photos in iPhoto.  However, due to the lack of decent keywording and other metadata in iPhoto, I ended up adding a lot of metadata in Flickr instead.  As a result, my iPhoto library is woefully out-of-date with my Flickr library, even though it's far more complete as I only upload a subset of my photos to Flickr.  I specifically want to extract Flickr tags back into the files themselves, and ideally rip the Geotagging information I added within Flickr.
While iPhoto is drastically improved by Keyword Assistant, it doesn't store the keywords (read: tags) in EXIF form, but in its own database.  During this investigation I discovered that iPhoto does import keywords from EXIF, and also Geotagging info.  The fact that it doesn't manage EXIF is a fairly annoying flaw, and one that I hope they'll be fixing.  I've heard that Microsoft Vista now does sensible things with EXIF.  iPhoto is, quite frankly, falling far behind other solutions at this point, and I hope next month will bring a new iLife with an improved iPhoto.
So, I had a good look around the 'net for some utilities to try to clear up this mess.  I've had a play with things like Cal Henderson's Flickr::API and Dmytro Kovalov's Mac::iPhoto before, and they're not particularly mature.  Incidentally, Mac::iPhoto also seems currently broken.
Others have attempted using Applescripts.  The ones I found around the 'net are far too slow to cope with the ~8000 photo collection I have.  This is probably due to the sucky design and/or implementation of Apple Events in MacOS.
Instead, I've had a play with PerlObjCBridge, or whatever Apple's calling it.  In Perl, it's "use Foundation;".  This gives access to the Cocoa API within OS X, which I figure is probably the fastest way to manipulate Property Lists.  Since iPhoto stores at least a backup of the database in XML form (specifically Property List form) as "AlbumData.xml", we can use this to cross-reference the data.
The most critical link between my Flickr and iPhoto collection is missing.  This would be a link between each individual photo and its alter ego in the two different collections.  Since filenames aren't necessarily complete or preserved by either iPhoto or Flickr, this is relatively difficult to establish.
I've found that a reasonably good connection is between image creation time/dates.  By matching the EXIF timestamp data within the file stored by iPhoto with the EXIF data extracted from Flickr, you can get a reasonably good correlation.  At this point, it would be a nice idea to shove the Flickr URL for the image into the local EXIF data and get iPhoto to read it.  From then on, there would be an established link.
Well, I got about as far as adding the URL, tags and geocoding to the image, but I gave up when it came to getting iPhoto to read it.  There is a relatively obscure "rebuild" function in iPhoto, triggered by holding down Cmd and Opt while starting iPhoto.  This allows rebuilding of thumbnails and the binary databases (presumably) from the XML.  Unfortunately, it doesn't seem to reread the images for new metadata.  I think this would require actual modification of the AlbumData.xml file to work, which sounds like a far bigger job.
In the meantime, this proves that such a script is feasible, albeit painful.  At the moment, this is a run-once script, so it's not much use for regular usage.
SOURCE CODE:  I am supplying this code freely with the understanding that there is no warranty or guarantee.  Also, I'll go as far as to say that incorrect usage could quite easily delete your photos, destroy your Flickr account, upset Flickr, and kill your pets.  DO NOT USE THIS CODE UNLESS YOU UNDERSTAND IT COMPLETELY AND ARE WILLING TO TAKE RESPONSIBILITY FOR ANYTHING GOING WRONG.  For more details, read the README file.
The most recent version can be obtained from my Subversion repository: iphoto_flickr_exif_munge/.
I also apologise for the quality of some of the code.  It's far more experimental than I'd usually want to release, but I think it might be of use to someone like me in a similar situation.  Rather than just throwing it into the depths of my hard drive and forgetting it, I figure it's probably worth blogging.
My conclusion to all of this is that I really need to get my iBook replaced with something good enough to run Aperture or Lightroom, and then reimport the whole bloody lot.  Painful, to say the least.  I'm also hoping that Google get around to writing Picasa for the Mac.  I think I'd prefer it in the long term.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/12/27/iphoto-flickr-exif-munging/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
	</channel>
</rss>

