Well, I solved one of the problems in disttest. Now each slave node spawns their own Xvfb that acts as that slave node's X server, thereby eliminating the congestion on any ~/.Xauthority file or on the listen queue. However, for some reason Xvfb sometimes spontaneously segmentation faults! This happens relatively seldom, but is still an annoying bug in Xvfb. I haven't been able to pinpoint the reason yet. All in all, disttest is still a useful tool for distributing the testload on several computers, reducing the time almost linearly with respect to the amount of computers (I've tried over 10 nodes), restricted by the greatest execution time of a test.
We also released version 0.8.1 of Coral, a general-purpose modeling and metamodeling tool, supporting XMI as input/output format and the Diagram Interchange standard for diagram information in UML 1.4 models. The summer interns have been working on a constraint checking tool, which seems to do its job really well. Other new stuff in this release is improved round-trip support for Eclipse EMF models, as well as various bugfixes and improvements. Unfortunately we seem to have lost some compatibility with Poseidon, since they have started to use some UML 2.0-like constructs in their I/O format.
With Microsoft publishing their DSL tools, and although there still might be a considerable hype factor involved, one wonders if open-source programmers should try out more modeling and code generation techniques?
As an example, in Civil we had some state machines written in Python: the user interface was stateful and the army units had their plans and states for their current and forthcoming actions. Although code-wise we certainly could have done better, we could also have tried having some diagrams and plugged in some code where needed.
As another example, one would think e.g. a common format for specifying interfaces using UML diagrams and generating interface declarations in different languages could be useful, although that is a lot easier said than done. SWIG is an impressive effort, although I have not been friends with its idea of "This object "belongs" to the C++ code, whereas this belongs to Python", which sounds, and is, horrible. Objects in current mainstream languages like Java, C#, Perl and Python do not belong anywhere; when the refcount drops to zero (or the VM finds a cycle), the object is garbage-collected by calling the finalizer and reclaiming the memory, that's it. Then again I understand the pragmatic point of view, since SWIG can be used to wrap old C and C++ libraries for new languages with moderate effort. Also, if there were no issues in creating wrapper interfaces, then a specific language would not really offer any significant benefits over some other language, would it? They would all be the same language, like the CLR.