Wednesday, March 17, 2004

Fault Tolerant Shell and fault tolerant scripting I spotted the Fault Tolerant Shell via Lambda. Interesting idea. I've not looked closely at the implementation but you could probably implement something like this just using closures and some helper methods... retry(count:5, timeout:10000) {    execute "cp -R foo bar"    execute "grep cheese */*.txt"    retry(count:2, timeout:1000) {      execute "groovyc *.groovy"    } } The only trick is to be able to easily stop a section of the script from running; but through using closures & process handling & async execution, it should be fairly straight forward to wrap this up into 2 helper methods. 4:18:48 PM    comment []

Timtam rocks! Cool WYSIWYG Wiki editor As soon as I've gotten the groovy eclipse plugin working on my machine with m7, the next thing on my list is to try get Timtam working on OS X. Its an awesome WYSIWYG wiki editor for Radeox style wikis, like SnipSnap / Confluence - check out the screenshots. Another great eclipse plugin from Zohar. I'm really looking forward to editing project documentation with this plugin. I've heard stories that Timtam can work on OS X with Photon, though I've no idea what that is or where to get it :). 9:10:02 AM    comment []

RE: Java Programmers to Syntax Familiar Is Chad wrote an interesting piece on the importance of Java similar syntax. I do agree with Chad's perspective. One of the main design goals of Groovy is to reuse Java's semantics. Thats to stay java.lang.Object is the root of the object hierarchy, that Object.equals(), Object.hashCode() and Comparable are used for comparions & lookups of objects, that java.util.List and java.util.Map are used for collections, Java Beans are fully supported and that Java & Groovy classes are interchangable inside the JVM and for Groovy to be build on top of the whole J2SE APIs, rather than having 2 parallel platforms etc. Whats far more important is binary compatibilty between things on the Java platform, rather than the language syntax used to create the binary. So having a similar look and feel syntax is less of a priority. Though we have tried to reuse Java-like syntax where possible. i.e. a secondary goal is to be quick and easy for Java developers to pick up. We don't see Groovy replacing Java any time soon - so folks using Groovy will be using Java too - so we wanted it to be easy to mix from one to the other as painlessly as possible without unecessary syntax differences. Though we're not absolutely tied to Java syntax and already we've made some subtle differences in syntax. e.g. we use autoboxing and == means 'equals' rather than 'identitcal' and all the comparison operators handle nulls properly. Incidentally it was great for the project to get biled today (even if I wasn't quoted as an asshat :). We must be doing something right :) Update: just spotted a great presentation on Groovy by Ted. 9:03:42 AM    comment []