A few of the major new features and functionality include tab support, allowing you to have multiple connections per window, a new bundle (plugin) system, allowing anyone to extend the application's functionality and a completely redesigned data export system.

The last one on that list is one that I started out doing myself (with a lot of help from the other devs fixing bugs), having detailed my plans for it way back in October 2009 and then subsequently how I got on with the redesign once it was merged back into trunk in May 2010. The reason it's taken so long to see a release is because it was merged back into trunk just after a major release (version 0.9.8) and the release after that only included bug fixes.

As I mentioned before, the redesign didn't exactly go to plan, but I'm happy with how it's turned out and more that happy now that it's been released for everyone test and provide their feedback. The UI is a significant improvement over what it was like before and operationally the architecture is a lot more modular, which should allow us to easily enhance it in the future by implementing support for more export formats.

Overall the response to this release has been amazing, probably our best yet when looking at the emails and the number of donations coming in, so it's been more than worth it. I'm sure a lot of users that aren't aware of the nightly builds thought that project might have died given the time between releases, so hopefully it's been a pleasant surprise and a reminder that's it's definitely still alive.

On a side note, something that I keep meaning to dedicate a an actual post to is the reason why I love open source software and why I spend so much of my spare time involved in it. Aside from continuously learning, I guess the response to this release highlights those reasons; nothing makes it more worthwhile than hearing from users on how much they love the app and how it has become and integral application in their daily workflow.

So enough about what Clang is, why bother using it when GCC is so widely supported, as well as some might argue, nothing actually wrong with it. If it ain't broke don't fix it, right? Ok, so I'm not going to go into any great detail about why GCC is so flawed and Clang isn't (because no software is perfect, not even compilers), mainly because I don't know enough about either project to do so and I'm not going to start pretending like I do. I am however going to point out some benefits of Clang and why you should consider looking into it.

The development of Clang is actively sponsored by Apple and although it's not currently (though it should be within the near future) the default compiler (GCC 4.2.1 is) when installing the developer tools, it is included in the form of Clang 1.5. If your project hasn't got a huge dependency on GCC, then I'd definitely recommend giving Clang a try and checking out firsthand the benefits over GCC that it can provide. Since it's designed to be compatible with GCC as much as possible, it's usually as simple as selecting it as the compiler within your Xcode project or a target's build settings.

The most obvious benefit of using Clang is performance. Performance is said to be one of the key aims of the project, in the sense of performing significantly faster at compile time as well as subsequently producing more efficient binaries than GCC, all the while using significantly less memory in the process. Check out the performance section of Clang's Features and Goals page as well as the dedicated performance page for specific in-depth details and stats on how it performs compared to GCC. I say that performance is the most obvious benefit to using Clang, because it really is that noticeable once you start using it. For example, we switched to building Sequel Pro using Clang a while ago, and the performance benefits during builds were immediate:

GCC 4.2.1:

real	4m13.692s
user	6m14.724s
sys	0m57.559s

Clang 1.5:

real	2m18.764s
user	3m11.980s
sys	0m32.187s

The above times were obtained from executing the following command, which builds a release build¹ of Sequel Pro, including all it's dependencies:

time xcodebuild -project sequel-pro.xcodeproj -configuration Release build

There are a lot of factors to consider when profiling the performance of a particular process, the most obvious being the hardware it's running on² and the current utilisation of the CPU, memory and other system resources during the build and the list goes on, but being almost twice as fast when performing a clean build is nonetheless impressive. It's also pretty obvious, but the above times are for building the entire application, not just compiling the Objective-C source files. This means it includes the copying of resources (images, templates, preference plists, etc) and frameworks as well as compiling NIB/XIB files using ibtool. That is, the general process of packaging all of the resources and binaries that results in a usable application. Clang's performance page refers to this time as non-compiler, an overhead of the build system (i.e. xcodebuild). You generally won't see such a big performance hit when compiling a pure C command line program. It also goes without saying that you're not going to be performing a clean release build every time you change a source file during development, which is where (if you're on a Mac that is) Xcode's or xcodebuild's (which are essentially the same thing) incremental compilation kicks in, so you might not see huge speed improvements every time, but it is definitely faster and less memory intensive.

