More work on Life.groovy

According to “Groovy in Action” lists of lists are the correct way to do multidimensional arrays in Groovy, so I reckon I will try that now – as well as making some better use of some of the other language features, such as better use of ranges, that I noticed could be done.

Life.groovy now available

It’s far from sophisticated, and it will offend Groovy and agile programmers generally for not having a test suite, but a version of John H. Conway’s Game of Life is now available for anyone interested – licensed under the General Public Licence, so free to use and modify within those terms – it is at:

It is defiantly Old Skool in it’s approach to such fripperies as graphics and user interaction…

Game of Life in action

Game of life in Groovy

My next, and final, exam is on objected orientated design and programming. The language we used to illustrate this was Groovy. To freshen up my skills I have decided to write a version of Conway’s Game of Life – I wonder if I can do that in a few hours (no GUI display though)?

Groovydoc issue

LED elevator floor indicator
Image via Wikipedia

I have been working on a coding exercise using the Groovy programming language and struggled for a bit with an issue with Groovydoc, the documentation protocol the language uses (which is meant to be very similar to Javadoc).

Groovydoc documentation is very thin on the ground and it seems to me that the tool is not exactly complete either, so actually working out why things are failing can be a bit of trial and error.

Anyway, I had my code all in the package “elevators” but when I ran this:

groovydoc -d groovydoc -private *.groovy

Inside the source directory it produced garbage files (did not recognise the packages properly, trying to put everything in the DefaultPackage but also generating broken files for elevators package also).

Going one directory level higher and trying this:

groovydoc -d groovydoc -private -sourcepath . elevators

Produced the same result. But this (two directory levels out) seems to work:

groovydoc -d src/groovydoc -private -sourcepath src elevators

A bit of a Groovy gotcha

This tripped me up this afternoon so it might be useful to write about it…

I have been tidying up my classwork exercise Groovy, seeking to eliminate the repeated redefinition of constants – so I defined something like this:

enum ExerciseConstants {
final int value
ExerciseConstants(int value) {
this.value = value

Then I wrote some code like this:

ExceriseConstants.each {
int x = it.getValue()
ExerciseConstants.each {
int y = it.getValue()
if (foo(x,y))
return true
return false

But while foo(x,y) would surely be true only false was ever returned.

The reason is that .each (which is not supposed to be broken out of in this way) sees that return and all that happens is that control is returned to the outer closure.

In these circumstances it is much better to use code like this:

for (i in ExerciseConstants) {
for (j in ExerciseConstants) {
if foo(i.getValue(), j.getValue()) == true
return true
return false

Which works as (I) expected.

The lambda calculus and closures in Groovy

Alonzo Church (1903–1995)
Alonzo Church: Image via Wikipedia

No sooner had I written about the lambda calculus and Structure and Interpretation of Computer Programs than I sat in a lecture on closures in Groovy and was presented with a structure like this (which multiplies two numbers, in this case 3 and 4):

a simple closure in Groovy

Which immediately reminded me of one of Alonzo Church‘s formulations of lambdas – eg:

A lambda calculus representation of a formula

More to come…

Eating humble pie

Groovy (programming language)
Image via Wikipedia

Maybe this should be titled … why you should check your examples thoroughly.

A few days ago I posted a Groovy code fragment here and said I was having trouble with the same code on an application.

My problem was that the application was a piece of coursework and I really did not want to post that here in case there was some sort of plagiarism issue later on. So I wrote a code fragment that, I thought, encapsulated the problem.

I then also took the issue to the groovy-user mailing list – see here.

The problem, though, was that there was a subtle difference between the two examples and so I was not asking people to test the same thing.

My problem was that I wanted people to enter a string of two integers separated by a comma but that the String.tokenize() method was failing to parse the input string correctly (or so I thought).

In reality the core issue was that the Scanner object (in the real code but not in the test example) was already tokenizing the input string.

To make matters worse, though, my code example was failing, but in a different way, on my Ubuntu machine – though it does not any more now I have upgraded Groovy from 1.7.0 to 1.7.6 – as the screenshot below shows – this may or may not be a bug in the code installed by default with Ubuntu so beware:

Crash in groovyConsole

Anyway, the fundamental issue was the Scanner and not the tokenize message.

Issue with String.tokenize() in Groovy

Groovy (programming language)
Image via Wikipedia

Here is some Groovy code:

class Test {
String zx = new String("4, 5")
void toy() {
char xx =','
def myBits = zx.tokenize(xx)
println "first bit is ${myBits[0]}"
println "second bit is ${myBits[1]}"

Test ff = new Test()

Apologies for the fomatting but hopefully you can see what this trying to do: tokenise a String with comma as the delimiter.

Run this code in the Groovy web console and it gives the output you would expect –
first bit is 4
second bit is 5

But when I run it at home it will collapse with a null pointer exception if I try to read the second object. Essentially it falls over if there is any whitespace after the comma.

This appears to be a problem with my configuration as asking on IRC only got me a reply that the person concerned could not replicate the problem and clearly it runs in the web console too.

Anyone else seen something similar/willing to test the above code fragment?

Update: I thought that maybe this was because I was using the openjdk (installed by default on amd64 boxes by Ubuntu). But the error persists with the Sun/Oracle JDK. Very strange.

Redirecting stdOut in Groovy

Groovy (programming language)
Image via Wikipedia

I am adding this because – while it is out there on the web – it took me some time to find it and I suppose this helps make it more visible in search engines.

I was writing a Groovy unit test for a void function that normally would print to the screen. The only simple way to test would be to redirect stdOut to a string and then test the string.

This is the (or one) way to do it:

public void testPrint() {
//based on solution on
//redirect stdOut and check string is formatted
def bufStr = new ByteArrayOutputStream()
def oldStdOut = System.out;
def newStdOut = new PrintStream(bufStr)
System.out = newStdOut
System.out = oldStdOut
String prtTestStr = bufStr.toString()