Change first row label to 'wall', add 'cpu' row, update documentation.

[snim2]

This PR resolves Issue #3.

[ltratt]

Can we squash some of these commits down (doesn't have to be all of them, but we probably don't want indentation commits if we can avoid it) and do a force push to update the pull request?

[ltratt]

Oops, it looks like squashing has gone back beyond this branch?

[snim2]

Ugh git :-(

That push was following the procedure here: http://blog.screensteps.com/recovering-from-a-disastrous-git-rebase-mistake

i.e. create a new branch that starts from just before the erroneous rebase, fix the rebase, delete old branch, rename new branch, force-push. So, I'm not sure what went wrong with that one...

[ltratt]

This has gone sufficiently wrong that github won't merge it automatically. We seem to have 17 commits in the pull request?

[snim2]

Well, this is extremely embarrassing. I'm not exactly sure what I did to screw up the PR, but the code on the travis-ci branch has already diverged from the commits here and will be hard to merge in once the refactoring there is complete.

Maybe it would be easier just to kill this branch altogether and change real->wall and add cputime on the other branch. That would give a more linear history once the whole lot has been merged into master.

Ugh :(

[ltratt]

Yes, I suspect you're going to have to manually extract the correct patches. If you're lucky, you can create a new (temporary) branch, cherry pick out the good commits (4bb0155 and e02a1ba?), then push that temporary branch over this (thus making the pull request hunky dory).

[snim2]

Closing this PR; will deal with Issue #3 in another PR, now the testing work has diverged from this branch.