Sequel Pro isn't exactly a massive project. It isn't small, but it has a relatively simple source tree and only 5 dependencies, all of which are included in it's trunk. According to Xcode Statistician Sequel Pro's source contains nearly 68,000 SLOC, excluding the source to all it's dependent frameworks that we build ourselves. It's therefore only fair that Clang be tested against another much larger project, for example, Adium, which by my estimate contains roughly 150,000 SLOC. I chose Adium, because (1) my basic estimates show it's more than twice the size of Sequel Pro (and in actuality is probably much larger) and (2) because it's an OS X application it also incurs the same non-compiler overhead associated with building the entire application and not just compiling it's source. The results were not surprising:

GCC 4.2.1:

real	11m53.566s
user	15m9.794s
sys	4m32.265s

Clang 1.5:

real	7m44.828s
user	9m3.748s
sys	2m45.088s

Note that all of the above timed builds were done for release configurations³ of the respective applications and although they'll defer in some very slight ways the process is generally the same. The point is, performing a release and development (or debug) build of the same application is a very different process and release configurations were simply chosen in this case to put both compilers through their paces with respect to these differences. The main difference should be obvious, the target architectures that the resulting application should be able to run on are different. During development, it's generally expected that the built application is only going to be used by the developer and so there's not much point in building it for any other architecture⁴ other than the architecture of the developer's system. A release build on the other hand is intended to be distributed to your users and so should be built for whatever architectures you intend to support.

The above stats might show Clang out performing GCC, but both versions of the compilers are not exactly up to date. GCC 4.2.1 was released back in July 2007 and although I don't have a specific release date for Clang 1.5, version one was released along with LLVM 2.6 in October 2009, so it's safe to assume it's less than a year old. It therefore might be unfair to compare these versions considering Clang has potentially well over two years of development time over GCC, but they're both the default versions included with Apple's developer tools. In some ways it could explain some of the large differences seen in compilation times between the two compilers, but I'm not convinced it can explain them all. Having said this I could be wrong.

Finally, having established the relative age of both compiler versions I was interested in seeing how their latest and greatest versions would perform. I originally intended to use the most up to date release versions of both compilers, that being GCC 4.4.5 and Clang 2.8, both released this month on the 1^st and 5^th respectively, but that didn't exactly go to plan. Having spent hours trying to get GCC to compile cleanly I gave up, so this isn't as much as a comparison of the latest versions of GCC and Clang, but more of a this is how the latest version of Clang compares to version 1.5. In contrast to GCC, building LLVM/Clang was super easy, but it did take a bit of tweaking to get Xcode to use it properly, but I'll spare the details for another post. The following times are also from using a trunk build of LLVM/Clang, which is labelled as version 2.9 (i.e. the next stable release):

Clang 2:

Sequel Pro:

real	1m40.509s
user	2m34.364s
sys	0m17.281s

Adium:

real	7m52.085s
user	10m14.829s
sys	2m18.600s

As the times indicate, the results are varied. Sequel Pro builds quite a bit faster (~40 seconds), but building Adium is actually slightly slower. As I already mentioned there are a lot of factors to consider when profiling performance, especially time so I'd keep these in mind when comparing the numbers.

Finally, a performance analysis wouldn't be complete without some colourful graphs or charts illustrating the data. The following charts therefore show all of the above builds split out by compiler (note that times are in minutes and shorter bars are better):

The above times include all of the output from the time command, and while interesting to see the user and system CPU time spent involved in executing the commands⁵, from a user's perspective the real time is the one that matters. That is, it indicates the actual real world elapsed time that it took for the command to complete.

So if you've read this far, then in short I think Clang is really awesome and think you should too. I've only presented one of the main benefits of it over GCC here and I'm not suggesting you should ditch GCC simply because of it, but rather you try it out and decide for yourself. Clang is not quite fully GCC compatible, but it also has a lot to offer that GCC doesn't that I haven't already mentioned. For example, it provides much more informative (and less cryptic) warning and error messages (diagnostics), much better IDE integration and a very impressive static analyzer to help track down bugs, specifically potential memory leaks in your applications.

