Programming

More about the iPhone dying

/ hsoi

I mentioned how on Sunday my iPhone died, apparently of sudden and complete battery drain.

I’m still mystified as to why, but a friend read my blog posting and said he knew of two similar experiences. He said he believed the culprit at the time was a game called “Stick Wars Lite“. Funny he should mention that!

I was going to pick up foo.c to take him to the IPSC match but I arrived very early and didn’t know if he’d be up and about yet, so I pulled into a nearby strip mall parking lot and started to fiddle on my iPhone. To my surprise, foo.c pulled in next to me because he wa coming to grab some breakfast. I got out of the car and went into the shop with him. All this time the iPhone was in my hands. I heard some faint music and looked at my hand and noticed that the iPhone was still on and the screen must have been touched because it had brough up a game.

Stick Wars Lite.

I distinctly remember that game being active.

I then just hit the power button to put the phone to sleep.

Three people experiencing this? Might be more than a coincidence. However, I’m not sure that is the problem because I’ve attempted to reproduce it and it won’t happen (of course).

Nevertheless, I believe the phone did die because the battery was drained by something not playing nice and thus consumed all the power. One recommendation given was to never put your iPhone to sleep with an application active, to always go back to the Home screen before sleeping it. IMHO that should not be a requirement, or if it is then the iPhone ought to handle it automatically when you hit the power button.

I’ll keep an eye on things and if I can reproduce it, certainly I’ll report it to the developer. Being a developer myself, I appreciate it when people file (useful) bug reports, so I make sure to do the same for my fellow developer. Need a reproducible case first. 🙂

Learning to Program

/ hsoi / 3 Comments

I learned to program on my Apple //e a long long ago.

But I did take a class in undergrad that was a sort of introduction to programming for non-programmers (now that I think about it, I don’t know why I took the class as it was well below my knowledge level). It used a neat book called Karel The Robot. You can Google on “Karel the Robot” and all sorts of stuff comes up, including a lot of love and praise for it. It’s really a good way to learn how to program because it’s simple and friendly. It doesn’t focus upon a particular language, which is part of the simplicity and appeal. It allows people to learn about general programming concepts and constructs, and how to use them as building blocks to solve problems. After you grok the concepts, then you can get yourself caught up in the semantics of a particular language… trying to do both at once is just too much to focus on.

So I’m writing this blog entry as a bookmark to myself. I’ve been wanting to teach my kids how to program and wanting to use Karel to do it. So I found Karel on SourceForge. I also found RUR-PLE (history of it here) which is a Karel-like approach that uses Python. There’s also Guido van Robot. I really like Python as a language (tho I don’t get to use it often enough), and feel it’d be a great first language for my kids.

Anyway there you go. Karel.

The plutil command obeys no one’s rules but its own.

/ hsoi

I love stumbling across little bits of programmer humor.

I just looked at the man page for plutil (“man 1 plutil“):

STANDARDS

The plutil command obeys no one’s rules but its own.

Heh heh.

Working on a smaller machine

/ hsoi / 1 Comment

As a software developer I appreciate having good hardware. In fact, I appreciate having lots of good hardware as that best facilitates getting work done in a day.

Over my career I have evolved what I prefer to have for optimal work. I like to have a laptop on which I do “communication” work. So the laptop does email, web browsing, instant messaging, and whatever other administrata or time wasting I wish to do. Having it on a laptop is good because often such tasks require portability. I do set up the machine to also do development work, but it is not meant to be a primary dev machine.

I then like to have a very beefy machine for dev work. For instance, these days something like an 8-core Mac Pro with 10 GB of RAM and multiple internal hard drives works very nice. I also like to have multiple monitors attached to the machine because lots of screen real estate is good. Furthermore, it works better to have multiple monitors instead of one big monitor because there is often different logic that can be done based upon “screen 1” or “screen 2”, especially when doing things like debugging and needing to cope with the menubar and screen redraws.

Finally, I like having extra machines for whatever needs. These are often sandbox machines of various configurations that I can nuke and pave and do what I need to to help test, reproduce bugs, and so on.

