a glob of nerdishness

April 30, 2008

Version Control

written by natevw @ 2:43 pm

There was never any question that I was going to use a version control system for this year’s development work. The question is, which one?

Obviously, CVS is out. I’d rather use plain old RCS. Xcode does have nice Subversion integration, and Apple’s development tools are pretty good at working around its precious .svn litter. However, with a lot of development work happening on my laptop now, the server ball-and-chain is very unappealing. (Not to mention that in lieu of a real backup plan, my server was getting powered down and hidden just about every time we left our rental unattended.) Even some of Subversion’s own developers have bravely and frankly admitted that Subversion is not the future of version control, at least not for developers who have any choice in the matter.

After playing around with a couple of the modern alternatives, I’ve definitely caught the Distributed Version Control bug myself. Other folks have explained DVCS better, and given a number of reasons [pdf] for it. I’m addicted for two simple reasons: it’s light, and it works offline. Making a repository is as burdenless as creating a directory, and I don’t need to be at home for the utilities to work.

The question remains: which utility? I quickly narrowed my choice down to Bazaar and Mercurial, but was then at an impasse. (Git was out from the get-go. There are some brilliant minds behind it, but that’s also a shortcoming. I’ve got better things to do than comprehend the brainchild of hard-core Linux hackers, and they apparently have better things to do than support their mess on the other two major operating systems.)

Mercurial has some cool features which I don’t claim to fully understand, like the Mercurial Queues patch management system. There’s a few things that seem strange (like the CVSesque lack of versioned directories) but in practice things like don’t usually come up. I know of at least one other Mac developer who chose Mercurial over Bazaar. I like Bazaar’s clean command line and its clean website, and how it rarely needs me to fiddle with its configuration files. I’ve joined the #bzr chat on IRC a couple of times, and the folks there are friendly, helpful and focused.

I had told myself originally that I would just use Mercurial, but in the course of playing with them both I ended up accidentally using Bazaar for my original prototype. As I was liking Bazaar anyway, I decided to stick with it for code and have been happily using it for months now. I did start using Mercurial for something else lately, and found myself annoyed at all the manual configuration file tweaking it made me do versus Bazaar, and in the process was reminded how much less polished going to the Mercurial site for documentation feels.

If you’re having trouble choosing between Bazaar and Mercurial, the best advice I have is a coin. You can even bias it before flipping! Overall, they are both excellent choices for a developer who mostly wants to code. To be honest, that’s kind of a shame. It seems like Mercurial has hit a sweet spot for developers who know better than to try reconfiguring their minds for enjoyment of the heroic git, yet do want something they get to wrestle with a little. I’m happy for the Mercurial team, but would hate for what Bazaar represents to lose out.

As a Bazaar fan, I really enjoy its usability and polish, yet I so often see “Mercurial or git” as if they were the two options from Subversion. It feels like I’m the underdog with a Macintosh in the 1990s, hearing someone say that they’re “deciding between Windows or Linux”. I do have confidence that even if Bazaar doesn’t have an “OS X” in its future, it is popular enough that I will be able to migrate should the need arise. The Bazaar and Mercurial teams are on good terms, perhaps they will eventually find a way to pool their mindshare against the lead dog. Until then, it looks to be an interesting race!

April 25, 2008

Debugging Universal applications in Rosetta

written by natevw @ 11:02 am

Apple have a guide on debugging PowerPC binaries on an Intel-based Macintosh. Unfortunately, those instructions do not work if the application is a Universal Binary.

If Xcode’s build settings dialog hadn’t gone from kinda bad to utterly screwy, it might have been easiest just to temporarily edit your application target’s build settings to build just ppc. As an alternative, you can use the following steps to debug the PPC code of a Universal binary on an Intel Mac:

  1. First, make sure your Debug version of your application’s target is set to include the ppc architecture. It may be set to just the “Native Architecture” to speed up normal debug builds.
  2. You will need the OAH_GDB environment variable set. In bash, use: export OAH_GDB=YES.
  3. Instead of running your application directly as Apple’s reference states, use /usr/libexec/oah/translate /<path>/<your_application>.app/Contents/MacOS/<your_application> from the shell in which you set the OAH_GDB flag.
  4. Open another terminal tab and start gdb using gdb --oah.
  5. Instead of attaching to <your_application>, you will need to attach to the “translate” process that’s running your app. GDB may autocomplete the whole thing if you press Tab after typing just “attach “.
  6. Now use gdb’s c command to Continue (or start, in this case) execution. Prepare for extremely slow execution, since your app is running under both Rosetta and the debugger.

