Life with Lunchhooks

A “Sweet Solution” for iPad Tinkering

W. Clawpaws — Sat, 30 Jan 2010 22:00:00 -0800

One thing that has people up in arms about the iPad is how it limits people's freedom to tinker, and how if devices like the iPad are successful, the net effect will be to mean that a whole generation of people will grow up without ever knowing the joy and power of programming. A good example is this one by Alex Payne, where he says:

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I'd never be a programmer today. I'd never have had the ability to run whatever stupid, potentially harmful, hugely educational programs I could download or write.

The idea that you can't write cool, fun or interesting programs on your iPad (or even iPhone) does sound like something to worry about; there is just one problem with the idea—it isn't true: you absolutely can start writing programs on an iPad moments after taking it out of the box. Any child or adult can spend hours exploring the joys of programming on an iPad. Potentially, they could even write sophisticated programs that feel like they belong on the platform.

True, without access to a Mac and Apple's developer tools, you can't write native UIKit applications in Objective-C, and without paying $99 and agreeing to Apple's onerous terms (or having a friend who will build executables for you), you can't run those apps on a real iPad. But that doesn't mean you can't program on your iPad, nor does it mean that you can't write programs that feel native.

People mocked Steve Jobs when he said he had a “very sweet solution” for non-native programming the iPhone:

We've got an innovative new way to create applications for mobile devices. Really innovative.…The full Safari engine is inside of iPhone. It gives us tremendous capability.…You can write amazing Web 2.0 and AJAX apps that look exactly and behave exactly like apps on the iPhone. And these apps can integrate perfectly with iPhone services.

When Jobs announced this approach, John Gruber called it a “shit sandwich”, but later on he realized just how powerful that environment could be when he discovered mobile web apps written with PastryKit really could feel almost identical to native iPhone apps.

And it shouldn't be a surprise. Today's JavaScript is fast and powerful. You only have to look at 280 North's 280 Slides application to realize that today's web can create applications that feel full-featured. (Apple's MobileMe provides a similarly rich experience.) Yet, despite its power, people often forget JavaScript entirely when they think about environments for doing interesting computation.

A lot of the hacker types commenting on the iPad remember the days of having a machine they could understand in its entirety, and lament how that experience is being denied to a new generation of programmers—you can certainly argue that no matter how powerful JavaScript is, it is hardly the same kind of experience. I certainly remember the Sinclair ZX Spectrum, and the fun of knowing exactly how it worked from books like Ian Logan and Frank O'Hara's The Complete Spectrum ROM Disassembly. Other people had similar experiences with the Commodore 64 or the Apple //e. If a child today would like to have that experience, they can, because there are web-based emulators like jsspeccy (ZX Spectrum) and jsc64 (Commodore 64) that recreate these platforms entirely in JavaScript. A simple Google search can find many more emulators and programming environments implemented entirely within the browser.

Those same hacker types might say that the playing with virtual hardware inside a web browser is not the same as hacking on the actual device as they did on the computers of their youth. That's true, but it's also the case that an iPad or MacBook is not like a Commodore-64 or ZX Spectrum. You really can't understand the whole thing. The complexity is higher, and eventually you are going to get to a boundary that says “don't go beyond this point” (e.g., you don't need to know how we render a PDF image, just make the call and we'll do it for you).

It's nostalgic to remember the days of the Apple //e, Commodore-64, and ZX Spectrum, but those days were gone long before the iPad was conceived. Kids were already mostly uninterested in programming because there are so many other more interesting distractions on today's powerful Internet-connected machines. Games and social networking do more to keep people away from programming than not being able to build native apps for nothing on an iPad does.

Times change. There was a time when anyone could maintain everything in their car. There was a time when everyone knew where their food came from. That's rare today. If commodity computers become less open for tinkering because most people don't care about tinkering, I'll be sorry to see it happen, because I enjoy that kind of tinkering. I'll do my best to lobby to stop it from happening, but if it happens, it happens—it'll be just another trade-off we make as part of the process we call progress.

But as things stand, although the iPad isn't as tinkering-friendly as some people might like, it's erroneous to paint a picture that says it prevents people from learning about programming. Even if Apple doesn't allow any other programming environments on the iPad (something that strikes me as unjustifiable in the long term), for as long as it has a web browser, and as long as the web itself provides a powerful environment for tinkerers, one that is itself a universal machine, there will still be a lot of ways for little Sally to learn all about programming on her iPad.

We're Getting a Golf TDI

W. Clawpaws — Tue, 25 Aug 2009 23:31:00 -0700

Alvaro called us and let us know that it was possible for us to come and place an order for our car, so we went ahead placed an order and made a $500 deposit.

In terms of the product code numbers, our order was as follows:

5K149M — Golf 4-Dr 2.0L TDI Auto
5R5R — Shark Blue
4X4 — Rear Airbags
9VE — Dynaudio Sound System
9W2 — Bluetooth
P71 — Navigation
P83 — Xenon Headlamp Package
W79 — Cold Weather Package

(In other words, everything except the sunroof, which we almost never use on our current car.)

Because this is a new model, and likely to be in short supply, the odds of getting someone to sell you the car at a discount is fairly low; in fact, some dealers are likely to get greedy and try to charge a premium, so we went in only aiming to buy the car for the MSRP. Alvaro said that once they had the cars in, they'd probably be selling them for more than MSRP, but because we were preordering (and possibly because we've been by a few times), he had no problem agreeing to sell for for MSRP. (And although it took a few extra minutes for him to check with his manager, we did get that in writing.)

Alvaro also said that we were actually the first 2010 Golf order they've placed, so I guess we're at the head of the line. But now we have to wait for VW to actually accept the order; that will probably take some time, but we can wait.

Update (2009-11-19): Allocation!

One of the annoying things about getting a Golf TDI is that VW of America isn't getting many of them from Europe. The speculation is that the engine is also used in other cars with higher margins, and is in short supply, so they'd rather sell those cars than Golf TDIs.

But our dealer finally got some allocation to process Golf TDI orders, and we were at the head of the line, so ours has gone through. Our car will be made in the first week of 2010, and should arrive in the last week of February!

More cars, test driving, etc.

W. Clawpaws — Thu, 09 Jul 2009 17:57:00 -0700

In our saga to find a suitable new car, we once again hit the dealerships and drove more cars…

More Toyota “Fun”

On Friday, we went back down to the Toyota dealership. Andy seemed to be able as reluctant as ever to actually put any effort into trying to sell us anything. He actually seemed annoyed to see us, saying that they still had no Mark V Priuses.

But with a bit of arm twisting, we got to drive a lower–trim-level Prius. He only let us take it a short distance out and back—about two blocks. I drove it out and C drove it back. It wasn't very far, but it was enough for me to decide I really didn't like the driving feel of the Prius. Driving it reminded me of piloting a shuttlecraft from Star Trek. The view out of the cabin is rather strange, which contributes to the effect, and the car really felt like it wallowed rather than drove. So, the overall feeling was do not want.

