The Whiteboard Pattern

I’m not quite sure why it’s called a whiteboard pattern, but one of the neat things about the OSGi platform is the service registry. Service consumers and producers interact through the service registry that the platform provides, which takes care (in principle) of service lifecycle and dependency resolution. A correctly written service only becomes available to a correctly written consumer when the service’s dependencies have been met and its initialisation is complete. If the dependencies of any service are no longer satisfied (because of the disappearance of a required bundle), the service is removed from the registry and consumers are notified. Not rocket science, but saves developers a fair bit of effort and makes interoperable components easier to write.

The canonical example of the whiteboard pattern is an IRC bot whose commands are implemented as services. In this example, an IRC Bot is created that maintains its connection to the IRC server while commands are loaded and unloaded from the Bot on the fly. Here, the ServiceTracker is used to listen for the appearance and disappearance of bundles. Neat, but there’s still some associated boilerplate:

  private ServiceTracker serviceTracker;

  public void start(BundleContext context) throws Exception {
    serviceTracker = new ServiceTracker(context,
                              MyTrackedService.class.getName(), null);
    serviceTracker.open();
    ... startup code...
  }

  public void doStuff() {
    Object[] implementors = serviceTracker.getServices();
    if (implementors != null && implementors.length > 0) {
      for (Object o : implementors) {
        MyService myService = (MyService) o;
        … do stuff…
      }
    }
  }

  public void stop(BundleContext context) throws Exception {
    serviceTracker.close();
    serviceTracker = null;
    … shutdown code …
  }

iPOJO

iPOJO attempts to reduce this boilerplate and make service registration and listening even simpler. Under iPOJO, the boilerplate is reduced to:

  @Requires
  private MyService[] implementors;

plus some hand waving. iPOJO takes care of making sure that the implementors array contains registered implementations of MyService - all your application has to do is iterate over them.

iPojoRC

With a view to having a play around with this stuff, I thought I’d implement the IRC Bot using iPOJO. You can find the fruits of that labour on my github account. It seems to work pretty well. I’ve so far not had a problem adding and removing commands on the fly. It’s even possible (if you’re really careful with versions) to rev parts of the IRCCommand API and have the old and new versions running side by side, but in practice it’s much easier just to mvn clean install.

Why?

Summut to do, innit. More seriously, OSGi seems to be gaining ground as a way of building and distributing Java applications. It plays very nicely with Maven and there are some quite neat bundles available that you can just drop in to your application with very little wiring. That said, one of the challenges of OSGi is dealing with packages and dependencies when you create your own bundles. Most of the tutorials recommend starting with all your code in a single bundle, with good reason - I invariably spend more time sorting out dependency and classloader issues with my bundles than I do writing the code inside them. If you’re going to start a serious OSGi project, it’s good to have experience of bundling simple things and the IRC Bot is a great example of simple code in many bundles.

The following code compiles. There’s a method where I’m putting the type hints in, a method where I’m not, and a method where I’m passing the retrieved hash value directly to an explicitly typed function. In all three cases, at least in principle, the runtime types should match - I’m putting in a String, I expect a String out the other side.

There is, so we’re clear, a runtime cast (call to asInstanceOf), but this is where I’m expecting the developer using my class to be right. And where they’re right, what I don’t expect is a ClassCastException.

import scala.collection.mutable.Map

object Main {
  def printIt(optString: Option[String])
  {
    optString match
    {
      case x: Some[_] => println(”Got: ” + x.get.substring(0,2))
      case None => println(”Got nothing”)
    }
  }

  def withInferredType(token: Token)
  {
    println(”\n— With Inferred Type —”)

    val fish = token.get(”fish”)
    printIt(fish)
  }

  def withoutExplicitType(token: Token)
  {
    println(”\n— Without Explicit Type —”)

    val fish = token.get(”fish”)
    fish match
    {
      case x: Some[_] => println(”Got: ” + x.get.substring(0,2))
      case None => println(”Got nothing”)
    }
  }

  def withExplicitType(token: Token)
  {
    println(”\n— With Explicit Type —”)

    val fish = token.get[String](”fish”)
    fish match
    {
      case x: Some[_] => println(”Got: ” + x.get.substring(0,2))
      case None => println(”Got nothing”)
    }
  }

