Monday, 25 July 2011

It has been a rough plan of mine since around April that I would use Scala as the foundations for my typestate research. I had not intended, however, to get quite so involved in the community as I now have. Scalathon was what changed my mind.

Some recent history: the original plan for my summer was to go work for Google, however they were unable to find a place for me and have instead now offered me a fall internship. Prior to securing the fall internship I was concerned that after all the effort expended with interviews for both Google and Microsoft Research, that I was going to be left with nothing. At the last minute I was made aware of some potential funding to visit a foreign academic institution of my choice, so I applied for this with the intention of travelling to Carnegie Mellon University to collaborate with Jonathan Aldrich and his PhD students. I succeeded in getting this funding, much to my delight, and then soon after was notified by Google that they had found a placement for me for the fall. All of a sudden, instead of one awesome three month trip to the USA, I had two placements back to back totalling over 7 months of foreign travel. Logistical nightmares aside, it was an amazing opportunity.

Since I now knew I was going to be in Pittsburgh for the summer, I had heard about Scalathon and decided to go, despite still being a relative Scala novice, just to see what the buzz was like and hopefully meet some cool people. Up until this point I had been a lurker in the community. I've been involved with a number of open source communities in the past, enough to know that often they are very ego driven and unless you have the energy and patience to deal with this, you're not going to get very far. So I had watched the Scala community from afar, and had of course heard the rumours circulating that the culture was somewhat toxic, with strong personalities and people who like to wield category theory and advanced functional programming concepts in an effort to educate you, the great unwashed, whether you wanted to learn or not.

To my delight, I discovered that its really nothing like that. Sure, there are some on the mailing lists who still seem to revel in intellectual jousting matches. However, all the people I have met face to face in the North East are a very likeable bunch of incredibly smart, motivated people. It was humbling to meet people like Daniel Spiewak - during Scalathon I was playing with parser combinators to create a better parser for links in Scaladoc. Being incredibly new both to the concept and the specifics in Scala, I had a quick Google and found a blog post on the topic. Pedro Furlanetto, who was sitting next to me as I was doing this, then said "you realise that page you're reading was written by the guy sitting across the table from you?" (referring to Daniel). That was a somewhat surreal moment. What was even better, as I got deeper into the topic and had a question which couldn't be answered readily by Googling, I asked Daniel for a little bit of help and he readily obliged.

Others were also happy to help:

Daniel Sobral, who apparently has more points on Stack Overflow than any other Scala community member (mostly through answering a ridiculous amount of questions on Scala with very detailed, thorough responses)

Mark Harrah, of sbt fame, was happy to help Pedro and I with a class loading issue when trying to run some of the scaladoc code from within an SBT launched REPL.

Paul Phillips, scalac Rockstar, humoured me by answering a rather trivial git related question that I immediately regretted asking as I felt like I was completely wasting his time.

Josh Suereth, author of Scala in Depth, was more than happy to answer dumb questions about Scala style. He also lives near Pittsburgh, and invited me in to visit the office before he left for Typesafe.

After this universal display of kindness, I felt that I really should get more involved and start "paying it forward" in the community. I'm still not really in a position where I feel comfortable committing serious code to the Scala codebase, however there was one other area that it became apparent could make use of a grad student with a very flexible schedule: documentation. The first day of scala included a documentation spree, which was an immensely positive experience and some of the most fun collaborative work I've done in a long time. So, I felt I should try and push this idea forward and try and organise "docsprees" as a monthly event. After all, it doesn't take that much time to do, it just requires someone with the will to think through the logistics, rally the troops and get it moving. This is what I have now done, and I hope it will be a success. This probably wouldn't have happened without the encouragement of Yuvi Masory and Heather Miller to just get stuck in and make some noise. No doubt there are many who are currently saying "who the f**k is Iain?" (perhaps even to the Eagles tune), but based on my experience of interacting with the Scala community so far they're probably just glad that someone is taking the time and effort to rally the community around documentation.

At this point, I think I've made my decision about which language I'd like to use for the next decade. I might as well try to help make it the best, most accessible language it can be.

Friday, 10 June 2011

