If you’re a frequent reader of this blog, you definitely know what’s going on with the DLR in Silverlight. For those who are new, or just don’t know, hopefully this post will clarify some things.
First off: my previous entries about Silverlight since sdlsdk-0.4.0 dropped:
- “console=true”: REPLs in Silverlight
- Adding scripting to a C# Silverlight app
- jimmy hacking (at) Microsoft / Silverlight stuff near bottom
- Dynamic Language Testing in Silverlight
It would seem the next release will be focused around REPLs, testing, scripting support, and maybe some server-side integration pieces. And you’d be right. Proof is in the project’s public source code repository.
But what about the dynamic language runtime and the languages themselves?
There has not been a new release of sdlsdk for many months, and that’s simply because the above features are not finished, NOT because the DLR and languages have not releases anything for Silverlight since then! The DLR released dlr-0.9 and IronPython released ironpython-2.0.1, both including Silverlight binaries. Also, Harry Pierson put together a nightly build site for the DLR, which includes IronRuby and IronPython, and had Silverlight-specific builds.
Then why the sdlsdk project?
sdlsdk is the main project and release vehicle for Chiron and Microsoft.Scripting.Silverlight, which makes writing applications in DLR-languages possible. It’s also the place for collaborating and experimenting with crazy usages of Silverlight+DLR. The DLR and languages are parts of other projects, so I can not justify bumping the version number of sdlsdk simply because a new version of IronRuby, IronPython, and the DLR are in there. The easiest way to update sdlsdk’s DLR+languages is to grab a daily build of the DLR and drop the binaries into sdlsdk’s /bin folder. The next sdlsdk release might include a script to automate that, as long as new builds don’t break it. =)
This is possible because the DLR, IronRuby, and IronPython teams use a shared continuous-integration server that runs test suites in Silverlight on each checkin, ensuring that they all continue to work really well.
Common misconceptions
During development the state of these projects could be completely different within a few weeks, so misconceptions form very fast. Here are ones which beg for correction …
Chiron, a special HTTP server, performs language compilation on the server and generates a .xap file.
FALSE. While Chiron is a special HTTP server, which generates a XAP file for any given directory, it does not perform language compilation on the server! Chiron is a development-time tool which only sticks the script files in the XAP, and they are run in the browser. When putting your app into production, you tell Chiron to write the XAP file to disk, and then you can put your app on any web-server you want.
Chiron’s existence shows the limitation Silverlight imposes by requiring a XAP file. DLLs can be downloaded by the AppManifest.xaml outside the XAP, so the XAP just serves as a AppManifest.xaml container. I’m hoping to get this fixed by Silverlight 4. =\ It also shows a limitation in not supporting continuations, which would let the user script pause while asynchronously downloading a script file, and then resume the initial script. I’ve been prototyping ways to get around this, but nothing working yet.
Also, if you’re using another web-server in your app (like you have a ASP.NET app with a Silverlight control), you can just set up a file-system-watcher and tell Chiron to regenerate the XAP to disk everytime you edit a file, but it will be served with the other webserver. This is used by silverline, a Rails plugin I wrote to integration Silverlight and IronRuby.
This is why you can’t include JavaScript files from inside other JavaScript files, and all your dependencies need to be pre-defined in the HTML file, because JavaScript can’t download the script files while the JavaScript engine is running.
Common interface implementations were inconsistent between languages, so I can’t create a solution where advanced users can pick and choose a language.
FALSE, in theory. The DLR hosting API (contained in Microsoft.Scripting.dll) provides a single set of APIs that can be used to host many languages. For example, Microsoft.Scripting.Silverlight uses the DLR hosting APIs to run any DLR language in Silverlight, based on what extension the entry-point script has (.py, .rb, etc ...). There are simple hosting examples here.
It is the language’s responsibility to implement certain interfaces so they are host-able by the DLR. IronRuby and IronPython are existing examples of that, and there is documentation in the hosting spec on how this all works, so new languages can follow suit.
However, there are always going to be language-specific scenarios which have different ways of using the hosting API, or the hosting API doesn’t support the feature and you have to use the language’s hosting API. In those cases, it’s best to re-think your scripting design and make the hosting code as simple as possible.
Also, a couple months ago, IronRuby’s hosting support was no where near where it is today. Again, things change fast. If you have any feedback on DLR hosting, please ask around on the DLR Discussions List.
And the state is ...
I hope that made some things clear; the DLR, IronRuby, and IronPython are committed to supporting Silverlight developers. Unfortunately, the reverse is less strong, so if this is important to you please talk about it on the silverlight.net forums. Things might be a bit nicer when the inner ring of the DLR (Microsoft.Scripting.Core.dll) is part of the System.Core in Silverlight, but we’ll see.