Software Development

Mach ports are a way for processes to communicate in Mac OS X. (Other mechanisms for inter-process communication include distributed objects and sockets.) A mach port is an endpoint of a communication channel. If 2 processes hold endpoints to the same communication channel, then one process can send messages to the other.

Mac OS X provides wrappers around mach ports — NSMachPort and CFMachPort. But sometimes you have to drop down to the native mach_port_t API.

Don’t do this on whim.

• Works on Snow Leopard (with Mail.app running in either 32bit or 64bit).
• After moving a message, automatically selects the following message (instead of selecting nothing).

Mailbundle attached.

Steve Mokris is a developer at Kosada, Inc.

There are a few functions used to zero out memory on most unix variants. memset(), bzero(), and calloc() are all a few such functions. calloc() isn’t very useful for clearing already allocated memory, so it won’t be appearing much more in this article. However, the other two are somewhat more interesting than meets the eye.

In case you’re not super minimal like we are and don’t already know, Richie Hawtin is the Berlincoolest musician ever. His label, M-NUS, is celebrating its 10th anniversary with, among other things, a blue lighted cube (pictured left). Ali Demirel, visualist for Richie Hawtin, includes Quartz Composer in his arsenal of interactive and realtime media tools, and has been using a couple of Kineme tools to control and interact with his visuals.

He used Particle Tools to get some interesting effects in the visuals displayed behind the musicians during their set. He modified the “Fire” sample to fit with the other visuals and the music.

He also used Kineme File Tools String with URL to access the information acquired by the Cube. Members had RFID chipcards, and it would get their name whenever anyone held up their RFID chipcard to it. Demirel then chose the right moment to display their name in the visuals.

For an interview with Mr. Demirel, including links to videos, check out the full story on Kosada.com.

In the year that has elapsed since I failed to explain why I was using PINE for email, I’ve switched to Apple Mail.

Well, it’s been alright, but much to my regret the improved latency due to keystrokes only traveling around my local machine – instead of through the interweb and back as was the case with PINE on a remote machine – makes it almost justifiable. Almost.

Lately I’ve been working on integrating (or, more accurately, attempting to integrate) the Python scripting language into some plugins for an application we develop plugins for. We’ve wrapped many libraries with varying levels of success, so this one wasn’t going to be much different. Or, so we thought.

People like their applications to work. Even better, they like them to work, even when things change. For the WinTel world, this isn’t a big deal (Vista aside ;), because the underlying CPU architecture hasn’t really changed, from a program’s point of view, in the past two decades. Unless you have a weird program that’s designed for AMD’s 3DNow! instruction set and you switch to an Intel CPU, or perhaps an application designed for a more esoteric old SIMD architecture, your application should run just fine (as long as your Operating System is ok with it).

Mac OS X doesn’t have the luxury of working on the same underlying CPU though, so things need to be handled a little bit differently. The solution Apple came up with was

For years, iPhoto users have been stuck using a limited number of email clients to send their photos easily. This was mostly remedied by the iPhoto Mailer Patcher, but it left out non-applescript aware applications because, after all, iPhoto uses applescript to interface with them. One of the more notable omissions is Thunderbird.

Finally, this void has also been filled, via the iPhoto Thunderbird Bridge. It’s still quite primitive, but all the basics are there for iPhoto-Thunderbird integration.

If you’re an iPhoto/Thunderbird user, give it a whirl.

NSSpeechSynthesizer, the Cocoa class responsible for giving applications a voice under OS X, is leaky. Creating and destroying thousands of instances of this class slowly consumes all the available memory in a system, leading to degrading performance and eventual application instability.

The disappointing part is that this bug was first noticed almost two years ago.