Category: programming

I recently did some work for Andy Ridgwell, an old colleague from Bristol, writing a build and configuration system and GUI for a medium-sized climate model called GENIE. GENIE is an EMIC, an Earth system Model of Intermediate Complexity. It's about 55,000 lines of Fortran and includes models of the atmosphere and ocean plus models of atmospheric chemistry and biogeochemistry in the ocean and ocean sediments.

This model had been in use for some years by different groups, and the infrastructure around it had become quite baroque. Andy wanted this tidied up and made nice (i.e. rewritten...) to make the model easier to set up and use. He also wanted a cross-platform GUI for configuring and running the model, allowing you to keep track of the model state in real-time, to pause and restart model runs, changing the model configuration in between, and so on.

A major consideration for this work was that as well as being easy to use the new system had to be easy to install (on both Linux and Windows) and easy for scientists to hack on. That ruled out Haskell, my usual tool of choice. I decided to use Python instead, for a couple of reasons.

by Peter Seibel

I like the premise of this book -- find some of the best programmers out there and talk to them about their craft (or art, or science, if you prefer). First thing to say though, is that the list of interviewees tells you something about the state of the computing industry today: out of fifteen people interviewed, only one is a woman. Of the other fourteen, all of them are white men. You can argue that most of these people are pretty senior and are mostly more a product of the culture of the 1960s, 1970s and 1980s than now, but still. I'll come back to this in a minute, because it turns out that the interview with the sole woman, Fran Allen, was one of the most interesting.

For the BayesHive project, we have code split over a number of different Git repositories, all hosted on GitHub. We use GitHub for issue tracking and keeping notes on wikis.

Some of the splitting into separate repositories makes sense (our web app is in its own repository, for example), but some of the splitting is mostly historical and makes things a little inconvenient -- the infrastructure for the Baysig statistical modelling language lives in three different repositories, which made sense at one time, but doesn't now. Having these closely related bits of code in different repositories makes it more difficult to track down regressions (git bisect doesn't work across multiple repositories) and can make branching messy (if you're implementing a feature that requires work in multiple different repositories, you need to remember to create a branch in each of them, otherwise it's easy to commit inconsistent changes to the master branch in one repo and your topic branch in another repo).

As a result of all this, we decided to merge some of our repositories together. Based on a bit of Googling, this seems to be a relatively common requirement, and the advice that's on offer out there is a little conflicting and confusing. In this article, I'll try to reduce some of the confusion related to repository merging, as well as showing how to migrate GitHub issues from the pre-existing multiple repositories into the new merged repository. I've written a couple of small Haskell programs to do these tasks -- they're available here.

I remember being pretty blown away by the constraint-based drawing tools in AutoCAD the first time I used them, and I've been try for a long time to make some space to work on this sort of thing for myself (I got started a while ago, but stalled through lack of time). Of course,…

I've recently started making some tiny contributions to Brent Yorgey's Haskell diagrams library, mostly bug fixes. The bug fixes are primarily just a way of familiarising myself with the diagrams codebase though. I have my eye on a rather chunkier task in the open issues list. That's writing a constraints solver for diagram layout. I've been interested in this sort of problem for some time, and have never had a good reason to get down to it, so I'm going to see what I can come up with.

And I'm going to try something I've not done before, which is to document experiments, design and development as blog articles. It may all turn out to be hideously embarrassing, it may end up that none of what I do actually makes it into the mainstream of the diagrams library, but having to write about what I'm doing will keep me honest, force me to be clear about what I'm doing, and will provide an incentive to work on this stuff.

The first week of the online Stanford AI class has gone by. The format of the presentation is pretty good, with lots of short lecture videos chained together with little quizzes embedded. It's really pretty neat. There are some minor errors in some of the lectures, which is normal, though in this kind of online setting, it's more difficult for the keener students to correct the lecturer as the lecture goes along, so some people are likely to spend a bit of time confused because of that. Some people have complained on Reddit about the relatively superficial level of the coverage of the lectures, but as far as I'm concerned, that's what the book (and papers) are for. The course is called "Introduction to Artificial Intelligence", after all.

The two things we covered this week were a very quick introduction to the field, then some stuff about search. Although there is a big pile of code available for download associated with Russell & Norvig's AI book which would have made playing with some of this stuff easier, I decided to write some code of my own in Haskell, mostly for my own amusement. I wanted to implement A* search, with a clean interface for setting up problems.

Last time, we looked at the basics for a webcomic scraper. In this post, we'll look at extending our code a little to incorporate some date handling and some simple XML processing.

I'm a relative beginner with Haskell, and like many people, to start with I was a little perplexed by the Haskell approach to I/O. A small worked example helped a lot. I was curious to see how easy it would be to do something like the webcomic scraper application implemented in Clojure here and here. This is a simple application, but it does do realistic I/O, downloading files from the web, writing them to disk, and also doing some computations on the file contents. Over the course of two articles, I'm going to build something comparable in Haskell. It turns out to be pretty easy!