(NOTE: this post is now redundant, Scala syntax highlighting in Sublime Text 2 is now dramatically better as of Build 2065, released on June 15th 2011)

At the recommendation of @roblally I decided to give Sublime Text 2 a spin, as I was starting to grow impatient with poor tooling for Scala development. I've been using IntelliJ 1.5 CE with the Scala Plugin and the SBT plugin for a week or so, but I've been getting really frustrated with how slow the whole setup has been and the inaccurate error reporting. So, perhaps it's time to go all caveman and go back to using just a text editor and SBT in a command line. I often use jEdit for simple editing of LaTeX and other such documents, but Rob believed Sublime would be worth a spin for coding oriented development. So, here we are.

So, I've been using it for all of about 15 minutes. The first thing that immediately popped out at me was that the syntax highlighting for Scala was incorrect - often in my Lift code where there are a number of objects declared within Mapper classes the syntax highlighting would pick out the object keyword on the first line, but not on subsequent lines. Minor point, obviously, but I like this kind of basic stuff to work or I don't see the point in having it at all. So, turns out the syntax highlighting in Sublime Text uses TextMate definition files, so with a quick Google I was able to find a github repo by mariussoutier that provides a better .tmLanguage definition file for Scala than that which ships with Sublime Text just now. The syntax file is here and you can just copy-paste the contents of that over the top of what exists in Sublime Text, and it seems to just work.

Tuesday, 31 May 2011

Since this is what I was doing 5 minutes ago, it seems like a reasonable first article for the reboot of the blog. A little side project I've been working on over the last couple of months has been an implementation of n-body physical simulation as part of the SICSA Multicore Challenge. The intention behind the challenge was to get as many different implementations of n-body simulation as possible, using a wide variety of languages, target architectures, and so on. I decided to give Google Go a spin, as I was interested in potentially using it as a research vehicle for my static analysis research. I will perhaps talk about my experiences of using Google Go and the n-body implementation in a later post - for the impatient, you may be able to glean some information from the presentation I gave at the workshop, or by looking at my horrible code.

When developing the implementation, I was using my trusty Macbook. However, I was intending to run the experiments on a linux based 8-core Xeon monster in the department, and was also interested in comparing performance of 32-bit and 64-bit binaries. I soon discovered that the standard Go compiler can do cross-compilation, though it wasn't obvious from the documentation how to do this, exactly. So, here's what to do. Firstly, build the compiler from source as you would normally:

This should go through without any errors. Though, if you're behind a proxy you may need to disable the network tests before running all.bash:

> export DISABLE_NET_TESTS=1

With a working build of Go, you should be able to happily develop away on your current machine. However, when you want to build a binary for a different operating system or architecture, you'll also need to build the tool chain (actually, the packages mostly) for the other platform. To do this, you'll need to set the environment variables GOOS and GOARCH to the appropriate values. See the Getting Started page for the list of options. With the environment variables set, you can run make.bash to build the appropriate packages for this alternate architecture.

> export GOOS=linux
> export GOARCH=386
> ./make.bash

I built versions for darwin, linux and freebsd in both 32-bit (386) and 64-bit (amd64) flavours.

Now, when it comes to building your program, if you followed the advice in "How to write Go code" you will probably just be running gomake. Now, before you do this simply set the GOOS and GOARCH values to the platform you wish to target. This will produce a statically linked binary for that os/arch combo, which you can then copy to your target machine to run. Simple!

To simplify things, I wrote a little script that would compile the binary for all the platforms I cared about. You can see this script here, though essentially all it does is

Monday, 9 May 2011

I decided to "reboot" this blog today as part of a general drive to separate my professional and private lives. The blog which previously existed at this address was a mixture of both, but from now on it will be exclusively to do with my professional life, similar to my Twitter account. Personal stuff will go on Facebook, so if you know me, add me there.

Currently working part-time for Onedrum as a network specialist, contributing to the JXTA and Netty open source libraries on their behalf.

Currently undertaking a PhD in Computing Science at the University of Glasgow

I work in the area of programming language semantics and type theory, though I try to stay connected with practical software engineering as much as I can. So posts here in future are likely to be a mix of theoretical and practical topics.