Cocoa Geek

The new version of Ubuntu is out now - so a great time for everybody to try linux. It really is a top-notch distro and increadably easy to configure. Go fo it.

The new version of Ubuntu is coming in a couple of weeks, and since it has now entered beta phase i decided i would upgrade my installation of Hardy Heron. The installation is very easy just requiring the command:

sudo update-manager -d

The installation is remarkably quick, installing all the updated packages. The only problem i had with the installation was my GRUB config file was overwritten meaning i had to re-write some entries. As with previous upgrades config file diffs can be displayed and merged as required.

After a quick restart and reconfiguring my display drivers (very easy - just a matter of picking the correct driver) i was in 8.10. Changing my theme and background to the new artwork i was very pleased to see the removal of that awful orange that has been used in previous versions, its now quite a nice dark and moody brown which reminds me somewhat of Ubuntu Studio.

On the whole it has been remarkably stable, since the feature freeze is coming in now then future updates are going to be entirely focused on fixing bugs. I am currently running the update commands about twice a day and getting at least 15 packages updated each time.

I can’t wait until it is fully stable and released at the end of this month, Ubuntu is getting stronger and stronger as a desktop OS and with the current 6 monthly release cycle its also moving very quickly. I think a huge amount of credit should go to the community for working so hard on bug fixing and packaging. Making this OS the easiest linux distro to get started with.

At work, attempting to port a large program from linux to Solaris i hit a snag - I successfully compiled it with the Sun C compiler in 32 bit successfully. However this needed to be ported to 64 bit. The compilation was fine all the errors were solved with relative success by passing compiler flags and finding the correct libraries, unfortunately running it gave an instance Segmentation fault.

A Segmentation Fault is a fault that is given when a program tries to use memory to which it does not have permission either by trying to read or write to it… Basically it is a total pain in the ass… Debugging these types of problems can be tricky.

Using C one of the most common, and first found causes of this is with the scanf() function. For instace compiling the following code will read a number from the standard input and write it back out:

#include <stdio.h>

int main(void) {
  int n;
  while (scanf("%d", &n) == 1){
    printf ("%d\n", n);
  }
  return 0;
}

Running this should work fine, now lets try editing this code and instead of passing &n (the pointer) as an option to scanf() lets just pass the int n:

#include <stdio.h>

int main(void) {
  int n;
  while (scanf("%d", n) == 1)
    printf ("%d\n", n);
  return 0;
}

Running this will give us a segmentation fault. This in a large program can be insanely difficult to debug as your pointer could be defined a long time before it has been called to a function. So how can you start to debug this?

Well the tool i used for the first time was truss (the linux version being strace, and the osx version being dtrace) what this does is allow you to view as system calls a process makes as it is being called - or at what system call it crashes on. In other words if you are trying to open a file or read a memory address that can’t be called you will see it here:

read(0, "1\n", 1024)                    = 2

--- SIGSEGV (Segmentation fault) @ 0 (0) ---

+++ killed by SIGSEGV +++

Here is the final lines of output after running the strace command on my faulty scanf() code. It shows clearly that my program dies as i try to read the line from the standard input. The other important thing is that i didn’t have to recompile my code with a debugging flag to try to work out where my bug was. Strace (etc) reads the system calls - therefore telling you when and where you read memory or files, remember here that unix assumes they are essentially the same thing.

There is a huge amount of these programs that i haven’t talked about here - it is a very simple use of the command however one i wanted to document (as much for my own reference in the future as much as for anyone else!) because it is an essential command for trying to figure out why a program is dying, you don’t even need the source code in order to do this kind of debugging. I think its also important to be aware that this tool can also be used for ensuring your code is secure, integer wrapping or other similar vulnerabilities can be assessed using tools like this.

Google has developed a web browser. Lets face it no one is really surprised, there have been rumours of this for months and with the impending release of Android i don’t suppose that an increased level of web integration on mobile devices and the desktop from google is any shock either.

I do however find it very interesting that they have chosen to use webkit as the back end for the browser as opposed to gecko. Google has long funded mozilla and therefore the gecko platform, webkit however was a fork of the knoqueror browsers KHTML by apple. Apple prefers open source projects it works on and with to be under a BSD style license in order that the code can be used in close source applications, this is a possibility for using webkit over gecko.

