If a code monkey goes on holidays…

...but doesn't upload any shots: Does anybody know about it?
Well very few, but the worst bit is I can't show it off.

Back near the start of August, my brother and I took our patrols over to Tasmania for a quick whip around. Goals were:
1. Cadbury factory tour
2. Drive in some snow
3. See an old Huon pine tree
So here is us on the first day at some lighthouse.

Stopped off at some falls.

Some more falls

A small snow fight

Spotting a rainbow

Crossing a lake

And on Mt Wellington where it snowed for all of about 30 seconds

Is was just 4 full days in Tasmania, but worthwhile. Some say “what a waste” bringing two cars but it meant all 4 of us got a front seat and if anything went wrong, the other car could probably do some towing. The only thing that bothered me is that you can’t drive and take photos (Mum still needs to pick up on the finer details of the camera).

When we got home we got some tickets to some races that I went to but caught a cold from. So I haven’t had the energy to put these pics up previously.

So we seen the Huon pine, We got to play in the snow. But the Cadbury factory was shut on the weekend, which is when we pulling into Hobart.

-= Comments from previous blog instance

1. Emma  |  August 24th, 2008 at 12:14 am
Those pics are beautiful honey

2. Emma  |  August 24th, 2008 at 12:17 am
wish i could have gone with you actually

3. RuF! RuF! RuF!  |  October 2nd, 2008 at 2:16 pm
FUCK DUDE the waterfall ones ARE AWESOME you should blow them up (wall sized) and make some kick ass prints : )

Dynamic instanceof?

Just came across an interesting line that I thought was worth sharing.
[java]
public static boolean isInterfaceOf (Object o, Class interfac) {
return interfac.isAssignableFrom(o.getClass());
}

Now java obviously has a instanceof keyword that allows you to do this, shorter to type and more recognisable.
The project I’m having a peek at (Archimedes an open source CAD program) only has one use for this where instanceof couldn’t work.
It hides the collection of objects and you can get all of the objects of a certain type. You could get around this by exposing the collection.

Just thought that this method actually makes the coding longer than what it actually does.

When people fail

An alternate route must be found.

I got such a laugh out of this one.

Just make sure you read grog free and not free grog :D

Solving the timing issue - Overkill?

So after sleeping on the problem, I came up with a solution. I need to touch the latch after the task has been done.

private Future makeMove(final Player player, final int round, final CountDownLatch latch, final ExecutorService executor)
{
  return executor.submit(new Callable()
    {
      public Choice call() throws Exception
      {
        try
        {
          Choice result = player.brain.makeMove(round);
          gameEventListener.moveMade(player, result);
          return result;
        }
        finally
        {
          executor.execute(new Runnable()
            {
              public void run()
              {
                latch.countDown();
              }
            });
        }
      }
    });
}

The trick is that I need finer control over the executer.

ExecutorService p1Executor = Executors.newFixedThreadPool(1, new DaemonThreadFactory());
ExecutorService p2Executor = Executors.newFixedThreadPool(1, new DaemonThreadFactory());

The reason I need an ExecutorService for each player is that when the first player finishes their moves, when the second player submits the “hit latch” task, it is possible that task gets executed and finished before the current task ends.

So I can finally access the get method with a 0 wait time: return future.get(0, TimeUnit.NANOSECONDS);.
I need some input though:
Is this overkill?
Is this ugly?
My first thought was that it gets the job done in very few, readable lines. So no.

Java Out of Order

So I've got a fairly consistant output now, and its the out of order or "optimisations" being made that I think have screwed me over.
Not really a gotcha, it's just I let him sneak up on me.

return executor.submit(new Callable()
  {
    public Choice call() throws Exception
    {
      try
      {
        Choice result = player.brain.makeMove(round);
        gameEventListener.moveMade(player, result);
        return result;
      }
      finally
      {
        latch.countDown();
      }
    }
  });

Now I don’t think there should be anyway that the latch.countDown(); could be re-ordered to come before the makeMove().
This allows me to get the result of the Futures with a very small wait: return future.get(1, TimeUnit.NANOSECONDS);.
But it still isn’t instant. My problem now being that the Future isn’t being set with the result in time. If you look at it from the other side, I’m not really hooking into the right part of the Future. I really need to trigger the countDown() after the future has been finished. The Callable interface doesn’t have any other methods I can hook into and my first search of the package leaves no leads.
At least I’m a little bit happier.

More Rock Paper Scissors

Long long ago, I wrote an Interface for people to write Rock Paper Scissors Bots.
We were playing around with them on one open day, I can’t believe that I didn’t blog about it.
Anyway, to distract me from my actual project, I’ve started working on it again, simplifying code and extracting out interfaces with the intention of providing more that one way to join in the tournament (which is currently only if you are specified in code).
IRC seems like a perfect alternative.
One of my first challanges was how to ask two bots for their choices, but only give a limited time before giving up. It would be cool to let humans play as well so my limit is 10 seconds at the moment. The reason I have to ask two bots at once is that I don’t want to ask bot 1, wait at most 10 seconds, then ask bot 2. Both of these can be done at once.

So, using the java.util.concurrent package, I whip up an ExecutorService. The problem with the Executors.defaultThreadFactory() is that when the program ends, those threads from the factory prevent the application from ending.
That’s easy enough to fix:

class DaemonThreadFactory implements ThreadFactory
{
  ThreadFactory impl = Executors.defaultThreadFactory();

  public Thread newThread(Runnable r)
  {
    Thread t = impl.newThread(r);
    t.setDaemon(true);
    return t;
  }
}

Now, I need to wait on two different threads, sounds like a semaphore, or a CountDownLatch in Java. I pass the latch to the Callable that will be done in the other thread.

executor.submit(new Callable()
{
  public Choice call() throws Exception
  {
    Choice result = player.brain.makeMove(round);
    latch.countDown();
    gameEventListener.moveMade(player, result);
    return result;
  }
});

Then it is just a matter of CountDownLatch.await(long timeout, TimeUnit unit)

When you submit a task to the ExecutorService, you get back a Future object which can be check if the task is done and what the result of the Callable was.

future.get(2, TimeUnit.MILLISECONDS);

And this is where the fun begins.

You’ll note that I am waiting 2 milliseconds to get the value, after waiting at most 10 seconds from the latch. I know that the methods were completed because the event “moveMade” was raised.
But sometimes, just sometimes, they get call timesout.

When I was working with Threading in Advanced .Net, I was happy debugging this sort of code because all of the utility methods were my own. I wrote them, I should know what is going on. Here I am just going off the API.

Time to “Mind Meld” with the source code of the FutureTask me thinks. It seems like there is a missing synchronized keyword somewhere but I would have thought that the FutureTask would have taken care of that for me.
I’m almost putting money on there being a “Gotchas” post being made after this one.

Wander down to Warrnambool

So I went away for the weekend. Something the family hasn’t done in a while.
Went down to Warrnambool just to see if we could come across some whales.
I borrowed a friends camera for the occasion and took some shots.

Screwing around with focus:

and finally, we saw a whale.

-= Comments
1. Emma | June 29th, 2008 at 8:16 pm
HEHEHEHE… it looks like a rock. Nice photos though

2. jay | June 30th, 2008 at 5:44 pm
nice whale