Update: Something I failed to notice during my tests is that Clang 1.5 does not support compiling for the PPC (PowerPC) architecture. Attempting to do so produces the following warning: clang: warning: not using the clang compiler for the 'powerpc' architecture, at which point it will fallback to using GCC. You can see this by passing the
-### option to see the commands that it would execute during compilation. The fact that the PPC architecture isn't fully supported is actually mentioned in the Clang manual where it states that some support is included, but significant pieces are still missing. I guess PPC support either didn't exist or wasn't enabled in Clang 1.5. This warning however is not present when using version built from trunk (2.9) and using the -### option shows that Clang is at least used to generate the assembly, but it still falls back to GCC for machine code generation. This small difference could potentially explain some of the performance improvement that Clang 2.9 has over 1.5.

It's taken us this long to realise that we should have been doing this a lot more often from the very start of the project, so we're now committed to releasing two or three bug fix releases in between our 3-4 month major release cycle.

If you'd like to preview and test (obviously not on production systems) out the major new features coming in version 0.9.9 check out the nightly builds.

Check out the release notes for details on all the changes.

The full list of changes in this release can be found in the version history.

For anyone interested in a little bit of history, when Snow Leopard (OS X 10.6) was released, which included further restrictions on InputManagers resulting in SIMBL having to be rewritten I was all set on discontinuing the development of SafariTabs. The reason being because its feature set was reducing with every release of Safari and to be honest I didn't like the new approach SIMBL was taking to 'injecting' plugins into target applications.

As well as the sheer number of requests I got about SafariTabs support on Snow Leopard, I quickly realised that I couldn't live without being able to undo the most recently closed tab, which is why I continued its development. I've always maintained that SafariTabs was created to add features and functionality to Safari that I personally found lacking and is the primary reason why I've resisted in adding every feature request that I've received. Much like the UNIX philosophy, it is intended to do one (or a few) things and do them well.

With the release of Safari 5 Apple has finally added an extension API, tab undo support and the ability to control how links that open windows are treated (for example, automatically or always open them in new tabs). The last 2 features being those that SafariTabs provided and seeing that I rarely use the tab restore function I was again debating whether or not I should update it. Similar to when Snow Leopard was released I've since received a load of requests for Safari 5 compatibility, either because users genuinely use the tab restore or they've yet to realise that Safari now provides half of the features that SafariTabs once did. Regardless, there seems to be demand for it and so I appreciate your patience, while I work on updating it. I'll be releasing a compatibility (and reduced feature set) update within the next couple of days.

As expected the new architecture doesn't exactly match what was planned in every way, but 28 new files and countless lines of code (the majority of which isn't new and was simply migrated and tidied up) later I'm pretty pleased with it. The main thing is that it does follow the general structure based upon units of work that are performed concurrently via instances of NSOperation subclasses, as well as all export data formats inheriting from a common exporter base class.

So it isn't perfect and I'm sure there are a few bugs that were missed during development, but having just recently released a major new version, we've got plenty of time to resolve them. Although not to everyone's liking, I always think that it's best to get branches merged back into trunk as soon as possible to allow wider testing and further contributions from other developers. It's always good to get a few others to check out your code after you've been staring at it for 6 months.

The most user visible change in the redesign is the new export interface, which is now a single dialog allowing users to easily switch between exporting to different data formats. I'd encourage everyone to give it a try and test it out (with the usual warning that applies when using nightly builds: not to be used on production systems or valuable data).

If you'd like to keep up to date with any further improvements, request new features or report any issues, take a look at this issue, which is being used to track everything related to the new export redesign.

Enjoy.

Without reposting everything that is mentioned on the announcement post, some of the major new features include user management support, 64-bit support and significantly improved auto-completion with placeholder lists as well as tab triggers and text macros for query favourites. I should also mention that stability has also been significantly improved since adding a lot of multi-threading in the previous version.

Check out the release notes for details on all the changes.

Anyway, after venting my anger/frustration earlier today about the Digital Economy Bill being passed through Parliament, I thought I'd mention that I turned 23 today. I thought about writing a huge post about how much I'd learnt and all the mistakes that I'd made over the past year as well as what I plan to do over the next year and all that crap until I realised that I probably wouldn't have finished it before I turn 24 judging by the frequency of posts around here as well as my amazing ability to endlessly procrastinate. I'm simply going to say that I hope this coming year is better than the last, in more ways than one.

Thanks for reading and subscribing.

