printf("RIP Dennis Ritchie :( \n");

There aren't many computer-related books on my shelf. But the white one* is there, and I guess it will be there as long as I have a shelf.

Thank you, Dennis. RIP.

* The C Programming Language, B.Kernighan, D.Ritchie

git and nomad life

This entry is like a note to myself, just to help remember setting this thing up again if needed...

So I have my track creations in a public git repo at repo.or.cz.
So far I've only been using it to publish my ideas to the world, but now my time schedule has changed and I wanted to gain full access from another computer, too.
I had no problems using git clone to clone the project on the new computer. Then I've set up some tracking branch with 'git branch -t track_name origin/track_name', fetched it with 'git fetch origin' and began working on it after the merge: 'git merge origin/track_name'.
But then after some changes I wanted to push them to the repo, so I could continue work on the other computer. However I could not get it working unless adding a new user at repo.or.cz/reguser.cgi. It also meant generating a new SSH key with ssh-keygen, and copying the public key to the appropriate edit field on the register page.
Then I've edited the file .git/config and added a new line in the section '[remote "origin"]' a new line, right after the fetch URL line:
pushurl = ssh://newusername@repo.or.cz/srv/git/kilo_torcs_tracks.git

Now I can fetch the whole thing issuing 'git fetch origin track_name' and push to it 'git push origin track_name'. The server asks for the SSH passphrase and voila it works.
Right, it may be obvious for some, but I am happy now and wanted to share it :D

Note #1: you may ask why did I not use my existing pubkey to register. Simple: forgot where my USB stick with my pubkey was, and did not want to wait 3 more days with the whole procedure when I got back to the same situation... yes I know, I am lazeeeeehhhh.

Note #2: remember, don't git pull, rather git fetch and then git merge... Details here and here.

Knockhill dilemma solved

Thanks to everyone who has expressed his/her opinion about my planned track.

The results are:
Realistic: 5
Easy: 2

manfariel has even produced side-by-side videos with a real-life on-board lap on the left and himself driving around the track in Speed Dreams, on the right, synchronised. Wow!

So the more realistic option wins, even without my own vote. Thanks again for sharing your views.

Knockhill dilemma

HELP NEEDED!

I've been working on a track for some time now, Knockhill in Scotland.

It is a 2 km long (or better, short), fast track with very interesting corners, turns and altitude changes. What gives me headaches is the latter one. The information available of the track says that it is "varying by around 200 feet (60m) from highest to lowest point." I've mapped the track outline, tried to get the altitude and banking changes right, but I have a burning un-certain feeling in my soul about it.

At first try I've made it so that the Z-size, ie the difference between the lowest and highest point on track was 200ft. Man, was that track hard to drive? Sure it was. It had some drops that you would even think about going down there by bike, not even a racecar... Robots behaved very different in the drops and climbs, some were flying out straight ahead like an F-14 catapults from a carrier ship, others slowed down and managed to follow the track more safe. In short, the track looked and behaved too dangerous.

Now, I haven't been to the track IRL. I only know it from photos and BTCC races available on Youtube. So I've never walked down there on those slopes to get a real feeling of them. There may be this kind of sharp changes in altitude, or there may be not.

My next idea was to halve the altitude changes of the track. It was easy to do, only had to change the 'grade' and 'profile end tangent' values of each segment in the track XML file. After generating the track, I was eager to see how it feels to drive around. And - I liked it more than the original! It seems the robots like it more, too. It simply feels more natural.

So I have this track that feels great to drive, and another one that is more hi-fi in regards of data. Which one is better? I cannot decide, so please help me! The two versions are available here (safe one) and here (tricky one). Please download and test them and share you views either in the comments or via e-mail.

Remember, I need your help

or this track won't be finished ever and all the great resources used for creating it will be lost forever to humanity :D

NB the tracks are unfinished - they don't have a pitlane, textures are basic, etc. But they are drivable. I've driven them in Speed Dreams, but I guess they also work in TORCS. To install them, just copy the contents of the archives to the track/road location, in a folder named 'knock'.

Install Speed Dreams on Ubuntu

Following up of my TORCS install howto, today I'll tell you what I had to do to get Speed-Dreams up and working on a brand new, clean Ubuntu 11.04 (Natty Narval) install.
NB: I usually work on the trunk branch of Speed Dreams, using git-svn, but I think the download packages should work the same.


So this is what I've started with:

• sudo apt-get install cmake libsdl1.2-dev libjpeg8-dev libxmu-dev

then made some links:

• sudo ln -s /usr/lib/libGL.so.1 /usr/lib/libGL.so
• sudo ln -s /usr/lib/libGLU.so.1 /usr/lib/libGLU.so
• sudo ln -s /usr/lib/libXi.so.6 /usr/lib/libXi.so

(idea from here)


then downloaded and installed Plib the usual way (later I learned there is a plib-dev package in Ubuntu now...):

• Visit the PLib download page.
• Download the 1.8.5 version, then do as told: tar xzf plib-1.8.5.tar.gz
• cd plib-1.8.5
• ./configure
• make
• sudo make install

and then onto adding some more dev libs:

• sudo apt-get install libopenal-dev libenet1-dev

At this point "cmake ." still wasn't happy, whining about some plib thingies. Quick googling led me to our own forum (khm) and launching cmake in interactive mode (cmake -i .) I was able to set the correct location of the PLib includes.
This was so satisfying that cmake agreed to complete 100%.


Now in the make phase I quickly faced the first problem, at about 9% of compiling. It missed some libplib*.so files in the /usr/lib directory. Noproblemo, linking is our friend (every other day):

• sudo ln -s /usr/lib/libplibul.so.1 /usr/lib/libplibul.so
• sudo ln -s /usr/lib/libplibsg.so.1 /usr/lib/libplibsg.so
• sudo ln -s /usr/lib/libplibsl.so.1 /usr/lib/libplibsl.so
• sudo ln -s /usr/lib/libplibjs.so.1 /usr/lib/libplibjs.so
• sudo ln -s /usr/lib/libplibssg.so.1 /usr/lib/libplibssg.so
• sudo ln -s /usr/lib/libplibssgaux.so.1 /usr/lib/libplibssgaux.so

And so it compiled at last...
Now I'm busy racing :)

git <-> svn

You may guess now I like working with git. I am always amazed how easily I can match the abilities of this software with the several, often changing needs that arise during my work or hobbies. Oh right, it cannot help in skating faster...
And then there is Subversion. I should not say I hate it but I think it is a slow dinosaur, ugly, fat and slow-moving. But still, many projects use it so if you want to participate in them, you've got to follow the flow.
And there comes git-svn to the rescue. It enables you to use your beloved git in a subversion-based project easily. This is how I've set up my workplace for Speed Dreams development, using git for effective feature branching, mergeing, rebasing and such git candy:

mkdir sd

git svn init https://speed-dreams.svn.sourceforge.net/svnroot/speed-dreams/trunk

git svn fetch -r3096 (of course you can choose another SVN revision)

git svn rebase

and voila you have a nice and shiney git repository that mimics the SVN repo.
Anytime you want to update your repo (like doing 'svn up'), just issue

git svn rebase

The above process is explained in more detail here (thanks, Flavio), along another entry here.

Now onto feature branching:

I quite like the Story branch pattern, so basically what I do is:

1) Find a ticket to work on in the Speed Dreams Trac system, let's say it is ticket #100.

2) git co -b 100_ticket_short_title this creates and switched to a new git branch that I will use for this ticket only

3) hack this & that

4) git add -p

5) git ci -m 'Commit message that really tells something. Re #100' - so I always try to include the ticket number in the commit message, good for Trac coverage.

reiterate 3-4-5 until ticket is finished

6) git diff --cached (review all the work done)

7) git rebase -i HEAD^8 (or so, view last 8 commits and squash them together if needed - this to get rid of the side effects of very frequent git commits)

Now before committing to SVN let's make sure it won't cause any conflicts:

8) git svn fetch && git svn rebase (OK maybe git svn fetch isn't needed)

If still 'green', then commit to SVN:

9) git svn dcommit

Now switch back to the master branch and update it, too:

git co master

git svn rebase

Set the ticket status fixed and delete the branch, if you like. I prefer to keep it around for some weeks in case the ticket is reopened after the initial tests, but you can get rid of it or create a new branch then - really just a question of taste.

The only thing you should really take note is: you cannot do a git svn rebase if you have any uncommitted changes. Fabio's blog says he uses git stash to put away his changes, does the rebase, then does git stash apply to get his changes back. I prefer to commit my changes instead, do the rebase and then work on the usual way. Which one you choose is up to your taste - both approaches work fine.

This is the real git magic - you can choose the way you work!