Infinity: Easier Than You Think. Infinitely.

Spaghettified musings on software

  • October 2009
    S M T W T F S
        Jan »
  • Advertisements

groovy gpars – trials and tribulations Part Duex

Posted by gdjsky01 on 2009/10/10

When we left off in part one of this sojourn I had given up for the night hoping someone might see my tweet a take a look. Well getting the authors of gpars to take a look is a good thing! 😉 Thank you both.

A quick update to my part one, I see the download link for gpars is live on CodeHaus.

First I tried to join the gpars mailing list. I tried to join the google code mailing list first because that had recent activity. But I am awaiting the normal confirmation. It occurred to me, being the sharp guy I am :P, that when the move was made from Google Code to CodeHaus, the mailing list moved. So I went over to CodeHaus and tried to join a list over there. And I  am awaiting a confirmation approval. ;P

In the mean time I thought I’d browse the archive there. However the list of mailing lists showed no gpars mailinglist. So maybe the google group is the only group for now.

While this may all seem annoying, I assure you it is not. It is all completely understandable when you realize the authors are moving to a new home, and they probably have real work, jobs, and familiy to attend to. So patience should be extended to them. In time everything will straighten itself out. I did not know Dierk König was on the project! Mr “Groovy in Action!”, very cool! And I believe Vaclav works on Intellij? Is that right. I love IDEA and have used it since 2005.

Ok back to the grind….

So I am back to using the MacBook Pro since using Windows XP gave essentially the same results. First thing I did is look in lib directory of gpars. Duh!!! Right there was the correct version of the jsr166y jar. Who knew? 🙂 Okay so that was not in my classpath and needed to be. I copied that JAR to the groovy 1.6.5 library directory and deleted the one I had downloaded elsewhere Voilà! Now the DemoParallelizer and Enhancer works.

Vaclav was correct that the integration page of the CodeHaus site would have tipped me off to the correct version, but I was impatient and did not want to work with maven (ick), or gradle, or grape, or.. <insert favorite build system here>. etc.

However the Actor demos, like the DemoDiningPhilosophers were still not compiling at all. So I was perplexed at the comment about using Groovy 1.6.5 since that is what I am using. But then a light bulb (more like flash blub) went off in my head. Maybe what I had to do is compile the gpars project with Groovy 1.6.5… and do so with the source of gparallelizer 0.8.4… so now I had to find the 0.8.4 source of gpars.

I have no knowledge at all of gradle or git except for a very interesting interview with the author of gradle on the Groovy and Grails Podcast. You DO listen to that right? No? Go subscribe… I wait… go on… I’ll wait… Back? Excellent.

What I know and dislike for the most part is maven (that should be another blog post). I know Subversion, and I am learning bazaar. But git and gradle were not on the radar. For this ‘spike‘ I was just using the demonstration gpars source. No build system. Just the jars, the source, and good ole Groovy 1.6.5. I had no intention of building from source.

Best I could figure, on CodeHaus I was able to find a tag that said “Updated to groovy 1.6.5” That sounded promising so I clicked on ‘snapshot‘ which downloaded a tar file.

Again being a baby in the cradle of gradle all I could do is poke about. Like a –help switch. 🙂 Ah ha! A  –gui switch produced a nice GUI (imagine that!!) and I tried a build. Once again the building process got to :compileTests and hung. About 30 seconds later it ran out of heap space. Well I’d been down this road before (BTW: in Intellij, using the project ipr provided, the tests run just fine… weird huh?). For some reason the unit tests will not compile using gradlew. I tried using JAVA_OPTS set to  -Xmx2048m and still no worky. 🙂

So I clicked on the assemble gradle target which (apparently) skips the tests. (Yes yes I know that is not good, but this is a code spike – not production.) Hmmm… that produced a .0.9-SNAPSHOT jar, where I’d been expecting 0.8.4… no matter, that is where the SCM tag indicated the switch to groovy 1.6.5 took place. I copied that jar to groovy lib directory and ran some of the demos that had given me problems.

Success is Nearly Ours!

The jar I built ran most of the demos. Not all of them, the DemoMashupWithMethods in the Dataflow demos still, on the Mac, just starts the downloads and exits. But virtually all the Actor demos ran. Whether they are correct, of course I can not know without the unit tests working. I will bring the project into Intellij and see if the unit tests pass. They did yesterday. The difference is Intellij is compiling and running the tests, not Gradle. Not that I know that is the problem. I don’t.

I believe I have enough working now to study what types of object in gpars might map to my use case and how. Then to try some ideas of my own with gpars in the service tier of my application. For now it’ll just be ‘playing around’. At least until gpars settles down in its new home and everything runs ‘out of the box’.

More to come… comments are very welcome. Hope to see some of you (and talk) at SpringOne 2GX

Quick update: For those still curious, I did build the IntelliJ project and IntelliJ ran all the test except one. An exception test. This could be just a result of getting an intermediate build from the GIT repository instead of an official release.

I see the author of gpars did an interview with the Groovy and Grails Podcast. It will be interesting to listen. As I mentioned, Glen Smith and Sven Haiges podcast is definitely worth a listen if you are in any way involved with Groovy, GrailsGradle, or Griffon development.


One Response to “groovy gpars – trials and tribulations Part Duex”

  1. Vaclav said

    Hi Jeff,

    I’m glad to see you’ve passed all the obstacles and thanks for all the feedback. You may try the dev’s page on codehous to get more insight about the project structure. We use the gradle wrapper (gradlew) to build the project. All tests should normally pass.
    I’ve also fixed the demo you reported not working.

    Did you manage to subscribe to the gpars user mailing list?

    BTW, you’re correct in your assumptions about the team members. I hope you enjoyed the Grails Podcast episode 97 🙂



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: