Domain of the Bored

Last week, John Gruber and Dan Benjamin released episode 20 of their podcast, The Talk Show. It was devoted to the Apple Extended Keyboard (the Saratoga) and Apple Extended Keyboard II (the Nimitz). This renewed my interest in bringing my own Nimitz back into service using a Griffin iMate.

The Nimitz is the greatest keyboard ever made for the Macintosh. It has the best keys, the best height adjustment, the best Caps Lock key (it physically locks down!)—everything.

One of its distinctive features is a couple of pegs near the top of the keyboard—one near the Escape key, and another near the Power key.

The Saratoga had, printed under the F1 through F4 keys, the words “undo”, “cut”, “copy”, and “paste”. Because these definitions were useless (not to say confusing) to most Mac users, the Nimitz moved these labels to a plastic overlay that came with the keyboard. Those who actually needed it could put it on, which they did by hanging it on those two pegs, and everyone else could simply leave it in the box.

That overlay is even more useless today. But I think the idea of an overlay defining the function keys is a good one, especially as Mac OS X has made the function keys actually useful.

So I decided to make a new overlay.

My original plan was to distribute the EPS file for this overlay, and provide instructions on how to customize it.

After writing that it's easy to edit the file, followed by an entire page of instructions on how to do that properly, I decided it would be better to write an application to do it for you. I call this application the Apple Extended Keyboard II Overlay Generator.

I've included with the application two ready-made overlays: a replica of the classic Apple overlay; and my Mac OS X overlay. You also have the option of editing them or creating your own from scratch.

Assembly instructions (among other information) and the download are on the webpage.

For a forthcoming blog post, I was recently writing a test app that displays images. This had me once again slogging through the list of System-Declared Uniform Type Identifiers and assembling type declarations for the image types by hand.

I'm tired of doing that. So I wrote a new application called UTI Property List Helper.

This application automatically updates the CFBundleDocumentTypes and UTImportedTypeDeclarations arrays in its window with information on the types you enter, obtained from Launch Services' database of all types registered by any app on your system.

No more searching for that OSType, or leaving it out because it's too much work—this app does all the grunt work for you. Enjoy.

As some of you know, I use the multi-stroke key bindings by Jacob Rus to easily type strings such as ⌃⇧⌘⌫. I mostly use these characters in three places:

1. Correspondence with users
2. Posts here
3. Documentation

And it sure beats looking those characters up in UnicodeChecker or the Character Palette.

But I was never satisfied with the original set of key bindings that that file provides. The first problem that I had was that the arrow keys are emacs keys, not vi keys:

←	Solid Left (back)	⌃M + ⌃B
→	Solid Right (forward)	⌃M + ⌃F
↑	Solid Up (previous)	⌃M + ⌃P
↓	Solid Down (next)	⌃M + ⌃N
⇠	Dotted Left (back)	⌃M + B
⇢	Dotted Right (forward)	⌃M + F
⇡	Dotted Up (previous)	⌃M + P
⇣	Dotted Down (next)	⌃M + N

I'm a vi guy, so I wanted the hjkl arrangement for my arrows. So that was the first change I made.

I also added a bunch of characters, and reassigned some of them:

In case you're wondering about the division sign (÷): The OS already provides this as ⌥/, and always has been (all the way back to 1984). I didn't need to add it.

Also, in case you're wondering about “Apple” above: The Apple logo is ⇧⌥K, so I didn't need to add that, either. (Plus, I never use it.)

I just wrote a test app that prints the name and start-date of every process that the Process Manager will tell it about. Here it is:

ListProcessStartDates-r4.tbz

It's a command-line tool, so you'll need to run it from a terminal. Alternatively, you could wrap the executable in a service using ThisService, then use the service to insert the listing into a text document.

The code to convert the start-date of each process is ugly: Process Manager provides those dates as numbers of ticks since system startup, and I currently go through NSDate to convert those to numbers of seconds since 1970-01-01. I'm fairly sure that this answer is imprecise.

I'd prefer to get the startup time as a number of ticks since some epoch (probably 1904-01-01), so that I can do a more precise conversion. If you know of a way, please post a comment.

When I respond to a user via email, I sometimes need to refer to a file or folder in the user's file-system. Since users don't ordinarily see path separators, I use a cascading-indent syntax:

    Home
        Library
            Application Support
                Adium
                    Users
                        Default

This works well, but typing all those tabs would be a good way to get RSI in my left hand. So, today, I finally wrote a Perl script to do it for me.

cascading-indent.pl.bz2

Of course, I use this script as a service, thanks to ThisService.

