Tarrasch V3 Development now on Github
I do have something vaguely exciting to share, and that is that I have finally jumped on the bandwagon and put the source code on Github. I did put Tarrasch V2 on Bitbucket (a Github competitor), but this was a rather half-hearted effort, and I did it when Tarrasch V2 was finished. The plan this time is to do open source development “properly”. These days that means working in the open, publishing your code more or less as it is written and modified. The platform of choice for this process is Github.
Before taking this step I spent (wasted) a lot of time reading about git (the technology underpinning Github, git was created by Linus Torvalds of Linux fame). It all seemed very scary and complicated. It turns out, and this so often seems to be the case, that reality is less scary than imagined reality, and that instead of reading and obsessing about git I should have simply jumped in and started using git. You cannot learn to swim by reading about it on the internet.
Github has become a popular phenomenon, and they’ve couldn’t have done that without making the barrier to entry fairly low. I followed their “Getting Started” tutorials on both my Windows and Mac machines and started experimenting. I was pleasantly surprised how easy it all turned out to be, and I am already experiencing benefits, including benefits that I never expected. Unsurprisingly, I now have a good solution to backing up the source code regularly online. That pretty much comes for free from working this way. Additionally, I no longer have to save progress as an endless series of snapshot .zip files, most with comically unhelpful names like Tarrasch3Dec2013AfterFixingThatAnnoyingOffByOneBug.zip for example. Instead I am using state of the art software for keeping track of (hopefully) steady progress on a long term project.
The unexpected benefit is that developing the code on both Mac and Windows machines is now much simplified. I was worried how I would get git to handle this “workflow” issue, but it turns out to be very simple and natural and it actually solved the annoying problem of keeping code on the two machines in sync. Basically git makes it easy to keep the local code repository on one machine in sync with the remote code repository that lives on Github. If the remote code is advanced relative to the local code you go “git pull” to pull down the newer code from remote. Conversely if the local code is advanced relative to the remote code you go “git push” to push the newer code on to the remote. This works great with one programmer with one Github account (i.e. me) working on two machines. Let’s say I’ve been working on Tarrasch with my Mac. At the end of the session I go git push to update the remote. If I next use my Windows machine, “git status” will warn me that the remote repository is in advance of the local code. I just go “git pull” and I am in sync and up to date. Easy peasy and a great advance on my previous situation, which saw me quite reluctant to switch from Mac to Windows or vice-versa.
My single code repository has both Xcode (for Mac) and Visual Studio (for Windows) project files. This is fine, Xcode ignores the Visual Studio project files and vice-versa. Github user KostyaKow (that’s his account name, I recognise him as a friendly fellow who often emails me about Tarrasch) has already noticed that Tarrasch is now on Github, and unsolicited he added a generic Linux project file (these are called “makefiles” in unix speak). He then sent me a “pull request” to ask me to pull down his changes. I have done that, and incorporated them into the master repository. I don’t think KostyaKow actually got Tarrasch working on Linux (yet), but a start has been made, and expert programmers can work on it in whichever platform they prefer (Windows/Mac/Linux). Github is a kind of social network for programming and it seeks to encourage and facilitate collaborative work like this. Hopefully there will be much more collaborative activity in the future.
There is an annoying wrinkle in this otherwise happy picture. As always with the coding aspect of Tarrasch code, it is wxWidgets. Tarrasch relies on wxWidgets as a portable layer of software (basically it makes Tarrasch’s user interface possible). It is quite a nice thing to work with once you have it set up, but unfortunately it is vast and unwieldy. It is difficult to setup and configure your programming environment to accommodate wxWidgets. My XCode and Visual Studio project files assume wxWidgets has been set up just as it is on my machines. KostyaKow’s Linux makefile effectively does the same for his machine. I haven’t got a working Linux wxWidgets environment which is why I haven’t actually tested KotyaKow’s makefile myself.
The sad wxWidgets situation won’t stop a skillful and resourceful programmer. If you are such a person and you want to play with the Tarrasch source code, the first thing you should do is install wxWidgets and follow the tutorials and other resources, and build some demos and samples. If you are using Mac, you want to use the new V3.0 wxCocoa release, which makes modern Macs a first class wxWidgets citizen for the first time. Make sure you can rebuild the “richtext” demo/sample as the richtext wxWidgets library is not used by the simpler demo projects. After you’ve done that you should be able to modify the existing Tarrasch project files to reference *your* wxWidgets installation rather than *my* wxWidgets installation.
I really hope to improve this rather unfortunate solution to the “wxWidgets problem”. Eventually.