  def main(args: Array[String])
  {
    val token = new Token
    token.put(”fish”, “cat”)
    withExplicitType(token)
    withInferredType(token)
    withoutExplicitType(token)
  }
}

class Token()
{
  private var elements = Map[String,Object]()

  def get[A <: Object](key: String): Option[A] =
  {
    for (val value <- elements.get(key))
      return Some(value.asInstanceOf[A])
    return None
  }

  def put[A <: Object](key: String, value: A)
  {
    elements.put(key, value)
  }
}

resulting in:

 scalac Token.scala && scala Main

--- With Explicit Type ---
Got: ca

--- With Inferred Type ---
Got: ca

--- Without Explicit Type ---
java.lang.ClassCastException: java.lang.String cannot be cast to scala.runtime.RichString
        at Main$.withoutExplicitType(Token.scala:29)
        at Main$.main(Token.scala:52)
        at Main.main(Token.scala)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at scala.tools.nsc.ObjectRunner$$anonfun$run$1.apply(ObjectRunner.scala:75)
        at scala.tools.nsc.ObjectRunner$.withContextClassLoader(ObjectRunner.scala:49)
        at scala.tools.nsc.ObjectRunner$.run(ObjectRunner.scala:74)
        at scala.tools.nsc.MainGenericRunner$.main(MainGenericRunner.scala:154)
        at scala.tools.nsc.MainGenericRunner.main(MainGenericRunner.scala)

In all three cases I’m doing the same thing with the same data. In the ‘Inferred Type’ case, it’s actually doing the thing I want in production. But all three cases compile and one throws a ClassCastException - I had very much hoped that the type system would pick me up on the broken case.

What am I doing wrong, lazyweb? Any comments greatly appreciated.

Considered Harmful

Morning. I’ve had a think about it and as usual with me writing about Scala, it’s my mistake rather than the language’s. What I’d hoped to achieve was something like duck-typing where I could pull something out of the hash and use it as whatever made sense in the code. Static type inference doesn’t work this way though.

In the above code, in the two cases where I was constraining the type, it works fine. In the case where I don’t constrain the type, Scala can legitimately choose any type that implements substring; in this case it chose RichString, which happens not to be the type I put in to the hash. In general, this is a pretty dangerous approach - what I want is for the type system to force me to nominate a type for the result of the get before I use it.

Turns out the way to do this is to have get return Object and use asInstanceOf at the call site. C’est la vie.

I’m going to keep my proposal brief, partly to avoid TL;DR-ism, and partly because it’s probably garbage, but here goes.

Creative Commons over Time

Legislative reform is a tough battle. Let’s just side-step it. Take the existing CC licenses and extend them to allow CC/T; the creator retains all the rights to their work afforded under “default” copyright until a nominated date, after which the work is covered by the nominated CC license. Instead of saying “CC BY SA”, you’d say “CC BY SA / T2015″. Until the expiry date is reached, the creator can exploit the work in whatever way they see fit, just as they can today under the “default” copyright regime.

How does that help?

The idea here (and I confess I’ve not talked to any artists) is that going completely CC is scary for artists whose living is made from their creative output. As fervently as you might believe their work would be better served by a CC license, it’s really tough to persuade people to “give away” their livelihoods. Instead, the pitch goes like this… Their work is going to end up in the public domain; everything created today is implicitly “PD / T2150″ (let’s say). All I’m proposing is that instead of using the default date, they choose a date themselves and a license for use after the date has passed. They might well choose “CC / T2100″, or “CC / T2050″, but it’d be an improvement.

Raising awareness

In and of itself, that won’t achieve anything, but if you can convince artists to take control over the relationship between their work and society, that’s already a small win. The bigger win will require use of technology. Assuming some plucky evangelist can persuade artists to start using these licenses, the next step is to write a webservice to map the (for instance) ASIN for a CD / track / book to an expiry date. That done, you could a) set up you own shop highlighting the expiry date on the items or b) write a GreaseMonkey script to overlay the expiry date on Amazon’s existing shop. You could colour code works - Red for “PD / T2150″, Green if the creator has nominated an expiry date (we needn’t be any more divisive than that to begin with).

Working out the “correct” term

