Juggling the various combinations of processors, operating systems, and JVMs has turned into a big project for us which we never anticipated. It is complicated even before getting into the specific configurations of memory, IO, and disk storage. What this means for us is that we are focusing on demonstrating scalability for each system, but not attempting to make comparisons between systems.

A common "gotcha" when using the JDBC API is making sure that your driver is found by the client of the JDBC API.

This tutorial will walk you through the steps necessary to utilize the Eclipse Update Manager to download and install the DataRush Development Tools for use with the DataRush SDK.

Pre-requisites

Part 1 of a recent article at Embedded.com explores fundamental concepts and techniques for parallel programming. The DataRush framework provides mechanisms for avoiding or solving many of the issues and challenges they mention.

DataRush is sufficiently sophisticated (or at least different) that understanding it takes several passes. I am writing a series of posts aimed toward exploring what DataRush is and is not. This should give the passing programmer a better feel for what DataRush might do for them and how it fits into the broader scheme of concurrent programming techniques.

So, back to the question at hand; is DataRush dataflow? The answer is obvious: that depends upon what "dataflow" is.

According to [CTMCP], dataflow behavior results when expressions contain unbound variables. When execution reaches such an expression, the program simply pauses, awaiting a value. If at some point in the future another thread binds a value to the variable, the program picks up where it left off. They call variables with these characteristics dataflow variables. A simple example in Oz (from page 60) follows:

local X Y Z in
  X=10
  if X>=Y then Z=X else Z=Y end
end

Note that X is declared, then immediately bound to a value. The purpose of the expression is to bind Z. However, that leaves Y unbound. From the expression above, we simply cannot tell what value Y should take and, unlike some other programming languages, Oz does not arbitrarily specify a default value.

j2xs' post about Sun Labs Programming Research Group's Fortress inspired me to dust off some writing I did back in graduate school. One of the questions asked by Dr. Greg Lavender of UTCS in our domain specific languages class was what new programming features Fortress (intentionally linked to an outdated version of the spec) contained and what facilities it had for "growing the language" (in the words of Steele). What follows is an adaptation of my response given nearly two years ago.