Ultimately googles choice of rendering engine has little impact on the success of their browser, the usability and compliance with the web-applicatios that people use will be far and away more important in the success or faliure of Chrome.

Over the weekend i compiled LLVM and the LLVM-GCC front-end on ubuntu mostly because of all the hype surrounding it at the moment. Alot of people are talking about the optimization improvements over GCC and the increase in performance it give - if all the hype is to be believed no one would be using GCC anymore. So what is the state of play with it at the moment?

Well its biggest breakthrough up until now has been its inclusion with OS X with xCode 3.1. Although not currently the default compiler it is still there and there has been alot of talk about it being shifted to the default compiler in the near future. I imagine this would happen as apple have been funding alot of the development of LLVM themselves, they seem to view it as being one of the parts that will dramatically increase performance in the future on OS X particularly in regard to the multi-threading advancements in Snow Leopard.

In the Ubuntu / Debian world there isn’t quite as much support yet for the compiler, trying the packaged off the Ubuntu repositories is a waste of time at the moment, they are badly packaged, badly named and to be honest don’t work out of the box. Reading the mailing lists would give us the picture that there is a large effort to put these into the upstreams for the next Ubuntu release (Intrepid). So i compiled them from the sources, one important thing to point out that is not in the documentation for those who do want to compile them on linux is that they require the gperf package - and won’t give you an error until it is too late, i ended up starting the whole thing again. Other than that compilation is nice and easy.

So how about performance? Well first of all i tried re-compiling some of my favorite apps with the LLVM-GCC compiler and i didn’t get one error. Adding the -Wall flag however did miss some warnings out that are flagged up by GCC.  Compile times seemed generally quicker however i didn’t actually do any measurements for this yet.

Execution performance was something else i tried to measure, i got hold of  a very CPU intensive calculation off a friend and compiled it with both GCC and LLVM-GCC, the GCC execution time in 3 runs all averaged out to 55s with a SD of > 0.02 of a second. Running the same calculation compiled from LLVM-GCC gave a mean execution time of 38 seconds with the same SD - thats a saving of 30% in this example.

The code i was running for this test is typical scientific number crunching with 64bit ints, so this is obviously a very useful advantage and time saver on a calculation that would take longer to run.

The next thing i tried was running the amber granular synth, again this was compiled with both of the compilers and again i ran each execution 3 times. I chose one of the example run’s from the documentation the only change being i increased the size of the output file from 5s to 60s. Again there was a quicker performance with the LLVM-GCC compiler although this time not quite as impressive. The mean for the GCC compiled version was 1.433s, the mean for the LLVM-GCC version was 1.186s. This is a time saving of roughly 20%.

These results obviously show that LLVM-GCC does live upto some of its hype, however it will be interesting to see what the state of play is like in a couple of years. Will it still be being talked about in the same way? Or will the GCC guys improve their optimization techniques in future versions? I am still interested in testing it in other ways as well, these tests were both CPU intensive but not really data intensive. That will be the next set of tests that i will try.

Further to my Doxygen post a couple of weeks ago i thought i would just write something up on using it in xCode. There are some really useful features for not only viewing the documentation you produce but automatically updating your documentation as you compile.

Viewing documentation in xCode

First of all create a new group in the project files hierarchy - call this group something like Documentation.

Add the index.html file that was created when you first ran Dexoygen on this project. Double clicking on this file will probably just show the HTML that was produced for this file, which is pretty useless. To change this default behavior right click on index.html and select the Get Info under file type which will be set to text.html this needs changing to text.html.documentation. Close the Get Info window and double click the index.html file again this time it will open in the standard documentation browser.

Updating the documentation as you compile

This time you need to add a new build phase to your compile. Find your target file and right click again. This time choose Add > New Build Phase > New Run Script Build Phase when you run this you will get a nice window allowing you to write a shell script that will be run after the other build phases are compleated. It is important before you do this that you make sure you saved you config file in the doxygen Gui and saved it in the root of your projects file structure.

Now just add the following to the script field:

/Applications/Doxygen.app/Contents/Resources/doxygen Doxyfile

Where Doxyfile is the name of your config file for your project. You can rename this build phase to make it more obvious to you or someone else what it is doing.

For those of you who don’t know, doxygen is a mature system for creating documentation of your source code. Which can be downloaded from the doxygen website here. This is a really useful and intuative system, particularly for large projects that produces a variety of output and styles.