So, the Prius is out. That really surprised me, because I had pretty much considered it a foregone conclusion that we'd end up with a Prius, but it just didn't resonate with me.

We also looked at a Yaris in the showroom, but Andy seemed utterly bemused that we would even look at one. He did reluctantly allow us to test-drive a Corolla (following the same short-distance test course we'd driven in the Prius). The Corolla was familiar in many ways because our current car is equivalent, but somehow the interior felt cheesy, like it was aimed at people who wanted something flashy but had to settle for what they could afford.

Trying More Hondas

Also on Friday, we went back to see Kevin at the Honda dealership. On our previous visit, we had test-driven the Fit, but had only briefly looked at the new Insight and hadn't looked at the Civic at all.

So, we got to take both the Insight and the Civic on the same fifteen-mile test drive that we had done for the Fit. Based on our experience at other dealerships, I now realize how unusual it is to be given that kind of opportunity.

Although the Insight is outwardly similar to the Prius, something about the driving experience was different. Unlike the Prius, it was a car that I could consider owning, but it wasn't without its drawbacks. Engine noise was more noticeable than the other cars, and rear visibility when reversing wasn't good. (C thought the engine noise was way beyond what she'd expect in the cheapest car on the market in 2009.)

The Civic was okay (once we got it started; after sitting on the lot for a while it had a dead battery). Yet it was also bland and unmemorable.

Driving the Mini

The next day, we went to our local Mini dealership and test-drove both the Mini Cooper and Mini Cooper S. The trunk size and (utter lack of) rear legroom killed the Mini for us. There is essentially no space in the trunk and when the driver's seat is properly positioned for me, there is only one inch of legroom for a rear passenger behind me. In other words, I can't have a rear passenger behind me. That's just stupid.

Also, both Minis we drove seemed to have a small amount of throttle lag, which was annoying. To get anything close to the performance of our current car, you had to have the Mini in sport mode, which completely blows the gas milage; made even worse by the fact that the Cooper S had worse gas milage than our current car even in the economy mode. We wanted a car that was practical, economical, and fun to drive. But the Mini failed on all three; it was out of the running. C was surprised; she'd thought the Mini was about as obvious a choice as I'd thought the Prius was.

Back to Volkswagen

Finally, as promised, we went back to Volkswagen. Alvaro was both nice and attentive, and we got to test drive both the Jetta TDI and the Rabbit. By this point, we were thinking that the 2010 Golf TDI was looking like a likely prospect, so we drove the Jetta (which has the same engine and drive-train) for feel, and the Rabbit to get a sense of what the size and driving position would be like in the Golf.

Our test drives were fairly short (longer than we had at Toyota, but nothing like what Kevin at Honda allowed us), but I still think we got a fairly good sense of the cars. Based on the feel of driving the Jetta TDI, we're pretty convinced that the 2010 Golf is going to be fun to drive.

Alvaro's boss Tim sounded us out about getting a 2009 Jetta (since they were trying to close out that model year), but even though he could have given us a deal on that car, we really had our hearts set on the 2010 Golf.

About my only concern is with colors, which tend towards bland and innocuous (as with all the cars but the Mini). The nicest color available is Shark Blue; I'd love something more saturated, but the only saturated color is red, and C hates red cars.

We Have a Decision!

Based on all our research, we've decided that the 2010 Golf TDI is our best choice. It doesn't have as large a trunk as the Jetta, but it looks like it will be big enough for our usual needs (unlike the Mini, which doesn't have enough room for groceries). Unlike the Jetta, the Golf just feels cuter and more fun—I wanted something with a “cute small car” feel, but some practicality, and the Golf seems to have the right mix. Also, the Jetta hasn't moved onto the Mark VI chassis yet, which in theory means it isn't quite as quiet as the Golf. Also, the 2010 Golf has an upgraded interior design, making it really nice inside compared with the Jetta, and way beyond anything else we'd considered other than the Mini.

By choosing a TDI, we get a good mix of power and fuel economy, so that seems like it ought to be a good thing. (And there is a government rebate of $1300 for buying a fuel efficient vehicle.)

The only problem was that the 2010 Golf TDI isn't even out in the U.S.A. yet, so now we're going to have to play a waiting game. On the positive side, it seems like we're going to have to custom order one to have it built with the options we want.

Getting the Brush Off at Volkswagen

W. Clawpaws — Fri, 03 Jul 2009 14:19:00 -0700

Wednesday, we hit the Volkswagen dealership to check out the Jetta TDI and look at Rabbits/GTIs to get a sense of what the upcoming 2010 Golf TDI will be like. These TDIs get about the same gas mileage as many hybrids (although not quite as good as the Prius) and are supposed to be much more fun to drive. The Jetta TDI won the 2009 Green Car of the Year (although in 2008 the winner was the Chevy Tahoe Hybrid, which is hardly my idea of an ecologically sound vehicle to drive). In addition the 2009 GTI was first on US News's aggregate car review rankings for upscale small cars.

Unlike the Honda and Toyota dealerships we went to, Volkswagen seems to allow their salespeople to hang out indoors, but Alvaro came out to greet us and ask us what we were interested in. We told him the Jetta (after a brain-fart where I initially said Passat).

Alvaro walked us over to the Jetta TDI, and then after a small amount of talk suddenly had something far more urgent to do (he claimed he had a phone call he had to make). So, we got to poke around in a baking hot Jetta (black car, black interior) by ourselves.

To me, the car seemed a little like a tank, with huge wheels and big heavy doors, but having seen them in the wild, I'm fairly sure that a lot of that is some sort of illusion that comes from looking at it on the dealers lot -- C had a similar reaction to the Prius. But the interior seemed fairly well appointed, although there was some hard plastic in places.

Two neat interior features that C discovered were a 110V power outlet on the back of the center console and a completely lockable trunk (i.e., you can prevent people accessing the trunk even if they have access to the passenger area).

At least 20 minutes later we gave up and started to walk towards the showroom. On our way, we saw some Rabbits and started to peer into them, and that was Alvaro's cue to reappear. I asked about a test drive and he piled on the excuses. Apparently they only had two sales guys in the dealership right now, and someone else was coming to do a test drive and that was a sure thing, and anyway, the Jetta TDI was kinda blocked in and would be hard to get out, and it was probably the wrong phase of the moon, too.

Possibly I was too primed by Andy, the Toyota salesman who doesn't like to sell cars, but I was a little pissed off at Alvaro's attitude and I think I showed it. I think I left giving him my card and saying something like, "When you want to sell me a car, you let me know". C told me afterwards that I needed to have a little less of a chip on my shoulder about being taken seriously, and she's probably right,

Having struck out at the VW dealership, we stopped in at a neighboring Toyota dealer, and actually found someone worse than Andy from our local dealership. She was all about trying to get us to put a deposit to wait for to pay over the odds for a car we've never even seen, let alone test driven. Um, no thanks. She did at least give us a brochure though; I guess that's something.

Alvaro did call me the next day, and we were both nice and smoothed things over, and we agreed that I'd come back the following Tuesday to do a test drive and get a better sense of the Rabbit since the upcoming Golf TDI does seem like a very likely prospect. I still have high hopes for Volkswagens. We've done more homework in the meantime: C seems to be a little less concerned about having a diesel and we've found that the integrated navigation system on the newer cars has good iPod integration (after a few years of serious stumbles from VW).

Voyage into Toyotaland

W. Clawpaws — Thu, 02 Jul 2009 10:56:00 -0700

After checking out the Fit at the local Honda dealer on Tuesday, we headed out to the the local Toyota dealer to check out the Prius and other cars. This time, we were greeted by Andy. Like the Honda dealership, the Toyota dealership seemed to be making their sales guys hang out in a tent outside, but Andy seemed far less pleased to see us than Kevin had been.

I told him we were interested in the Prius V, and after listing the ones they did have (which didn't include the V), he rather abruptly disappeared. That seemed really odd to me; I would have expected that a salesman would have wanted to engage a bit more (e.g., talk up the car I wanted; hear about what other cars I was considering, so that he could cast his cars in a positive light compared to the competition; or sell me on a different car that he had on the lot). But Andy just wasn't very interested.

While Andy disappeared inside, we did get check out the interior of the Prius. C's instinctive reaction was not good. The 2010 Prius has a high center console that separates the driver from the passenger and to C it felt like a wall between us. It also seemed like hard plastic was in abundance, although I think part of it is also that dark-colored interiors don't make as good a first impression as light-colored ones.

When Andy returned, he told us they might have a Prius V next week and he'd let us know and we could come back. I asked about driving the Prius IV, which they had on the lot, and he said that I really had to test the V because it had a totally different feel (I think the V is like the Touring version of the 2009 model), and even if I wanted to test both the IV and the V, I should test them both at the same time. Maybe that was reasonable, but I still felt like I was getting the brush off. We were being sent on our way without even being asked what other Toyotas we might be considering, and without a brochure. He did give us his card.

I think part of Andy's issue was that he saw us getting out of a 1993 Geo Prizm in jeans and T-shirts and assumed that we must be deadbeats. C yearns for the attitude that she saw in San Francisco where multimillionaires bum around in jeans, causing people in service industries not to make too many stupid assumptions, but that doesn't seem to be the case here. I think that when I gave him my business card, Andy may have realized that his snap judgements were wrong, but who knows what goes on in the mind of a car salesman?

Anyway, we left with C having a pretty negative take on the Prius, hating the interior and being convinced that it was "huge", and with me knowing too little to form a coherent opinion. Rightly or wrongly, Kevin at the Honda dealership had given us a baseline that was going to prove to be hard to measure up to. Andy had fallen far, far short.

Checking Out the Honda Fit

W. Clawpaws — Wed, 01 Jul 2009 10:35:00 -0700

Monday was my first ever trip to a car dealer, and C's first trip in a long time. We had decided to try the Honda Fit first. The Fit has gotten a lot of good reviews, including being ranked first in the meta-rankings done by US News for affordable small cars and hatchbacks.

We went to a local Honda dealership, parking our car just outside the lot and walking in, and were almost immediately greeted by a friendly looking guy who introduced himself as Kevin.

We told him we were interested in the Honda Fit, and after looking at it for only a few moments, he offered us a test drive. While he disappeared to get the keys, we looked at the exterior and the dealer's price sticker. I did notice that the cars on the lot seemed to have been extended with various dealer add-ons (window tinting, paint protection, shiny wheels), so I did wonder just how hard they would push such options on their customers...

Getting out was a little more of a challenge because it was actually Kevin's first day at this dealership (he had been at another Honda dealer in the area) and he needed help to get the keys, and then the car had a dead battery and needed to be jumped, but soon enough we were on our way.

Kevin didn't seem to mind where I drove or how far, so I ended up taking the car on a journey of a little over 15 miles, taking us through broad urban arteries, some sleepier suburban streets, up into the local mountains, and then back down, onto the freeway for a quick dash, and back to the dealership. The ride had everything I'd want to test -- freeway driving, toiling up a hill, and so on.

It felt pretty good. The engine seemed zippy and responsive enough to be fun to drive. I didn't get a chance to really get to try out the paddle shifters, but I expect that they work. The car is a little tall and I think that its height and small size meant that it felt a little less stable than a sedan, but I also didn't really want to push a brand-new car to its handling limits to find out just where they were.

The dash had an MPG display so you could see how economically you were driving, which was neat. The model we had also had the navigation system, which seemed quite servicable, and had built-in iPod integration (which we couldn't test, as the cable in the glove box was just a USB socket).

Driving back, I tried to persuade C to take the wheel, but she was having none of that, which means that we may have to come back sometime just so that she can drive it. At the time C wasn't entirely happy with the seat, because the lumbar support pressed in all the wrong places, but in retrospect it may be that she just had the seat tipped too far back.

One of the nice things about Kevin was that he rode along in the back and was talkative and interested without being too pushy. He did try a little too hard to be agreeable—I think that if I'd claimed that the sky was green, he'd have been able to see it, too, and sometimes his knowledge of the car was a little sketchy, but he got huge points for being nice and attentive without being annoying.

Back at the dealership, we looked more at the interior. It's certainly very flexible as far as what you can put into it. It does feel a little cheap, with a lot of hard plastic, but I expect that that's something you can get used to.

Then we stepped inside, and talked a bit more. We talked a bit about the other cars we'd look at and mentioned the Prius, and Kevin said we really needed to try the Insight if we were considering the Prius. I had been turned off the Insight in part because I'd read some horrible reviews, such as Jeremy Clarkson's where he wrote:

So here goes. It’s terrible. Biblically terrible. Possibly the worst new car money can buy. It’s the first car I’ve ever considered crashing into a tree, on purpose, so I didn’t have to drive it any more.

But as usual, it turns out that Jeremy Clarkson is an idiot. He didn't get the car, as evidenced by his saying:

It doesn’t work. Put your foot down in a normal car and the revs climb in tandem with the speed. In a CVT car, the revs spool up quickly and then the speed rises to match them. It feels like the clutch is slipping. It feels horrid.

The key is that it feels a bit different, but it's actually quite drivable.

We didn't have long with the Insight because we had a dinner engagement, but Kevin did manage to get us to seriously consider it as a viable candidate.

All in all, a good first day of test driving.

Car Search Begins

W. Clawpaws — Tue, 30 Jun 2009 22:07:00 -0700

If you've been avidly reading my blog (what?!?), you have noticed that from time to time we ponder new cars (more than two years ago, I was pondering Priuses and more recently considered the Mini-E). After years of armchair pondering, we've (or at least I've) decided that we should actually move forward on doing something more concrete than just web surfing, which means the exciting adventure of attempting to buy a car...

What We Have...

First, let's set the context. We have a 1993 Geo Prism LSi, which is sixteen years old, but has less than 120,000 miles on it. The positive attributes of our current car are as follows:

It's a compact car, but with plenty of trunk space and room in the back for two (or even three if they're able to squeeze);
It gets good gas mileage (claimed 27 city, 34 highway; we get about 24 mpg for our very short daily commute and errands, and about 34 on road trips);
It has pretty good acceleration; and,
It's fun to drive.

Given all the good things about our current car, why replace it? Basically, it comes down to two things:

Increasing maintenance costs;
Somewhat outdated safety features (especially side-impact protection).

In other words, it's not urgent that we replace our car now, but we probably should replace it sometime and now is as good a time as any. Buying a new car is thus a good summer project, and because we're not desperate, we can walk away with nothing if we can't find the car or deal that we want, but hopefully we'll find something we want.

What Do We Want?

When it comes to replacing our current car, we don't want a car that's significantly larger than our current car, worse when it comes to gas mileage, or worse for reliability. That means no SUVs, and no full-size cars. Midsize cars are unlikely, too.

Also, given that we'll probably keep the car for some time, we're going to go with a new car rather than a pre-owned one.

Research

There are many, many sites you can head to for research on cars. Beyond the manufacturers' sites, I've mostly gone to Consumer Reports or Edmunds.

Initial Candidates

As things stand, our current front runners are as follows (in no particular order):

Toyota Prius
VW Jetta TDI (and maybe the Golf TDI too)
Honda Fit
Mini Cooper

I'd have loved to include the Mazda3 as well, but it gets such mediocre gas mileage that I can't really do so in good conscience.

Beyond the front runners, there are quite a few maybes, including

Honda Insight
Honda Civic
Toyota Corolla
Toyota Matrix
Toyota Yaris

Beyond these brands, poor fuel economy seems to rule out many of the other options, including the US brands like Ford and GM.

To know more requires looking at and test driving cars, which means a journey to various dealerships. I'll recount how that works out in the next few posts.

GarageBand's Learn-to-Play feature on PowerPC

W. Clawpaws — Sat, 31 Jan 2009 20:52:00 -0800

One of the neat new features in iLife '09 is the "Learn to Play" feature in GarageBand. Unless, that is, you have a PowerPC Mac, because Apple says in its requirements for iLife '09 that

Learn to Play requires an Intel-based Mac with a dual-core processor or better.

And indeed, once I installed it on my Dual G5 PowerMac, I got a dialog that said

The Learn to Play feature requires an Intel-based Mac with a dual-core processor or better.

That's a shame, because that machine has been relegated to doing little else than doing GarageBand stuff, mostly because my MacBook Pro is powerful enough and has a large enough screen that there is rarely much need to go into our home office to do work-related things. But for Garageband, it's a fairly nice setup, with a Keystation 49e and an iControl. Moreover, using my MacBook Pro would be much more awkward -- especially since the monitor is old enough to have an ADC connector and won't plug into the laptop without an expensive adapter, so using GarageBand on it would feel much more awkward and cramped.

So I wondered whether this machine could be made to run Learn to Play. Even though it's about six years old, it's no slouch, so I figured it probably could, if only Apple would let it. Google is usually your friend for these kinds of things, but a few searches turned up nothing useful. If I waited, someone else might figure it out, but if I wanted it working today, I had to be that someone, and so I began to investigate.

I began by using lsbom on the Archive.bom file inside GarageBand_LTPContent.pkg (found in /Library/Receipts after installation), and things looked good, because this Learn-to-Play Content package was just the sound, video, and metadata for the provided first lessons, meaning that the Learn to Play code was in GarageBand proper. Again using the output of lsbom, this time on the content of GarageBand.pkg, combined with the file command, I found that all the compiled material had been compiled for both PowerPC and Intel.

So now all I had to do was change GarageBand's mind about the validity of the PowerPC platform. First, I monitored what files it accessed using OS X's opensnoop command. The opensnoop command gives you output that looks like

  UID    PID COMM          FD PATH                 
  501   3678 GarageBand    18 /dev/urandom         
  501   3678 GarageBand    18 /var/tmp/etilqs_U4un5wbhzMrpkXI 
  501   3678 GarageBand    16 /.vol/234881056/121855

which is nice, but as you can see, sometimes file access goes through Carbon functions (such as FSOpenIterator), even if you're writing an entirely Objective-C based application, and Carbon loves to go through /.vol. So, just in case one of those files was of interest, I ran the output through the following one-liner as a filter

perl -pe 'use Mac::Files; s{(/\.vol/\d+/\d+)}{ResolveAlias(NewAliasMinimal $1)}eg'

(I actually added some caching in my original one-liner, but I've omitted it here for clarity). There may have been a single function I could have called to do the job, but as someone who tries to stay away from Carbon, good enough is good enough.

From this output, I discovered that when GarageBand gives you the error message, it's actually rendering an HTML page, coming from store_requirements.html inside the application bundle. I then decided that I should really be using Instruments to look at what was going on, and from looking at a file trace there, I found that the stack content at the time of the call looked like

 1. -[MAStore showErrorPageForURL:errorPageTemplate:webView:]
 2. -[DfNewProjectDialogController _selectCategoryForID:]
 3. __NSFireDelayedPerform
 4. CFRunLoopRunSpecific
 5. RunCurrentEventLoopInMode
 6. ReceiveNextEventCommon
 7. BlockUntilNextEventMatchingListInMode
 8. _DPSNextEvent
 9. -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
10. -[NSApplication run]
11. NSApplicationMain
12. main

Running GarageBand from within gdb showed that DfNewProjectDialogController's _selectCategoryForID: method was the one to look at, but it's a long function, and in gdb, you just see a lot of calls to objc_msgSend_rtp and objc_msgSend. A little digging with Google took me to this page on Dave Dribin's blog, where he recounts discovering Technical Note TN2124: Max OS X Debugging Magic which has a lot of useful tips, but most particularly

If you set the NSObjCMessageLoggingEnabled environment variable to YES, the Objective-C runtime will log all dispatched Objective-C messages to a file named /tmp/msgSends-<pid>.

Cool. I thus got a 250 MB file logging every method call as GarageBand ran. From that, the key part was

- DfPreferences DfPreferences doesMentorMeetsMinimalSystemRequirements
+ ECHardwareUtilities ECHardwareUtilities sharedHardwareUtilities
+ ECHardwareUtilities NSObject class
+ ECHardwareUtilities ECSingleton sharedInstance
+ ECHardwareUtilities NSObject class
+ ECHardwareUtilities ECHardwareUtilities singleton
+ ECHardwareUtilities ECHardwareUtilities singleton
- ECHardwareUtilities ECHardwareUtilities cpuType

When I saw that, I smiled. When GarageBand wonders doesMentorMeetsMinimalSystemRequirements, we just have help it come to the right conclusion. To make GarageBand happy with a PowerPC, we just need to put the following in a file, such as ppc-gb.gdb:

break doesMentorMeetsMinimalSystemRequirements
commands 1
  return 1
  continue
end

and then run

gdb -x ppc-gb.gdb /Applications/GarageBand.app/Contents/MacOS/GarageBand

(Update: And then you type run into gdb to actually start it up, and type quit when you're done, or run again to restart it.) It's possible to pretty this up a bit, and no doubt someone else will if they read this entry, but for me, objective achieved.

Ha!

And yes, it does run fine on a dual 2 GHz PowerPC G5, at least for the first Piano lesson. (I have the next two downloading as I write this.) Your mileage may vary, of course.

(Note to Apple, please don't break this. Note to other people, don't scream from the rooftops about how Apple sucks because you need to have this hack, because if you scream too loud, you may end up with a GarageBand that can't be hacked like this, or developers may end up with crippled tools, and these tools are very useful in lots of other situations besides this one.)

Update (Feb 4, 2009): GarageBand 5.0.1 came out today, and everything still seems to work. I can also report that the other piano lessons I downloaded (up to lesson four) also seem to work just fine.

Steam Engine Time

W. Clawpaws — Sat, 20 Dec 2008 00:54:00 -0800

In an email conversation with my brother, inspired by this blog post about Windows 7, I got to talking about some of the things Microsoft actually does right, and in that discussion mentioned some of the cool things that come out of Microsoft Research, including their OS research (since that was the context of the discussion).

One of the interesting bits of OS research coming out of Microsoft (stemming in part from their interest in managed languages) is Singularity. When I first heard about it though, I was struck by how similar it was to JavaOS from the mid 90s (descriptions of which seem to have now virtually disappeared). When you see similarities between two things, you might be disposed to wonder whether someone copied something, but that need not be the case. If something is a good idea and the time is right for it, it's entirely possible that independent people will think of the same thing.

Staying in the OS arena, a recent example of this phenomena seems to be Microsoft's Xax technology (which allows you to run “unsafe” legacy code within the safety of a web browser) — most interestingly, they show how you only need a very small number of system calls to get the job done. What's erie is that essentially the exact same time, Google was doing something similar, with Native Client.

It's interesting how often unrelated people end up coming up with the same thing. It happens all the time, even with “transformational” inventions (e.g., the telephone, television, etc.). Lots of people have noticed this phenomenon, but it was Charles Fort who coined the phrase “It's steam engines when it's steam engine time.”

(It's also one of many reasons I believe that patents are problematic.)

Cars again, Mini-E this time

W. Clawpaws — Sat, 20 Dec 2008 00:12:00 -0800

Every once in a while, I look over the cars you can buy, play with the configurator, and then wander away. As I've said (to various cries of incredulity), it annoys me that you can be expected to spend more than $25,000 on a vehicle and yet be offered a paltry array of bland colors (grey, white, silver, beige).

One of the companies that gets things mostly right is Mini. It does seem like you can configure an actual car, and then get that car (c.f., other companies where you can configure things, but you've only got three options to choose “Package A”, “Package B” or “Package C”, then you're expected to go to the dealer and drive away with whatever they have on the lot).

So, I returned to the Mini-USA site today to see what was new, and saw that they were taking 500 people to test the “Mini E” for a year. It's not exactly cheap, and I'm not sure how practical it'd be for most people, but I think that for us it would be pretty cool — we drive relatively short distances most of the time, so we aren't likely to run it out of juice.

I'm sure they have tons of applicants, and it looks like they're using “character” questions to make the decisions. Thus, they had lots of questions on things like “Who was your childhood hero?”, and ”List the three inventions you couldn't live without.” Somehow I don't think they wanted answers like “my math teacher” or “agriculture, the wheel, and the inclined plane”.

Anyway, I'm not going to get my hopes up too much, but if you don't try, you can't win.

Update: Mini did get back to me and pretty much offered me a lease, but when I looked at the terms, I came to the conclusion that they were asking way too much for a one year lease—you could lease two minis for the cost of leasing the Mini-e.

How Quickly We Forget

W. Clawpaws — Wed, 13 Feb 2008 16:19:00 -0800

I'm fairly amused to see the claims that people make about the iPhone, in particular the claims about how limited it is as a platform (i.e., how little we can expect from it given how limited its CPU, RAM and storage capabilities are). For example, recently Craig Hockenberry wrote about how difficult the iPhone will be to develop for and said this about its RAM constraints:

There are some very tight limits on memory usage. You’re given approximately 64 MB of space to work with [...]

Is 64MB tight? When we compare an iPhone to the desktop machines of today, it's true that it looks a little pokey—my laptop has 4GB in it, and my desktop machine has even more—but that isn't the question here. The question is whether it ought to be enough for the kind of applications people will want to run on the iPhone and, in the context of Craig's article, whether ordinary developers ought to be able to write applications that run on the iPhone without breaking too much sweat, and whether the familiar and easy-to-use development tools developers have become used to can be reasonably expected to target the iPhone.

I have to defer to Craig's actual experience developing for the iPhone when it comes to describing the situation as it currently is, but there is no reason to suppose that it has to be that way. I'd argue that Cocoa and OS X have a long history, and in that history many of the same tools and libraries we're still using today targetted a much more resource-limited platform.

It's easy to be spoiled by the vast amounts of memory that desktop machines have today, but 64MB isn't peanuts. If we go back to the origins of OS X, NEXTSTEP, we find that it ran with much tighter resource constraints. The base model of the very successful NeXTstation originally had 8MB of RAM and a 105MB hard disk—yes, it actually had less disk space than the iPhone has RAM. True, to install the developer tools you probably wanted the 400MB disk option, and with only 8MB it was fairly quick to start swapping, but if you maxed the machine out—to a “whopping” 32MB of RAM—you could run quite a lot without needing to swap. It's true that NEXTSTEP could swap if it needed to, but applications that needed double the physical RAM of the machine were rare indeed.

As a quick test, I booted up my OpenSTEP 4.2 virtual machine in VMware, where the whole virtual machine only has 64MB of RAM, and started a few applications (the wonderful spreadsheet Quantrix, Lighthouse Design's clone of Lotus Improv, Diagram, which The Omni Group later cloned as OmniGraffle, and Preview opening a large PostScript file). Here is the output from ps:

openstep> ps ugxc
USER       PID  %CPU %MEM VSIZE RSIZE TT STAT  TIME COMMAND
clawpaws   184   0.0 14.1 16.8M 9.01M ?  SW    0:05 WindowServer
clawpaws   186   0.0  2.9 3.58M 1.88M ?  SW    0:00 pbs
clawpaws   189   0.0  1.1 2.56M  704K ?  SW    0:00 appkitServer
clawpaws   190   0.0  3.7 5.79M 2.34M ?  SW    0:00 WM
clawpaws   191   0.0  3.0 6.06M 1.92M ?  SW    0:00 Preferences
clawpaws   206   0.0  4.3 7.83M 2.77M ?  SW    0:00 Diagram
clawpaws   208   0.0  1.8 7.17M 1.18M p1 SW    0:00 tcsh
clawpaws   236   0.0  6.4 8.35M 4.09M ?  SW    0:00 Quantrix
clawpaws   249   0.0  1.1 2.06M  752K p1 T     0:00 ftp
clawpaws   251   0.0  6.0 6.70M 3.86M ?  SW    0:00 Preview

Perhaps you think it isn't fair to compare NeXTSTEP or OPENSTEP to what we have today in OS X, but if so you probably haven't seen or used either of them. It may be technology from more than a decade ago, but it's no Windows 95—Unix is old, too, and many of its basics haven't changed much over the years. Objective-C, Interface Builder and friends were there from day one. Today's Cocoa libraries look and feel very much like their counterparts in OPENSTEP.

Craig also writes:

Guess what? This nightmare will become a reality as soon as you start building your iPhone application. There are no NIBs. None.

I don’t think this is one of those “let’s skip it for version 1.0” design decisions. The process of unarchiving the objects in the NIB takes CPU cycles and memory: both things that are in limited supply on the phone.

I hope that you can see from the above how little water the above argument holds. The iPhone has plenty of CPU power for this task—NEXTSTEP used nibs and ran on a 25 MHz 68040, not a 400 MHz ARM.

But there is something else wrong with this argument, too, namely the idea that it is somehow cheaper to create objects programmatically rather than by decoding an object serialization representation such as a nib file. That's a time/space performance claim that needs to be substantiated with evidence. Very very often, human intuition about what is fast is wrong, because modern machines are complex beasts and things like caches and memory access behavior can make a big difference. The way to know is to run tests and see if the performance difference is actually noticable. But to provide some counter-intuition to anyone who thinks it's obvious that pure code ought to be faster, here's one: compact code interpreting a compact data representation may fit in level one cache, whereas the longhand code to do the same task may not.

So, I don't buy it. I'm not saying that the iPhone SDK will have nibs, but I am saying that I've yet to see a good reason why it couldn't.

Storing iPhone apps locally with data URLs

W. Clawpaws — Mon, 16 Jul 2007 10:11:00 -0700

Some people think that you need net access to run web-based applications on your iPhone. Not so. The URL below provides a simple tip calculator (sadly this crappy blogging system doesn't let me do a direct link, which sucks, but you can copy and paste and add it your bookmarks on your computer then sync with your iPhone, and/or make your own page with a direct link). By using a data: URL, the entire page content is all in the URL. If save a bookmark for this URL, you can access this little JavaScript-based app even in airplane mode.

data:text/html;charset=utf-8;base64,PGh0bWw+CjxoZWFkPgo8bWV0YSBuYW1lPSJ2aWV3cG9ydCIgY29udGVudD0id2lkdGggPSAyNDAiIC8+Cjx0aXRsZT5UaXAgQ2FsY3VsYXRvcjwvdGl0bGU+Cgo8c2NyaXB0PgoKZnVuY3Rpb24gdGlwKGFtb3VudCkgewogICAgcmV0dXJuIHRpcDsKfQoKdmFyIG91dHB1dCA9IG51bGw7CnZhciBwZXJjZW50ID0gMTguNSAvIDEwMDsKdmFyIHJ0aXBfZmFjdG9yID0gMC4yNTsKdmFyIHJ0b3RhbF9mYWN0b3IgPSAxLjAwOwoKZnVuY3Rpb24gd3JpdGVPdXQobGluZSkgewogICBpZiAob3V0cHV0KSB7CiAgICAgIG91dHB1dC5hcHBlbmRDaGlsZChkb2N1bWVudC5jcmVhdGVFbGVtZW50KCJiciIpKTsKICAgfSBlbHNlIHsKICAgICAgb3V0cHV0ID0gZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoIm91dHB1dEFyZWEiKTsKICAgfQogICBvdXRwdXQuYXBwZW5kQ2hpbGQoZG9jdW1lbnQuY3JlYXRlVGV4dE5vZGUobGluZSkpOwp9CgpmdW5jdGlvbiB1cGRhdGUoKQp7CiAgICB2YXIgYW1vdW50ID0gTnVtYmVyKGV2YWwoaW5Gb3JtLm51bS52YWx1ZSkpOwogICAgaWYgKGFtb3VudCA9PSBOYU4pIHsKICAgICAgICB3cml0ZU91dCgnSHVoPycpOwogICAgfQogICAgdmFyIHRpcCAgPSBhbW91bnQgKiBwZXJjZW50OwogICAgdmFyIHJ0aXAgPSBNYXRoLnJvdW5kKHRpcCAvIHJ0aXBfZmFjdG9yKSAqIHJ0aXBfZmFjdG9yOwogICAgd3JpdGVPdXQoJyQnICsgYW1vdW50LnRvRml4ZWQoMikgKyAnICsgJCcgKyBydGlwLnRvRml4ZWQoMikgKyAnID0gJCcgKyAoYW1vdW50K3J0aXApLnRvRml4ZWQoMikpOwogICAgdmFyIHJ0b3RhbCA9IE1hdGgucm91bmQoKGFtb3VudCArIHRpcCkgLyBydG90YWxfZmFjdG9yICsgMC4yNSkgKiBydG90YWxfZmFjdG9yOwogICAgd3JpdGVPdXQoJyQnICsgYW1vdW50LnRvRml4ZWQoMikgKyAnICsgJCcgKyAocnRvdGFsLWFtb3VudCkudG9GaXhlZCgyKSArICcgPSAkJyArIHJ0b3RhbC50b0ZpeGVkKDIpKTsKICAgIAp9CgpmdW5jdGlvbiB6YXAoZmllbGQpIHsKICAgIGlmICghIGZpZWxkLnphcHBlZCApIHsKICAgICAgICBmaWVsZC56YXBwZWQgPSB0cnVlOwogICAgICAgIGZpZWxkLnZhbHVlICA9ICIiOwogICAgfQp9Cgo8L3NjcmlwdD4KCjwvaGVhZD4KPGJvZHk+Cgo8aDE+VGlwIENhbGN1bGF0b3I8L2gxPgoKPHA+CkVudGVyIGFmdGVyLXRheCB0b3RhbDoKPC9wPgo8Zm9ybSBuYW1lPSJpbkZvcm0iIG9uU3VibWl0PSJ1cGRhdGUoKTsgcmV0dXJuIGZhbHNlOyI+CjxpbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJudW0iIG9uRm9jdXM9InphcCh0aGlzKSIgdmFsdWU9IjI0LjM3IiAvPgo8aW5wdXQgbmFtZT0ic3VibWl0IiB0eXBlPSJidXR0b24iIG9uQ2xpY2s9InVwZGF0ZSgpOyIgdmFsdWU9IlRpcCIgLz4KPC9mb3JtPgoKPHAgaWQ9Im91dHB1dEFyZWEiPgo8L3A+Cgo8L2JvZHk+CjwvaHRtbD4=

By putting images inline using data: URLs, you can create pretty rich pages and store them locally. I created a 363,488 byte URL for my home page (complete with images) and it loaded just fine on my iPhone.

Here's a quick Perl one-liner to turn HTML into a data: URL.

perl -0777 -e 'use MIME::Base64; $text = <>; $text = encode_base64($text); $text =~ s/\s+//g; print "data:text/html;charset=utf-8;base64,$text\n";'

By making these links programmatically, you even have an ugly hack to do persistent storage on the iPhone. Just encapsulate your app and its state in its URL.

Good Hash Functions

W. Clawpaws — Sun, 22 Apr 2007 00:35:00 -0700

I happened to want to create a hash table with integer keys and went looking for a suitable function. As usual, Google is your friend. And as usual, once you start researching things on the 'net, hours can go by.

Thomas Wang has a good discussion of various integer hash functions, but that also lead me elsewhere to discussions of good hash functions in general.

In the past, I've found that many of the hash functions that are claimed as being better than Knuth's classic string hash function don't actually prove to be any better by most metrics, and some seem to be much worse.

For example, one popular hash on the street these days seems to be Paul Hsieh's SuperFastHash. It does run quickly, and on the whole its statistical properties seem to shake out reasonably well. But when you look at the actual integers it returns, in my tests using /usr/share/dict/web2 on my Mac, there seem to be a far more collisions than you'd statistically expect. Statisitically, you'd expect about six collisions in the 32-bit space. Knuth's hash function has only five, and they're very dissimilar words, namely:

227010540:  autovivisection grovelings
890239928:  dialypetalous mumpishness
2851341963: anisostemonous umbellifer
3508170762: ctenodactyl fuliginousness
3909438781: prerogativity puzzleheaded

The SuperFastHash function, on the other hand has 59 collisions, an order of magnitude more. Here are a representative few:

432696082: Cotinga Cotonam
535511585: miscoin misfond
631000912: amidine aminity
668950620: untossed unworked
738886349: hennin penman
749072160: revisible rewirable

Notice that the words that hash the same seem somehow similar. That's just weird.

In addition to his own hash function, Paul Hsieh also has some other useful code on his site, including a hash test program comparing several different hash implementations for speed, and a portable implementation of stdint.h.

The FNV (a.k.a. Fowler/Noll/Vo) hash is another hash function that seems popular these days. It seems broadly similar to Knuth's hash function, but does a better job of distributing hashes for short strings across the full 32-bit space for hashes. For example, Knuth's hash hashes bat and cat to 137867 and 139236 respectively, but FNV hashes them to 950299920 and 1587996537. Like Knuth's hash function, FNV places single-letter words in adjacent spots (although there is an alternative version, FNV-1a, that avoids this problem), Here are the collisions in 32-bit space for FNV.

374764810:  diabolically koilanaglyphic
1055878936: deuteropathic vertebrosacral
1290893597: parer vila
1408982841: basiotribe narcotinic
1713658462: averral climatical
3129894270: Scorpididae transposer

Bob Jenkins published an article in Dr. Dobbs journal in 1997, providing a good hash function of his own, and has continued to tweak his code since. His page on hashing has lots of good stuff, including links to his code. His hash function is no slouch, and is the only one I looked at that maps single characters to radically different positions. Below are his 32-bit collisions, again with about the distribution you'd expect:

728135544: chorda fingerbreadth
733592810: stockily virginally
893264706: combaron unlimited
1456871225: gaspingly secularistic
1486736111: unbodied Yankee
2683815022: blackpoll Paharia
2947362466: Borinqueno unskewed
3298503807: distributress granulator

Thanks to Paul Hsieh's test program, here are some performance numbers for these different implementations (as benchmarked on my aging PowerBook G4):

FNVHash         :  3.9300s
knuthHash       :  2.9700s
BobJenkins      :  2.4600s
SuperFastHash   :  2.2800s

Running on some other architectures, I find that FNV and Knuth are really about the same (the difference between the two seems to be a G4 artifact). On the whole, although it may look like there's a big difference between the algorithms, in my experience, I've found that the hash function, (or even the whole hash table implementation!) isn't really the bottleneck. In other words, if you make your hash function twice as fast, usually no one will notice.

Paul Hsieh's SuperFastHash may be a tiny bit faster than Bob Jenkins's hash, but I think not enough to really stand out, and its strange collisions worry me. Bob Jenkins's hash function is probably the best and the one to use if you want an industrial-strength hash, but it is massive and complex. FNV may be slower, but it's short and sweet, just two mystery constants to remember. But if I have to write it myself, from memory, I'm still going to go with Knuth. Usually, Knuth's slightly odd pattern really won't matter.

For more, see Wikipedia's coverage of hash tables, which also has pretty good coverage of hash functions.

Getting Backtraces with Standard ML

W. Clawpaws — Fri, 16 Feb 2007 21:10:00 -0800

I still have a pretty good soft spot for Standard ML. Haskell may be sexier, but whenever I want to get something serious done, I find myself turning to SML.

One of my occasional claims for why I sick with ML is that you can actually debug SML programs (c.f., Haskell, where being laziness makes debugging "interesting" -- great if you want a research project).

But in practice, debugging in SML/NJ can actually be a pain. If you get an exception from one of the library functions, you may end up with an unhelpful error message like this one:

    uncaught exception Domain [domain error]
      raised at: Basis/Implementation/real64.sml:88.32-88.46

Without any sort of backtrace, you get no clue about where/how the exception was raised.

But it turns out that there is a feature in SML/NJ that lets you get a backtrace. It's just that it's barely documented at all!

It turns out that if you type:

    CM.make "$smlnj-tdp/back-trace.cm";
    SMLofNJ.Internals.TDP.mode := true;

when you first start SML, and then compile your code, when you get an exception, you'll get a backtrace.

Now, you'll see something more like:

    CALL   art.sml:52.7-52.55: Art.toIntensity[2]
              (from: art.sml:89.38-89.57: Art.emitGray[2].iz)
    CALL   art.sml:79.27-93.33: Art.emitGray[2]
              (from: art.sml:13.26-13.29: Art.for[2])
    GOTO   art.sml:10.7-13.45: Art.for[2]
              (from: art.sml:78.22-93.34: Art.emitGray[2])
    CALL   art.sml:77.19-93.34: Art.emitGray[2]
              (from: art.sml:13.26-13.29: Art.for[2])
    CALL   art.sml:10.7-13.45: Art.for[2]
              (from: art.sml:75.14-93.35: Art.emitGray[2])
    CALL   art.sml:64.7-98.7: Art.emitGray[2]
              (from: ???)
    CALL   art.sml:249.7-307.9: Art.doMix[2]
              (from: ???)
    
    uncaught exception Domain [domain error]
      raised at: Basis/Implementation/real64.sml:88.32-88.46

Cool. You've got to wonder though, why people would write a cool and useful feature like this and not clearly tell people about it.

Use Google to * Yourself

W. Clawpaws — Mon, 12 Feb 2007 20:42:00 -0800

In bored moments, I sometimes wish that Google had a "Just show my some random interesting thing" button in addition to its "I'm feeling lucky" button. It doesn't, but if you're after something relatively random and occasionally worthy of a chuckle, Google is your still friend.

Google's search facilities allow you to include wildcards in your searches. You can't just search for "*", but you can make seed phrases. It's often quite strange what the top hit is. Here are a couple, and their top hits as of today,

"There is a * in my *" — There is a carrot in my ear.
"I can't believe I * a whole *" — I can't believe I wasted a whole decade.

And so on...

Certainly a silly time waster, but if you hopefully you won't waste a whole decade.

Universal Binaries without XCode

W. Clawpaws — Sun, 11 Feb 2007 13:53:00 -0800

OS X inherited fat binary technology from NextStep. Back in the NextStep days, the incantation was easy, you'd just add -arch i386 -arch ppc to all your compilation/linking/library commands and you'd be all set.

With OS X, Apple made it "even easier" — just a check box in XCode. And for projects that still use things like Makefiles, they give you detailed instructions for Building an Open Source Universal Binary. Great right? Not so much, because the those instructions essentially tell you how to make XCode manage the whole build, which is, frankly, nuts.

If you try to go old school and pass -arch i386 -arch ppc to gcc, all seems fine until you try to link, and which point it dies horribly. Turns out that the "standard" developer libraries are thin, not fat. So, to link your program, you need to pass -syslibroot /Developer/SDKs/MacOSX10.4u.sdk to the linker to have it find some libraries with the proper amount of universal goodness. For a C++ project, the relevant incantation is

   g++ -Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc

Why didn't they just say that? Maybe they were too embarrassed...

Understanding mdfind

W. Clawpaws — Sun, 11 Feb 2007 13:23:00 -0800

I love Apple's Spotlight in theory, but in practice I hate the GUI implementation. On my 1.33Mhz G4 laptop, having it try to search while I'm still trying to type the first is both painful and usually useless. And, to make matters worse, when using Spotlight from the Finder, it seems to crash the finder about 50% of the time.

So, half the time I end up just using locate or find. But I keep thinking that I should really be using mdfind. But the manual page is less than helpful. It says

The query can be a string or a query expression.

which isn't very helpful because it doesn't tell you what valid query expressions look like.

Some people tell you to just do a search in the Finder, save it as a saved search/smart folder, and then go peek in ~/Library/Saved Searches. There you'll find evil XML (or binary) plist files, which are unreadable by normal people. But here's a useful trick to render them in human readable form (i.e., the old-style ASCII plist format). If the file ends with a .plist extension (e.g., ~/blah/foobar.plist), you can use defaults read ~/blah/foobar (note the lack of the .plist — the defaults command insists on adding it). If it doesn't end with .plist, you can make a temporary symlink that does.

So, you can look at saved searches, but learning from examples only goes so far. And, you can use mdls on existing known files to find potential attributes to use in your search.

But what you really need is to know the query expression syntax, and the metadata attributes. Why they can't just tell you about these references on the mdfind man page I don't know.

This documentation is a good start, except that it is still fairly sparse. From what I can tell, the inRange operator doesn't work, or at least doesn't work on dates. This works to find the files I've changed in the last day:

   mdfind '(kMDItemFSContentChangeDate >= $time.today(-1)) && (kMDItemFSContentChangeDate < $time.now) && (kMDItemContentTypeTree = "public.content")'

but this one doesn't

   mdfind '(inRange(kMDItemFSContentChangeDate,$time.today(-1),$time.now)) && (kMDItemContentTypeTree = "public.content")'

The kMDItemContentTypeTree = "public.content" part is to weed out updated cache files and the like, although apparently Makefiles don't qualify as content (none of the importers recognize them, I guess), so they get weeded out too. sigh

Still, I'm closer than ever to weaning myself off locate and find. Maybe.

Fun with Lego Mindstorms NXT

W. Clawpaws — Sun, 11 Feb 2007 01:44:00 -0800

C got me an Lego Mindstorms NXT for my birthday. A great birthday present is something you're pleased to have been given, but would never have bought for yourself, either because you hard to justify or because you would never have thought of it. I think this qualified on the former count — I knew if I got one, it'd be a terrible time sink. But I forgot Bertrand Russell's quote that "The time you enjoy wasting is not wasted time". I've certainly enjoyed almost all the time I've wasted on NXT fun (even browsing the technical docs).

It seems to be developing quite a community. There are several blogs, including

There are also a ton of ways to program the thing. I've mostly used the provided NXT-G graphical programming environment and NXC.

It's also pretty amazing what people have managed to do with NXT-G. For example, I'd never have attempted something as complex as a radar display what struck me as a fairly primitive and awkward language. I guess it's more capable than I thought, but I still think it's an insanely awkward way to express anything remotely complex.

I've built all the roaming robot designs that come with the set, but I like the basic TriBot best for versatility. I need to try doing some other designs too. LegoEdWest has build instructions for various straightforward variations on the original theme, such as Brian Davis's JennToo robot.

For coolness-factor, here's a Segway clone built using just the light sensor (and another cooler one), and a PackBot clone (which requires various extra parts to build.

And if you want more fun than what comes in the box, there are some really interesting hardware pieces on the horizon, including compass, acceleration, and gyro sensors, as well as input and output multiplexors. See

There sure is a lot going on here.

Cars, Priores/Priuses/Prii

W. Clawpaws — Sat, 10 Feb 2007 14:53:00 -0800

So, C was idly looking at new car websites last night. We're both always frustrated by the fact that most cars are available in such bland colors. I mean, if you're going to spend hours researching your new car, spend more than $20,000 on it, and have to wait weeks or months for it to arrive, you might at least be able to get it in a range of colors at least as interesting as a $69 iPod.

Myself, I keep hoping that the rumored 2008 Prius will be totally overwhelmingly cool and come in some actual colors. But I won't hold my breath.

And the official plural of prius? Apparently it's Prius. Wow, how bland, what a surprise.

SIGCSE booked

W. Clawpaws — Sat, 10 Feb 2007 14:38:00 -0800

So, I'm headed to SIGCSE. Registering on the last day of early registration is pretty dumb since all the conference hotels are pretty-much full, and flights are about $550. On the other hand, if I'd waited even longer, I would have felt even dumber.

There are lots of interesting things on the program.

I'll have to try to find out more about the vicinity (Covington, Kentucky) .