MacGDBp 1.3

I’m pleased to announce MacGDBp 1.3. This release features a new tool that allows you inspect values in the variables list via a HUD (screenshot below). This inspector will allow you to see long strings and to select/copy text values. To access this feature, go to Window → Inspector (Shift+Cmd+I). The currently-selected variable (which now, in 1.3, remembers itself across debugger stepping) will have its full value displayed in the HUD window.

Under the hood, there are two significant changes. The first is a rewrite of the receiving side of the socket layer (it now precisely uses the message length when buffering memory), which should eliminate the “buffer is incomplete” errors that occasionally popped up. The second is that the PHP stack will no longer be managed internally. After every debugger step, the entire stack will be now re-created because Xdebug proved to be unpredictable for keeping in sync with an internal state. Debugger actions may now seem a little less snappy, but I think accuracy is more important than speed here. In 1.4 I’m going to use a caching mechanism that will speed up performance by reducing network access.

This release also features a bunch of bug fixes, a couple of which would cause the debugger display to not work under certain circumstances. As always, the change log and commit log have all the details on the release.

Firefox vs. Safari: Toolbars

I cannot commit to a web browser. I like Firefox because I think it provides options (via extensions) and the awesome bar is, in fact, awesome. Safari however provides better platform aesthetic and WebKit is a faster rendering engine.

But besides that, I noticed recently that Firefox feels a little “cramped” after using Safari 4 beta. And this is the reason why:

I’m amazed at what 24 pixels can do.

Toolchain and Gitcrement

I’ve posted today a git repository called Toolchain. This is a collection of scripts that I use that others may find helpful. You can find the repository here. In this post, I’m going to talk about one of the items in Toolchain called Gitcrement.

Gitcrement is a set of two scripts that solves the problem of creating build numbers when using git for source control. Unlike Subversion, where the repository revision is the perfect choice for a build number, git has no such luxury because it uses SHA1 hashes for identifiers.

This is where Gitcrement comes in. Gitcrement is a simple interface to a database that contains a sequential ID number (the build number), a username, the current date/time, and a git SHA1 hash.

The gitcrement.py has four commands: init, next, list, and current.

To create a new Gitcrement database, go into any git repository root and type “gitcrement init“, which will create a new database file called .gitcrement.

When you want to create a new build number, simply type “gitcrement next” to record the current user (`whoami`), date and time, and whatever SHA1 hash `git info .` would reveal.

To see the current build number type “gitcrement current” and to get a list of all the build numbers type “gitcrement list“.

That’s all there is to it. To make this system useful, however, it needs a script that can be run in Xcode to automatically call “next” and save the value as CFBundleVersion in Info.plist. So, there’s another Python script called xcbuild.py, which you can use as a Custom Shell Script Build Phase. This will advance the Gitcrement number every time you build the “Release” target in Xcode.

Gitcrement requires Python 3.0, which is not installed by default in Leopard. You can find it here or through MacPorts or fink.

Also, you may need to edit the installation paths in the tops of both files to point to where your copy of “git” is (in gitcrement.py) and where you install the “gitcrement” script (in xcbuild.py).

You can download Gitcrement here:

Link in Gitweb

Source TGZ

Chromium for OS X

Mac users interested in Google Chrome can now try out the latest pre-alpha development version. I have compiled the source tree and the binary can be found here. I’ll be rebuilding and posting the build roughly once a week.

As it says on the page, these builds are unstable and should only be used to see how development is progressing. I will not support these builds and (I’m assuming) neither will the Google team. That being said, enjoy.

Bugdar 1.2.3 and the Future

Today I released Bugdar 1.2.3, exactly 364 days since the last release of Bugdar. I regret that this release was so long-coming and was far overdue. This release fixes a bunch of bugs that have been accumulating over the course of the past year.

In the future, I will not drag my feet when releasing minor updates like this. The problem is that the current code base for Bugdar (currently the 2.0 Alpha) is quite incompatible with the 1.2.x line. This means, all fixes for bugs affecting 1.2.x need to be redone for 2.0 — which is a lot of duplication of effort. So, rather than continuing to do that, I came up with a better solution.

Bugdar 2.0’s development has been broken up into distinct phases. Unfortunately, due to my own lack of time, progress is slower than I would like. Therefore, I’ve decided that there will be a 1.3 branch to “bridge the gap” between the far-off 2.0 and the current, aging 1.2 branch. Phases 1-3 of the 2.0 development cycle are really underlying architecture changes that just bring the code base up-to-date. After those three phases are complete, Bugdar 2.0 will look and work essentially like version 1.2, but will be more robust and (most importantly) will have a significantly improved language system. It is after Phase 3 that I intend to branch the 2.0 development line into two (the maintenance branch 1.3.x and the current development head 2.0). This would effectively kill the 1.2.x line. And because the two branches would have a more recent ancestor, migrating patches should be easier.

This branching strategy requires little work on my part and will reduce the time I spent migrating patches between branches. Also, it will put in place a language system that will work across 1.3 and 2.0 which is crucial. I have been wanting to create a language pack exchange system so that users can collaborate on and exchange translations of Bugdar, but at present the MO/Gettext system is not good for that. This new language system will be designed to do that. And this branch strategy will get that deployed sooner rather than later.

I wish I could have some sort of timeline for when 1.3 will come out, but I can only really say “as soon as I can.”