April 18, 2007 at 5:33 pm
· Filed under programming
At my job, we have one of those new espresso pod machines in the kitchen. Usually after lunch, I’ll start to get a little drowsy and need a caffine kick.
Today, I chose the heavy duty espresso forte pod and made myself a double espresso.
After finishing it, I immediately found the puzzling bug that the lead dev and I had been staring at. Super. I then misread the spec and dove deep into Qt4’s QTableView MVC architecture before coming up for air.
There are twothreefour things wrong with caffine.
- Too much and I get anxious and my heart starts jumping
- I start thinking too fast and making mistakes
- I hear you can build up a tolerence, so I’d need more and more to have the same effect
- The inevitable crash
I try to not have it every day, so I can preserve the wonderful, creative effect it has.
Permalink
April 17, 2007 at 5:56 pm
· Filed under apple, software
This is old news, in blog time, but Gruber’s response to Jalkut’s comment on the Leopard delay misses a couple points.
Gruber says:
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.
Permalink
April 7, 2007 at 6:28 am
· Filed under ardour, programming
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.
Permalink
April 6, 2007 at 4:51 pm
· Filed under software
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.
Permalink
April 5, 2007 at 11:06 am
· Filed under news
I’m throwing my hat into the Cocoa/developer blog circle. I plan to write about trends in programming, learning Cocoa, and whatever tidbits and information I learn while working on my projects.
Permalink