beatworm.co.uk

There’s a handy little command line tool nestled away inside Apple’s system WiFi framework.

Apple80211.framework/Resources/airport

It doesn’t come with a man page, but --help will print a usage guide.

Leopard introduced a number of system level changes to font handling. There’s a system daemon, fontd that handles runtime font registration. Some of the new features that are implemented include on-demand font activation, on a per-application basis and system font-protection, which guards against removal or disabling certain fundamental system fonts.

There’s a couple of situations where you might need to interface with the font registry database. Sometimes the system font caches can become garbled, and require a manual flush – before leopard these could be easily found under /Library/Caches/com.apple.ATS – now they’re squirreled away under /var and managed by fontd. Font protection might stop you from legitimately manipulating certain font files; in a prepress environment you might need to replace one of the magic System protected fonts with a custom version.

There’s a command line utility provided, called ‘atsutil‘ which offers a user interface to these features. It has a fine man page.

To purge the font caches, which will fix persistant text rendering problems, you use the command atsutil databases -removeUser

To display the list of System protected fonts use the command atsutil fontprotection -files.

To globally disable the font protection feature, use the command atsutil fontprotection -off. Re-enable it with the -on switch.

Don’t remove system protected fonts, unless you are replacing them with a workable substitute.

I can’t ever remember the name of the Debian package for the library manpages, I often have the same trouble recalling the names of the OpenSSL development packages in Debian.

The openssl binary and man pages are in the openssl package.

The SSL shared libraries are in the libssl package. Similarly, the SSL headers and library man pages are in the libssl-dev package.

Now I can google bing for it.

1. Obtain S60 smartphone. I’m quite fond of my Nokia E51

2. Install Python for series 60 on your phone.

3. On a nearby OS X Leopard notebook, setup a new bluetooth serial port, type RS232. ( System preferences -> Bluetooth -> Advanced ). Call it something like ‘Bluetooth-console’. Ensure the Mac is paired with the phone.

4. In a terminal, run ‘screen /dev/tty.Bluetooth-console‘

5. Set your Mac’s bluetooth to ‘discoverable’

6. Launch the Python application you’ve just installed on your phone. Select Options -> Bluetooth Console -> Other. Choose your Mac, and then select the Bluetooth-console serial port as the device.

7. Meanwhile, back on the Mac: a python shell will start in your screen session after a small delay.

8. In the python session, “import audio”

9. In the python session, “audio.say('I never realised my phone had a built-in speech synthesizer')”

10. Fall over in astonishment.

I often travel with a laptop. I almost invariably travel with a charged mobile phone. I enjoy using the fancy multi-touch trackpad in my MacBook Pro, but an odd thing happens sometimes when I’ve put my phone down nearby on the desk; I reach automatically to try and use the phone as a computer mouse. One of those amusing peculiarities of muscle-memory and reflex that can surprise, when you’re engaged by something, within the computer, verging upon a liminal state.

It’s a slightly amusing quirk, but when I think further about it, I find plenty of reasons why it perhaps ought to work.

External mice are more useful than trackpads, although not enough use to me to justify carting one around. My phone is palm-sized, about the ideal weight, is already paired with my laptop over bluetooth, has clickable buttons all over one face, and an optical camera on the reverse. In short, it already has most of the technology needed to be a wireless optical mouse.

Most but not all. I’m a bit dubious about whether it could be done in software alone. I doubt that the lens will focus well enough to motion tracking without a special surface, and it’s completely lacking the light source, but it is almost tempting enough to try. It might be feasible with some sort of very recognisable surface, perhaps a monchrome checkerboard grid, which would be very easy to render and print.

So much for my new year resolution to write more often.

Just before I went away for Christmas, my trusty white MacBook had developed a bit of a problem with it’s keyboard. Initially this manifested as the function keys intermittently losing the ability to switch between special Mac control keys, such as brightness, eject media and what-not and normal user-programmable f-keys. Initially I thought this may be a problem with the fn key that is the toggle, but eventually the keys f1-f9 stopped working entirely. This was irritating, but didn’t really render the machine unuseable. Most of the time I use it with an external keyboard, and luckily all the defunct keys functions were duplicated in software.

The next key to go was the right Shift key. Although, of course there’s a left Shift key, for a touch-typist, this was a little harder to ignore. Although I find much to admire about Apple’s current laptop keyboard design, unfortunately user-repairability isn’t one of its many blessings. There’s no simple way to get into the top casing on a polycarbonate MacBook, it’s an expensive specialist job for a service centre.

