<?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; Mac-OS-X</title>
	<atom:link href="http://gidden.net/tom/tag/mac-os-x/feed/" rel="self" type="application/rss+xml" />
	<link>http://gidden.net/tom</link>
	<description></description>
	<lastBuildDate>Fri, 02 Jul 2010 13:00:07 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1-alpha-15359</generator>
		<item>
		<title>Extracting pages from PDFs on OS X</title>
		<link>http://gidden.net/tom/2009/01/27/extract-pdf-pages/</link>
		<comments>http://gidden.net/tom/2009/01/27/extract-pdf-pages/#comments</comments>
		<pubDate>Tue, 27 Jan 2009 16:54:18 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[Programming]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[Mac-OS-X]]></category>
		<category><![CDATA[osx]]></category>
		<category><![CDATA[pdf]]></category>
		<category><![CDATA[xcode]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/?p=66</guid>
		<description><![CDATA[I need to slice and dice a lot of images from a number of multi-page PDF files, but I don't happen to have the right bit of ImageMagick installed on my MacBook Pro.  Instead, I took the slightly longer route of writing a utility to do it.

Mac OS X comes with a neat little utility called "sips" which can be used to transcode images and PDFs.  However, I haven't found any way of telling it to choose a particular page of a PDF file.  I've googled a bit on the subject, and couldn't find anything.
Of course, I could manually extract the pages using "Preview" but there's no fun in that.
ImageMagick would also usually do the trick, but I haven't installed GhostScript as part of ImageMagick, so PDF file support is fairly broken.
Anyway, extracting pages should be a fairly simple thing to do, considering OS X's drawing layer is very closely related to PDF.
I've put the code in my Subversion repository here, so you can extract the XCode project by running:
svn co http://gidden.net/svn/ExtractPagesFromPDF/
at the command-line.
The code is very basic, and doesn't handle encrypted PDFs or anything special, so treat it as "sample code".  Also, I'm no XCode/Objective-C/CoreGraphics expert by any means, so this may not be the best way of doing it!  No warranties, blah blah blah.  Use at will and at your own risk.
How to use:

Build the project in XCode
Get the executable file, "ExtractPagesFromPDF" and put it somewhere in your $PATH
ExtractPagesFromPDF myBigDocument.pdf
The subpages should be created in the current directory, with the format %04d.pdf (ie. 0001.pdf, 0002.pdf, ...).  If you have files with those names already, move them out of the way!

Now that's written, I can now use "sips", "ImageMagick", etc. to continue the processing I need to do for the project.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2009/01/27/extract-pdf-pages/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<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>30</slash:comments>
		</item>
		<item>
		<title>Mac Flight Tracker widget timezone bug</title>
		<link>http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/</link>
		<comments>http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/#comments</comments>
		<pubDate>Thu, 10 Aug 2006 20:54:07 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Techie]]></category>
		<category><![CDATA[apple]]></category>
		<category><![CDATA[bdt]]></category>
		<category><![CDATA[bst]]></category>
		<category><![CDATA[bug]]></category>
		<category><![CDATA[dashboard]]></category>
		<category><![CDATA[flight-tracker]]></category>
		<category><![CDATA[flighttracker]]></category>
		<category><![CDATA[javascript]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[Mac-OS]]></category>
		<category><![CDATA[Mac-OS-X]]></category>
		<category><![CDATA[MacOS]]></category>
		<category><![CDATA[nsdate]]></category>
		<category><![CDATA[OS-X]]></category>
		<category><![CDATA[osx]]></category>
		<category><![CDATA[os_x]]></category>
		<category><![CDATA[tiger]]></category>
		<category><![CDATA[timezone]]></category>
		<category><![CDATA[widget]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/</guid>
		<description><![CDATA[The Flight Tracker dashboard widget that comes with Mac OS X 10.4 (Tiger) seems to have a fairly major bug.  However, this bug seems to be the result of something quite obscure to do with timezones, and it only seems to manifest itself in the UK during the summer.

I've noticed this problem a few times:  specifically whenever any one of my close friends or family members flies anywhere.  This time, my mother is on her way back from San Diego to Bristol via Newark.  Thanks to the incredibly annoying terrorist attack attempt today, my dad and I were understandably concerned about flight delays, so I pulled up the Flight Tracker.  Unfortunately, the information seems completely wrong.
Turns out, the minutes are right but the hours don't relate to any of the relevant timezones.
Anyway, a little background.  Here in the UK, we have two main time scenarios:  firstly GMT, which is for all intents and purposes, UTC.  We also use BST:  "British Summer Time" which is UTC+1h, and kicks in for archaic agrarian reasons and the "Think of the children!" brigade who are convinced it'll stop traffic accidents.
While the rest of OS X seems okay and correctly uses BST, Apple's Mail.app has always strangely listed incoming mail as being sent relative to "BDT", which comes out as "British Daylight Time", which is fairly meaningless as there's no such thing.  The times are correct, but they just have the wrong abbreviation afterwards.  On researching it, this seems to be the result of bad data from the Unicode people which might have made its way into NSDate.  Anyway, it's usually just a cosmetic thing, and of little or no consequence.
I believe, however, that it's the cause of the Flight Tracker widget's problems.  To test this, I altered the widget to display the timezone, by replacing the bit in FlightTracker.js, in function formatDateForDisplay() that says
var timeStr = date.toLocaleTimeString("short");
with
var timeStr = date.toLocaleTimeString("long");
This reveals that the times are supposedly in "BDT".  I believe this might be the problem.  I think something is reinterpreting this as "Brazilian Daylight Time", which would explain the weird offsets.  I think JavascriptCore or something is referring to the same bad data as Mail.app, probably via NSDate.  I'm not a Safari hacker, and I haven't really investigated that far, so I'm not sure where the problem is.
Looking a bit deeper into FlightTracker.js, I'm not really surprised there's a problem.  The timezone calculation code is fairly messy, with comments such as:
// We're going to be stupid and hard coded about parsing the server provided date strings for now
// ??? for some reason parseInt returns 0 on this but parsefloat works ???
and
// here we do proper handling of the timezone offsets.
// We enter everything in pretending it's UTC time
// and then we convert it to miliseconds since 1970,
// add the timezone offset in miliseconds to it
// and then set this as the new UTC time
There seems to be some string hacking going on at several places to decode the data sent from FlyteComm.  The original data is reasonably well structured, with the timezone offsets being given correctly as -0700 and +0100, which presumably indicate that the times are given as local times of the departure/arrival locations, as per normal for the airline industry.
I'm not completely sure what's going on, as I'm not really set up to debug someone else's widget, especially one with weird custom controls, and barely any code comments.  It's obvious to me that the widget isn't particularly well written, and is one of those things that "just works".  It was probably hacked up for fun by a Dashboard developer, and then fasttracked to the nearest Steve Jobs keynote rehearsal.  As Steve Jobs's Dashboard demos tend to be done at MWSF and WWDC, I doubt this problem has ever really been seen at Apple.  I bet if it was a problem with Pacific Daylight Time being misinterpreted, it'd be fixed immediately!  I've done a little bit of googling, and it looks like the BDT bug has already been submitted to Apple (several times), and it's still there.
When I get a chance, I may try to debug this one further, and perhaps rewrite FlightTracker's timezone code properly using the correct offsets rather than performing nasty magic using getLocaleTimeString().
What I would prefer is that the timezone of each time is given next to the time.  Ideally, they should toggle-on-click or slowly fade between local times (to the flight) and local times to the machine, and possibly relative times ("1 hour ago", "in 53 minutes", etc.)  That would make the tool a lot more intuitive anyway.  I'd rather not reinvent the whole widget, as in all other ways, the widget's really not too bad.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/08/10/mac-flight-tracker-timezones/feed/</wfw:commentRss>
		<slash:comments>15</slash:comments>
		</item>
		<item>
		<title>X11 Colors list for Mac OS X</title>
		<link>http://gidden.net/tom/2006/08/04/x11-color-list-for-macosx/</link>
		<comments>http://gidden.net/tom/2006/08/04/x11-color-list-for-macosx/#comments</comments>
		<pubDate>Fri, 04 Aug 2006 21:29:38 +0000</pubDate>
		<dc:creator>Tom Gidden</dc:creator>
				<category><![CDATA[General]]></category>
		<category><![CDATA[Techie]]></category>
		<category><![CDATA[clr]]></category>
		<category><![CDATA[colors]]></category>
		<category><![CDATA[colours]]></category>
		<category><![CDATA[mac]]></category>
		<category><![CDATA[Mac-OS]]></category>
		<category><![CDATA[Mac-OS-X]]></category>
		<category><![CDATA[MacOS]]></category>
		<category><![CDATA[NSColorList]]></category>
		<category><![CDATA[OS-X]]></category>
		<category><![CDATA[osx]]></category>
		<category><![CDATA[palette]]></category>
		<category><![CDATA[PerlObjCBridge]]></category>
		<category><![CDATA[rgb]]></category>
		<category><![CDATA[x11]]></category>
		<category><![CDATA[x11-colors]]></category>
		<category><![CDATA[x11-colours]]></category>

		<guid isPermaLink="false">http://gidden.net/tom/2006/08/04/x11-color-list-for-macosx/</guid>
		<description><![CDATA[A friend of mine is a recent newbie Mac user, after finally succumbing to the shiny white lure of the MacBook.  As an expert Unix user, he was missing the old X11 colours list, because he can't have his terminal set up with a horrible shade of puce without having to work out the RGB values for it.

Christopher Holland has already created an OS X color list for the Resene color list which is allegedly used on many X11 windowing systems, but to be honest, I haven't encountered it before.  I last used an SGI in about 1997, and I must confess I never looked at the color selector.  It also didn't seem to include the specific wretched tincture my friend wanted.
So, rather than taking the easy route and just picking the closest match from the Apple crayons, we had to grep /usr/X11R6/lib/X11/rgb.txt instead.
To eliminate the possibility of this nightmare operation having to be done again when he finally comes to his senses and picks a normal color, I hacked together a quick bit of code to create a .clr file.
Just use the "Open..." doodah in any colour selector in Mac OS X.  It should automatically copy the file into your user's Library/Colors.]]></description>
		<wfw:commentRss>http://gidden.net/tom/2006/08/04/x11-color-list-for-macosx/feed/</wfw:commentRss>
		<slash:comments>-1</slash:comments>
		</item>
	</channel>
</rss>
