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.
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
People sometimes ask me why I don’t charge for the software I write. I explain to them that, to me, it’s not about the money. But that’s only part of the story. After thinking about it there are a few reasons why I release everything as open source.
1. You’re Giving Back to the Community
This is what the entire FLOSS community and its mentality is about. You have this great software and you want to give back to the greater community by making it open source. Doing so means that all developers can see how you’ve chosen to implement certain things, they can borrow code, and they can help improve software by submitting patches. For me, I learn a lot of programming languages and techniques by dissecting open source software, and I feel it’s only fair for me to give back to the community as much as it has given me.
2. You Don’t Worry About Business
I’ve been reading some articles about indie development and I watched all of the C4[1] videos. From doing so, I’ve realized that starting an independent software shop is a lot of work. You have to get a credit card processor, you have to have a licensing infrastructure, you have to worry about piracy, and (arguably the most difficult) you have to find the right price for your software. We’re software developers, not business people. This is not my idea of a good time and I’d much rather spend time developing rather than doing the aforementioned tasks. Going open source frees you from all of that.
3. People Can’t Have Expectations
That is sort of a half truth. People will always have expectations about software, regardless of whether or not they pay for it. But when you develop open source software, you’re essentially a volunteer. People get what they pay for. I try to do my best in creating software and supporting it, but because it’s open source, there’s no expectation that I have to. As a full-time college student, I don’t have a lot of free time — I develop when I can. If I had paying customers, there’d be an expectation for future versions on a reliable time scale, but I’m not under that pressure. Additionally, I do not have to support this software with immediate email responses, blog follow-up comments, or forum posts. I do so because I like doing so. If this were a business, people would have high expectations for support, but because I do open source work, if I deliver good support, it’s only a bonus. If I don’t, they really can’t complain because they don’t pay for anything.
