Thursday, November 27, 2008

A Tech Support Mystery

Last week, my co-worker Gerald came to my cube saying his PowerMac G5 was consistently locking up after starting up and bringing up Entourage. He had come to me as I am the Mac programmer on staff, and therefore considered to know all things Macintosh.

I went down to his cube to find the G5 unresponsive to mouse clicks; locked up just has he had said. Very odd. After a few seconds of futzing around I realized that the machine did respond to right clicks. And a few seconds later, Gerald mentioned in passing that every time he restarted, the optical drive ejected. I immediately knew what the problem was. Can you solve this mystery? Answer below.

The left mouse button of his Logitech mouse was stuck in the clicked state. Thus the machine was non-responsive to mouse clicks, and as everyone should know, holding down the mouse button while restarting will eject the optical drive of a Mac. I went and got a Mighty Mouse, plugged it in and the machine worked perfectly.

Friday, November 14, 2008

Patience Needed for Switching .mpg Application

My MythTV records over the air broadcasts as .mpg (MPEG) files of several gigabytes each. My preferred mode of viewing them these days is to open up a SMB share on the MythTV box, copy the file over to my MacBook while I'm working and then view it later. Amongst the many annoying things about this process—inefficient SMB transfers, avoiding having Time Machine back up the show, OS X not letting me watch a partially transferred file—a small one is that Quicktime owns the .mpg extension, when it'd be nice if VLC did. But every time I would open a Get Info window on a .mpg file the whole Finder would lockup, apparently generating the preview. And then I'd relaunch the Finder after a minute or so. So I never was able to click the Change All... button.

Turns out that the Finder will eventually, after several minutes, give up with creating a preview, and you can change the Open With application to VLC and then click the Change All... button. So be patient.

Friday, November 07, 2008

Sleep Advice for Geeky Fathers

As a father of young children, I have some advice for my fellow software engineers in similar boats who want time for their side projects. At some point, if you are lucky, your children will be sleeping from their bedtime of say 9:00 PM to maybe 7:00 AM depending on their natural needs. My advice is to work within this framework when it comes to your own sleep schedule.

Every day, come home from work, play with your children till their bedtime, fall asleep as they do and wake up naturally. For me, falling asleep at 9:00 PM will mean waking up in a quiet, empty house at 4:30 AM with 2½ hours of time to work on my software projects and catch up on my TV watching before the children awake. I will spend the rest of the day fully rested, and at my peak performance. Compare with the alternative strategy of staying up after the babies' bedtime which if I "get on a roll" might keep me up till 12:30 AM, with no margin for error. What if the babies wake up at 6:00 AM as they sometimes do? I'll spend the rest of the day under a sleep debt: low performing and grumpy.

Also, my recommended strategy allows you to pay off your sleep debt. If you do this and wake up later than expected the first few days, you had an accumulated sleep debt you needed to pay off before reaching peak efficiency.

I'm basing this advice on this Google Tech Talk which I highly recommend watching:

Thursday, November 06, 2008

When Is A Leak Not A Leak

I was sent a bug report on some software I had written a while back wherein it would become less and less responsive over time till it just sort of died. Sounds like a leak.

But when I hooked it up to the Leaks Instrument, I saw no leaks. No red peaks at all. Must not be a leak then.

But one more look. The net objects allocated were going up and up and up. This should not happen, the application should have reached an equilibrium point of net objects allocated, and oscillated around it.

So, I let it run for a while in the Objects Allocated instrument, and then examined the blocks which were being allocated and not deallocated. Turns out I had an object, an audio player, which had a scheduled NSTimer associated with it. When I released the player, it was still being referred to by the NSTimer, so it did not get deallocated. And in this case, I was creating one of these every second or so (probably not a good idea), which meant that not only was the memory leaking, but all those timers were adding overhead to the event loop. No wonder it crawled to a halt. So remember to invalidate unwanted timers.