One downside to using it as a service is that you can't directly use it in Mail. Mail inserts the contents of the general pasteboard (i.e., it pastes) rather than using the service-communication pasteboard. So I'll need to trampoline through TextEdit for this to work. (This is on my list of bugs to file.)

UPDATE 2008-03-14: Apple fixed this bug in Mac OS X 10.5.2. So now you can invoke it directly from Mail—no trampolining needed.

If you should have an urgent need for a flashlight, but have only an iPhone or an iPod touch with you, fear not. Now you have an iPhone flashlight.

If you're like me, you reject Leopard's new 3D-looking Dock out of hand, preferring the new 2D smoke look also introduced in Leopard. All it takes is a simple defaults command to switch the Dock from 3D to 2D mode.

I think the new 2D Dock looks a lot cooler than the Dock in Tiger, except for one part that, for me, sticks out like a sore thumb.

It's the separator between the applications and not-applications sections.

Here's what Tiger's separator looks like:

Simple; gets the job done.

Leopard, on the other hand, has a goofy-looking zebra crossing instead:

I can't have that. So I fired up Lineform and created a new separator that I think looks a lot better:

Obviously, it's modeled after the white LEDs that have replaced the black arrowheads to mean “application is running”.

In case you prefer this separator as much as I do, here's how to install it:

1. Download this image. I'll assume you downloaded it to ~/Downloads.
2. If you keep your Dock on the left or right edge of the screen, open the image in Preview and rotate it.
   • If your Dock is on the right edge, rotate the image left (⌘L).
   • If your Dock is on the left edge, rotate the image right (⌘R).
3. Rename the image file. If your Dock is on the bottom, name it separatorstraight.png; otherwise, name it separatorstraight-horizontal.png.
4. Open a second Finder window.
5. Hit ⇧⌘G and go to /System/Library/CoreServices/Dock.app/Contents/Resources.
6. Make a backup of the separatorstraight.png or separatorstraight-horizontal.png file from that folder.
7. Move (⌘-drag) the image file from ~/Downloads to the Resources folder.
8. Authenticate, if necessary.
9. Open a terminal window and killall Dock. The Dock will relaunch automatically.

I haven't made a 3D version. If you want one, post a comment. It shouldn't be too hard to make, thanks to vector graphics.

I've finished fixing number 12. Now, when you forget to answer the Turing test, your response will reappear in the comment form when the post loads.

For those of you who run Negative Turing Test on your own blag: WordPress has a bug as of both 2.1 and 2.3. Normally, when you submit a comment, WordPress sets three cookies that it uses to automatically fill in the Name, Email, and URL fields on the commenter's future visits. When a plug-in like NTT deletes the comment, WordPress fails to notice and empties out the cookies. The result is that, when NTT deletes the comment, the name, email, and URL fields come back empty. (This is true with or without the fix for number 12.)

There's nothing NTT can do about that—it's a WordPress bug that I discovered in testing the fix for number 12. I isolated the problem and have already fixed it here, and I'll soon submit a patch to the WordPress developers so that you can all have this fix as well. Until they accept it, here's the patch for WordPress 2.3.

Since 0.7, Growl has been able to detect a registration dictionary in your application when your app launches—all you have to do is put it in a file with a certain name inside your app bundle. We call this feature auto-discovery or auto-registration.

I don't think people have been taking much advantage of this feature, though, for two reasons:

1. We didn't mention it in the docs. (This would be the major reason.)
2. There was no handy-dandy editor to quickly bash out a registration dictionary file.

Sure, we can all use Property List Editor, but that's not a tool honed to the purpose. You have to rifle through GrowlDefines.h to find all the different keys you can use in the dictionary (the docs only cover the most basic set).

Well, now there's a tool honed to the purpose.

Here's beta 1 of the Growl Registration Dictionary Editor. I invite you to try it. Obvious things worth doing:

• Creating new reg dicts
• Editing existing ones
• Importing a reg dict from your saved tickets (great for porting your existing app to use auto-reg!)

Feedback will be appreciated. If you're subscribed to the Growl discussion list, you can send it there; if not, comments here are OK.

The source for the GRDE is in the Growl source repository.

If this announcement looks familiar to you, don't worry; you're not going crazy. I posted a similar message to the Growl discussion list, then decided to edit it a bit and post it here, since I know that at least several of you are Growl framework users who can put this app to good use.

Make RAM Disk is a simple app to create and mount a RAM disk on Mac OS X 10.4 or later. It encapsulates my previously-stated series of terminal commands into a tiny little app—just launch it and go.

I use my RAM disk for three things:

• Download holding area. I have Mail, Safari, OmniWeb, and Adium all set to download files to the RAM disk. If I decide I don't want to keep the download, I just leave it there until shutdown (only works on my desktop Mac).
• iShowU storage. I create a 1-GiB RAM Disk named “iShowU temp” which iShowU is set to use as its scratch disk. Using a RAM disk for this helps your recording frame rate.
• Xcode build folder. On my laptop, I symlink the project's build folder over to the RAM disk (e.g., mkdir /Volumes/RAM\ Disk/Adium-build && ln -s /Volumes/RAM\ Disk/Adium-build build). This cuts out a lot of the disk grinding that happens during a build, which I believe helps my battery life.

Enjoy!

I just released an application called Configure Application Dock Tile. The purpose of this app is to make it easy to turn an app's Dock tile off or on.

I first had the idea when making some screencasts (including the Adium screencasts). Normally, iShowU shows up in the Dock, and I don't like having that artifact in the screencast; I find it distracting. So I wrote this app to make it easy for me to turn off the Dock tile in future versions of iShowU.

(If you downloaded this earlier today, please do re-download it, as I overhauled the user interface. That's why this post disappeared in the meantime.)

This hasn't gotten anywhere near the traction that I think it deserves, so I'm announcing it here too: We've done a podcast!

While we were supposed to be attending WWDC, Colin, David, and I played hooky and went down to the Googleplex to record an episode of the Google Summer of Code podcast. The podcast is hosted by Leslie Hawthorn, who runs the GSoC program. Adium participated last year and is participating again this year.

The episode, which is available from the GSoC blog post, is very funny and gives a bit of insight into how we run our open-source project.

It's a little over 20 minutes of advice and programmer hilarity. Check it out. ☺

Spam comments blocked by Negative Turing Test in June 2007:

38,502

 unsigned short multiplierBase, multiplierPower;

The output from the accessors generator:

- (unsigned) short;
- (void) setShort:(unsigned)newShort;

- (unsigned) multiplierBase;
- (void) setMultiplierBase:(unsigned)newMultiplierBase;

- (unsigned) multiplierPower;
- (void) setMultiplierPower:(unsigned)newMultiplierPower;

This is both an advisory to you and a reminder to me. I'll be tackling this after WWDC.

I've reset the NTT counter at 26,445 spams. Once again, next month will bring another count of spams-per-month. I think I'll do this every month and establish a trend. Maybe find some free graphing software and plot a graph with the counts.

CPU Usage 0.4 creates and throws away an NSImage every time a view (one per processor) updates. This is incredibly wasteful: The application uses about 0.7% of a CPU on my system.

But I decided that I can make that faster. Profiling (thanks, Shark!) revealed that the hot spot was creating, measuring, drawing, and throwing away the attributed string that goes into the NSImage. That's not hard to optimize away: as the old doctor joke goes, “stop doing that”.

So I created a couple of branches, and went in two different directions:

• Direction A uses NSLayoutManager—specifically, one NSTextStorage, one NSLayoutManager, and one NSTextContainer for every (CPU, percentage) pair. A view can display any of 101 percentages (0–100%), so on my four-core system, this branch creates 404 storages, 404 managers, and 404 containers.
• Direction B uses an NSImage, just like 0.4 does, but keeps it around.

Both branches are written to create the (NSImage|NSTS, NSLM, and NSTC) lazily, but for testing, I added this code to force the creation of all the cached objects up front so that my time-trials would represent normal usage (that is, usage after all the objects have been created and cached):

- (void)drawRect:(NSRect)rect {
    //BEGIN TEMP
    if(!(percentageImages[0U])) {
        static BOOL isInDrawRect;
        if(!isInDrawRect) {
            isInDrawRect = YES;

            NSLog(@"Preloading percentage images for CPU %u", CPUNumber);
            NSRect tempImageBounds = [self bounds];
            NSImage *tempImage = [[NSImage alloc] initWithSize:tempImageBounds.size];
            [tempImage lockFocus];
            for(float usage = 0.0f, maxUsage = 1.01f; usage < maxUsage; usage += 0.01f) {
                [self setCPUUsage:usage];
                [self drawRect:tempImageBounds];
            }
            [tempImage unlockFocus];
            [tempImage release];
            NSLog(@"Done preloading percentage images for CPU %u", CPUNumber);

            isInDrawRect = NO;
        }
    }
    //END TEMP

    ⋮
    (The rest of -drawRect: is here)
}

That's from the NSImage branch, but the code in the NSLayoutManager branch is basically the same. (Note: tempImage is not the cached image; it's just a throwaway destination for the drawing done by -drawRect: in the inner call.)

Once I had finished this, and fully optimized both branches using Shark, the next step was to try them out and see how they fare.

