IronRuby on Your Phone

Windows Phone 7 application platform was finally revealed at MIX10. It generated a lot of excitement among .NET developers presumably due to the fact that it’s based on Silverlight. No need to learn a completely new programming model or libraries. Since the .NET Framework supports many languages you might wonder if you have the same choice on the Phone. In particular, could you script the Phone using languages built on Dynamic Language Runtime? I’m excited to announce that IronRuby 1.0 RC4 works on Windows Phone 7! Although there are some limitations the basic scripting just works as you’d expect. But keep in mind that the platform is still a technology preview (CTP) so not all features need to work seamlessly. Let’s dig into details.

Limitations

First of all, why are there any limitations at all if the Phone’s platform is Silverlight and IronRuby works on Silverlight since its inception? Although the UI and Media APIs are pretty much the same the Phone differs from the browser plug-in in the CLR execution engine and the Base Class Library. The Phone uses Compact Framework (CF) which provides only a subset of functionality available in the browser. The two platforms should converge in the future and the limitations will hopefully go away.

The main feature missing from the CF is Reflection.Emit. There are other differences but this is the most important one concerning dynamic languages. As you can imagine we do emit some code at runtime to implement dynamic features of our languages. However we also have an interpreter around. Each DLR based language can choose when to use the interpreter and when the compiler. Both IronRuby and IronPython interpret user code that is executed only a few times. It’s not efficient to compile such code since the cost for doing so is high and the execution throughput is not important. On the other hand code that’s running many times should be compiled and optimized. If the interpreter finds out that a function or a loop body is being executed more than N times it spawns its asynchronous background compilation. When the compilation is done the instructions that call the function or enter the loop are replaced by new ones that jump to the compiled code. The threshold N is configurable.

It should be clear now how to work around the lack of Reflection.Emit on the Phone. Let’s just interpret all the time! And indeed it mostly works. You won’t get a great throughput performance out of it but it works just fine for common scripts. Since the CLR interop is still available you can write performance critical code in C# and call it from the scripts. There are only a few CLR features that you need to avoid since the current interpreter doesn’t handle them without resorting to Reflection.Emit. The most significant are calls to methods with out or ref parameters. You also won’t be able to inherit a Ruby class from a CLR class or implement a CLR interface since that requires us to emit a proper CLR type. We are going to address both of these limitations in future versions.

So, IronRuby runs on the Phone. Why IronPython doesn’t yet? There is no technical reason why it couldn’t. Some parts of the IronPython runtime were just written before we implemented the interpreter and thus need some refactoring to enable full interpretation. You can motivate us to do the work faster by voting on CodePlex.

Sample App

Let’s write an app that hosts IronRuby on the Phone. It’s really simple! You just use the DLR Hosting APIs as you would do when embedding a DLR scripting language in a Silverlight app. I’ll show only the interesting parts of the app. You can download the full source code here. You’ll need Visual Studio 2010 for Windows Phone CTP and IronRuby 1.0 RC4 to try it out. Install them both and then open PhoneScripter.sln, build the solution and deploy to the emulator. Make sure that references to IronRuby and DLR assemblies in the project are correct.

The few lines that you need to run a Ruby script in the Phone emulator (and hopefully on the real device when available) are:

  • _engine = Ruby.CreateEngine((setup) => { setup.Options["CompilationThreshold"] = Int32.MaxValue; });

    Creates a Ruby engine that never compiles the interpreted code. I guess IronRuby could max out the compilation threshold by default when running on the Compact Framework. For now you need to do this manually.

  • _engine.Runtime.LoadAssembly(typeof(Color).Assembly);

    Loads System.Windows assembly into the dynamic runtime so that we can script the UI. System and mscorlib assemblies are loaded by default.

  • RubyContext context = (RubyContext)HostingHelpers.GetLanguageContext(_engine);
    context.ObjectClass.SetConstant("Phone", this);

    Makes the MainPage class instance (this) available to the script via a global constant Phone. We’ll use it to access UI elements on the page. This is a hack! You should use ScriptScope Hosting API to expose host objects to the script in your .NET apps. However, the scope dynamic object internally uses methods with out parameters and we can’t interpret calls to it from Ruby. We’ll enable this in future. For now, we work it around by directly accessing IronRuby’s RubyContext class. Be aware that this class is not a part of the Hosting APIs, we might change it in future versions and break your code. So do not use it in any production code.

  • MemoryStream stream = new MemoryStream();
    _engine.Runtime.IO.SetOutput(stream, Encoding.UTF8);
    
    try {
        try {
            _engine.Execute(Input.Text);
        } finally {
            byte[] bytes = stream.ToArray();
            Output.Text += Encoding.UTF8.GetString(bytes, 0, bytes.Length);
        }
    } catch (Exception ex) {
        Output.Text += ex.Message;
    }

    Executes a script entered in Input TextBox, captures its output and appends it to the content of Output TextBox.

We can now enter and run a Ruby script:

PhoneScripter

Advertisements

Forwarding meta-object