The plan, in case it’s not clear, is to let the market work out the “right” value for copyright term without global multilateral legislative reform. If you can get adoption and if you can raise awareness and if consumers actually care, what you might hope to see is a dutch auction in copyright term lengths. Artists could compete to best serve their fans by varying the amount of time they felt they needed to profit from a work. This won’t necessarily be the optimal value for society (consumers may underestimate the value to them of reduced term), but one would hope we’d end up with a smaller number for copyright term than that selected by legislation.

What about artists’ retirements?

It’s a commonly held misconception that part of copyright’s role is as a pension scheme for aging artists or a life insurance policy for their families. Society affords artists a temporary monopoly on their work so as to encourage them to create more work, on the understanding that the work is donated to the commons after that monopoly expires. It’s easy to find examples of outliers for whom extended term is a key concern, but the majority of artists won’t see continued revenue from their work that is anything like as substantial as the value to society of having all that work in the public domain. If they’re looking for a pension / insurance scheme one might politely suggest that they should invest in a pension / insurance scheme.

Won’t we just end up eating our CC babies?

There is obviously a risk in this that artists who might otherwise choose a pure CC license end up choosing to exploit their works under a CC/T license. Much like GPL vs. LGPL, we’d obviously prefer that CC/T licenses didn’t exist at all lest they tempt people away from the “right” answer. I think it’s a risk worth taking to try and accelerate the copyfight and get people thinking about the relationship between copyrighted work and society.

So. Cory writes to tell us of an exciting new police initiative (hot-linked here - could change to goatse at any moment):

Yay. But does taking photos of CCTV cameras make you a terrorist? I’ve decided to find out. To play my new game, you will need:

• A Nokia Series 60 3rd Edition phone with internet connection
• A geo-tagging application
• A Flickr account that you’ve enabled for auto geotagging
• An app to upload your photos to Flickr

Now all you have to do is snap pictures of the cameras you find and upload them to Flickr before the police confiscate your camera. Of course, you can delete the photos from your phone the second they’re uploaded. No point leaving them hanging around - at best you’ll look like a weirdo in the unlikely event that the police go rifling through your personal property.

Here’s my photo stream - where’s yours? (Remember to tag your photos ‘cctvfun’).

Aren’t you helping the terrorists?

Let’s get some perspective. You’re still more likely to die in your bath than you are to die in an explosion. If people photographing CCTV cameras represents a significant threat to everyone’s safety, we should make some kind of law against it. At least that way there would be some kind of review of whether or not such a restriction on our freedoms makes sense and is proportionate to the threat. We shouldn’t allow the police to make up their own laws - that way madness lies.

As long as it’s legal to do so (and possibly even after it stops being legal to do so), I would encourage everyone to join in my new game and help redress the balance of surveillance.

About a month ago, a colleague was whining about having to write Java and it was hard not to sympathise. He’s a Python man, and Java’s Kingdom Of Nouns can seem a little clumsy. Sometimes, you just want to map{}, and trying to do that in Java can leave you feeling dirty.

There are proposals for first class functions and closures in Java - Neal Gafter is your man there. They look fun n’all, but they are apparently a little way off. What I needed in order to silence my colleague was less irritating Java in production straight away. In order to satisfy the needs of m’colleague, m’self and m’company I would need a couple of things.

Pour lui

• Concise variable declarations - none of this

  Map<String,List<Integer>> map = new HashMap<String, List<Integer>>()

  nonsense

• Functions as first class values
• Excellent library support

Pour moi

• Strong, static typing
• Eclipse integration
• Monads. Everybody loves monads

For practicality’s sake

• Maven integration
• Interoperation with the existing Java code base

I had a look on Wikipedia for a suitable JVM language since that would ensure the easy interoperation and give us a decent set of libraries. It turns out Scala has everything we need. It’s mixed paradigm functional / object-oriented, it’s got a Hindley-Milner style type inference system, and it’s got a really active community. The eclipse/maven integration isn’t quite there yet, but it gets much better as you get closer to the bleeding edge.

Some Code

