A Good Mix 19: Reflection, the Silverlight Toolkit, Dynamic JSON, libraries, builds and more

A collection of blog entries and articles on IronPython and the Dynamic Language Runtime from the last few weeks.

• Speed Test: Reflection vs IronPython

Randall Sutton was using reflection to apply rules to an object when he realised he could do it with IronPython, but he was worried about performance. He wrote a quick test to compare the performance and was surprised by the results. The first run was very expensive for IronPython, but from there on in IronPython was much faster than C#.

Without expending any effort actually working it out, my guess is that because IronPython uses reflection so heavily it caches the reflection lookups - and it is this caching that is giving it the performance benefit. Reflection on .NET is not fast, by any stretch of the imagination, and improving the performance of reflection would make a big difference to speeding up DLR languages.

• The Silverlight Toolkit and the Dynamic Language Console

The Silverlight Toolkit is an open source project by Microsoft providing additional controls for the Silverlight browser plugin. By releasing them as an open source add-in it reduces the size of the initial plugin download (at the cost of increasing the size of applications that use them), but also means that they can also be used directly in Moonlight (the Mono version of Silverlight for Linux that went into beta a few days ago) without having to be re-implemented.

The toolkit is divided into five 'bands' offering different ranges of controls. The bands are mature, stable, preview and experimental. The controls in the mature band alone are:

• AutoCompleteBox
• Calendar
• ChildWindow
• DataGrid
• DataPager
• DatePicker
• GridSplitter
• HeaderedItemsControl
• TabControl
• TreeView

The Silverlight Toolkit Codeplex site has live examples demonstrating the controls. The examples each have three tabs; two showing the XAML and C# for using the controls from Silverlight 2 and 3. The third tab has a dynamic language console that allows you to interact with the control from IronPython or IronRuby. This is a great way to 'try before you buy', to see what they are capable of or use Python's introspection to learn how they work.

• pycopia-fepy project

This is an intriguing project and I only happened on it by chance when I saw the release appear on the Python Package Index (PyPI - the Python equivalent of Perl's CPAN). The project page says:

Modules for use with IronPython.

The purpose of the modules here are to enhance the IronPython runtime with extra modules for debugging and better integration with the rest of the Pycopia framework.

This doesn't really tell us a lot. The pycopia homepage says:

The Pycopia project is a framework of frameworks for the rapid development of applications related to telecommunications networks, web, data processing, process control, and more.

• The IronPython standard libraries dilemma – [a learning strategy]

This is a short blog entry by Simon Segal, the man behind the Entity framework profiler with integrated IronPython scripting. In this blog entry he ponders what to do when there are both Python libraries and .NET libraries available for a task in IronPython. Even with basic things like file I/O and threading you have a choice whether or not to use the standard Python idioms or .NET libraries. They have slightly different semantics of course but it is often not obvious which is a better fit.

Simon also describes his strategy for learning Python and IronPython:

To help myself form my own opinions I decided that the best learning path for me was as follows:

1. Read the Python 2.5 (CPython) documentations PDF Tutorial and re-type it’s code examples and follow with my own experimenting. This allowed me to get a fairly good overall feeling for the language.
2. Read IronPython in Action to get a good overall point of relevance to .NET and see how the power of .NET as a platform would impact the Python experience and visa versa.
3. Read Python in a Nutshell and get a grasp on Python’s roots and how the language is best put to use on it’s original platform (the C implementation).

Some people will surely think that points 2 and 3 should be reversed? Perhaps, but my rationale for taking this approach is that Python is not likely to become a daily instrument in my work and I want to understand as much as possible about it in the .NET world first. I do believe however that to truly understand the power of Python I will need to learn deeply about its roots and oddly I suppose that step in the process will come last.

• Creating Dynamic JSON array finders using the DLR

A blog entry on implementing a way to dynamically query JSON arrays using the Dynamic Language Runtime. The entry creates a wrapper class in F#. It has examples of using the wrapper in IronRuby, using C# 4.0 and the dynamic keyword, and of course with IronPython. The post includes some interesting details on writing dynamic objects implementing IDynamicMetaObjectProvider that can be used from all these different languages. IronPython in particular it seems needs some special treatment because of the way BindGetMember is called instead of BindInvokeMember.

• Compiling IronPython and IronRuby

The IronPython and IronRuby project files have changed recently, in order to allow them to be compiled by both Visual Studio 2008 and the forthcoming Visual Studio 2010. The details were posted to the IronPython and IronRuby mailing lists:

We have just updated ToolsVersion attribute in .csproj files included in IronPython and IronRuby solutions to "4.0". This change will soon show up in CodePlex and GIT sources.

It allows to open these projects in Visual Studio 2010 (using IronPython4.sln or Ruby4.sln). The binaries produced by both builds (from VS2008 and VS2010) still have dependency only on .NET 2.0 assemblies so there is no change in that.

You'll need Service Pack 1 installed in order to build Ruby.sln or IronPython.sln from VS2008. When you build from VS2008 you'll get a bunch of msbuild warnings:

Project file contains ToolsVersion="4.0", which is not supported by this version of MSBuild. Treating the project as if it had ToolsVersion="3.5".

This is expected, you can ignore them.

Thanks,
Tomas Matousek