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 {
FIRST(1)
SECOND(2)
THIRD(3)
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.

Advertisements

The lambda calculus and closures in Groovy

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):

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

More to come…

Related Articles

• Some differences between lambda-calculus and Lisp (2). (kazimirmajorinc.blogspot.com)
• Hacker News | Compiling to lambda-calculus: Turtles all the way down (news.ycombinator.com)
• Some differences between lambda-calculus and Lisp (1). (kazimirmajorinc.blogspot.com)

Eating humble pie

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:

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

Related Articles

• Issue with String.tokenize() in Groovy (cartesianproduct.wordpress.com)
• Redirecting stdOut in Groovy (cartesianproduct.wordpress.com)
• Found my copy of “Basic Computer Games” (cartesianproduct.wordpress.com)

Coming up… the lambda calculus

Image via Wikipedia

Another thing that The Annotated Turing taught me is what all those lambdas that I have seen over the last 25 years were about, or at least it introduced me to what they were about.

So I have just ordered a copy of Structure and Interpretation of Computer Programs: and I can guess that some blog posts will eventually follow.

Oh no. Maybe I am turning into a LISP hacker – having finally reached the age that all these guys were when I first became aware of them (older, actually).

Related Articles

• Bought on a whim but seems like a good one (cartesianproduct.wordpress.com)
• The importance of Turing’s findings (cartesianproduct.wordpress.com)
• Hacker News | Compiling to lambda-calculus: Turtles all the way down (news.ycombinator.com)

Interesting looking book…

Image via Wikipedia

I am looking for a book that will help me build and run tests on applications for their memory use.

In doing so I came across this: Michael Kerrisk’s The Linux Programming Interface

It looks more like an encyclopedia than anything – at a huge 1552 pages. Is it worth it – does anyone know? There is one very glowing review on Amazon but any other views would be welcome,

Related Articles

• The Linux Programming Interface (books.slashdot.org)
• The Linux Programming Interface (oreilly.com)
• The book I want to write (cartesianproduct.wordpress.com)

Issue with String.tokenize() in Groovy

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()
ff.toy()

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.

Related Articles

• Redirecting stdOut in Groovy (cartesianproduct.wordpress.com)