Other languages — Early JSR223 support
Field has always been an environment for piecing together large chunks of statically-typed, verbose, and soberly written Java with small amounts of nimble, experimental and heat-of-the-moment Python. Recently we've experimented with integrating alternative languages into Field — both languages that are actually 'hosted' in different applications (Python in Maya and MotionBuilder,AppleScript and JavaScript in Adobe products) and languages that are hosted directly inside Field (most notably Scala).
These experiments are ongoing, but more recently, with Field's move to the Java 6 JDK, we've been able to rapidly open up Field to alternative languages. Our current work in this domain is represented in the jsrscripting plugin. Right now we are playing with JavaScript, Groovy and, oddly enough, Java itself.
First (assuming that you've enabled jsrscripting in the plugin manager) note the new palette representing the "additional languages" that Field knows about:
.
Likely, you are looking at a window containing these error messages. Hopefully, these errors will tell you exactly what you need to do — you need to download languages (and libraries) from places and standard shims from http://scripting.java.net . Field has even made these urls actual hyperlinks for you. Once you've done this tell extend Field (through the Plugin Manager) to know where these .jar files (and source files if you have them) are.
While Field can, in theory, work with any language that has a JSR-223 standard interface for it, integrating the language runtime with Field takes a little work (not much, but a little). So we are going slowly right now as we experiment with these new languages. Expect more documentation, and conventions as to how Groovy &c access Field things like T, _self and p (the ProcessingPlugin's Processing Applet) and so on.
After installing any and all of these languages, you'll have a much less error filled palette. To actually 'activate' a language and its runtime click on it (and optionally click on the checkbox to get Field to do this automatically).
.
Each language installs a new Text Transform that pipes code to that language's interpreter (or compiler) and runtime environment — see MayaIntegration or EmbeddingGui for examples of Text transforms in the TextEditor — these appear in the right-click menu for transforms.
Notes — ongoing — what's working and what's not
So how are we doing? The first thing that's working is the idea itself — as you can see from JSRPlugin and it's sources (in 'extras' in the source-tree) there really isn't much to it at all. We're most pleased with the "Java" plugin:
Global variables T (the current main launchable — of crucial interest if you are embedding Field in your own application) and _self magically appear (they are actually statically imported). Classes that are defined are propagated back out into the main Field environment — so you can instantiate and pass around the things that you define. If you really wanted to you could make a new Text Transform that turned around and called the JavaC transform that would do away with the outer class declaration — instantly you have something that resembles Processing
What's not working? much of the convenience behind _self and the library support in Field is dependent on Python. Syntax highlighting for the embedded code is actually just still the Python syntax highlighter (although this doesn't do that bad a job). There's no sensible way of getting to other global variables (we have a solution for this, but it's untested). And finally, completion inside these text transforms is just the standard Python text editor completion seen elsewhere in Field, it doesn't know anything about the hosted language and therefor is likely to be incorrect.