Archive for Development

Bitbucket beers…

I just wanted to drop a quick note about the event “Beers with BitBucket…” that the bitbucket team sponsored this last Tuesday the 25th of October in Chicago.

I went along and scored some bitbucket bling: Two free t-shirts and a bottle opener as well as of course far too much free beer 🙂 (The beer was quite good.) In fact there was enough free beer that by the end of the night after I had left the two t-shirts at a table at one of the after function bar’s there was only one t-shirt left after I picked up my stuff. So obviously the bling was really popular! Still I guess that’s what happens in Chicago “after hours”.

Still in any case I met some really cool people. The bitbucket guys were really chilled. I pronounced “Atlassian” totally wrong and they still liked me 🙂 Anyway thanks to Atlassian and the bitbucket crew I have a much better idea of their strategic direction and that they are really in this for the long haul and push.

In fact after I came back at around 2am (I know, I know, wandering around downtown Chicago at 2am fending off all the hmm… people who were trying to sell me “stuff”, maybe wasn’t the brightest thing to do…) But in any case I went to subway for some food and one of the bitbucket system administrators was there and of course we got to talking again and he insisted on personally paying for my subway sandwich… It’s just one detail, but I just got the feeling the team of engineers were just genuienly nice people. I get the feeling they really want to do good things for developers everywhere! So in any case personal thanks to Justin and the others!

I should also say the other people who attended were really interesting. Eg I met one of my MacHg users Sean Farley, and he was a really neat guy (He has a really strange Gravitar image, but I gave him some friendly grief over it. (Scraws!)) . Anyway, it turns out he was also a physicist and he knew a lot about Mathematica (my day job), and knew a lot about well a lot of other really interesting technologies. We got along famously…) But in any case I got some extra impetuous to add an annotation view to MacHg… I really have to get onto this.

But all in all it was a really fun night! Thanks to the bitbucket crowd for hosting it. You guys rock!

Cheers, Jas

Leave a Comment

On XCode 4…

The only thing worse than managing multiple windows is managing multiple panes… Brent Simmons

I feel like this all the time in Xcode 4. I have been using XCode 4 for quite a while now and while I love the fact that Clang and all the back end smarts are much nicer, the interface has really taken a retro-grade step in my opinion. I recently had to go back to XCode 3 to do some stuff and wow it was soooo much faster to get around and do stuff. There is now so much pane management in XCode 4.

For instance lets consider doing a find across your project. In XCode 4 you hit cmd-shift-F, enter your find text and hit return. Then you have to go drag the find results sub-pane bigger… then look through all your results. Then when you find something interesting you have to double click on a result to look at the find instance (being very careful not to single click it or else the main bit of code you were looking at to provide context to your find disappears). Then when you finally found what you want you have to dismiss the new windows you created, then resize the find column back to something you use for eg a stack trace / build results / whatever (Debug Navigator / Log Navigator) and then go on your way.

In XCode 3 you just hit cmd-shift-F, enter the find and hit return, look through the results, and then close the window. Sooo much quicker and simpler. Its things like this which just made XCode 3 so much smoother…

Apple please, please, please, also allow a more windowed approach like there used to be which was so much more flexible and quicker…

Leave a Comment

MacHg 0.9.14 released!

I just released MacHg 0.9.14 which adds the ability to drag and drop from the browser to the dock or finder; improves importing and exporting patches; fixes a major bug to do with very heavy processor load and visual flickering; updates the Mercurial bundle to 1.7.5; handles the new security model of Mercurial 1.7.5; includes TrustedCertificates for https connections; fixes handling of external diff tools for the users who were having issues; and fixes or addresses many smaller issues including: #136, #148, #158, #159, #163, #164, #173, #178, #179, #181, #185, #189, #192.

It feels good to get this version out the door since it fixed that very infrequent but fairly serious bug of maxing out the processor and causing page flicker. It was really hard for me to solve this bug since I couldn’t reproducible it. But finally in the end through users help, I found an example which could reproduce the problem. And happily with that I solved the issue.