There have been too many cool things to mention really, but here’s the first one that seemed apt for a blog post. Scala has some nice XML support, but lacks some of the functions you might like on an XML Node like, for example, ‘getAttributeValue(attributeName)’. In Haskell, you could define a new typeclass and create an instance for Node. In Java / C++ you could delegate (if you like pain). In Ruby, you could mixin. The answer in Scala appears to be… an Abstract Type Member.

Disclaimer:
I don’t know what the right answer actually is, but this works and seems kinda cool

import scala.xml.NodeSeq
import scala.xml.Node

object XmlTest
{
  implicit def nodeToNodePlus(node: Node):NodePlus =
  {
    return new NodePlus { type T = Node; val init = node }
  }

  abstract class NodePlus
  {
    type T <: scala.xml.Node
    val init: T
    private var value: T = init

    def getAttributeValue(name: String): String =
    {
      return value.attribute(name).get.first.text
    }
  }

  def main(args: Array[String])
  {
    println("Hello")
    val xmlDoc = <hi><hello id="world"/></hi>
    val hello = (xmlDoc\"hello").first
    println(hello.getAttributeValue("id"))
  }
}

The mechanics of what’s going on there are… err… pretty opaque to me. But to break that down a little:

• An object is a singleton class, equivalent in most senses to a static class in Java.
• An implicit is a function from A to B which the compiler will use whenever inference tells it that you need a B but have an A (yes, evil, but okay if used carefully).
• type T is an Abstract Type Member. I think.
• <: is a subclass restriction

… all of which allows me to introduce a new function to an existing class without access to that class’s constructor. Handy.

That’s probably garbage. No doubt I’ll find out that’s not the way to do it or that it won’t do what I expect, but it seems to work. The take-away is that Scala is an easy transition from Java, is much prettier and cooler, and that I can’t think of a good reason to write any more Java code.

… having slept on it…

Ah. You see. What I did there was… I got carried away. My NodePlus class is actually no better than a wrapper - I can’t actually do any Node operations on it. The implicit mechanism makes it look like I can, but I can’t. And the Abstract Type Member was a bit of a red herring. What the Abstract Type Member is doing is letting me parameterise my type which is, I guess, a kind of useful. Given that Scala types accept formal parameters, though, it’s not completely clear how much win is involved.

I’ll let you know if I find out how to do the thing I actually want to do.

One of the morning sessions in Cambridge was a discussion about censorship and the role of the IWF and, being fairly strongly anti-censorship, I chose to go to that session. Long story short, I may have gone on record defending my right to view images of child abuse. I don’t think I made my point as eloquently as I might have done, so I thought I’d summarise the issue here.

The Role of the IWF

I should start by saying that I think the IWF does “a good thing”. As an organisation, they’re run fairly openly and one of their many functions is to be the UK’s notice and take down body. If you have a problem with the UK internet and you want to get it sorted, they’re the people to contact. As such, they are a fairly innocuous alternative to regulation of the UK internet which, I believe, would be a pretty bad idea. Their primary function is not the blocking of child pornography / images of abuse for which they have become so (in)famous recently, and I was pleased that their representative there (Sarah Robertson) acknowledged that their blocking system is imperfect / ineffective. One of the things I objected to most strongly about the blocking system as a technologically-minded person was the idea that an organisation like the IWF imagined it was even possible to censor the internet. It turns out they don’t, which is a relief.

My Question

So, given that Sarah acknowledged that the system was flawed - that it served merely as a deterrent and to avoid people accidentally browsing to images of abuse - my question was why the system isn’t opt-in, or at the very least opt-out. If I want my connection filtered, I would be able to go to the IWF or, install some other filtering software. Sarah replied that the system is opt-in, which is true if you’re an ISP, but I happen not to be. I made the point that as an individual, I couldn’t opt out of having my internet connection censored (by what I cheekily described as an opaque organisation - I meant merely that I had no way of knowing what was on the block list). To an extent, it’s possible for users to vote with their feet and sign up with ISPs that don’t implement the IWF scheme, but these ISPs are being pressured in to joining the majority of providers in installing the software / hardware required.

Sarah’s Question

Why would I want to opt out of the system? The IWF blocking system stops me viewing images of abuse which I presumably wouldn’t want to anyway, and moreover, it stops me breaking the law. If I browse without the protection of the system I could accidentally navigate to an illegal image and open myself to prosecution under UK law. Fair point. And at the time I didn’t have an answer, but have since been thinking about it because it’s a really good question.