So as you can see, I’ve found surrounding myself with a lot of machines is a daily necessity for getting my job done.

What happens when I’m forced to use a little machine for everything?

I’ve been temporarily reassigned to another group in the company that needs some help with their projects. Due to the nature of the products and the fact I like to keep very clean machines (sorry Unsanity; no Input Manager hacks here), plus given the nature of the work may require working in other locations, I requested they provide me with a laptop for dedicated use for this work.

I received one. A recent MacBook Pro.

15″.

Man, that’s small. Well, to me at least. 🙂

Compounding that is Apple changed some things in Snow Leopard to make stuff bigger. For instance, the default font in Xcode is Menlo Regular 11, instead of old Monaco 9 or 10.  I played with it some trying to pick other fonts or make things smaller, but I have to say, after I got over the initial shock my eyes do like the Menlo 11 better. But with bigger font means less content on the already smaller scren.

Then when I need to run Xcode for dev work, TextWrangler for notes and other things, Firefox to get into the bug database, and a few other apps… gah. Too many windows on that little screen. Sure I love Exposé and use it all the time, but it’s still a lot for that little screen.

So I started to use Spaces.

I toyed with Spaces before, but I just haven’t had a compelling need for it. I think it’s neat. I’m glad Mac OS X has it. But I haven’t been able to successfully put it into my workflow…. until today.

Turned it on, 4 spaces. Xcode on the main, TextWrangler “below”, Firefox “to the right” and since I prefer to use the keyboard I know the shortcuts to navigate around. Man… everything worked pretty slick. A few things were annoying, such as being on the non-Xcode space and then Xcode’s build window popping open on that space; it makes sense in a way, but it’s not what I want… I want to keep that app’s windows on that space. I wonder if there’s a way to force that.

I don’t know if I’d need to use Spaces on my big dev machine with the 2 monitors and lots of screen space. But on the little machine yeah, what a help it was.

Finally Upgraded to Snow Leopard

/ hsoi / 3 Comments

Finally was able to upgrade all of my Macs to Snow Leopard (Mac OS X 10.6).

You see, as a software developer I can’t always jump on the latest bandwagon. Sure I might have new OS versions running on partitions of other machines, maybe even pre-release versions. But I can’t primarily change things around because we might be in the middle of something. If I’m working on a release, to change things like the OS or the toolset could bring about big delays or other troubles. The rule is to settle on the toolset and environment, make the release, then you can upgrade stuff. And so finally I can upgrade, tho I have been using Snow Leopard in various capacities for some time.

I am enjoying the little refinements in the OS. I’m glad Apple took the approach they did with this OS and working on refining what they already have instead of having to cram a gazillion new features in. Make what you have really good.

One thing I got the most kick out of was seeing a lot of disk space reappear. My MacBook Pro was down to only a couple GB free and I was starting to look at buying a bigger replacement hard drive. After installing Snow Leopard, I regained almost 20 GB of disk space. Of course, I know exactly why this change came about, but that doesn’t make it any less wonderful. 🙂

OmniObjectMeter, I love you

/ hsoi

Last night and this morning I’ve been dealing with some odd behaviors in the code I’ve been writing. I know it’s my mistake, the trouble is finding just where the mistake is. I spent time in the debugger observing behaviors that lead me to believe some object instances were not being released thus causing the side-effects I was seeing. As well, the lack of deallocation is a pure memory leak. So, find and fix the leak and many things should improve.

The current tool from Apple for finding memory leaks is the “leaks” tool of Instruments. I do think Instruments is cool and very powerful, but it’s also extremely obtuse and complex. It’s a tool that I don’t need to use all the time (in fact, rarely). Consequently what I learned the last time I needed it has left my head so I have to ramp up all over again. That’s just too much precious time spent, and too many brain cycles distancing myself from the problem at hand. Tools should not get in the way of solving your problem. Before Instruments, Apple had tools like MallocDebug and ObjectAlloc, which were useful and simpler tools but still weren’t the best in terms of interface and usability.

