A Good Mix 20: Startup time, inline C#, Global.asax in ASP.NET, an interactive shell in the web, Gtk# and more

Another collection of blog entries and projects related to IronPython and the Dynamic Language Runtime.

• IronRuby 0.9 starts 6 times faster than IronPython 2.6B1, why is that? Does anyone know?

IronPython 2.0 is significantly slower to start than CPython, which is an issue for those writing command line tools and full applications in IronPython. IronPython 2.6 improves the situation, but as the lament in this short blog entry expresses it is still slow even when compared to IronRuby:

IronRuby 0.9 starts 6 times faster than IronPython 2.6B1 Why is that? Don’t they use the same DLR engine? If IronPython started the same way, probably I would not use ‘CPython plus .Net exposed through MSFT Com’ technique. It is just unfair.

On the usual support channel (Twitter) Dino Viehland explained that the IronPython interpreter does a bunch of work at startup time that IronRuby doesn't. On startup the interpreter imports the site module site just like CPython (and IronPython uses site.py from the Python standard library), this in turn imports a bunch of other stuff - meaning that IronPython is actually doing quite a lot at startup time. They still need to work on startup performance though...

• IronRubyInline

This project doesn't have anything to do with IronPython, but it's a really neat idea and would be very easy to adapt for IronPython.

IronRubyInline allows you to put C#, F# and Visual Basic code inline with IronRuby code. It compiles at runtime and allows you to use the compiled classes within the same Ruby code that defines them:

%Q{
public class CsCat
{
public void Greet()
{
Console.WriteLine("Hai u!");
}
}
}.compile

cscat = CsCat.new
cscat.greet # Hai u!

It is similar, although a bit more impressive, to my article on Dynamically Compiling C# from IronPython.

• I Hate Global.asax

Another lament, this one from the venerable Devhawk, on the interaction between Global.asax in ASP.NET and IronPython.

I always thought of global.asax as an obsolete construct primarily intended to ease migration from classic ASP. After all, ASP.NET has first class support for customizing request handling at various points throughout the execution pipeline via IHttpModule. Handling those events in global.asax always felt vaguely hacky to me.

...

The reason I suddenly care about global.asax is because Application_Start is where ASP.NET MVC apps configure their route table. But if you want to access the Application_Start method in a dynamic language like IronPython, you’re pretty much out of luck. The only way to receive the Application_Start pseudo-event is via a custom HttpApplication class. But you can’t implement your custom HttpApplication in a dynamically typed language like IronPython since it finds the Application_Start method via Reflection. Ugh.

• Get a Rails-Stylee Interactive Shell For Your NHibernate Backed Domain Model
  

If you’ve ever used Ruby on Rails you’ll be aware of the goodness that is script/console. The console lets you interact with your domain model from a terminal - no need for dedicated GUI screens or tools.

If you can’t see the benefits, then think about this: Have you ever used SQL Server Management Studio to inspect some data in your tables, or even to tweak a value in a column? Yes? Well, imagine being able to inspect items in your domain model, and even create new objects, invoke behaviours (call methods), update properties etc. It’s very handy, and useful for quickly checking or updating data.

I’ve always missed having this feature during .NET development. The good news is that’s it’s quite easy to do using IronPython or IronRuby. My EngineRoom partner, Chris Owen, first got this hooked up using IronPython - so credit to him! Since I’m more familiar with Ruby I’ll use that in this post.

• When trivial CPython snippets don't work...

Yet another lament! An intriguing peek into the IronPython development process from Dave Fugate, the IronPython tester extraordinaire:

I've spent way too much time today trying to get a simple _ssl sample to run under CPython to show how broken IronPython's _ssl.cs is. First, I discovered that not only do CPython's tests not work (they're trying to connect to svn.python.org, port 443, which consistently times out); they seem to be disabled as well via test_support.is_resource_enabled('network'). If anyone has encountered the "TypeError: sslwrap() argument 1 must be _socket.socket, not _socketobject" and knows how to workaround it, I'm all ears.

• Mono, Gtk# and ironpython

An old blog entry (from 2007) but one I've not seen before. It's an example of using the Gtk user interface from IronPython via Gtk#.

import clr
clr.AddReference('gtk-sharp')
import Gtk
def delete_event (o, args): Gtk.Application.Quit ()

def say_hi (o, args): print "Hello, World!"

Gtk.Application.Init ()
w = Gtk.Window ("Hello, Gtk# World")
w.DeleteEvent += delete_event
b = Gtk.Button ("Say Hello")
b.Clicked += say_hi
w.Add (b)
w.ShowAll ()
Gtk.Application.Run ()

As you can see from the screenshot below, the recipe works with Gtk# and IronPython 2.6 Beta 2 on Windows - however the window is a bit small and unresponsive.


I'd really love to see some articles on using Gtk as a cross-platform user interface with IronPython, Gtk# and Mono / .NET.