njr 3.0

These days nearly 100% of my iPod listening is podcasts, and iTunes’ iPod-syncing podcast support is decent but lacking in a few areas.

One issue that bugs me is that, after connecting my iPod, I must update podcasts then update the iPod again in order for the already-listened episodes to disappear from the iPod. While the play counts update on the first, automatic iPod sync, the associated action (removing the corresponding episodes) doesn’t happen until you do another podcast update.

Another issue is the update timeout—after a few days if you haven’t played an episode of a podcast, it’ll stop updating. For people like my father who abandon their iPod for months at a time (hi, Dad!) it is a great bandwidth-conserving idea, but for me, with video podcasts and a non-video iPod, I like to accumulate episodes to watch when I’m exercising at home.

One of Doug’s AppleScripts for iTunes handily solves the second issue, and I’ve written a script to deal with the first. iTunes doesn’t let you query its iPod update status, so I instead wait for iTunes to unmount the iPod. I found this script which periodically checks the iPod disk space usage, but it fails for me, probably because iSync takes a long time to often do nothing.

Embedding this bash script into AppleScript was a real pain, what with do shell script‘s many and varied limitations, as I had to remove line breaks, indentation, my use of extended globs and even the while loop, because iTunes failed to finish updating the iPod while the script was executing. I think I will be checking out the newly revived PyOSA so I can do all this in Python instead.

Download the AppleScript, unzip it and place it in ~/Library/iTunes/Scripts.

(Note: this script is only tested on my Mac with my 3G FireWire-connected iPod; it definitely won’t work if you have iPod disk mode turned on, and may not work on other configurations.)

8:37 PM | Computing, macOS
2 Comments

The biggest day-to-day annoyances I’ve had since 10.0 have been, in descending order of irritation:

• Fonts: inconsistencies between rendering paths, bad support for bitmaps (I still can’t use my favorite font in BBEdit), ATSServer hangs/crashes, silent refusal to activate, font cache corruption, worthless Font Book interface, etc.
• Disks/filesystems: HFS+ slowness, Spotlight flakiness. AFP instability, slowness and complete inability to handle concurrent accesses. Disk Arbitration flakiness. Disk imaging instability and yet more flakiness. Flaky network browsing. Still no LVM. ZFS on OS X can’t come too soon—it’s been a joy to use on Solaris.
• USB: crashy drivers (less so of late), poor transfer throughput, overly aggressive port deactivation and poor feedback when something appears to go wrong. Some of these problems might be hardware—this Intel mini doesn’t work with my external USB 2 enclosure, whereas my iBook worked fine.
• Finder (need I say more?)

Today alone I spent about an hour troubleshooting font problems. First I spent about four reboots trying, and eventually failing, to get the fonts in ~/Library/Fonts to activate. No amount of font cache trashing or safe booting fixed it; I eventually just renamed the folder and told FontExplorer X to import them, at which point everything worked… until half an hour later when Camino hung then Terminal hung (as did every other app I tried, such as Dock and LaunchBar). Turned out ATSServer was using 100% CPU in some C++ destructor. I had to SSH in from another machine to kill ATSServer, at which point everything started working again. Guess I should be glad that it worked, or something.

I wonder how bad the underlying code really is, and pray it’ll get some attention in Leopard.

7:28 PM | Computing, macOS
6 Comments

launch 1.1 is out. I started working on it back in March, but after rewriting most of the launching logic only to find out that the feature I was implementing (command-line arguments) didn’t work because of an Apple bug, I got a bit disheartened. Finally, some email prodding from Peter Hosey, the Intel mini I got last week at school (thanks to my advisor), and good old-fashioned burnout after getting back from Portland caused me to finish it up.

Changes in this version:

• -L: send “launch” (ascr/noop) event to app, bypasses automatic opening of untitled document, etc.
• -o: pass command-line arguments (still broken)
• display content type ID (UTI)
• display architecture of Mach-O files
• switched to new LSOpen APIs (now requires Mac OS X 10.4 or later)
• switched to new date formatting APIs (the old ones are deprecated)
• for compatibility with open, take app path as argument to -a
• Universal Binary, compatible with Intel Macs

Sample output demonstrating some of the new features:

% launch -f /usr/lib/libSystem.B.dylib
/usr/lib/libSystem.B.dylib: document
        type: ''        creator: ''
        architecture: PowerPC, PowerPC 64-bit, Intel 80x86, Intel x86-64
        kind: Unix Executable File
        content type ID: com.apple.mach-o-dylib
        data fork size: 7.62 MB on disk (7983880 bytes used)
        created: 9/29/06 6:50:49 PM
        modified: 9/29/06 6:50:49 PM
        accessed: 10/30/06 5:19:11 AM [only updated by Mac OS X]
        backed up: 12/31/03 7:00:00 PM

Now to crawl back into my hole and attempt to finish this paper…

5:22 AM | Computing, macOS
No Comments

WWDC was fun, if exhausting; everything went wonderfuly smoothly (ignoring the traffic on 101 driving into SF on Friday night) until my flight home, when we were delayed four hours while United maintenance drove two bolts from SFO to SJC. Joy.

For some reason I didn’t get too much out of the WWDC sessions; perhaps I picked the wrong ones to attend. The small amount of time I spent in the labs made me wish I had hung out there more. I got to meet lots of people, both among my friends and the Mac developer crowd, and have some interesting conversations—although, as usual, even with thousands of people surrounding me from time to time I felt completely isolated.

I haven’t finished organizing photos and videos yet, mainly because I’ve been so busy since I returned, Lightroom really likes a faster machine than my iBook, and my iBook died over the weekend in any case. The photos I took at the large and enjoyable #macdev dinner are here, however.

There’s now a date and Web page with the papers for the OOPSLA 2006 Dynamic Languages Symposium in Portland in October, at which I’ll be presenting the work I did on a hardware transactional memory-enabled PyPy. Half the papers are Python-related, which is rather cool.

Finally, a couple of zsh tips. The great thing about a shell with as many features as zsh is that you never stop learning about new features and ways to use them. The annoying thing is that you seem to forget things just as quickly. Until this morning as I came across a mention in the zsh book (which I highly recommend), I’d used this idiom to get all the directories under the current one:

% print ./**(/)
./bin ./eio ./inputs ./outputs ./results ./src

But this excludes the current directory, which I often want (and usually forget) to include. Instead, you can do the following:

% print ./**/  
./ ./bin/ ./eio/ ./inputs/ ./outputs/ ./results/ ./src/

which, in addition to being shorter, has more DWIMitude.

This one is probably a bit better known, but I also discovered yesterday I can get a directory history list by typing ~- followed by the tab key. Reverse the sort order with ~+. Either way, it beats typing popd repeatedly to find the directory you want.

11:20 AM | Administrivia, Computing, macOS
3 Comments

The next ten days are going to be pretty hectic, as I’ll be staying at no less than 6 different places. I’ve been cleaning up, doing laundry and packing all night, and along with my clothing and electronics I’ll be sure to take with me the most important items of all:

More info at Mike McCracken’s blog.

11:59 PM | Administrivia, macOS
1 Comment