This is old news, in blog time, but Gruber’s response to Jalkut’s comment on the Leopard delay misses a couple points.
That’s right in the middle of the most productive stretch in Mac OS X history – 10.0.0 was released in March 2001, 10.1.0 was released in September, and 10.2.0 was released less than a year after that in August 2002.
It only looks productive if you’re going by the numbering scheme. The features introduced in the increments from 10.0->10.1->10.2 were nowhere near as large as what was introduced in 10.3 and 10.4.
10.0 was unusable. That’s why 10.1 was given away for free six months after 10.0 was released. 10.2 came soon after because 10.1 still wasn’t very good.
If the release version numbers weren’t determined by marketing, 10.1 should have been 10.0.1 and 10.2 should have been 10.1.
As far as I can tell, 10.4 was the first release of OS X where it felt slower.
In Ardour, we have numbered audio tracks named Track 1, Track 2, and so on. Most software when faced with what to name the next created track will just use a static int that is incremented with each track.
With Ardour, we wanted to make it smarter. We wanted to be able to re-add Track 1 if the first track was deleted. But not if the first track had just been renamed. We use C++ for the libardour backend, so we were in luck.
The STL includes bitset, a very handy wrapper for what’s essentially an array of booleans, but optimized for space.
The technique is: look for the first false slot in the bitset. The index is the number of the new track. When a track is deleted, mark the slot as false. This lets the user rename a track and it won’t interfere with the counting.
The one problem with this is the size of a bitset is set at compile time. You could use vector<bool>, but its use is discouraged. Luckily, boost.org has an implementation of dynamic_bitset which can be grown during runtime.
This smart counting gives Ardour a polish and the users love it.
I’ve created a boost.framework for those of you lucky enough to be using C++ on OS X. It’s all header files, so you only need to include it in the frameworks path. It doesn’t need to be linked in. It unzips to a large size, but you only pay for what you use.
Based on stuffonfire’s zsh shout out, I’ll be switching to it on all my accounts and giving it a whirl. I’ve made it halfway through the user’s guide, but I might look for an actual book too.
I need to look up the syntax for bash every time I write a for loop, so I don’t have to worry about the difficulty of forgetting my old knowledge. I’ll post if I find anything interesting about it.
I had a hard time finding a definitive statement on MacOS X memory alignment so I did my own tests. On 10.4/intel, both stack and heap memory is 16 byte aligned. So people porting software can stop looking for memalign() and posix_memalign(). It’s not needed.