Some years ago I discovered OmniObjectMeter from The Omni Group. It was a godsend. It allowed me to pinpoint and track down memory leaks quickly and easily. It was so simple, so logical, so well thought out. It was easy to get going with it, it was easy to use it, and most importantly you could find your problems very quickly. Unfortunately OmniObjectMeter was left to languish and didn’t work for some time (there was a “secret beta” that helped it limp along). But I’m happy to report it’s back up and kicking with version 2.6 that was released February 2009. You see, I tried using Instruments this morning and while I could see the leak I couldn’t exactly pin down the location that caused the leak. I lamented for OmniObjectMeter, checked the Omni website on a whim, discovered v2.6, downloaded it, and within 5 minutes my leak was found, fixed, and verified.

That’s testimony. 🙂

I’m glad she’s still working. Plus, now OmniObjectMeter is free! I’m proud to say I paid for my copy (well, I got the company to pay for it) all those years ago. So FTC, yet again this is just a satisfied customer telling the tale of his happy experience.

AppleScript is not dead (yet)

/ hsoi / 5 Comments

Jason Snell @ Macworld has an article reacting to Jonathan “Wolf” Rentzsch‘s declaration that AppleScript is dead.

Hrm… get this. That previous link to AppleScript takes you to the developer web pages for AppleScript. I originally wanted to link to Apple’s user/commercial page for AppleScript: www.apple.com/applescript. But if you click on that, notice what it takes you to: Automator. That tells you what Apple thinks about AppleScript as a technology.

It’s scripting for the rest of us.

Continue reading →

Snow Leopard’s file system changes

/ hsoi / 2 Comments

Mac OS X 10.6 “Snow Leopard” brought a slew of under the hood changes. There are two distinct but related changes that Apple made that most users will probably never notice and many developers probably never will either. But if you happen to be someone who works with the file system, these changes may affect you. These changes are:

1. KB vs. KiB. That is, is a kilobyte 1000 bytes or 1024 bytes.

2. file-system-level compression of files

Since I recently went around with these, I felt it’d be worthwhile to share what I discovered, since there isn’t much information out there on the topic. The only thing I found that remotely discussed the matter was this page of Ars Technica’s Snow Leopard review.
Continue reading →

Mac OS X x86 debugging

/ hsoi

It’s been ages since I’ve had to do anything dealing with assembly language. And while I may not have to do much programming in it, it’s still a useful thing to know when it comes to debugging.

Today I’ve been trapped in debugging hell. We’ve got some code that works fine on Mac OS X versions prior to Snow Leopard (10.6) but seems to hang under 10.6. The code flat out executes differently. I watch how our code is invoked and things just don’t happen in the same order across the OS versions. Apple must have done some major under-the-hood changes to NSBrowser and NSTreeController. And since we’re using Cocoa Bindings, it’s a bitch to debug. Everything that’s happening is happening because of Key-Value Observing (KVO). I get somewhere into the bowels of NSBrowserBinder and it appears to be looping… looping… and never exiting the loop for some reason.

Now that we’re in the new x86-based world order of Macs, I went looking for some tips to help me work with debugging the x86 assembly so I could see what the OS was doing. I found a few useful resources.

Greg Parker at the Hamster Emporium has a great article about crashing in objc_msgSend and how to decipher the crash. I wasn’t crashing, but still there are some nice gdb commands and interpretation of the registers.

Then over at the Google Mac Blog, a 2 part article on spelunking. Part 1 and Part 2. These aren’t debugging articles (more like trying to hack around and discover how undocumented functions work), but they still explain a bit about how the x86 ABI works, AT&T syntax, and how Mac all mesh together. Note that Avi Drissman previously published the same article in his own personal blog, but edited it a bit for republishing in the Google blog.

Clark Cox provides a handy table on how to inspect Objective-C parameters in gdb.

And you thought the only thing I knew how to blog about was guns. 😉

How to manage geeks

/ hsoi

An article from Computerworld on how to manage geeks.

Speaking as a geek, I can say that article is sound. Old school management practices will not work. Once you understand the geek, you’ll see that typically the best thing to do is let them do their job… get out of their way, shield them from crap, do things to enable them to get their work done.

And then we shall… and it shall be productive and glorious. 🙂