Scala Action
Introduction
There is now an action which interprets the text of a message as Scala code and returns back the result. Here's how it works and some things you can do with it.
First of all, you need to enable this feature. You will be able to create "scala" actions even if it's disabled, but they won't do anything. To turn it on, use this setting in e.g. default.props (the only one you can rely on in a ):
actions.scala_interpreter.enable=true
*Note*: It's sensible to have this feature off by default, as you will gain full control of the JVM in the classloader context of the application. Unless there are security manager restrictions, you might be able to execute OS code, shut down the JVM, modify the database, inspect live objects and possibly change them, etc. This could be both a threat and an advantage.
Now it's time to set up our embedded scala interpreter: 1. Create a pool, let's call it e.g. "scalapool" 2. Create an action, which has a filter for the newly created pool. In our example, the filter is "pool:scalapool". The action itself is just "scala". In theory, you could use any filter, but the special symbols necessary for hashtags and users interfere with Scala code. Besides, except for a pool, you don't have much control what gets in your timeline, and I doubt that any unintended message there is valid Scala code. 3. Send some Scala code to scalapool.
Let's see what we can do with Scala in ESME:
Calculator
Try these:
- arithmetic calculations: 3 + 3
- string operations: "olleH" reverse
-operate on lists, e.g. sum numbers: List(1,2,3,4,5).foldLeft(0)(_+_)
As we can see, the result is displayed in a new message, which is a reply to the current one, and is in the same pool. The message source is "scala".
Printing to the console won't do what you expect (you won't see it in your reply), so don't use it.
Background execution.
Each new message is executed in a separate interpreter. While this has some disadvantages (you lose the bindings for each consecutive execution), there are some advantages to this approach. For instance, you could have several computations execute in parallel, and the previous won't block the next one. Try these messages, one right after the other:
{Thread.sleep(10000); "later"} "now"
The first message will wait for 10 seconds and then return the string "later". If during those 10 seconds you manage to enter the second message "now", the result will be returned before the result of the first message.
This, of course, is an expensive way to schedule reminder messages. If you want it, request a feature in Jira :)
Monitoring
-free memory in the JVM: Runtime.getRuntime.freeMemory
-total JVM memory: Runtime.getRuntime.totalMemory
-current date and timezone on the system: new java.util.Date
-get a JVM property, e.g. the JVM version: System.getProperty("java.vm.version")