I launched all three versions of CPU Usage, and then did the following:

# Watch the CPU usage of the CPU Usage processes for five minutes (300 seconds)
top -l 300 | fgrep 'CPU Usage' > top-CPU_Usage.txt      %/Volumes/RAM Disk(130)
___
# Fourth column (as determined by whitespace) is CPU usage
fgrep 221 < top-CPU_Usage.txt  | awk '{ print $4; }' > top-CPU_Usage-0.4.txt
___
fgrep 1121 < top-CPU_Usage.txt | awk '{ print $4; }' > top-CPU_Usage-NSLM.txt
___
fgrep 1118 < top-CPU_Usage.txt | awk '{ print $4; }' > top-CPU_Usage-NSImage.txt
___
# The results, in percent of one CPU
~/Python/avg.py < top-CPU_Usage-0.4.txt                   %/Volumes/RAM Disk(0)
0.671
___
~/Python/avg.py < top-CPU_Usage-NSLM.txt                  %/Volumes/RAM Disk(0)
0.667
___
~/Python/avg.py < top-CPU_Usage-NSImage.txt               %/Volumes/RAM Disk(0)
0.737

Note: For timing purposes (since top's CPU-usage display is in tenths of a second), I divided CPU Usage's sample interval by ten. Normally, it samples every 0.5 sec; the two prototypes above sample every 0.05 second (that is, ¹⁄₂₀ sec instead of ¹⁄₂ sec).

This means that to compare them to 0.4, you must divide the results by ten to adjust them back to the half-second interval that a release would have. Here are the *real* results:

0.4	0.671%
NSImage	0.0737%
NSLayoutManager	0.0667%

So CPU Usage 0.5, with the cached-NSLayoutManager behavior, will use ¹⁄₁₀ as much CPU as 0.4 does. And here's what that looks like:

Sweet!

For your enjoyment:

And an alternate version:

Created with Motivator. Choice of screenshot inspired by Gus Mueller's “viii”.

ADDED 2007-05-26: Here's a third version using a photo from thefunniest.info.

In case you ever need to graphically point out that you are being sarcastic, here's an animated GIF you can use to do that. Please copy it to your own website before use, or at least use CoralCDN, so I don't get a big bandwidth hit if the page you use it on becomes popular.

I created it using the GlassGiant neon sign generator, Core Image Fun House (which is how I created the unlit frame: by creating a “white” version with the generator, then darkening it with an Exposure Adjust filter), and GifBuilder.

Feeling creative? Here are the original lit, white, and unlit frames, in PNG format.

I just posted my second ThisService-created service: del.icio.us Info for URL. Select a URL within some text, then invoke the service, and it will open the del.icio.us info page for the URL (assuming that at least one person has bookmarked it) in your browser.

AFAIK, this is also the first pure-shell-script service.

In profiling CPU Usage, I need to get my CPUs busy so that the CPU-usage views have something to do. This means that I need a program to busy-wait.

Busy-waiting means running a tight loop that doesn't actually do anything except run. In C, the most efficient such loop is:

for(;;);

That's all well and good, but it only busy-waits a single processor. I have four, and I need 1 < n < 4 of them to be lit up so that CPU Usage has something to indicate (otherwise it will sit there showing 0-0-0-0, which doesn't make good profiling—busy processors will jump around a bit, which gives CPU Usage something to do).

Now, my first approach was to write this in Python. That's my go-to language for anything without a GUI. Here's what came out:

#!/usr/bin/env python

def busy_wait():
    from itertools import repeat
    for x in repeat(None):
        pass

import thread, sys
try:
    num_threads = int(sys.argv[1])
except IndexError:
    num_threads = 100

for i in xrange(1, num_threads): #We'll do the first one ourselves after starting all the other threads.
    throwaway = thread.start_new_thread(busy_wait, ())
busy_wait()

Looks good, right?

What was weird is that I couldn't seem to get it to max out all my processors, even with num_threads=5000. That seemed mighty suspicious.

It was then that I remembered the Global Interpreter Lock.

You see, in CPython, only one thread can be running Python code at a time. (Exceptions exist for things like I/O, of which my program contains none.) This means that my yummy multithreaded busy-wait program—being purely Python—was effectively running single-threaded.

I reimplemented the program in pure C. Not only does it run much more efficiently now (no interpreter overhead), but it also requires far fewer threads: Four threads will light up all four processors. Victory!

If you want a copy for yourself, here it is. It takes one argument, being the number of threads to spawn. It defaults to the number of logical CPUs in your machine (HW_CPU in sysctl), so if you just run it with no arguments, it will will spawn one thread per processor.