Skip to content

{ Category Archives } Thousand Parsec

Thousand Parsec is a space empire building framework which I lead.

Compiling for Windows using Cygwin on Linux….

So for the past week while I have been at the best conference in the world I have been trying to compile tpserver-cpp for Windows. I had done the hard work and gotten it to compile (as documented here, here and here) on Windows previously. However, as I was in Hobart at a Linux conference I didn’t really have access to Windows computer. That was not going to stop me, so I attempted to cross compile the binaries under Linux. This has a number of advantages as it would mean when someone finally gets around to creating a autobuilder, we can produce Windows binaries too.

Ubuntu provides the mingw32 compilers in the repository so I didn’t think it would be all that hard to get working. The problem is that tpserver-cpp does not have a “native” Windows support but cygwin comes to the rescue and provides a compatibly layer. Using cygwin turned out to not be as simple as using mingw32 compiler with the cygwin headers.

I ended up using crosstool to build my own cygwin compiler. I battled for a long while with the fact that Ubuntu now enables “fortify source” by default. This breaks many versions of things like binutils and gcc (which often do naughty things which fortify source does not like). After I figured out how to disable it, I was still was only able to get an ancient version of gcc to compile (3.3.6) which meant I had to fix a lot of problems in the tpserver-cpp code. I guess someone had to do it eventually, but it was annoying that I was forced too.

I then manually downloaded a bunch of cygwin packages to build a tree for the dependencies (such as boost and guile). This was much faster then trying to compile them on my own. Finally, I was able to build tperver-cpp and create a Windows binary! I can confirm it runs fine under Wine and am now getting friends who are still shacked to Windows to test it there.

It sounds much simpler now, but it took me over a week of work to boil it down to these steps. It was like a constant game of wack-a-mole, once I had solved one problem another popped up.

So what now in this area? I want to get a recent version of the compiler working and preferably build all the dependencies ourselves (rather then rely on the cygwin compiled versions). I would ultimately like to see the cygwin compilers being packaged with Ubuntu/Debian in the same way that the mingw32 compilers are. I don’t know if any of that is likely to happen however as I never seem to have enought time. For now I have uploaded a copy of my cross compiler (It needs to be extracted so it is found in /opt/crosstool).

I hope this helps someone!

Tagged , , , , , , ,

In the land of the sheep…

I wrote this post while in New Zealand but never posted it, now I’m at I have time to finish it up.

Well its been a long time since I have posted on my blog. As I lasted mentioned I now work at Google, which has been going well but keeping me fairly busy. For the last month (October, 2009) I have been back in Mountain View, California. While I was there for mainly work purposes, I did get the chance to go to both the Summer of Code Mentor Summit and the GitTogether. Both where a lot of fun but tiering.

It was good to see the BZFlag guys again – they even had cool t-shirts this year. Not as cool as our Thousand Parsec shirts, however. 🙂 I was finally able to meet kblin who I had know through the WorldForge project for many years. As always he looked nothing like I expected.

At the GitTogther I was mainly interested in trying to make git usable with large media repositories. This is one area which Subversion still has an advantage. After much discussion we came up with a solution to the problem which I gave a short presentation.

It also gave me a chance to catch up with the Open Source Progams Office. It was great to catch up with Leslie Hawthorn and her fabulous crew.

No sooner had I gotten back from the states, I headed of to New Zealand. Lee Begg who I also first met through the WorldForge project and was the co-founder of the Thousand Parsec project, is getting married and I will be a grooms man.

Tagged , , , , ,

Thousand Parsec accepted into Google Summer of Code 2008!

As I’m too lazy to write a post myself, here is one from JLP:

Google has just published the list of accepted mentoring organizations for Google Summer of Code 2008 and it is great to see that Thousand Parsec has made it once again. We must be doing something right 🙂

So, if you are into turn-based 4X space strategy games and would like to help in game development, this is your chance. Take a look at our Google Summer of Code and Ideas for Programmers pages and get involved. There is even US$ 4500 to encourage you to take that step into the world of open source software programming.