I will also comment and say that the new security changes in Mercurial 1.7.3 & 1.7.4 are for the better but adding the corresponding support in MacHg was not without some pain. Most of the changes which occur to Mercurial these days are pretty much internal changes but the security changes in handling https were definitely changes that had to be accommodated by GUI writers like me.

It was also good to nail that complaint which I also couldn’t reproduce about external diff tools not working correctly, since they worked fine for me… (It turned out that the users didn’t have /usr/local/bin on their path, whereas I did through /Users/jason/.MacOSX/environment.plist)

Anyway, with those changes, things are coming along really nicely. MacHg 1.0 is nearly here…! 🙂

Comments (3)

MacHg 0.9.12 released!

MacHg 0.9.12 adds stable graph drawing and large speed and optimization improvements to load times.

I missed releasing MacHg 0.9.12 on Christmas by a couple of days. (But of course family things took precedence and… well… I have had a fantastic Christmas.)

Anyway for all my users, your present is now available for download 🙂 …

I am quite happy that I have finally solved the graph jiggling problem. Although the changes required were huge, MacHg is definitely the better for it now. Actually, in general I am quite happy with MacHg 0.9.12, since I have managed to solve a number of tricky under the hood type problems in this release. Now I can get back to a few more UI sorts of issues and most importantly additions. (Full 0.9.12 release notes.)

MacHg 0.9.12 is almost a candidate for MacHg 1.0.0 but the refactor present in this release (0.9.12) is truly massive so some regression might have been accidentally introduced…

(The annotation view is the major feature planned for MacHg 1.1.0.)

Cheers, Jas

Leave a Comment

MacHg Status

Hey all,

I just wanted to say that several people have been emailing me about MacHg and progress. As many of you have seen the public amount of work I have done on it has dropped off in the last number of months.

Well the explanation is simple my normal paying job right now is ramped up and so all my normal time (as always), is spent on that and in addition all the spare time that I can reasonably muster is also spent on that at the moment. Its really exciting stuff. In any case when that calms down in the near future I will be adding some features and polishing others in MacHg that I have long planned to do.

Top of the list is the “jiggling” of the graph as one scrolls… I actually have something working  internally but there are kinks to iron out. I rewrote things completely in MacHg only to find out that some child accessing is O(n^2). This was a real pain and I tried to get the Mercurial guys to have nice ways around this for GUI writers like me, but no dice. Thus I have had to work around this in a messy and un-ideal way. Still it working in my internal prototype builds.

Anyway more soon! I promise 🙂

Cheers,   Jas

Comments (2)

Versioning your application with the Mercurial changeset hash

A user of MacHg (Marko Käning) wanted to be able to see the changeset hash in the About MacHg box (see here). I had been meaning to do this at some stage and, well, given the request, now seemed as good a time as any… It turns out it was quite easy to configure XCode to create the appropriate information while building MacHg.

(In my workflow I release versions of MacHg every so often, and I want users who get the source code off of bitbucket and build it for themselves to be able to easily tell me something like “In such and such a version of MacHg I am seeing XYZ happen.”)

So now MacHg shows the following sort of thing when you look in the About MacHg box (note the grayed c0d2f1df774d hash code):

ok so how did I go about making this work? It happens in two steps:

  1. As part of the build process, get the hash key automatically and insert it into the applications info.plist.
  2. Inside your application extract the stored value from the hash key and display it in the about box

Steps to Automatically set the BuildHashKey when building your Application

  1. Open your XCode project.
  2. Under targets select your application.
  3. Right click on the target and choose Add -> New Build Phase -> New Run Script Build Phase, as in:
  4. Change the shell to be /usr/bin/python instead of /bin/sh.
  5. Then in the script, copy and paste the following — I actually did this in bash first but decided to do it properly again in python so that I will be able to read it again in six months time if need be, python being that much more readable :

import os, subprocess, re, sys

targetBuildDir = os.getenv("TARGET_BUILD_DIR") getChangeset = subprocess.Popen('hg parent --template "{node|short}" --cwd ' + targetBuildDir, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)