Sensibly I’d followed my own advice when I purchased this laptop, and bought it from the always-wonderful John Lewis with their standard two-year full warranty on electrical goods. I was coming up very close to the two-year anniversary, which fell within the first week of January, itself another lucky stroke, as it meant that I’d be able to take it with me on my trip to North America, where hopefully it would hold up well enough to let me edit photos, communicate, and act as an additional entertainment for any idle moments. It managed the job fine, and as soon as I was back in the U.K. I packed it off to John Lewis for maintenance, which is something that they arranged with their usual attention to customer service. More thumbs up for John Lewis.

Which left me Mac-less, save for my rather under-spec G4 mini, which can barely read mail and a web-page at the same time, under Leopard. And so no blogging.

The two year mark was also my planned point for a new machine upgrade. Buying a machine for work, I was able to take advantage of the Apple Developer Program hardware discount. Sadly this means abandoning John Lewis to purchase direct, but now we’ve got a real Apple Store in Bristol, I think AppleCare is probably a good deal.

I figured I’d be needing a machine with better graphics hardware, to better make advantage of the already signposted future directions in OS X technology. The new ‘unibody’ Macbooks didn’t really suit, as I’ve probably got as many firewire devices as USB. Also, my recent work had been feeling the strains of my Macbook’s 13″ screen and modest integrated graphics chipset. And so I’m typing this update from my new 2.8GHz, 15.4″ MacBook Pro.

It’s mostly a great upgrade. On the positive side, it’s pretty and slim, and I’m remembering just how right the 15″ widescreen form is for me. The screen is brighter than anything I’ve ever seen, and makes other LCD displays, including my expensive monitor look washed out and dull by comparison. The new glass front is dramatically easier to clean than any laptop screen I’ve owned. The extra-large button-free trackpad is brilliant, and even the gimmicky sounding gestures have proven to be almost practical enough for regular use. The unibody shell seems rigid and light, and bringing across the now-standard Apple keyboard hardware makes a brilliant switch from the old silver PowerBook G4 style, which I frankly hated. It’s super-fast, of course; the new CPU, memory bandwidth, and fast hard drive all combining to ensure that as yet, I’ve not seen any performance stalls when many simultaneous processes grow busy.

It’s not perfect of course. Some of the positives are also negatives. The glass fronted screen is considerably more reflective than the previous gloss models, and while in practice I find that I mostly mind this far less than I’d have thought, it’s undeniably worse than my gloss MacBook.

Then there are more straightforwardly negative negatives. Like many people, I’ve found trouble with the Apple mini DisplayPort to DVI connector – the integrated NVidea 9400 graphics adaptor can’t drive my 23″ TFT without sparkly artefacts, I have to run it through the additional 9600 GT GPU to get a useful picture. It’s too pretty, in as much as it makes me fret about the wear and tear that will inevitably mar its looks over time; surely computers should be tools not jewellery? It’s slightly heavier than a MacBook, and the battery life is probably less, it’s too hard to say, the calibration as yet seems to be a bit iffy with estimates. I miss the inbuilt LED charge gauges on the battery which allowed one to check the power without having to connect the battery up, so handy when travelling with two or more. I also miss the ports on the left hand side, and find the supplied ports a bit stingy; surely they could have squeezed a couple more USB slots and a firewire 400 in somewhere? I’m not sure I need a wired ethernet anymore.

Not only that, but shortly after I’d ordered it, Apple saw fit to announce an update to the polycarbonate MacBook line, giving it a memory bus and GPU boost to inject some of the performance I was lacking, and keeping the essential firewire port in place. And then they announced iLife ‘09 would ship a mere handful of days after my new machine was dispatched. I think I’ll still enjoy all the other Pro upgrades though, and they did offer recent purchasers like me the chance to upgrade the iLife suite for just a nominal cost.

Overall I’m happy, and I’m sure all the wrinkles will be ironed out, as I adjust to life with it. It ought to keep me in the manner to which I’m accustomed for the next couple of years, at least. What was that they said about never buying the first iteration of a new Apple product line? Oh.

Ever wondered what your most used shell commands are? Here’s a very silly way I knocked up to find out mine.

history|perl -anle'$C{/\d+\s+sudo/?$F[2]:$F[1]}++;END{print map{qq|$_\[$C{$_}]\n|} sort{$C{$b}<=>$C{$a}}keys%C}'|head -10

Some people would have you believe that perl is difficult to read.

If you have a Django 1.0 deployment configured to use sqlite3, and are struggling to understand sporadic eruptions of what are clearly exceptions thrown by closing a database cursor with uncommitted work; either manage.py commands on the shell, or page requests to the application generate stack traces centered around messages like ‘Unable to close due to unfinalised statements‘ then it might be a file permissions problem.