Interested students now have about a week to get to know us better. You can chat with us on IRC (Freenode network, #tp channel) or write to our development mailing list. Starting March 24 student applications can be submitted, all applications must be in by March 31. I’m looking forward to be a mentor again.

Tagged , ,

Google Summer of Code on again!

Leslie Hawthorn has announced that the Google Summer of Code is on again. Like, nobody saw that comming! Hopefully, Thousand Parsec will be a mentor organisation again. Have to keep those southern hemisphere mentor numbers up!

Thousand Parsec primary client 0.3.0 released!

As announced at, I’m happy to point out that we have finally anounced the 0.3.0 release of the Thousand Parsec client which I work on.

It’s been a long time since the last release of the primary client for playing Thousand Parsec games. Now, the wait is finally over and it was well worth it. Large parts of the client have drastically changed. Connecting to game servers is simplified. The new user interace enables you to more easily see important information and then more efficiently issue orders. Translation support makes it possible to conqueror the universe in your mother language. For all the details check out the full release announcement. If you downloaded a previous release and didn’t like it, please give this new release a try!

Summer of Code results

If you read my blog but not the Thousand Parsec news feed, you might have missed my wrap up of our Summer of Code. You can find the complete post here, some highlights include;

According to Oholo, over the summer the students made a total of 371 commits to our public repository, changing a total of 39,050 lines of code.


Participating in the Summer of Code has meant that students from around the world have started trying to figure out how to make Thousand Parsec part of their course work. One such student is Nathan Partlan aka greywhind who is doing a full year internship with Thousand Parsec.

You should check it out.

GSoC Mentor Summit

Well, I am currently sitting in the famous Googleplex. I’m attending the Google Summer of Code Mentor Summit that Google paid to fly me out for, which is very very cool (thanks Google!). I have never been to the USA before, so I have about 3 days next week to look around the San Francisco bay area.

Work was suprisingly cool about me disappearing for a week and a half when I had only been working there for 4 weeks!

As I have said previously, the Summer of Code was a really cool program to be part of and we had some really cool success. Hopefully we can get in again next year!

Summer comes to an end, but it’s not over.

Well, not really – I’m in the Southern Hemisphere and Summer is yet to arrive. What I am ranting about is the “Google Summer of Code”. This year, much to our suprise Thousand Parsec the space strategy empire building game I founded “oh so many years ago”, was selected to become a mentor organisation.

We had 3 students accepted into the program and then Google also agreed to fund an extra student outside the program! Sadly only 3 out of these 4 students passed the mid-term evaluation, but the work they have been doing is really, really cool!

This last 6 months have been really rewarding personally. I started the project in 2001 and it has been a long slog to grow the project past just the other founder and me. With all these new people who are actively excited about the project (and not just the SoCers!) it has been a huge relief that time over the last 6 years has not been wasted. With myself recently graduating, the nature of my contributions to the project is going to change and it’s nice to know that others will be helping to keep the project alive.

It use to be the case that if I stop working on the project, no progress would be made. Now almost everytime I turn on the computer I see new commits. When I go to our gitweb there is always a lot of green. It’s an absolutely wonderful feeling!

The next 6 months are also going to be really exciting, with TP04 reaching the final stages of specification, a new website reorg, a bunch of new games and an almost complete rewrite of the primary client. We might actually start attracting users :).

Skimpy, Scheme in Python

For something a bit different, I decided to work on making embedding Scheme in Python easier. I’ve previously been using the cool PyScheme, however it hasn’t been updated in quite a long time (since 2004) and is quite slow.

The reason I would want to do something crazy like this is that Thousand Parsec use a subset of Scheme called TPCL. The is used to transmit information from the server to clients about rules for creating designs. Servers also need to be able to parse TPCL for “dumb clients” which can’t parse TPCL for themselves.