The Individual and the State

One of the reasons we had all gathered in London, Cambridge and across the UK, was to discuss what some feel is a radical change that is taking place in the relationship between “us” as citizens and “them” as the government. In theory, the state and its machinery exists at our behest and is there to serve us. Some of the attendees at the Convention were there because they felt that this is increasingly not the case. Why do police photograph protesters at peaceful demonstrations? Why can’t protestors photograph the police? (Why, indeed, can the press not photograph the police, making it difficult to publicise and document a demonstration?) The Home Office seem determined to reduce the risk of the population coming to harm at the expense of curtailing our civil liberties - ought we not to be given a say in the amount of risk that we’re prepared to accept? And it’s not entirely the Home Office’s fault. Society and the press tend to blame the government when “bad things” happen - the only way for them to avoid further blame is to reduce the incidence of bad things.

The real question

Why would I want to break the law? I guess that’s not even really the question. I don’t really want to break that law. I certainly don’t want to view images of child abuse, accidentally or otherwise. But I would very much like the option to break any law. The IWF conscientiously populates the blocking list with the locations of images deemed to be illegal to view and, as far as I’m aware, no “right thinking” person would want to see the images that have been blocked. What they’re doing, though, is implementing a system which allows the government to have content they define as illegal “removed” from the UK internet.

I sometimes disagree with the government

There. I said it. Sometimes I break copyright law. Sometimes I drive too fast. Sometimes I start composing blog posts while I’m stuck in traffic. If someone offered to install a chip in my brain that would make it impossible for me to break the law, controversially, I don’t think I’d take them up on the offer. “If you don’t like the law, you should try to have it changed”. True. I absolutely believe that. But as (I think) Shami Chakrabarti aptly put it on Saturday, whoever you vote for, the government tends to get elected.

I can’t change laws quite as quickly as they’re being introduced. It’s simply not practical for me to campaign against everything with which I disagree, and I don’t think there’s enough popular support today for me to make a difference even if I did. I’ll continue to support the work of NO2ID and the Open Rights Group, and I’ll continue to get as involved as I can with things like the Convention on Modern Liberty. For the time being, though, I’d like to keep my moral autonomy; to be able to choose which laws I obey and which I don’t, to have the option to do things that the government doesn’t necessarily want me to do.

I promise I’ll be good

P.S. Obviously the IWF blocking list is a bit of a moot issue for me. I can bypass the filtering in any number of ways if I choose to do so. Recommend you check out Tor and/or ssh -D if you’d like to be able to do the same.

Antediluvian file formats

The project, in case you’ve not been following on github, is to resurrect a long-since abandoned game. This game was released as a cover disk on an Amiga magazine back in “the day” and the code has since been made available by the authors (in 68000 assembly), ported to BlitzBasic and (abortively) ported to C++/SDL.

The maps for the BlitzBasic game were stored as tile maps. Each game level combines a tile set and a map to place the tiles on the screen. For additional kicks, some of the files are compressed under a scheme called “BPCK” which involves fairly simple run-length encoding. The code to parse up those files was… err… relatively straightforward to write although I did have some issues with bit-order and palette mapping.

Tiles as Pixbufs

The tiles are stored as sequences of nibbles mapping pixels on to a 16-colour palette. In order to draw these, I extracted the RGB for the nibbles and inserted that 3-byte-per-pixel sequence into a pixmap (this is the source):

buildTile :: [BPCK.PaletteEntry] -> BPCK.Gliph -> IO Pixbuf
buildTile palette g = do
    let gData = BPCK.gliphData g
    buf <- pixbufNew ColorspaceRgb False 8 gliphX gliphY
    pbData <- (pixbufGetPixels buf :: IO (PixbufData Int Word8))
    rowStride <- pixbufGetRowstride buf
    chan <- pixbufGetNChannels buf -- Hopefully this is 3 (R,G,B)
    bits <- pixbufGetBitsPerSample buf -- Hopefully this is 8
    doFromTo 0 (gliphX - 1) $ \y ->
      doFromTo 0 (gliphY - 1) $ \x -> do
        let pixbufoffset = x*chan + y*rowStride
        let gliphOffset = fromIntegral $ x + y*gliphX
        let paletteIndex = B.index gData gliphOffset
        let thiscolor = palette !! fromIntegral paletteIndex
        writeArray pbData (pixbufoffset) (fromIntegral $ BPCK.red thiscolor)
        writeArray pbData (1 + pixbufoffset) (fromIntegral $ BPCK.green thiscolor)
        writeArray pbData (2 + pixbufoffset) (fromIntegral $ BPCK.blue thiscolor)
    return buf
    where gliphX = BPCK.gliphWidth g
             gliphY = BPCK.gliphHeight g