With it you can produce output as HTML, LateX or a few other common formats. On the website is a .dmg file which makes it incredabley easy to use - i am amazed its not more well publicised on the mac to be honest!

Further to my last post about GUIS’s for Bazaar, there is a python-gtk GUI called bzr-gtk available which can be installed through macPorts with:

sudo port install bzr-gtk

This command will install all the dependencies into your /opt directory if you haven’t installed much python stuff it will take a while (it did for me!). It is important to note that for my install of macPorts for some reason my terminals $PATH variable wasn’t updated. This is the variable that controls where bash looks when you typse a command into the terminal. If typing sudo port install bzr-gtk gives you an error you can change this yourself by using a text editor to change the .profile text file in your home directory.

Since this is a system file you will probably have to change it via a text editor in the terminal. The line you are interested in is the export path=$PATH line, just change this to export PATH=$PATH:/opt/local/bin/ and you should be good to go.

If this is the first thing you are installing with macPorts this could take some time, for me there was a huge number of dependencies that were installed – remember this isn’t bzr-gtk isn’t a native mac app!

Once its installed correctly you can just go to the directory with your project in and from the terminal type:

olive-gtk

This loads up the interface using the X11 implementation included with OS X, from which you can drop back through revisions, view revision logs, push, pull, update, merge code and commit revisions.  Its even possible to initialize a new Bazaar project on the whole it seems like quite a nice interface to work with for bazaar although and aqua interface would be a whole lot nicer.  I did have some problems with pushing my project to my server and the error message that was returned was suitably useless, however it did make reviewing changes for commits much nicer to view.

I think it would be much nicer if someone did an aqua version of this GUI but it is worth the install if you really need a GUI!

There seems to be alot of talk in the dev community of Version Control Systems (VCS) at the moment. Since this seems to be quite a fashionable thing to talk about at the moment i figured i would give it a go.

Why do we need VCS’s?

A VCS is a piece of software that allows the management and revisions of data and files. This can be any kind of information by typically text files are the easiest to manage and the differences between versions can be more easily tracked.

In the case of developers these are great tools that we can use to control revisions of projects. Small teams and solo developers can benefit from being able to more cohesively control current source in a centralized location and being able to test experimental code with our worrying about ruining already functioning code.

Trunks of code can typically be produced, in other words when version 1.0 is released a new trunk for 1.1 can be started still allowing you to patch the old code for as long as you need. Most importantly this can also provide a great way to back-up each point in the code as you go along, typically just from a simple command in the terminal.

VCS’s for the mac?

• Subversion
• Bazaar
• Other less common ones..

Subversion

The most commonly seen VNC, and the one that comes as a default install with the Developer Tools is Subversion. Subversion has been around for a long time and was initially built to supersede CVS. It has a huge feature set and is run from in the terminal with the ’svn’ command. There are loads of great resources out there for learning Subversion (http://svnbook.red-bean.com) but basically there is one master copy of the source called the repository.

With regards to controlling and accessing this repository there is support with svn itself through the terminal - however if you prefer a graphical approach there is some support in xCode itself. Personally i don’t think xCode is very good at controlling your source management options. Luckily there are some third party apps out there to do this for you.

SvnX is a great tool for accessing and updating your repository it also allows multiple “check outs” and keeps a log of all your working copies. Its very easy to use and also quite well documented. Earlier this week the open beta for Versions came out. This looks a stunning piece of software for use with subversion making the whole process of working locally with the source code easy - although it looks like it will only be in open beta until july!.

Bazaar

If you have checked out any of my source code you will notice that i’m not using subversion on this site. i’m using Bazaar. Bazaar is a VCS built entirely in python. This is a relative upstart in the world of VCS’s however was developed in association with the Ubuntu project in order to allow easy update of packages.

Although not installed by default on OS X the install process is relatively straight forward. Bazaar doesn’t use a repository type system, instead this is what is know as a distributed system where there are multipe branches of a your source code which Bazaar will later merge if required. As far as i know at the moment there are no GUI’s for it either - so although its easier to set up and manage initially for someone who wants a GUI Subversion may be the better option. Whatever you decide to use VCS’s are important - even to the solo developer having the ability to drop back to the code or database you were using last week is priceless. Try them out and let me know what you think!