Recent developments by DystopicFro on his Summer of Code project, a Ruleset Development Environment have meant that he also needs the ability to parser TPCL (and specifically the ability to detect errors). This got us chatting about PyScheme and it’s inadequacies.

What I have decided to do is create a module called SchemePy (pronounced Skimpy). On platforms where speed is of no concern, we will fall back to using a modified version of PyScheme. However, we can also use C scheme systems such as Guile (or other libraries) to improve speed.

Why have multiple implementations? It stops us from using custom things in one scheme implementation which are not compatible with other implementations. It also makes installation easier for the user, as they are much more likely to already have a compatible scheme library installed. Different scheme’s also have different speed advantages.

So far I have got the Guile wrapper 95% working. It’s written mainly in Python using ctypes. I needed a small C helper module as well because of the extensive Macro’s used by Guile. So far, you can convert between Guile and Python types easily, you can register Python functions into the Guile context and exceptions are caught. There is also the ability to pass python objects thru the Scheme environment to Python functions. I would like to thank the guys who hang out on #guile for all their help, it has made doing this wrapper much easier.

I’m happy enough with the outcome. My guess it will be between 10 and 20 times faster then PyScheme, but I’ve yet to do any benchmarking. I’m going to move to wrapping mzscheme too soon enough. It should be much easier to do now that I have gotten most of the hard stuff sorted out. I think a lot of it will be common between the implementations.

What I really need to do is get a test-suit working. Once I have more then one implementation working it will be very important to make sure that they all work the same way, the only way I can see to do that properly is to have a test suite which I can run every implementation against.

One thing which might be really cool to investigate is using a similar system to lython which compiles Lisp s-expressions directly to python byte code. If this was done well it should be the fastest method as it would mean no type conversion needs to be done.

Overall this has been quite a good learning experience. I have improve my ctype skills quite a lot (this wasn’t my first ctypes wrapper, that being libmng-py, a Python wrapper around libmng). I also understand how Scheme works quite a lot better now.

Using Tailor to go to git

As our code repositories for Thousand Parsec where down anyway (because of the host being compromised), we decided to do something we had been thinking about for a while. We converted all our code repositories to git.

We had previously been using darcs, however the unbounded memory usage was getting out of hand. The straw which broke the camel’s back was when nash couldn’t even checkout the web repository because darcs kept getting killed by the Out of Memory Manager (on a machine which has more then 512Mb of RAM).

After much discussion we decided to move to git. The biggest reason we choose to use git was that we didn’t want to get stuck with another non-mainstream SCM system. With large people like Xorg, the Linux Kernel and many others, I’m pretty sure git will become the SCM of choice in the near future.

As I had previously had a large amount of experience converting the darcs repositories to subversion (for our mirrors), I was put in charge of converting the repositories to git. As previously, I used Tailor.

The first problem is that darcs has git repository support. The suppose solution to this is using disjunct working directories. However, git did not appear to like this, I need to hack up the source code to get it to work. I’ve submitted the patches back the Tailor repository and they have already been included!

Another problem I ran into was that I don’t have a machine which has enough memory to convert the web repository! I don’t have a computer with more then 768mb of ram (feel free to send me some more if you want! :P). Luckily thanks to the Summer of Code, a student who goes by the name cherez (who I was very disappointed we didn’t have enough slots to select) gave me a shell account on his machine with 4Gb of Ram.

As a result of converting to git, I was also able to merge the development and stable branches (of both tpclient-pywx and libtpclient-py) into one repository. This was a little bit trickier then I would have liked, it involved finding the branch point manually and then telling tailor about it, in the end it worked out. You can find a copy of the config I used for branching here.

You can see the results of our conversion at our gitweb.

I have to say, I’m amazed by git. Every single operation is very, very fast, I guess it’s why they called themselves “Git – Fast Version Control System”. Another thing that amazes me is the size of the repositories, under darcs our repositories where about 4Gb, with git they are around 200Mb! Overall, I’m happy with our choice.