Maps as Pixmaps

The difference between a pixbuf and a pixmap is, as I understand it, that a pixbuf is an X-client side block of data into which you can load pixel information and a pixmap is an X-server side drawable (in the GTK sense) object. Pixbuf is more like a brush for painting, and Pixmap is an off-screen canvas. So to build my map I blatted the tile pixbufs on to a pixmap:

createTiledPixmap :: BPCK.ParsedImage -> BPCK.ParsedTileMap -> IO Pixmap
createTiledPixmap tileSet tileMap = do
    putStrLn $ "Building tile pixmaps"
    tiles <- tilesFromImageData tileSet
    let tileCount = length tiles
    putStrLn $ "Creating new pixmap " ++ show totalWidthPixels ++ " x " ++ show totalHeightPixels
    pixmap <- pixmapNew (Nothing :: Maybe DrawWindow) totalWidthPixels totalHeightPixels (Just 24)
    gc <- gcNew pixmap
    doFromTo 0 (tilesHigh - 1) $ \iy ->
      doFromTo 0 (tilesAcross - 1) $ \ix -> do
        let tileIndex = ix + (iy * tilesAcross)
        let tileId = (min (fromIntegral (BPCK.tileMap tileMap !! tileIndex)) tileCount) `mod` tileCount
        let curX = ix * tileSizePixels
        let curY = iy * tileSizePixels
        postGUIAsync $ drawPixbuf pixmap gc (tiles !! tileId) 0 0 curX curY tileSizePixels tileSizePixels RgbDitherNone 0 0
    return pixmap
    where tileSizePixels = BPCK.gliphSize tileSet
             tilesAcross = BPCK.tilesAcross tileMap
             tilesHigh = BPCK.tilesHigh tileMap
             totalWidthPixels = tileSizePixels * tilesAcross
             totalHeightPixels = tileSizePixels * tilesHigh

Results

The finished article looks a bit like this:


or this:


and pressing the space bar cycles through the maps on account of this:

onKeyPress app (\x@(Key { eventKeyName = name,
                              eventKeyChar = char }) -> do
    case char of
      Just ' ' -> do
        putStrLn $ "Switching map"
        currentState <- readIORef mapStateRef
        nextState <- nextMapState currentState
        writeIORef mapStateRef nextState
        drawWin <- widgetGetDrawWindow canvas
        gc <- gcNew drawWin
        (width, height) <- drawableGetSize drawWin
        postGUIAsync $ drawDrawable drawWin gc (renderedMap nextState) 0 0 0 0 width height
      Just c -> putStrLn $ “Press ” ++ name ++ “(’” ++ [c] ++ “‘)”
      Nothing -> putStrLn $ “weird key: ” ++ name
    return (eventSent x))

Conclusions

I’m now a lot more comfortable with Haskell and think I’ve mastered the “word-for-word translation of imperative to pseudo-functional” style. The file parsing code I’ve written performs like a dog on account of that, but it’s not on a critical path for anything. One thing that has struck me is how easy it is to refactor Haskell code (as long as you use hanging ‘do’s to avoid formatting upsets). So I’ll stick at it and see if I can’t finish this project inside of a year.

Why not SDL?

FYYFDANSEIC, etc.

Solution: in your new class, create a private field of type Object. Override the hashCode() method in the class to call hashCode() on that field. The result should follow a pattern similar to that below:

public class CustomHashSet<T> extends HashSet<T> {
    private Object hasher;

    public CustomSpecHashSet() {
        super();
        hasher = new Object();
    }

