Heipei

Yeah, you read correctly. As of right now, this website can be reached via heipei.net again.

For those of you who haven’t been reading this weblog 2 years ago: The domain heipei.net was snatched from me in September ’06. This of course happened to same part due to sloppiness when trying to move the domain (I can’t even recall the details). I have been monitoring the domain since then, and had discovered that the domain started expiring at the end of last year. After a 75-day redemption-period it was finally deleted, and I was able to register it (with no backorder or extra-charge).

Although most people know my weblog by now, I suspect a fair share of them has problems memorizing hackvalue.de/heipei/. And I think I’ll still be getting mail addressed to heipei(ät)heipei.net (at least spam :P). So, starting today, you can also reach me via

Please update any links on your websites/weblogs. The whole site can still be reached using the hackvalue.de/heipei/-prefix, but I’d prefer it if you referred to this domain directly.

Debugging programs for yourself (or from bug-reports from other people) requires knowing which version caused the bug. Of course most people think in terms of major releases, but a developer needs to know the exact revision, as this might make the crucial difference. UNIX command-line programs usually offer a –version switch, which returns detailed version and build-option information.

If you want to have something similar with Xcode you can use the “New Run Script Build Phase” to add a simple script to your build-process. In the case of GitX, the code looks like this (the original can be found at xcode-git-build-scripts at GitHub):

#!/usr/bin/env ruby

version = `/usr/bin/env git describe`.chomp

info_file = File.join(ENV['BUILT_PRODUCTS_DIR'], ENV['INFOPLIST_PATH'])
info = File.open(info_file, "r").read

version_re = /([t ]+<key>CFBundleVersion</key>n[t ]+<string>).*?(</string>)/
info =~ version_re
bundle_version_string = $1 + version + $2

info.gsub!(version_re, bundle_version_string)
File.open(info_file, "w") { |file| file.write(info) }
puts "Set version string to '#{version}'"

Needless to say that this script is not very error-resistant, but since ruby is included with OSX and people compiling GitX usually have git installed, it should work in most cases.

Update

I just discovered that the CFBundVersion is supposed to be a monotically increasing integer, separated only by periods. This is required by MacOS and things like Sparkle. The string “git describe” returns doesn’t match these criteria, obviously. So, if you encounter problems, you should fall back to using the format of x.y.z. where x.y.z is your major release number and is the number of commits since mentioned tag.

Working on my laptop a little bit more since I bought myself a new one I began the never-ending quest of doing things in MacOS via command-line that you’d have to do by GUI otherwise. But let me start by introducing GeekTool, a funny little PrefPane to display the output of commands on your desktop. Mine looks like this right now:

Most of the information there is redundant or meaningless. But two things I do care about: The SSID and BSSID (MAC-address) of the access-point I’m currently connected with. To get that info via the GUI you can Alt-Click the Airport-logo in the menubar, but you can also query it via commandline:

SSID: /usr/sbin/system_profiler SPAirPortDataType|grep "Current Wireless Network"BSSID: /System/Library/PrivateFrameworks/Apple80211. framework/Versions/A/Resources/airport -I|grep BSSID

In case you’re wondering: I have a wireless network at home with two APs, and sometimes I want to know which one I’m connected to, to see which one is causing trouble and to generally watch how the two signals propagate through the building.

Update

Hey, even better than just bitching about being on the “wrong” AP is manually changing to a different BSSID:

./airport -z<br /> ./airport --associate="heipei" --bssid="00:00:00:00:00:00" --password="supersecret"

Got this one from the git-ml (which I read via gmane, but that’s a different post):

I’m not very good at reviewing patches. Especially not if it’s something like JavaScript. git at least colorizes its diffs, which makes it somewhat better. But as soon as you have a big file which is being patched in multiple, disconnected places (different “hunks” in git terminology), so that the context between these hunks is missing, it gets to messy imho.

Fortunately there is an easy solution: In git there is contrib/difftool, which makes it easy to display git diffs side-by-side with a viewer of your choice. Of course that meant vimdiff for me. To see all the lines of a file (and not just the changed + a little context) I call git-difftool like this:

git-difftool --tool=vimdiff -U99999Now you can alias that command and use the normal rev-parse arguments. As you can see on the screenshot you can easily distinguish between removed lines, added lines and changed lines. For changed lines the part that was changed is highlighted.