if ( != ""): print "Error in obtaining current changeset of the Mercurial repository" sys.exit(0) # if you want the build to fail here since the changeset is malformed change this to sys.exit(1)

changeset = if (not"^[0-9a-f]{12}$", changeset)): print "Current changeset of the Mercurial repository is malformed" sys.exit(0) # if you want the build to fail here since the changeset is malformed change this to sys.exit(1)

infoPlist = os.path.join(targetBuildDir, "") if not os.path.exists(infoPlist): print "Cannot locate" sys.exit(1) # if you want the build to not fail here change this to sys.exit(0)

result = subprocess.Popen('/usr/libexec/PlistBuddy -c "Delete BuildHashKey" ' + infoPlist, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True) result = subprocess.Popen('/usr/libexec/PlistBuddy -c "Add BuildHashKey string '+ changeset + '" ' + infoPlist, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)

print "MacHg BuildHashKey set to " + changeset

Of course you need to change to the name of your application. Also you might need to specify the full path to hg (ie /usr/local/bin/hg) in the line:
getChangeset = subprocess.Popen('hg parent --template "{node|short}" --cwd ' + targetBuildDir, stdout=subprocess.PIPE, stderr=subprocess.PIPE, shell=True)
Also you might want to have the build fail if the changeset is not available, since currently the script above just keeps going.  (I want users who download and compile MacHg to not get lots of critical errors if things are not set up just right.)

Using the BuildHasKey in your Application

Then back in your application you can have a method which will get the hash key from the info.plist:

- (NSString) macHgBuildHashKeyString
    NSString key = [[NSBundle mainBundle] objectForInfoDictionaryKey: @"BuildHashKey"];
    return key ? key : @"";
Then it’s just a matter of styling it and viola, you have the ingredients for versioning your application with the Mercurial changeset hash key. Actually, after doing this I found out that over at Cocoa is My Girlfriend he had done something similar but in bash.

Leave a Comment

Make FileMerge diff .plist files

In doing macintosh program development I had often come across the case where I wanted to view the difference between two .plist files. Specifically when you are doing diffs of say your UserDefaults.plist in your application you are developing in XCode say…

Previously .plist files were all stored as ASCII files but in OSX 10.4 Apple started compressing them. If you attempt to diff one of these compressed .plist files in FileMerge it complains that the files are binary and should it proceed anyway. If you do proceed you get a comparison between garbage and garbage and you can’t see any of your changes to verify that you made the right changes in Xcode.

Anyway I had googled for a solution but didn’t find one easily. But recently this annoyed me enough that I overcame the thresh-hold of annoyance and looked for a solution. (likely you are reading this post for the same reason!) So it turns out that its pretty easy to get FileMerge to nicely display diffs of .plist files.

You need to add a simple filter to FileMerge. You can do this by hand.

  1. Open File Merge
  2. Go to Preferences -> Filters
  3. After the last item in the list of filters double click to enter new values and enter without the quote characters
  4. ‘plist’ in the extension column.
  5. ‘/usr/bin/plutil -convert xml1 -o –  $(FILE)’ in the Filter column.
  6. ‘Filtered’ in the Display column.
  7. ‘No’ in the Apply* column

Thats it. It should look like something like (I have a few other filters in there as well):

Picture of final FileMerge preferences

FileMerge Preferences

Or if you are more macho about such things, execute the following in the terminal:

defaults write Filters -array-add '{ Apply = 0; Display = 0; Extension = plist; Filter = "/usr/bin/plutil -convert xml1 -o -  \$(FILE)"; }'

Thats it. Go do some diffing!

Comments (4)

Almost there

Right my first blog post!

In my free time I have been working on developing a cocoa program MacHG. Its almost ready to launch to beta testing…

As is evident word press is mostly set up since you are reading this. My bitbucket setup is almost there… and well dreamhost was activated today and is hosting this as is evident. Google email is up. There are still some services which I will get set up like the forum thingy which is served by php. Also hosting of the screen casts. But soon…

Leave a Comment