    @SuppressWarnings("unchecked")
    public synchronized Object clone() {
        CustomHashSet<T> copy = (CustomHashSet<T>)super.clone();
        copy.hasher = new Object();
        return copy;
    }

    public int hashCode() { return hasher.hashCode(); }

    public boolean equals(Object o) { return this == o; }
}

Discussion

In Java, once a method has been overridden, it is impossible to get at the original implementation from any inheriting classes. I recently had to deal with this when I wanted to keep some objects that inherited from various Collections inside HashSets, and wanted distinct objects in the set to not be treated as equals just because they happened to contain the same elements. In other words, I needed to use the Object implementations of the hashCode() and equals() methods, rather than the versions defined by the Collections. This is because Object.hashCode() returns a unique integer for every distinct object (typically by using the memory address of an object).

At first, I thought this problem could be solved with reflection. The soloution should simply involve getting a Method instance for Object.hashCode(), and invoke that on any object. Unfortunately, that does not work; calling a method using reflection in Java results in a dynamic method lookup based on the object the method is being invoked on.

Since Java does not permit un-overriding methods, one has to cheat. An object that is never leaked to the outside world can be used to provide a unique integer for each instance. However, care must be taken when implementing classes that support cloning (i.e. implement the Cloneable interface, or inherit from a class that does). Since the clone() method only does a shallow copy of an object, it is essential to override clone(), and make sure that any copies created there get their own instance of the hashing object. There is another gotcha; in the presense of multiple threads accessing the same object, the following clone() implementation would be unsafe:

public Object clone() {
    MyObject copy = (MyObject)super.clone();
    copy.hasher = new Object();
    return copy;
}

This is because the Java memory model only guarantees initialization safety for objects created using a constructor. What this means is that, for an object created using clone() and changing fields after the call to clone(), the updates to those fields are not guaranteed to be seen immediately by other threads accessing that object. A simple way to address this is to put the initialization of the cloned object inside a synchronized block, as in the code given at the top of this recipe.

I’ve put the code that I’m working on up on GitHub because that’s what all the cool kids are doing. My project is called GP3 for reasons that ought eventually to become clear. HEAD at time of writing is 7b01940

Glade
Glade is a GTK UI designer. I won’t go in to a lot of detail - there’s been plenty written about it. What I will say, though, is that at version 3, you can often find yourself creating unexpected dependencies for your program by using the more complex widgets. I unwittingly picked something from the “GNOME User Interface” toolbox, which has a Glade class of “GnomeApp”. This includes a “BonoboDock” and a “BonoboDockItem”.

Launching your app
Borrowing heavily from the book, here’s part of the code I was using to launch my app:

main :: FilePath -> IO ()
main gladepath =
  do
    unsafeInitGUIForThreadedRTS
    timeoutAddFull (yield >> return True) priorityDefaultIdle 100
    gui <- loadGlade gladepath
    connectGui gui
    windowPresent (mainApp gui)
    mainGUI

gnome_program_init()
Having made the mistake of using a GNOME-UI widget, I saw this when I ran my app:

GnomeUI-ERROR **: You must call gnome_program_init()
          before creating a GnomeApp

This is because my Glade UI requires libgnomeui to be initialised. To make matters worse, libgnomeui isn’t linked by default in to Gtk2Hs. In my limited understanding of Haskell and Gnome, there are two options at this point. One is to import the gnome_program_init function from libgnomeui over FFI. The other is to write a C program to wrap a call to gnome_program_init and re-export a simpler function for you to import over FFI. I chose the latter option:

// gtk_docker.c
#include 

void do_gnome_init()
{
  static char **argv = NULL;
  if (argv == NULL)
  {
    argv = malloc(2);
    argv[0] = “gtk_docker”;
    argv[1] = ‘\0′;
  }
  gnome_init(”my-app”, “my-version”, 1, argv);
}

… and a header file

// gtk_docker.h
void do_gnome_init(void);

Astute observers will see that this is a bit of a cheat. GnomeUI wants the command line arguments that were passed to the executable. It would be possible, but irritating, to arrange this. I couldn’t easily divine how to pass an array of CStrings over FFI, so I wimped out. Also, I’m not technically calling gnome_program_init - this call appears to be deprecated in favour of gnome_init, and the latter call also silences the error message.