In my case, neither my developer shell account, nor the user id of the running apache httpd processes had write permissions to the directory with the sqlite3 database file. Not immediately apparent from the wording used in the error messages.

I have some Objective C classes that I’ve built for use in a project. They are model and utility classes, and have no direct UI responsibility. To aid in automated testing and debugging, I’ve built them as a project that creates a static library. The project has a test target that runs suites of automated unit tests, and a library target that builds a C-style static library archive binary. The install configuration of this target copies the library to $HOME/lib/, and the class headers to $HOME/include/$LIBNAME.

This way when I use these classes in another project, I can just #import the headers in the sources, add the static library to the project frameworks list, add the include and lib directories to the compiler and linker search paths in the XCode target inspector, and build as normal. Build times are reduced, base classes are frozen in a stable, well tested implementation, code re-use is easier, everybody wins.

Recently I broke this happy pattern, a little perplexingly, with what I thought was a fairly innocuous piece of refactoring. I noticed that one of my classes was rather a simple set container, and its implementation really little more than a thin wrapper around NSMutableArray, with only a trivial specialisation of behaviour. As it was only used within a parent class structure, with no interface outside the library innards, it seemed a bit of overkill to have it implemented as a sizeable class. The special behaviour really boiled down to maybe two additional methods on top of the normal array interface.

I first refactored it to be a subclass of NSMutableArray, but that actually introduced more complexity. NSMutableArray is implemented as a class cluster, with an abstract API around a private hidden shadow class. In order to subclass it, you are expected to provide your own implementations of a subset of its interface. In my case, this would have made for more code than the class I was trying to replace.

Of course, Objective-C allows you to define categories on any existing classes. Categories allow you to formally define and implement additional methods onto an existing class definition at compile time. I could re-implement my class as a tiny category on NSMutableArray, removing lots of my code, and reducing the size of my library footprint and perhaps add some value by introducing NSMutableArray’s extensive interface.

Surprisingly, it wasn’t plain sailing. Coding up the category, and tweaking the library to use NSMutableArray in place of the now-redundant class was straightforward. Once the updated code passed the original test suite, it was deployed as a library. The first time I built a project using it, it crashed on startup, with an unhandled exception. I cleaned all targets and rebuilt. Same problem. I checked the library headers to confirm that the new data structures were properly defined on include. No problems there, but still a hard crash on initialisation.

The system logs had an entry for the crash; selector not recognized attached to symbols that were recognisably the new array methods from my category. Running ‘nm’ against the library file showed the symbols present, and correctly defined as a category on NSMutableArray. I was stumped. After a bit of googling, I came up with the correct solution.

It turns out that in order to link against a static library that contains Objective C categories, you need to pass the linker a special flag, ‘-ObjC’. Adjusting the build settings of my project to include this flag in the ‘Other linker flags’ entry of the target inspector fixed it so that the symbols are correctly resolved at runtime. Here is the official word, Technical Q&A QA1490.

Apple released iTunes version 8 this week, which introduced some excellent new features, such as Genius playlists, but broke the fancy perl script that I wrote to rotate my music library on my iPod touch.

While revisiting this, I took the opportunity to re-implement it, aiming to fix a few of it’s faults, most specifically the terrible performance. I decided to use Python this time around, chiefly because of the existence of appscript, an apple event bridge with a nice syntax. Python’s object and sequence semantics are a slightly better fit with AppleScript’s data models, and appscript should be a more optimal solution than Mac::Glue for sending lots of messages iteratively.

I’ve also improved the actual command recipe, using ‘duplicate’ rather than ‘add’ to build the playlist seems more efficient. Also the overhead of having to periodically build glue modules with the ‘gluemac‘ tool is removed. Sadly appscript isn’t shipped with OS X, but installing it ( at least on Leopard ), is as simple as ‘sudo easy_install appscript‘.

The concept behind the tool is the same : use a nominated playlist to synchronise the albums with the iPod, and pick a random set of albums from buckets organised by album rating. Currently it’s set to shuffle in 10 ‘2 star’ albums, 20 ‘three star’ albums, and 30 ‘four star’ albums, selected from a ‘just music’ smart playlist that filters the master library, removing all spoken word, and podcasts and other miscellany from the pool.

Here’s the source. I’m far less experienced at python than I am perl, so I wouldn’t claim it was a particularly idiomatic solution. It does run many times more quickly than the perl / Mac::Glue solution, taking a minute or so, rather than the best part of an hour. I would put all the performance gains down to the AppleEvents bridge , appscript interface, and using more efficient apple event set operations, rather than iterating over individual data.