The Dynamic Language Runtime (DLR) allows us to add dynamic behavior to .NET classes. Writing your own dynamic class, i.e. a class implementing IDynamicMetaObjectProvider interface, might be as easy as inheriting from System.Dynamic.DynamicObject. Or you might need more control over the dynamic operations and implement the IDynamicMetaObjectProvider interface manually. Or maybe you already have an existing class and need to add dynamic behavior while preserving its parent class. And perhaps you already have a class that implements IDynamicMetaObjectProvider, find this implementation useful and want to reuse it. What code do we need to write to achieve that?

The ForwardingMetaObject class defined below makes it easy to forward dynamic operations from one dynamic class (forwarder) to another (forwardee).

public sealed class ForwardingMetaObject : DynamicMetaObject {
    private readonly DynamicMetaObject _metaForwardee;

    public ForwardingMetaObject(Expression expression, BindingRestrictions restrictions, object forwarder, 
        IDynamicMetaObjectProvider forwardee, Func<Expression, Expression> forwardeeGetter)
        : base(expression, restrictions, forwarder) { 
       
        // We'll use forwardee's meta-object to bind dynamic operations.
        _metaForwardee = forwardee.GetMetaObject(
            forwardeeGetter(
                Expression.Convert(expression, forwarder.GetType())   // [1]
            )
        );      
    }

    // Restricts the target object's type to TForwarder. 
    // The meta-object we are forwarding to assumes that it gets an instance of TForwarder (see [1]). 
    // We need to ensure that the assumption holds.
    private DynamicMetaObject AddRestrictions(DynamicMetaObject result) {
        return new DynamicMetaObject(
           result.Expression,
           BindingRestrictions.GetTypeRestriction(Expression, Value.GetType()).Merge(result.Restrictions),
           _metaForwardee.Value
       );
    }

    // Forward all dynamic operations or some of them as needed //

    public override DynamicMetaObject BindGetMember(GetMemberBinder binder) {
        return AddRestrictions(_metaForwardee.BindGetMember(binder));
    }

    public override DynamicMetaObject BindInvokeMember(InvokeMemberBinder binder, DynamicMetaObject[] args) {
        return AddRestrictions(_metaForwardee.BindInvokeMember(binder, args));
    }

    public override DynamicMetaObject BindConvert(ConvertBinder binder) {
        return AddRestrictions(_metaForwardee.BindConvert(binder));
    }

    // ... //
}

Let’s use this class in an example. Let’s define some class B simply as a subclass of DynamicObject that supports GetMember, InvokeMember and Convert to String dynamic operations:

public class B : DynamicObject {
    private readonly string _name;

    public B(string name) {
        _name = name;
    }

    public override bool TryGetMember(GetMemberBinder binder, out object result) {
        result = "got member " + _name + "." + binder.Name;
        return true;
    }

    public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result) {
        result = "invoked member " + _name + "." + binder.Name;
        return true;
    }

    public override bool TryConvert(ConvertBinder binder, out object result) {
        if (binder.Type == typeof(string)) {
            result = _name;
            return true;
        } else {
            result = null;
            return false;
        }
    }
}

And now let’s define a class A that forwards these operations to B via ForwardingMetaObject:

public class A : IDynamicMetaObjectProvider {
    private readonly B _b;
    public B B { get { return _b; } }

    public A(B b) {
        _b = b;
    }

    DynamicMetaObject IDynamicMetaObjectProvider.GetMetaObject(Expression parameter) {
        return new ForwardingMetaObject(parameter, BindingRestrictions.Empty, this, _b, 
            // B's meta-object needs to know where to find the instance of B it is operating on.
            // Assuming that an instance of A is passed to the 'parameter' expression
            // we get the corresponding instance of B by reading the "B" property.
            exprA => Expression.Property(exprA, "B")
        );
    }
}

Finally, let’s run some C# 4.0 code that shows how it all works together:

class Program {
    static void Main(string[] args) {
        B b1 = new B("b1");
        B b2 = new B("b2");

        dynamic a1 = new A(b1);
        dynamic a2 = new A(b2);

        Console.WriteLine(a1.SomeMember);
        Console.WriteLine(a2.SomeMember);
        Console.WriteLine(a1.SomeMethodCall());
        Console.WriteLine(a1.OtherMethodCall());
        Console.WriteLine((string)a1);
    }
}

Output:

got member b1.SomeMember
got member b2.SomeMember
invoked member b1.SomeMethodCall
invoked member b1.OtherMethodCall
b1

The really great thing about DLR is that your dynamic objects will also work in IronRuby and IronPython even though you haven’t thought about it at all when authoring them. Assuming that we compiled the above code into MyDynamicLibrary.dll we can run IronRuby REPL and check it out:

IronRuby 0.9.1.0 on .NET 4.0.20915.0
Copyright (c) Microsoft Corporation. All rights reserved.

>>> require 'MyDynamicLibrary.dll'
=> true
>>> b1, b2 = B.new('[b1 in Ruby]'), B.new('[b2 in Ruby]')
=> [B, B]
>>> a1, a2 = A.new(b1), A.new(b2)
=> [B, B]
>>> a1.SomeMethodCall
=> 'invoked member [b1 in Ruby].SomeMethodCall'
>>> a2.OtherMethodCall
=> 'invoked member [b2 in Ruby].OtherMethodCall'
>>> a1.to_s                             # invokes ToString
=> "B"                                   
>>> a1.to_str                           # invokes dynamic to string conversion
=> "[b1 in Ruby]"