Compilation
We haven’t solved the compilation problem yet. The compiler still needs to know where to find gnome.h and its included headers, and needs to know where to find the associated libraries for linking. There are good ways and bad ways to solve this problem… here’s a bad way:

#Makefile
LDFLAGS = -lgnomeui-2 -lcairo -lglade-2.0
CFLAGS = -I/usr/include/libgnomeui-2.0 -I/usr/include/gtk-2.0/ \
              -I/usr/include/cairo/ -I/usr/include/glib-2.0/ \
              -I/usr/lib/glib-2.0/include/ \
              -I/usr/include/pango-1.0/ \
              -I/usr/lib/gtk-2.0/include/ \
              -I/usr/include/atk-1.0/ \
              -I/usr/include/libgnome-2.0/ \
              -I/usr/include/libbonobo-2.0/ \
              -I/usr/include/libgnomecanvas-2.0/ \
              -I/usr/include/libart-2.0/ \
              -I/usr/include/libbonoboui-2.0/ \
              -I/usr/include/gnome-vfs-2.0/ -Werror -Wall

GHCC=ghc

default: gp3

gp3: gtk_docker.o GP3Main.hs GP3GUI.hs
        $(GHCC) --make $(LDFLAGS) $^

clean:
  rm -f *.o *.hi GP3Main

The real answer probably involves GNU AutoTools for the C toolchain or some craziness with Cabal. I’m sure I’ll get round to that

Calling the function
Now to clear that error message. We just need to…

{-# LANGUAGE ForeignFunctionInterface #-}

foreign import ccall unsafe "gtk_docker.h do_gnome_init"
      c_gnome_init :: IO ()

and

main :: FilePath -> IO ()
main gladepath =
  do
    unsafeInitGUIForThreadedRTS
    c_gnome_init
    ...

and we’re done.

Portability
Linking libgnomeui probably makes my code a lot less portable. Hard-coding the include paths certainly does. Fortunately I don’t have to care about other users just yet, and I’m unlikely ever to care about other platforms

Part 1: The GTK event loop

Most programs that use Gtk2Hs first do all the GUI-related initialization, and then execute the mainGUI computation. This is actually a loop that processes GTK-related events until the user quits the program. Because of the way thread switching works in Haskell, a thread executing a loop like that will not let any other “lightweight” threads run. (Lightweight threads are threads created using the forkIO computation.) One frequently suggested way to solve this problem is to make the GTK event loop periodically yield to any other Haskell threads by adding the following to your GUI initialization code:

timeoutAddFull (yield >> return True) priorityDefaultIdle 100

Note that this is only an issue when all lightweight Haskell threads run on top of a single operating system thread, as in the single-threaded RTS of GHC. If Haskell threads are allowed to run on multiple OS threads, then yielding is not necessary.

Part 2: GTK thread safety

It turns out that that GTK (the C library wrapped by Gtk2Hs) is not thread-safe. What this means is that all modifications of GTK state must happen from a single OS thread, which also must be the same thread that is executing the GTK event loop. If all Haskell threads are run on top of a single OS thread, this is easy to ensure. However, if you use a system where lightweight threads may be mapped to different OS threads (such as in the multi-threaded RTS in GHC), care must be taken when accessing a GUI. Essentially, application threads need to put GUI modification events onto a queue, with the thread that runs the GTK event loop processing the events from that queue. Fortunately, Gtk2Hs comes with such a queue built-in; you can use the postGUI functions to give the event loop blocks of IO to execute.

Note that, by default, Gtk2Hs will produce a warning when running under the GHC multi-threaded RTS. To get rid of this, use unsafeInitGUIForThreadedRTS instead of the usual initGUI to perform GTK initialization. The “unsafe” part of the computation name signifies that you are aware of the requirement to only modify GTK state from the correct OS thread.

Part 3: Deconstructing the GTK event loop

There might come a time when you want to do something more complicated than the above solutions allow. In such a case, you can actually substitute the mainGUI event loop with your own. Gtk2Hs provides functions that will process a single event at a time off the GTK event queue. Put these in a loop, sprinkle with your custom logic (such as pulling events off multiple queues), and you’re done!

Context

This was written with the GHC environment in mind. Other Haskell compilers and/or interpreters may differ in their implementations.