Jesper says that, due to a bug in WebKit, if you want your application to receive the
-webView:didReceiveIcon:forFrame: delegate method, you have to start up the (private) shared icon database.
Archive for December 2007
Jesper says that, due to a bug in WebKit, if you want your application to receive the
Jonathan Rentzsch has started a project to implement method swizzling correctly with different versions of the Objective-C runtime:
There’s at least four swizzling implementations floating around. Here’s a comparison chart to help you make sense of how they relate to each other and why JRSwizzle exists.
The year of 2007 is looking to be the beginning of the Golden Age of Version Control Systems. The DVCs became more stable and got much better documentation. Over the next year, I think we’ll see a lot of activity in the VCS area. If the progress of Git, Mercurial, and Bazaar in the last twelve months is any indication, they’ll be even further ahead of Subversion in another twelve months.
I’ve been pleasantly surprised with the progress in these new systems and with how people seem to be discovering and adopting them. Subversion works, but it’s frustrating. DVCS—and Git’s content tracking, in my opinion—aren’t actually necessary in many cases, but they’re seductive because the design is so beautiful. It’s a bit like choosing a Mac or an iPhone. And just as Windows is the new Classic, Git can play well with other version control systems.
Update: Why I Chose Mercurial.
Wil Shipley’s engineers get hired away by Apple, and he fights Core Data’s undo architecture. I’ve long been skeptical of these “magic” features and have wished that Apple would concentrate more on providing solid and flexible lower-level services. The high-level magic is great for demos and for applications that work the way Apple predicted, but it’s more likely to have what Shipley calls an architecture mismatch. And, often times, the drudgery that the magic was saving you from was not especially time-consuming.
Jonathan Wight has written an Automator action that lets you type Python code directly into an Automator workflow. It even provides syntax highlighting and Edit With BBEdit. PyObjC is used to help implement the action, and it’s also available to the code run by the action, so this should make it much easier to do interesting things from Automator.
These scripts, inspired by Bosco’s Foto Trimmer, make it easy to crop a single row or column of pixels off the edge of an image that you’re editing in Acorn. This can save you some intricate mouse work and/or manual typing of pixel values to resize the canvas, and it’s especially useful for manipulating screenshots.
Philippe Mougin combines Google’s new chart API, Cocoa, F-Script, Core Image, and Leopard’s new Scripting Bridge to create a pretty impressive demo.
As for as progress goes, yes there will be progress, but in a much more experimental vein. I released two branches, the one that the B50s come from (ed: the Quicksilver that’s currently running on your computer), and a newer one that is really unstable.
I’m inclined to encourage users to move over to the more stable and well supported alternatives like LaunchBar. Right now QS 54 (ed: the current build) accomplishes everything that I really need, the problem is stability, which for some reason most people seem to be ignoring.
So, the bottom line is that if there really were a mechanical way to prove things about the correctness of a program, all you’d be able to prove is whether that program is identical to some other program that must contain the same amount of entropy as the first program, otherwise some of the behaviors are going to be undefined, and thus unproven. So now the spec writing is just as hard as writing a program, and all you’ve done is moved one problem from over here to over there, and accomplished nothing whatsoever.
It’s true that you can’t make the programming, and thus the “entropy,” go away. But abstraction means that you can do more than just push the problem from one side to another. You can change its form. It’s like how some operations are easier in the frequency domain than in the time domain. The idea is that you write the specification in a high-level language, perhaps one that’s functional or declarative, that’s suited for reasoning about correctness. Then you have a compiler, which you trust, that converts it to executable code. This isn’t so useful if you’re unable to abstract your specification much from your program, but that’s hardly an indictment of specifications or formal verification. It just means that they aren’t applicable to every problem.
One afternoon Michael Culbert, the Newton technologist, came into my office to discuss battery contact bounce. I’d been nervous about the robustness of the storage system and had talked with him before about it, and now he confirmed my worst fears. Battery contact bounce is the jiggling of the power connectors when you toss a device onto a hard surface; the device can easily reset, and if the Newton was in the middle of a storage update, all the data would be lost. As I said, we’d been talking about doing transactions in the stores for a while, and Michael finally had a good argument for why they were going to be critical.
The best approach to identification seems to be to give up on having the identifier try to prove its own relationship to a “principal” (person or entity). Instead, the relationships are given as external statements made by other principals. The identifier itself can then just be a random unique number (such as a public key, which is easy to generate) with no intrinsic mnemonic value.
Drew Thaler explains more about why he doesn’t like case-insensitivity in filesystems. My somewhat naive opinion on this issue is that putting these smarts in the filesystem smells like bad design. It solves a good part of the problem implicitly, which encourages it to be mostly ignored at higher levels, and makes it likely that some code will accidentally rely on the filesystem where it shouldn’t. In other words, I think the end-to-end argument applies to filesystem case-insensitivity.
MacSanta is coming early this year. Today you can save 20% on DropDMG, EagleFiler, and SpamSieve, and on software from other fine Mac developers. A 10% discount will be available through December 31. Make sure that you sign up for the RSS feed so that you don’t miss the other deals throughout this month. Thanks to Paul Kafasis at Rogue Amoeba for organizing the promotion again this year.
The December issue of ATPM is out:
- Bloggable: Would You Like a Cup of Coffee With That?
- Mac About Town: Visions of Sugar Plums
- MacMuser: And Here’s Another Thing About Leopard
- MacMuser: Wonky Web Sites
- Next Actions: What Leopard Means For Getting Things Done
- Apple Talk: “Think Different”
- Desktop Pictures: Artmatic
- Software Review: HyperImage 1.0
- Book Review: Adobe Photoshop CS3 One-on-One
- Software Review: Signal
- Accessory Review: SmartCharge
- Accessory Review: TuneView USB
- Software Review: Videator 4.2.1
- FAQ: Frequently Asked Questions
Mike Ash posts his thoughts on what’s new in Leopard for developers.
- Garbage Collection
- Yes, this is a big deal, and Apple seems to have done a good job. I don’t know why people thought this would be impossible, though, given that other versions of Objective-C have had garbage collection for a long time.
- Objective-C 2.0
- Like Ash, I’m not really a fan of properties and find the new
for…insyntax unexciting. However, given the addition of garbage collection and the changes in the 64-bit runtime, I think it definitely deserves to be called 2.0.
- Xcode 3
- You’d think that having a rock-solid IDE would be a high priority, but Xcode (like Project Builder before it) has consistently been “buggy and weird.” Like Ash says, it’s not as if there’s an alternative, but I spend as little time in it as possible.
- Interface Builder 3
- Overall a huge improvement. Too bad about 2.x palette compatibility, though.
- I haven’t had a chance to use it much yet, but it looks promising. DTrace is great.
- Core Animation
- Good technology, but there’s little guidance on when and how it should be used.
- I’ll be using this.
- Miscellaneous API additions
- As with Tiger, Leopard includes lots of small improvements to the APIs, many of which I’d already rolled my own versions of. Eventually, if the Apple versions prove solid and flexible enough, and when I’m no longer supporting Tiger, I’ll be able to delete some code.
- 64-bit support
- This is going to be important, and I’m glad it made the Leopard release. Apple’s treatment of Carbon developers has been shameful, even though the actual decisions have been unsurprising and were arguably the correct ones.