The Squizion Software weblog

I started using Apple’s OS X full time quite a while ago, back in the 10.1 days. So long ago that I don’t remember what its codename was, maybe Puma? (I suppose I could look it up.)

Anyway, as a command line geek, I wanted a system where I could build and modify my own software. As most command line geeks know, running through the ‘./configure && make && make install’ steps for each piece of software that you want to play with gets old pretty quickly. So originally, I started using Fink because at the time it was the most mature system.

There are lots of good reasons for using a packaging system, but having a system for automatically fetching and installing dependencies is fantastic if you want to experiment with random code that someone else developed and released. Because chances are, that random code depends on some other random library written by someone else.

There are a number of things that I like about Fink:

• it worked really well for me — generally, when I found some new software that I was eager to try, the software (or at least its dependencies) was often already ported in Fink
• the addition of binary packages was a great thing
• the community was helpful

And some that are kind of stifling, like the rigidness of the Fink motto, “there’s only one way to build a package.” Of course, I understand the argument for it, and that there were various (unsupported) ways to get around it. For a volunteer organization, it’s hard to allow too much flexibility.

When I upgraded to Leopard, I decided to try out MacPorts because of the feeling I was getting from Fink that its support was stagnating. It’s hard to tell where the momentum is without doing some comparison of the traffic / quality of the developer lists. At this point, I feel more comfortable relying on MacPort for my software.

There was an adjustment period. But it was mostly a matter to translating the commands I was used to from fink into MacPorts syntax. At first, it was a little confusing to get thrown into variants coming from Fink, but they make sense. I wasn’t used to checking out the various options before installing a new package. Overall though, the transition was pretty easy.

I started writing my own Portfile [link] recently, so that’s another sign that MacPorts is growing on me.

However, after reading some recent email on the MacPorts developer list, I see the same themes that came up periodically in Fink.

• what about binary packages (vs. what about security)
• too many ports and updates, not enough maintainers

I can’t yet tell where these themes are going to go. It really depends on how much the community gets involved in making improvements. From what I can tell, it’s a matter of making contributions (time). The community is definitely open to receive them.

For me, the migration was worth it. I was able to install the software I wanted to use — such as svn, gnupg, git, imagemagick, ragel, scons. It allowed me to prune a bunch of old cruft that I never use anymore. It allowed me to experiment with a different OS X packaging system.

We’ll just have to see what happens next. I’m happy with MacPorts now.

My friend Trey started a new programming blog with weekly Emacs tips. Awesome!

I recently read (and promptly re-read) Steve Yegge’s emacs tips, which is full of good info.

I use Emacs all the time when I’m on Linux, but I rarely hack elisp. I can get around well enough, but there’s plenty of stuff that I know I could be doing better (faster, or more efficiently, or without dropping into the shell) if I had a genuine emacs master looking over my shoulder.

I’m looking forward to exploring some “new-to-me” features.

Found during pair programming (yes, I do it sometimes):

class Foo {
public:
Foo(bool in);
...
};

...
Foo f = new Foo(true);
...

Yikes. Didn’t expect that to get by the compiler. But it did. Without even a warning. The compiler was happy to turn “new Foo” into a boolean value and instantiate f, silently letting the memory leak away.

This helps:

class Foo {
public:
explicit Foo(bool in);
...
};

But still. Ug. Single argument constructors in C++ are just evil.

It’s not rocket science, but it surprised me just how painlessly I could set up automatic web site updates from my subversion repository. It’s all documented out there on the net, but this is my chance to record how I manage this site.

My testing ground is a working directory. My published web site is a working directory. When I commit a change, the published site is automatically updated to the latest trunk code.

• Set up the published site as a working directory:
  

  svn co file:///path-to-my-repo my-web-sitedir

• Set up the post-commit hook (in /path/to/my-repo/hooks) to run ‘svn update /path/to/my-web-sitedir’. There are more details in the subversion FAQ

Of course, none of that fancy version control applies to these blog posts. Posts are in a database and there’s a plugin for managing versions.

Hello, my name is Dave and I’ll be your host this evening.

This is my first post on the Squizion Software weblog. On this blog, I’ll be writing about topics that interest me: software, Linux, OS X, ruby, my family (ok, should have put that last one first).

Check out About Me if you want to know more about me. And enjoy…