…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.
August 20th, 2008
Just came across an interesting line that I thought was worth sharing.
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.
August 7th, 2008
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 
July 27th, 2008
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<Choice> makeMove(final Player player, final int round, final CountDownLatch latch, final ExecutorService executor)
{
return executor.submit(new Callable<Choice>()
{
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.
July 24th, 2008
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<Choice>()
{
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.
July 23rd, 2008
Previous Posts