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:

"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")