Note that only the odd numbered steps, especially steps 3 and 5, differ from Apple’s instructions. Since it’s a Universal Binary, you have to force PPC behaviour by manually starting your application in the Rosetta translator.

Whichever method (compiling ppc-only or running via translate) you like better, you will likely want to load your app’s symbols with the gdb command symbol-file /<path>/<your_application>.app/Contents/MacOS/<your_application>. If you’re like me and generally inept with raw gdb, you may find the tips and links Apple’s Using GDB for Testing article to be a good starting guide for learning your way around gdb. There are some caveats to debugging under Rosetta mentioned in the first Apple guide, especially that you can’t call functions. Of course, I didn’t realize that was even possible, so I guess I’ll have to try that when I’m debugging normally sometime!

April 8, 2008

Starting up, staring up

written by natevw @ 8:05 pm

Today was one of those days where I did a lot of errands, a few little tasks, and some communication, but not much actual programming progress. A little frustrating, but since I’m not in a mood to code anyway I might as well take this new non-monospaced font for a spin. I haven’t really followed up on what’s been happening since I quit my job at the end of last year.

I’ve been a bit hesitant to elaborate online exactly what I’m doing. Now that I realize how much work is actually involved, I feel a bit more comfortable sharing a little more! I said before, “my mission is simple: Create the best software for organising photos geographically.” The mission is still that simple, even if the work is not. While the past few weeks have taken me more into the photo and organizing side of things, the “geographically” part involves pushing my mapping skills way beyond where they were last year.

To me, that’s the most exciting part even though it does involve maths and algorithms and architectures that I really should have learned before I met the real world. (Pun intended?) Even the current progress — too lurid to flaunt in public right now — makes me glad I’m taking the hard road. I’d already come across EveryBlock and noted their similar feelings on cartography, and today one of their co-founders posted an article about creating custom maps. The beginning of the article is a nice confirmation that my work is worthwhile.

Nervous joking about famous last words aside, things are more or less progressing well. Many days can still be a struggle to think clearly, yet I’ve been able to keep course despite many new product ideas and a few new platforms. (The Software Developer’s Kit for the iPhone and cousins being quite high on that latter list!) As far as the startup process goes, I think I am somewhere near the “Crash of Ineptitude”, but Hoping that I am already past that and into the Wriggles of False…Hope. Oh.

So what’s the plan from here? For me, it’s mostly keeping my head in the game and continuing to do the best I can with the time and talents I’ve been given. In less than two months, one good friend is planning on moving out to the area to help part time, too. Hopefully around that time you’ll start seeing more activity on Calf Trail Software’s home page as a result of my work and his, with a light dose of some graphic design provided our artist comes back online.

After that the real work begins, I suppose. It’s likely that that startup diagram is actually fractaline in nature. What are the chances it will be worth it? There’s a lot of potential out there; that makes me eager to get back to work tomorrow.

Up-gradorred!

written by administrator @ 8:34 am

There were about 5,042 critical security flaws patched between the blog software that was installed and the one I upgraded to this morning. Now that I’ve gotten around to it, the cynic in me expects that tomorrow morning a huge big messup will come to light and I’ll have to do it all again. Sigh…

Anyway, while I was mucking about with it, I also tried switching themes. I kind of liked the “Classic” theme that came with this and was tempted to keep it, until I noticed that the “older/newer” page links seemed to be swapped. If I were going to do any sort of troubleshooting on this blog engine, I would just roll my own for practice at this point. Since I have a life, I just tweaked the stylesheet a bit to at least lose the atrocious monospaced font in the main text. This still doesn’t seem to be a great font for setting extended text, but I’ve been trying to ramble less anyway. (Besides, it’s better than before. And if you don’t like this, you should see the *colors* in the new admin pages I write this with.) Someday when I have nothing to do, I will integrate this blog into the main site better. Uh-huh.

So anyway, I’ve got work to do. Later.