I've come to expect a less than democratic process when it comes to pushing through new laws and legislation by this government (or any other for that matter) which claims to operate in a democratically elected society, but for me the passing of the Digital Economy Bill was one of the worst displays of democracy I've ever seen. Did nearly every MP just forget they were elected to represent the views of their constituents and choose to ignore the 20,000 people that wrote to them expressing their views on the bill and calling for more debate on it before passing it through Parliament and making it law.

Well, that's exactly what happened and less than 40 of 646 MPs turned up to the second reading of the bill on Tuesday, which lead to a very poor display of democracy in action for the 20,000 individuals who wrote to their MPs as well as undoubtedly many others. So some of the MPs present at the reading did try to voice their opinion as well as their constituents and openly admitted that they were not in a position to make a decision regarding something that they do not have sufficient expertise in. This however didn't seem to make a difference and I guess the big corporations that pressured the Government into pushing the bill through got their way.

The Open Rights Group is making no secrets of what think about the Government's decision to push the bill through, and I was more than happy to add my name along with 654 others to Mo McRoberts' (@nevali) excellent open letter to some of the MPs who were present at the reading.

I can only hope that the Government comes to its senses very quickly or any newly elected Government does the right thing and overturns this new law. Both of which I'm unsure of the possibility regardless of the intent.

While messing about with Google Chrome the other day I came across the 'About Memory' page (accessible via the 'Stats for nerds' link on the Task Manager or by typing 'about:memory' in the address bar) which obviously displays the application's memory as a summary, but also split by process, which in Chrome's case, is a process per tab. Aside from the interesting (if it can even be called that) memory usage stats was a warning of a bug that was causing Chrome to seriously over count it's own memory usage, with a link to the actual bug in their issue tracker. Half expecting the link to point directly to Chromium's issue tracker on Google Code, it actually pointed to crbug.com. Ok, so it doesn't take a genius to work out that they're using there own URL shortener to obviously provide short and memorable links when referring to issues, but I actually thought it was a pretty cool idea.

So aside from the obvious benefit of allowing anyone to refer to issues (bugs and enhancement requests) without having to remember the somewhat longer Google Code issue page URL, it also provides some form of insurance to links referring to issues from all over the web using the service will still work in the event that the project decides to change it's issue tracker (either the software or to entirely different domain). Seeing the benefit of this, I thought we could also implement the same sort of service for the Sequel Pro project using the appropriately named spbug.com.

The aim of the project behind Sequel Pro has always been to create the best MySQL database management app for Mac OS X and since joining as a developer in November 2008 every release has brought us closer to this goal. The release candidate for version 0.9.8 has just been made available and depending on feedback should be officially released within the next week or so. As we get close to the much-anticipated version 1.0 release we are now trying to create a solid development infrastructure to support the project. For example, included in the 0.9.8 release will be an integrated crash/exception reporter framework as well as a supporting website to view and manage the submitted logs at log.sequelpro.com. The aim of the added functionality and website is to enable us to improve the overall stability of Sequel Pro, by examining the feedback provided by users (especially for nightly builds). As well as the new log site, is the addition of a new site dedicated to the localisation of Sequel Pro into languages other than English at translate.sequelpro.com.

So where does the creation of a URL shortening service come in? Well, we now have multiple sites supporting the development of Sequel Pro, from version control, issue tracking, crash log management, nightly builds and localisation and so the creation of spbug.com allows us to easily refer to most of these during development (especially on IRC) and when responding to user requests and feedback via email.

Currently the service provides seven different redirects, including the default, which is the site itself redirecting to our issue tracker. Provided with the correct parameters the others redirect to:

• Issue
• Source Revision
• Source Revisions List
• Crash/Exception Log
• Crash/Exception Logs List
• Crash/Exception Log Report

The most basic is when referring to a specific issue, for example, spbug.com/530, which redirects to the following issue on Google Code:

To find out how to use the others, I put together a short help page at spbug.com/h, which details there use as well as some other functionality.

The service was originally implemented as single .htacess file with all redirecting done using mod_rewrite, but I wanted something a bit more flexible in terms of being able to update the URLs for which redirects point to as well as to enable some form of logging. The rewritten version is therefore a very simple PHP app, with all the URL redirect (and page rewrite) rules stored in a MySQL database. Redirect logging in terms of the requested URL and where it was redirect to can also be enabled and stored in the database.

The source for the service is also freely available under version 3 of the GPL.