RegexKitLite, from the developer of RegexKit, uses the ICU engine instead of PCRE and has a highly simplified API. This makes it very small (since ICU is built into Mac OS X) and gives it better support for Unicode. It’s also potentially more efficient, since ICU can often use an NSString’s UTF-16 buffer rather than creating a separate UTF-8 buffer, as would be required for PCRE. ICU’s regular expression syntax is not as rich as PCRE’s, however.
Archive for March 2008
Regression: This ability has never existed, but ever since the arrival of virtual machines in Mac OS X, developers have dreamt of being able to do this.
The engineer in me says that the page is already in the browser-window box—another box is just not needed, it’s waste.
And the designer in me would rather see an aesthetic that embraces the reality that it’s all lights and pixels on a flat screen. It’s not the real world or even the printed page. Why pretend it is? Isn’t there something to be gained by going with what-it-is rather than fighting it?
There can be a file in your top-level Library's Preferences folder called com.apple.SystemLoginItems.plist. This mechanism is used by a very few specialized applications that launch on a per-user basis and want access to the Window Server, but need to launch before the user actually logs in. (Timbuktu is an example of such an application.) It is deprecated in Leopard, where you're supposed to use a LaunchAgent instead; but some older programs still use it.
Ars Technica has a good review of Aperture 2.0:
The Color Vibrancy is genuinely great at doing what it is designed for: “selectively boosting saturation without adversely affecting skin tones.” […] It’s definitely effective, and I can’t quite figure out what it’s doing, which (as a retoucher) is driving me a little crazy. Local contrast definition, on the other hand, looks a little more familiar. Advertised as “offering local contrast for adding clarity to images,” the Definition adjustment looks a lot like unsharp masking with a really wide pixel radius.
Code signing itself is a neutral technology, but it gives incredible power to the system vendor, and that power is just waiting to be exercised and abused. I believe that the iPhone is serving as a testbed to see how users and developers will react to an environment with ubiquitous code signing and control. If it goes well I think we can expect to see our desktop Macs gradually move in this direction as well.
Overall, I like what Apple announced. I don’t mean to take away anything from what looks like great work they’ve done. However, I do want to point out that the spin was a bit much:
- Apple is taking 30% for what amounts to a VersionTracker listing. This is an acceptable, if a bit stiff, deal for most developers. However, it’s a much larger cut than Apple gets for music, and it seems to be more than what Apple would need just “to pay for running the App Store,” as Jobs said. It’s more like an access tax.
- Forstall said that Apple is opening up the “same native APIs and tools that we use internally to build all our iPhone applications.” More accurate would be to say that the SDK includes the subset of the APIs that Apple will allow developers to use. There are a bunch of very important things that Apple’s built-in apps can do that will not be available to developers.
- Jobs’s previous statement that the iPhone contained the entire OS, except for data such as desktop pictures and sound files, turned out to be a huge exaggeration. Lots of modern Mac APIs (that have nothing to do with the mouse or keyboard) are missing “to keep things slim.”
As with the original sweet SDK, Apple has made entirely reasonable business and technical decisions, but they chose to spin them unnecessarily.
Sven-S. Porst has written a lengthy post about how Time Machine works, as well as how it can be configured and used. It covers a bunch of interesting issues that I don’t think anyone else has collected into one article.
The March issue of ATPM is out:
- Bloggable: A Cold Day in Redmond
- MacMuser: The “Can Do, Just Works” Principle
- FileMaking: FileMaker 9
- Desktop Pictures: Havana Vehicles
- Hardware Review: ArtixScan M1 Dual Media Scanner
- Software Review: LicenseKeeper 1.3.2
- Software Review: MacPool 8.9
- Hardware Review: Wi-Fire
- Software Review: Xslimmer 1.5
- FAQ: Frequently Asked Questions
In MacRuby, all Ruby classes and objects are actually Objective-C classes and objects. There is no need to create costly proxies, convert objects and cache instances. A Ruby object can be toll-free casted at the C level as an Objective-C object, and the Ruby VM can also handle Objective-C objects without conversion.
I hope this can be done for Python, too.
“Tweak it afterwards” makes it sound lightweight. It’s not. In other screen recording software, such as Snapz Pro X, you define a region of the screen to be recorded and if a dialog pops up somewhere you didn’t expect, you start all over again. ScreenFlow does away with all that: you record the entire screen, and zoom in or crop the video later. That alone justifies the application for me. You can also add highlights such as cursor circles, click targets and sounds and keystroke overlays—all automatically and all after the fact.