I updated gcalc to fix an issue caused by Google changing the HTML around the Google calculator answers (they added an extra h2 tag). No biggie, but gcalc now works again. You can get the new version here.
Also, I made gcalc a (small) code.google.com project. So you can now check it out at http://code.google.com/p/uj-gcalc/.
The other day I needed to find the location of an application using its bundle ID. Easy, just use LaunchServices. But I needed to do this from a script. Here are a couple perl one-liners to do it.
$ perl -MMac::Processes -e 'printf "%s\n", LSFindApplicationForInfo(undef, "com.apple.TextEdit")'
/Applications/TextEdit.app
$ mv /Applications/TextEdit.app ~/Desktop/
$ perl -MMac::Processes -e 'printf "%s\n", LSFindApplicationForInfo(undef, "com.apple.TextEdit")'
/Users/jgm/Desktop/TextEdit.app
$ mv ~/Desktop/TextEdit.app /Applications/
$ perl -MMac::Processes -e 'printf "%s\n", LSFindApplicationForInfo(undef, undef, "TextEdit.app")'
/Applications/TextEdit.app
mdfind could do something similar. But it wouldn't necessarily return the one that LaunchServices thinks is the "preferred" one if there were multiple applications with the same bundle ID.)
id vs NSObject* vs id<NSObject>
There's often confusion about the difference between the following three declarations in Objective-C:
id foo1;NSObject *foo2;id<NSObject> foo3;id gives the compiler no information about the actual type of the object, so the compiler cannot do compile-time type checking for you. Thus, the compiler will let you send any (*) message to objects declared id. Actually, this is why the common idiom of [[Foo alloc] init] doesn't cause the compiler to complain. +alloc is declared to return type id, so the compiler won't yell when you then send the returned object the message init (or even initWithMyFoo:blah).id are just dynamically typed at runtime. The compiler has no useful information about the object's real type, so it can't warn you if you send it a message that it may not respond to.id is an Objective-C object does not mean that it points to an object that derives from NSObject, or that it even has common methods like retain and release. One solution is to statically type our variable using NSObject* as shown in number 2 above. This gives the compiler information about the class of the object pointed to by foo2 so the compiler can warn if you send a message to foo2 that an NSObject doesn't respond to. This means you can safely call retain, release, description, etc., but the compiler will warn if you call length or count or anything that an NSObject doesn't respond to.foo2 pointer above would not be able to hold an NSProxy subclass, even though NSProxy does implement common methods like retain and release. What you really want is a pointer to any object that behaves like an NSObject. And that's exactly what the third case does.id<NSObject> tells the compiler that you don't care what type the object is, but you do care that it conforms to the specified NSObject protocol**. The compiler will ensure that all objects you assign to that pointer conform to the required protocol. A pointer typed like this can safely hold any NSObject (because NSObject conforms to the NSObject protocol), but it could also hold any NSProxy, because NSProxy also conforms to the NSObject protocol. In english, the declaration id<NSObject> foo3; says "foo3 is a pointer to an object of any type that behaves like an NSObject". This is very powerful, convenient, and expressive. In reality, we often don't care what type an object is, we just care that it responds to the messages that we want to send it (e.g., retain, release). id. This is very common for return types on methods that don't know the type of object they're returning (e.g., +alloc). It is also common to declare delegates to be type id, because delegates are generally checked at runtime with respondsToSelector:, and they usually aren't retained. NSObject * worked but id<NSObject> would not. And using the protocol form has the advantage that it will work with NSProxys. You may think that you never use NSProxys, but Cocoa's distributed objects system makes heavy use of NSProxy subclasses. Additionally, the common case is that you simply want to ensure that an object can be retained or released, and in that case the protocol form conveys that intent better; you really don't care what class the object is, you only care that it behaves like an NSObject.init as inti.@protocol) named NSObject. There is also a class named NSObject that does indeed conform to the NSObject protocol, but they are two different things.
Markd over at the Borkware Miniblog posted some great pictures—and hilarious captions—of Macworld '08.
I just finished reading the book Inside the Machine: An Illustrated Introduction to Microprocessors and Computer Architecture, by Jon Stokes, and it was fantastic. It is an extremely thorough, yet very approachable, explanation of microprocessor architecture, and it uses popular Intel processors and PowerPC processors as the examples. It even covers up through Intel's Core 2 Duo chips.
It's probably too late to put this on your holiday wish list, so I'd recommend that you just treat yourself to a new geeky book.
About a month ago I noticed the WiFi on my 8GB iPhone starting to get a little flakey. My iPhone would no longer connect to my home network, which is basically an AirPort Extreme closed network using WPA2 and MAC address filtering; just the standard wireless stuff. I didn't want to believe that the phone was broken because then I'd have to send it in and spend a week without a phone, or talk to a "genius" and beg for a new phone or something, so I just kept putting off digging into the problem any further. If I tried a restore and it didn't fix it, then I'd be forced to go through all the hassle that I desperately wanted to avoid.
Over my two week Thanksgiving holiday trip in Chicago and Ohio my iPhone took another turn for the worse. During our flight back to California we ended up stranded in Chicago—sitting on the plane—for 9 hours before finally taking off for the 5 hour flight. (My wife and I also had our 4 month old daughter with us during this most enjoyable time.) Then it happened. About 1 hour into our 9 hour wait (14 hours total) my iPhone battery died and I had barely been using the phone! Now I was unable to get weather updates, catch up on Family Guy, or use the free O'Hare WiFi that I could still reach from the plane. It was terrible.
When I got back I realized that something was really wrong with my iPhone. With a full charge it would only last for about 6–8 hours with no use! Now I had no choice but to take it in to the geniuses at the Apple store.
Anyway, to make a long story not too much longer, I brought my broken iPhone into the Apple store, talked to a genius and she cheerfully grabbed a brand new 8GB iPhone for me, switched out the SIM card, and sent me on my way in a matter of minutes. I was so pleasantly surprised about how fantastic and easy the iPhone support was. It was great. I should have done this a month ago! Thanks Apple.
I wrote an article about Exploring Leopard with DTrace for MacTech Magazine. Check it out when you get a chance. It was very fun to write because DTrace is just so totally freaking awesome. The most difficult part of writing it was limiting it to "magazine length"—I felt like I could go on for a few hundred pages.
Now that this is out, I'll probably start posting some DTrace fun on this blog as I get time.
