Tuesday, December 30, 2008

End of Year Selection

A few months ago I got behind on posting interesting IronPython related links. I've caught up a lot, but a whole bunch of interesting stuff happened in November and December that I haven't reported yet.

Some of that will have to wait for another day, but we'll end the year with a selection of some of the snippets from the last couple of months.

IronPython Cookbook

A couple of new recipes in the IronPython Cookbook, by Davy Mitchell and Atif Aziz:
  • Process Monitor - demonstrates how to write a small utility in IronPython that monitors a process and re-launches it if it dies.
  • How to Play a Wav - this short example plays a WAV format sound file using System.Media.SoundPlayer.
Speech Synthesis in IronPython

Another short example of how to use IronPython to make your computer speak like a robot:
Other Assortments

Sunday, December 28, 2008

Pumping Iron: Dynamic Languages on .NET

The esteemed Mr Tartley recently stepped into the shoes of Harry Pierson (Microsoft IronPython PM) and spoke about dynamic languages on the .NET framework at the Øredev conference in Malmö, Sweden.

He has posted the slides and notes online, based on Harry's presentation but delivered with Jonathan's irrepressible style (and with the audience's reaction inline).
The talk is an exploration of the differences between static and dynamically typed languages, plus some of the specific language features of Python and IronPython.

My favourite part is where he discusses the cost of compile time checking. Those who advocate the benefits of statically typed languages often discuss what losing compile time checks costs, what they don't talk about so often is what keeping them costs:

"So let’s examine what we’re really talking about losing when we have no compile-time type checks. As we’ve noted, type safety really does catch and eliminate a whole class of errors, namely whenever you perform an operation that expects one data type, and you give it another. However, and importantly, this is not remotely sufficient to have any confidence that a program actually works, just because it compiles. There are many other classes of error that can and do commonly happen.

Jay Fields has a marvellous blog post about this, in which he hypothesises a function performing integer addition. Now, static type checking can confirm that all uses of your function pass it integers, and that the return value is always an integer. Obviously this is not sufficient to assure the function behaves correctly. Nowadays, when we want to be sure about the behaviour of something like this, we write unit tests.

Out of interest, how many people here are using unit tests? [almost every hand goes up] Alright, excellent, of course you do, you’re all professional, and it’s become mandatory, right, because they are so great. So absolutely everybody wants to be using unit tests, no matter if you’re using a static language or a dynamic language. And your unit tests get to be very detailed about the runtime behaviour of your functions, so they don’t simply check that your function is returning an integer, they are testing that 1+1 actually returns 2. Now, 2 is an integer, right? So once these tests are in place, the static type check is now redundant. It is providing no value, and can safely be removed.

Cue sharp intake of breath from everyone in the room currently working on compilers.

Interestingly, when I first started working with Python, I hadn’t used any dynamic language before that, and I was concerned about this myself. I imagined development could be inundated by multiplying bugs which we otherwise would have caught cheaply, at compile time. And this has an element of truth in it - we do find that we get some bugs which normally would have been flagged by the compiler. But it turns out, in practice, these errors are only a very small proportion of all the bugs that any application contains. And also, they are also amongst the most superficial. We passed in function parameters in the wrong order. We supplied a string when we should have used an integer. These are the sort of bugs which are generally trivially easy to locate, identify and fix. They are not the sort of errors that require hours to track down, or make you belatedly realise that you need to redesign the whole project. They are often simple typos, revealed immediately, with a line number, in stack trace that happens the second you run your application. In short, the actual cost of losing type safety is, surprisingly, actually negligible in practice.

People find this hard to accept. It surprised me. So much effort is expended maintaining type safety, it’s such a pervasive feature of almost everything we do in a static language, that it seems inconceivable we could live without it. But interestingly, once we notice how small the actual benefits of type safety are, the other thing you start to notice almost immediately afterwards, is that type safety also comes with a bunch of costs. And these costs are always overlooked, because type safety is so pervasive that it has become invisible, nobody even thinks about it when they have to jump through hoops to maintain it. It’s only when you consider not doing, by using a language that doesn’t enforce it, that you start to realise how huge the costs actually are.

These costs come in two forms, both the direct costs of having to jump through hoops, and also indirect ones, where the restrictions introduced in the name of type safety will fence off ways of doing things that are simply made impossible in a static language."

UPDATE: Comments from the reddit thread that I thought worth posting.
"your unit tests get to be very detailed about the runtime behaviour of your functions... So once these tests are in place, the static type check is now redundant. It is providing no value, and can safely be removed"

The last statement is simply false: If you remove the type checker, you actually have to add more tests. You cannot "safely remove" the type checker just because you have unit tests in a statically typed language.
My response:
Actually your statement is false for another reason - duck typing.

When you test in a dynamic language what you largely test for is that the code performs the correct operations on your objects - and so what type they are is irrelevant so long as they are used in the correct way. This is where the added flexibility of dynamic languages come from.

If your code performs the correct operations then it must behave correctly when passed the correct types (and of course you test that it is called in the correct way - but again not necessarily specifically caring about types).

Programming in dynamic languages is simply a different mindset to programming in statically typed languages - which is why the two camps disagree so much. Caring about type safety is not something that matters a great deal to dynamic language programmers, what matters is the way their objects are used.

NWSGI 1.0 Released

Jeff Hardy announced today the 1.0 release of NWSGI, a Web Server Gateway Interface (WSGI) for IronPython.

"I'm very pleased to announce the release of NWSGI 1.0. NWSGI is an implementation of the WSGI specification (PEP 333) for IronPython. It is implemented as an ASP.NET HttpHandler and is supported on IIS 6 and IIS 7 (and should work on any other ASP.NET-capable web server). NWSGI allows the integration of Python applications with existing ASP.NET facilities such as caching, sessions, and user management."
In the blog entry Jeff notes that NWSGI is a "nearly-complete" implementation of the WSGI specification. On deployment he says:

"NWSGI fully supports xcopy deployment and medium trust environments (with the caveat that parts of the Python standard library are not supported). There is also an installer available that provides a managment UI for IIS 7."

Saturday, December 27, 2008

IronPython and the Spark View Engine

The Spark View Engine is "a view engine for Asp.Net MVC and Castle Project MonoRail frameworks. The idea is to allow the html to dominate the flow and the code to fit seamlessly".

It now supports IronPython:

About Iron Python

IronPython is a dynamic language runtime (DLR) based implementation of Python. Spark scripting is based on assemblies in the 2.0 Release Candidate 1 binary zip. Other good resources are the Python documentation and the Python site itself.

The support for the DLR is very Asp.Net MVC centric. If there's an interest in expanded Castle MonoRail support, please speak up in the discussion group.

Creating a new project

A standard Asp.Net MVC web application is always a great starting place. First, add references to the following assemblies:

  • Spark.dll
  • Spark.Python.dll
  • Spark.Web.Mvc.dll
  • Spark.Web.Mvc.Python.dll

And the following from the IronPython release which are available in the Spark bin\dependencies folder. If you have problems with the these files from Codeplex try the ones in from the Spark distribution. You have the "works on my machine" guarantee.

  • Microsoft.Scripting.dll
  • Microsoft.Scripting.Core.dll
  • Microsoft.Scripting.ExtensionAttribute.dll
  • IronPython.dll
  • IronPython.Modules.dll

Yeah, I know. It's a lot of assemblies. You're going to love the next part though, adding the Spark view engine to an Asp.Net MVC web application has been simplified.

Add the following to your Global Application_Start method:

using Spark.Web.Mvc.Scripting;
protected void Application_Start(object sender, EventArgs e)

This will create a view engine and add it to the engines collection.

The Spark engine starter also has several utility methods for more advanced initialization. You can, for example, provide a settings object from code. You can also use the ISparkServicesContainer to provide specific implementations of different services used by the Spark engine.

OWL BASIC parser and abstract syntax tree

The first programming language I ever used was a version of BASIC on the BBC Microcomputer (over 20 years ago and counting). It did use line numbers, but had procedures and subroutines and allowed you to do structured programming including recursion. Having a programming language built into the machine made it incredibly simple to start hacking - and it even included an assembler so you could embed assembly language in basic programs. A lot of games on the machine started with a shell of basic that would bootstrap the game actually written in assembler.

Robert Smallshire has been working on an implementation of BBC Basic written in IronPython:
"Other personal projects, of both a software and familial nature have taken priority lately over my project to implement a BBC BASIC-a-like compiler for the .NET CLR, now called OWL BASIC in honour of the owl logo of the BBC’s Computer Literacy Project."

This blog entry is mainly focused on the front end parser which uses the Python PLY (Python Lex and Yacc) parser toolkit. This works very well with IronPython and is what we use at Resolver Systems for our spreadsheet formula language. As well as describing the grammar, Robert goes into the details of working with the AST (Abstract Syntax Tree) of parsed BASIC.

"Once the AST has been created by the parser, it can be analysed or manipulated by a visitor. One such visitor, which is an aid to debugging, transcribes each AST node into an XML representation. This is useful since it allows the AST to be conveniently examined using standard XML capable tools (e.g. a web browser) to aid debugging."

Introducing IronPython

Harry Pierson wrote an article on IronPython for the CoDe magazine. Initially it was behind a paywall, but now the whole article is available to read:
"One of the somewhat frustrating aspects of C# is the amount of structure that gets forced on the developer. Some of the structure is related to static typing, such as specifying variable types and casting operators. However, there are also no stand-alone functions in C#, much less just a bunch of code in a simple script. All functions have to be attached to an object, meaning the simplest implementation of “hello, world!” in C# looks like this":

class Program
static void Main()
System.Console.WriteLine("Hello, World");

Contrast that with the Python version:

print "Hello, World”

"Obviously, you don’t judge a language completely by its implementation of “hello, world”. But the point is that Python scales well with complexity."

His conclusion:

"Between significant whitespace and dynamic typing, there’s no question Python is a wholly different development experience from C# or VB. I’m a recent convert to Python from C#, so I know exactly how strange it can feel. But once you get past that feeling of unfamiliarity, you start to see just how productive Python can be."

Friday, December 26, 2008

C# Becomes a Dynamic Language...

This post is a bit late - in fact this news was announced several months ago at this year's Microsoft Professional Developer's Conference.

At the PDC the Dynamic Language Runtime was demonstrated - along with the news that it will be part of .NET 4.0. Both Visual Basic 10 and C# 4.0 will have dynamic elements that make use of the Dynamic Language Runtime.

In a blog entry after the conference Jim Hugunin links to Channel 9 videos of his talk on the DLR and Anders Hejlsberg's talk on the way C# is changing.
C# 4 will allow you to use objects dynamically through a new static declaration. A new keyword that allows you to statically declare dynamic objects!

Objects that are declared as dynamic will have operations on them (attribute lookups, method calling, indexing, numerical operations and so on) done through the DLR.

The intarwebz were awash with the news. Here is a selection of the most interesting and informative responses that I found:
You can try this out with CTP (Community Technology Preview) release of Visual Studio 2010 and a version of IronPython 2.0 (pre-IP 2 final) that targets it:
What are the benefits of having dynamic objects (or even static objects that implement the new IDynamic interface)?

Well, you could declare everything as being dynamic, and then C# effectively would be a dynamically typed language with duck typing - except unlike most dynamic languages you still have a lot of type declarations and you have a compile phase with the DLR used to perform operations through reflection.

Substantially more useful is that it makes integrating code in DLR based languages into a .NET application substantially less painful. Although the DLR hosting API is generally very straightforward to work with, passing objects from IronPython or IronRuby back to C# can be a problem. You have to declare ahead of time what type it will be - and if it is a Python or Ruby object that class won't even exist until runtime. You can now declare them as dynamic objects, and the DLR will use the semantics of the language they are defined in when it uses them. Your dynamic objects will still behave like Python or Ruby objects when used from C#.

The DLR can also be used for late-bound COM, something that hasn't really been possible from C# before. It can also be used to create really fluent APIs when working with things like XML, JSON or an HTML object DOM. Dynamic languages have been able to do object traversal with element names as attribute names for many years - and the equivalent in statically typed languages is more verbose and ungainly.

The C# futures documentation gives this example of using the new dynamic keyword:

dynamic d = GetDynamicObject(…);
d.M(7); // calling methods
d.f = d.P; // getting and settings fields and properties
d[“one”] = d[“two”]; // getting and setting through indexers
int i = d + 3; // calling operators
string s = d(5,7); // invoking as a delegate

It also has this to say:

"The type dynamic can be thought of as a special version of the type object, which signals that the object can be used dynamically. It is easy to opt in or out of dynamic behavior: any object can be implicitly converted to dynamic, “suspending belief” until runtime. Conversely, there is an “assignment conversion” from dynamic to any other type, which allows implicit conversion in assignment-like constructs:"

dynamic d = 7; // implicit conversion
int i = d; // assignment conversion

There's lots more in C# 4 - including named and optional parameters - it's shaping up to be a nice language, for a statically typed one...

Tuesday, December 16, 2008

IronPython 2 Final Released

IronPython 2 final (or Release To Web in Microspeak) is finally out. IronPython 2 targets Python 2.5, is built on top of the Dynamic Language Runtime and runs on .NET 2 SP1, Mono 2.2 and Silverlight.
This release of IronPython includes improvements in many feature areas such as better .NET interop support and hosting Python from managed code. There have been many other major improvements as well. The most notable are:
  • An MSI installer for Windows platforms which includes parts of the CPython 2.5 standard library
  • IronPython assemblies targeting Silverlight and tools such as Chiron to improve the Silverlight dynamic development experience
  • The addition of more C-based standard modules such as cmath and _winreg
  • Significant improvements in importing compatibility and features
  • Distribution of IronPython under the Microsoft Public License which has been approved by OSI
  • Performance improvements. On that note, a new Wiki page has been created for IronPython performance reports
  • Over 500 bugs have been closed in 2.0. 453 of these were reported on CodePlex
  • Support for precompilation of Python source files into a single dll
This seems like an opportune time to remind everyone that we fix bugs based on the number of votes they have on CodePlex. As we’re planning on releasing IronPython 2.0.1 fairly soon, please vote for your favorite bugs to help ensure they get fixed in time for the next release.

The IronPython 2 download page also includes some of the IronPython samples that have been converted to work with IronPython 2. One of these is Pyc, the command line compiler tool that creates binary distributions of IronPython applications and libraries.

Along with IronPython 2, there is an official release of the DLR: version 0.9. You can also read the release notes.

The release notes for DLR 0.9 note:

The DLR project provides one-stop shopping for folks who want to:
  • Implement a language on .NET using the DLR
  • Add dynamic features to their existing language like C#’s ‘dynamic’
  • Add scripting to their applications.
  • Create .NET libraries with dynamic objects
This Codeplex project includes the DLR sources as well as sources for IronPython, IronRuby, and samples (such as ToyScript).

We’re shipping some of this in the .NET 4.0 release coming up. Some parts are still open to design changes as we solidify those parts for post .NET 4.0, and we’ll continue to add more docs and samples. We will have coordinated releases or sync points across IronPython and IronRuby sites for major releases so that if you’re not pulling from the DLR project, you can still see which sources or releases are consistent across our projects.

Jim Hugunin did a great talk at PDC 08 on DLR architecture, concepts, and coding with the .NET 4.0 functionality.

If you want to read some documents without downloading sources or bits, you can read the DLR specs.

There is a discussion list (click on the “get email notifications” link). All mail there goes to dlr@microsoft.com which has all the folks working on the DLR and our languages on it.

Wednesday, December 10, 2008

Try Python and IronPython Web IDE Updated for Silverlight 2

I still haven't got around to posting updated versions of my IronPython and Silverlight 2 articles and examples. (However the IronPython in Action early access version does cover the final version of Silverlight 2.) What I have done is put online updated versions of Python in the Browser (an interactive Python interpreter that runs in an HTML textarea) and the IronPython Web IDE (a tool for experimenting with the Silverlight APIs live from IronPython - pre-loaded with examples).

IronPython is the new IValueConverter, IMultiValueConverter

A blog entry on using IronPython to create a DSL (Domain Specific Language) to evaluate expressions in WPF XAML (the XML used to describe user interfaces for Windows Presentation Foundation and Silverlight):
"Applying simple mathematical operations inside WPF DataBindings has always been a non-trivial task. By default the {Binding} or MultiBinding syntax does not allow the use of arbitrary expressions inside the Path."

"There are several cases where you would like to do a little bit of math inside of the {Binding} expressions."

"This requires the use of a converter that would do the actual mapping of values to the bounds of the Canvas."

"Ideally you would want the complete flexibility of a scripting language inside of your Binding expressions. Note however that there is a tendency to over-use / abuse a scripting functionality. That however is for the team to decide what level of sanity needs to be maintained in the script. With judicious usage, a scripting language for evaluating binding expressions is supremely powerful. As of today, IronPython is a great choice for exposing scripting functionality."

"ScriptConverter is a custom converter that I implemented that evaluates python expressions and statements. It hosts an IronPython engine and evaluates scripts specified inside the binding expression. Note that it is just a class that implements both IValueConverter and IMultiValueConverter. It is not a MarkupExtension or a custom Binding class, although one could certainly do both. The decision to implement it as a converter rather than a markup-extension was purely to keep the well-known {Binding} and MultiBinding syntax in your Xaml files."

Saturday, December 06, 2008

IronPython and [Insert MSFT Technology Here] (Starting with WPF)

Back in November (yes, I'm still behind on my posts but catching up), Harry Pierson (IPy PM) announced his decision to write a series of posts on how to use IronPython with a range of different Microsoft technologies:
Making good on his promise he starts with 6 posts on using the WPF (Windows Presentation Foundation) GUI toolkit with IronPython.

In the first part he starts a WPF based photo viewer for his wife's Windows Live photo collection.

"Turns out building this app in IPy was fairly straightforward, with a few pitfalls. I wasted half a day digging thru data binding before realized that data binding against IPy objects works out of the box - but only if you type the case of the property correctly (Title != title)..."

"Over the next several posts, I’m going to show you all the code for this app. It’s pretty small, only about 50 lines of app-specific python code + 50 lines of XAML to describe the window."
In part 2 Harry uses Expression Blend to design the User Interface and then loads the XAML it produces from IronPython:

def LoadXaml(filename):
from System.IO import File
from System.Windows.Markup import XamlReader
with File.OpenRead(filename) as f:
return XamlReader.Load(f)

He hooks up the events to the WPF Window loaded from the XAML and even shows a bit of C# with custom hooks to make it play nicely with IronPython.
Here’s the short version of this post: data binding in WPF to IPy objects just works... mostly. (For the longer version click though to the entry.)
Downloading the RSS feeds used by the WL Spaces Photo Viewer can take several seconds. Harry illustrates how to move functions into the background (not holding up the GUI thread) using a thread pool. To keep things clean (and Pythonic) he uses decorators to execute functions in the background or on the UI thread.
An alternative way of handling the background processing that uses SynchronizationContext instead of the WPF dispatcher.
Another change. The threading code is available for download from Harry's skydrive.
Implementing a REPL (Read-Eval-Print-Loop) so that he can poke around inside his application whilst it is running. This reuses components provided by IronPython to support the interactive interpreter.

Welcome David DiCato to the IronPython Team

Shri Borde (IronPython/IronRuby dev lead) just posted this to the IornPython mailing list:

Please welcome David DiCato to the IronPython team. He has his first shelveset in the Snap queue (queue.__init__ calls clear) already. You should hopefully hear more from him in the mailing list. Here is his intro in his own words.

"Hi everyone, I’m David DiCato, the new Dev on the IronPython team. I grew up in Surf City (i.e. Huntington Beach, CA) and moved just 50 miles north to go to school in Pasadena. At Caltech, I earned my BS in Computer Science, applied to Microsoft after a short break, and the rest is history. Although I have never touched a surf board, I like to dabble in snowboarding, as well as piano, guitar and biking, although I’m good at none of these things. I’m also a big fan of music, incl. classic rock, punk and electronic, and film, incl. Kubrick, Hitchcock and Scorsese."

Welcome to David. He doesn't seem to have a blog yet, but he has been warned that as member of the dynamic languages team he needs one...

Friday, December 05, 2008

Silvershell 0.6 Released

Dan Eloff has announced the release of Silvershell 0.6. (Also known as Python/E - Python Everywhere!).
Silvershell is an interactive Python interpreter (for Python 2.5 as it is based on IronPython 2) with two clients (implemented in pure Python). It runs in the browser with Silverlight 2 or on the desktop with a WPF (Windows Presentation Foundation - which means it won't run on Mono) User Interface.

It is much more polished than my Python in the Browser, with features including:
  • Saving of preferences
  • Autocomplete and call tips
  • The ability to switch processing to a background thread
Here is the announcement that Dan posted to the IronPython mailing list:

"New in this release is the ability to run on the desktop with WPF, execution of code in background threads, and a scratchpad canvas for playing with UI controls."

"There are still some bugs lurking in the intellisense code, and I'll be following soon with a bugfix release. But it works, and you can try it out. I find it more user friendly than the command prompt."

As well as being a fun and potentially useful tool, it is a good example of how web and desktop applications can be maintained with similar codebases through Silverlight and WPF.

Wednesday, December 03, 2008

IronPython + F# + Parallel + Async = A Kittehz Brekfst

Concurrency with threading can be a tricky subject, particularly amongst the Python community.

Nick Hodge has a blog entry on using the .NET Parallel Extensions to write concurrent libraries in F#, and then using them from IronPython:
Whilst thread-safety, dead-locks, queues and other nasties are nasty, Microsoft sees the world of n-cores as a software problem to be solved, not ignored. Both at a low-level and a high-level, well constructed and debugged Parallel libraries are appearing to make the splitting of tasks easier.

IronPython implements the Python language on the DLR and subsequently on the CLR, but this does not automagically provide IronPython with threading and parallelism. Nor could I suggest that IronPython is the silver-bullet for clean parallelism with Python. Various projects such as ParallelPython (including cluster support), Stackless Python and the recent python-multiprocessing package are appearing to move CPython into today’s world of n-cores.

IronPython does have kissing-cousin languages like F#. From F#, and the Microsoft Parallel Extensions Jun08 CTP – a parallel library is a .dll away. Step 1: create a .dll from Luca’s demonstration from PDC2008 specifically the MathLibrary/StockAnalyzer. Combining both the async/parallel versions of the F# code with the single-threaded version was easy.

Tuesday, December 02, 2008

LiveFX using IronPython

Ori Amiga is the group program manager of the Live Framework development platform. He has started a blog, and in his first entry he demonstrates how to use the LiveFX SDK from IronPython.

According to the website:

"The Live Framework is the uniform way for programming Live Services from a variety of platforms, programming languages, applications and devices. Consume and combine Live Services to build applications that span across digital devices and the web."

    1. Download and install the latest IronPython console from [here]
    2. Grab the sample LiveOE.py file from [here]
    3. Edit the LiveOE.py file and change the line
      sdkLibsPath = r"..\LiveFrameworkSDK\Libraries\.Net Library"
      to reflect the path where you’ve installed the LiveFX SDK .NET libraries
    4. Launch the IronPython console from the command line: [ipy.exe -X:TabCompletion]
    5. At the console, you can now type something like:
import LiveOE
livefx = LiveOE.Connect("username@live.com", "password")
for i in livefx.Mesh.MeshObjects.Entries:
print i.Resource.Title

Checking Type Contract from IronPython

Ronnie Maor blogs about testing a C# interface interface that is implemented in IronPython. As Python is generally much more relaxed he needs to ensure that IronPython honours the type contract of the interface it is implementing. He tests this by testing the Python code through the C# interface (which will complain loudly if you use the wrong types) - making the calls via reflection.
"One thing I wanted to test is that my class implements the C# interface correctly in terms of methods' signatures. Otherwise IronPython throws an exception when it tries to map the arguments to the python method, or when it tries to convert the return value. However, my tests are in python, and calls to the object from python don't go through the type checking/conversion parts."

"To overcome this, I call the methods using .NET reflection, which mimics a C# call more accurately and goes through the type checking code. Here's the utility class that helps streamline this process:"

Monday, December 01, 2008

IronPython in Action Update and a Review

IronPython in Action, the book co-written by myself and Christian Muirhead, is still wending its way towards actually being available in the shops. It's currently going through copy editing and technical review. The copy editor is doing a fantastic job of fixing all our grammar and punctuation and generally making the book a better read for those who are bothered by errant commas and semi-colons. Dino Veihland is very kindly acting as our technical reviewer; and is also doing a marvellous job.

Meanwhile, for those who don't want to wait, the full text of the book (pre-copy editing and without the appendices - but still awesome) is available via the Manning Early Access Program. This gets you a PDF version now, and a hardcopy when the book hits the trees. The early access version has just been updated to cover the latest versions of the IronPython 2 hosting API, ASP.NET IronPython integration and Silverlight 2:
Davy Mitchell has been reading the early access version, and has posted a review:
He seems to like it:

"In conclusion, if you are interested in IronPython this book is a must for your bookshelf. 'IronPython In Action' gives a packed tour of IronPython across the key technologies from the desktop, databases, system administration to the web server and client side. Commendably it manages to bring all interested groups along for the ride and you will definitely be inspired to 'Action'. Ho ho. Going back to my initial goals after reading it, I definitely have improved my IronPython, Python and .Net. Result."

Adding References to Assemblies in IronPython

The 'first point' of interoperation between Python code and the .NET framework is the clr module. This allows you to dynamically add references to .NET assemblies in order to be able to import classes from the namespaces they contain.

The clr module has a bewildering array of different functions for adding references to assemblies, and each of them have slightly different semantics and use cases. Dino Veihland (IronPython Developer) recently posted a very useful explanation to the mailing list:

clr.AddReference(str) will first try Assembly.Load and then try Assembly.LoadWithPartialName - this should mean that trying with the strong name won't do anything because LoadWithPartialName will do that for you. This is kind of the one-stop shopping for loading assemblies in the GAC or the app base. If those don't work it will also ultimately search sys.path when the load fails.

clr.AddReference(asm) will just add the assembly that you've already loaded - this is useful if you can load the assembly using some other mechanism (e.g. Assembly.LoadFrom or loading from byte array or whatever)

clr.AddReferenceToFile(str) will search sys.path for the file and load it from there using Assembly.LoadFile. This is good to not have the normal Assembly.Load/LoadWithPartialName mechanisms get in the way.

clr.AddReferenceToFileAndPath(str) will take a fully qualified path, append it to sys.path, and then do Assembly.LoadFile with the path. This is just convenience for quickly adding a fully qualified assembly.

There's also Load* variations which return the assembly object which you can dot through without altering what you can import.

Usually when debugging assembly load failures I use fuslogvw.

Saturday, November 29, 2008

IronPython and Parallel Imports

In the latest release of Resolver One we improved startup time by about 20-30%. Most of the startup time in Resolver One is spent in importing Python modules, which is considerably more expensive in IronPython 1 than it is in CPython (even when compiled in binary form). We achieved most of our speedup by delaying the creation of certain objects until they are needed (if ever), and other standard techniques for performance improvement.

There is good news for IronPython 2. Binary compilation is much more efficient as we can compile multiple packages into a single binary and then ngen (pre-JIT), making imports faster.

Whilst exploring how to improve our startup time Kamil Dworakowski experimented with a system for performing parallel imports on multiple threads.
IronPython doesn't have the same import lock as CPython, so you need to ensure that parallel imports don't pull in the same modules simultaneously or some of the imports may fail. To get round this Kamil created a modified modulefinder that analyses a codebase and generates a dependency graph for all the imports (done at 'compile time' not runtime). So long as you start at the leaves of the graph you know you are safe. You can then configure how many threads the parallel importer should use in its threadpool to do the imports.

On a multi-core machine this yields substantial improvements for import time. Unfortuately there are a few thread safe issues for importing in IronPython 1, leading to intermittent crashes when starting Resolver One. We weren't able to use Kamil's code for Resolver One 1.3, but the specific problems we encountered are fixed in IronPython 2 so we might be able to use it in our next release...

Even though we haven't yet been able to take advantage of Kamil's work, others have. Dan Eloff, who is building a Silverlight gaming platform with IronPython and C#, has used it. He had this to say on the IronPython mailing list:

Thanks to the excellent work of Kamil and the help of Jimmy I now have importing being done in parallel in 4 threads in Silverlight.

I had to restructure my code a little to reduce circular imports (not
a bad thing to do anyway) and I had to hand-tweak the dependency graph to deal with conditional imports and other difficult to track

The result was better than I could have hoped for. I'm seeing 43%
faster loading on my dual-core development pc. I used to have blank screen at start that made you wonder if the browser has frozen. But now the browser is responsive and I have a nice working progress bar. But that's not the best news.

The kicker is that the benefit is even larger on slow single core
machines with dialup internet. I posted a while back on this list that
IE does not immediately send an asynchronous request. It waits until its UI thread is idle (which doesn't happen if your importing modules like crazy on it.) So the net effect was the application loads (about 28 seconds on a P4 2ghz) and then it sends the request, waits for the response (which is big in my case), and processes it - all in order.

So if that takes another 30 seconds, you have nearly 1 minute of load time. With the UI thread mostly idle now, this happens in parallel to the importing, and the overall load time drops by a whopping 45%.

In the words of my generation - w00t!

Friday, November 28, 2008

WSGI on .NET and in the Cloud

Jeff Hardy has been working on getting Django to run on IronPython, or at least that is part of what he has been working on. This includes his project NWSGI:

NWSGI is a .NET implementation of the Python WSGI specification using IronPython. It is implemented as an ASP.NET HttpHandler. The main goal is to provide an easy path for running Python web applications/frameworks (such as Django, Trac, etc.) on IIS7.

He recently released a new version of NWSGI:
This release has some possibly breaking changes and a whole host of new features. There is also an installer available along with the zip archive.

New features in this release:
  • The major new feature is IIS7 management integration, including a UI editor. It makes configuring NWSGI a breeze from the command line (appcmd) or from the UI. The IIS7 integration is only available through the installer.
  • There is one minor feature addition: wsgi.file_wrapper is now supported for faster file transfers. It uses HttpResponse.TransmitFile to send the file directly.

The changes are in the configuration system to support the IIS7 management system. Unfortunately, IIS7 doesn't use System.Configuration; instead, it has its own assembly, Microsoft.Web.Administration. This caused some complications for configuration. There are now three possible usage scenarios (IIS6, IIS7 xcopy, and IIS7 installed) that require slightly different web.config settings; I will detail these in an upcoming post.

As for using Django with IronPython and NWSGI, Jeff has some interesting ideas (and demo code to go with it) on ASP.NET features that might actually be useful for Django:
Using NWSGI to run Django on IronPython opens up some interesting possibilities, such as using ASP.NET's caching, session, or authentication systems for Django. I imagine any ASP.NET shop spent time configuring their ASP.NET providers for those systems, and I thought it would be interesting to see if that effort could be used for Django apps as well, and it certainly looks like they can.

A demo version of django-aspnet is now available...

Azure is Microsoft's new cloud computing platform. If you're interested in using IronPython and NWSGI on Azure, Jeff has been looking at that too:

Architecturally (as far as NWSGI is concerned), Azure is just IIS7 running in medium trust. You have to use xcopy deployment, which makes me glad I went to the effort of supporting it.

NWSGI 0.6 actually supports medium trust. I only discovered after the release that the error I was hitting was a bug in Cassini; it works fine in medium trust on IIS7. With that hurdle out of the way, there's no reason NWSGI shouldn't work on Azure.

And, what do you know, it works just fine: NWSGI "Hello, World" for Windows Azure. You'll need the Azure SDK and the Visual Studio tools to run it.

Two Source Code Repositories for IronPython

Dave Fugate is an IronPython tester. In the blog entrry he talks about how source code from the Microsoft internal development repositories is synced to the TFS repository on Codeplex.
In particular he addresses the issue as to why all the commits to the public repository have the astonishingly helpful checkin message "Latest sources migrated to CodePlex TFS", rather than actually telling you anything useful about what has changed.

He also explains how their processes have changed, enabling them to do code syncs to the public repository more often. (Something that is very useful for us at Resolver Systems as we port Resolver One to IronPython 2. We are using the new source drops daily so that we can pick up problems as quickly as possible.)

Thursday, November 27, 2008

Ironclad 0.7 Released

Following swiftly on heels of the IronPython 2 RC 2 and DLR 0.9 is a new release of Ironclad. Ironclad is an Open Source project by Resolver Systems, and is an implementation of the Python C API in C#. It allows you to use Python C extensions from IronPython, and our goal is to be able to use Numpy within Resolver One spreadsheets.

The latest release is version 0.7 and includes several major advances since the last release.
Major advances in the release include:
  • Huge chunks of numpy can now be imported and used
  • Lots of the numpy tests now pass (from core, fft, lib, linalg and random subpackages) - the distribution includes a test runner that runs the tests we have enabled so far
  • Major performance improvements (several orders of magnitude faster in some areas)
  • Ironclad works with IronPython 2 RC 2 and it no longer creates a separate Python engine, nor does it break the importing of .NET libraries!
The following interactive session shows numpy being imported in IronPython 2 using Ironclad:

C:\compile\ironclad-v0.7-bin\build>"C:\Program Files\IronPython 2.0\ipy.exe"
IronPython 2.0 ( on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.path.append(r'C:\Python25\Lib\site-packages')
>>> import ironclad
>>> import numpy
Detected numpy import
faking out modules: nosetester, parser, mmap, urllib2, ctypes
>>> numpy.__version__
>>> a = numpy.array([[1, 2, 3], [4, 5, 6]])
>>> a.shape
(2, 3)
>>> a[1, 1]
>>> a = numpy.arange(60).reshape(3, 4, 5)
>>> a
array([[[ 0, 1, 2, 3, 4],
[ 5, 6, 7, 8, 9],
[10, 11, 12, 13, 14],
[15, 16, 17, 18, 19]],

[[20, 21, 22, 23, 24],
[25, 26, 27, 28, 29],
[30, 31, 32, 33, 34],
[35, 36, 37, 38, 39]],

[[40, 41, 42, 43, 44],
[45, 46, 47, 48, 49],
[50, 51, 52, 53, 54],
[55, 56, 57, 58, 59]]])
>>> a[..., 3]
array([[ 3, 8, 13, 18],
[23, 28, 33, 38],
[43, 48, 53, 58]])

So much progress has been made in this release that Giles Thomas hints that "we’re now seriously considering having it as an option (with an explicit note that it’s not ready for production use) in the next release of Resolver One".

IronPython 2.0 RC 2 and DLR 0.9 Released

IronPython 2.0 Release Candidate 2 has just been released. This fixes several bugs identified in RC1 (several of these reported by Resolver Systems as we port Resolver One to run on IronPython 2).
Barring the discovery of any major new bugs, the intention is for IronPython 2 final to be released within 2 weeks!

Bugs fixed in this release include:
  • 19350: Missing restrictions on index operation against user defined type
  • 11733: time.timezone has different semantic than in cpython
  • 19675: subclasses of float have trouble with __int__ and __str__
  • 19656: Module Name Lookup Broken
  • 19678: in operator calls __getitem__ on class that has __len__ and __iter__ defined
  • 19665: operator.isSequenceType(NewStyleClass) broken
  • 19130: One hour error in IPY implementation of time.mktime and time.gmtime
Along with this release, the Dynamic Language Runtime has a new home - and a separate release (version 0.9) has been made. The example DLR language 'ToyScript' is now bundled with the DLR rather than being included in IronPython releases.
In the announcement on the IronPython mailing list, Bill Chiles (DLR program manager) had this to say about the Dynamic Language Runtime:

The DLR project provides one-stop shopping for folks who want to:

  • implement a language on .NET using the DLR
  • add dynamic features to their existing language like C#’s ‘dynamic’
  • add scripting to their applications.
  • create .NET libraries with dynamic objects

This Codeplex project includes the DLR sources as well as sources for IronPython, IronRuby, and samples (such as ToyScript). This is a classic open source version 0.9 release with high quality code through much of the system. We’re shipping some of this in the .NET 4.0 release coming up. Some parts are still open to design changes as we solidify those parts for post .NET 4.0, and we’ll continue to add more docs and samples. We will have coordinated releases or sync points across IronPython and IronRuby sites for major releases so that if you’re not pulling from the DLR project, you can still see which sources or releases are consistent across our projects.
Jim Hugunin did a great talk at PDC 08 on DLR architecture, concepts, and coding with the .NET 4.0 functionality (http://channel9.msdn.com/pdc2008/TL10/ ). In his talk, he also outlines what’s in .NET 4.0:

  • fast dynamic dispatch with polymorphic inline caching
  • dynamic object interoperability across languages and libraries (including C# ‘dynamic’ consuming IronPython and IronRuby objects naturally, including any language whose objects participate in the DLR’s dynamic object protocol)
  • support for library authors to easily make their model objects consumable with nice looking and lightweight code in languages that support the DLR dynamic object protocol (for example, with C#’s ‘dynamic’, you can write xml.Customer.Name instead of xml.GetChild(“Customer”).GetChild(“Name”)
  • ability to mix binding logic from various languages and library objects in a single dynamic call site cache
  • Expression Trees v2 with support for control flow, assignments, etc.
  • COM IDispatch binding as DLR dynamic objects

The following highlights the support shipping only on Codeplex until a future .NET release:

  • common hosting model for languages built on or supporting the DLR hosting model
  • helpers such as a default .NET binder, complex numbers, tuples
  • more Expression Tree support, such as globals access in hosted scenarios and iterator/generator functions.
All the code is available for what the DLR Team is shipping in .NET 4.0. Furthermore, we’re releasing all the code for LINQ Expression Trees v1 since the DLR merged its ASTs with LINQ trees. Some of you have noticed this code has been on the IronPython site for a couple of months now. We will continue indefinitely shipping all of our code open source through .NET 4.0 shipping and future releases of .NET as we move more and more of the DLR into .NET (for example, the common hosting APIs and language implementer APIs). We have no plan in place at this time for source take back from the community.
It is worth noting that the sources and binaries in the .zip files are circa mid-October, and the daily source tree pushes have several small but pervasive cleanups to the API (name changes), perf improvements, and so on. We’re busy here solidifying final design changes for the DLR parts going into .NET 4.0. We wanted to have our release match IronPython 2.0, and they had to lock down sources before we did. The documents in the release speak to the latest sources. Some of the documents are our internal working specs, but in general we prefer you know where we’re planning to end up with the code. There are no significant cognitive changes in the APIs, so you’ll easily map from the docs to the actual code.
For a consistent IronPython release, go to www.codeplex.com/ironpython and get their v2.0 RC2. We won’t normally have consistent release across all projects for RCs, betas, etc., and we don’t have one for IronRuby today. When we RTW IPy v2 and DLR v0.9 shortly, we’ll have consistent releases for all three projects.
If you want to read some documents without downloading sources or bits, go to http://www.codeplex.com/dlr/Wiki/View.aspx?title=Docs%20and%20specs :

  • dlr-overview.doc
  • sites-binders-dyn-objs-spec.doc
  • expr-tree-spec.doc
  • dlr-spec-hosting.doc
There is a discussion list at http://www.codeplex.com/dlr/Thread/List.aspx (click on the “get email notifications” link). All mail there goes to dlr@microsoft.com which has all the folks working on the DLR and our languages on it.

IronPython Program Manager is excited about the release, and describes it as Early Christmas from Iron Languages and DLR :

Tomorrow may be Thanksgiving, but the Microsoft DevDiv dynamic language teams are trying to make it feel like Christmas with three separate pre-holiday releases.

So there you go, new versions of IronPython and IronRuby plus a whole new DLR CodePlex project to boot. Enjoy.

He notes that along with the IronPython and DLR releases, there has also been a new release of IronRuby:

IronRuby 1.0 Alpha 2
There’s been zero blog traffic on this, just a notice on the IronRuby mailing list. As per said notice, “Notable features” include “the inclusion of iirb.bat, igem.bat, irails.bat, irake.bat”.

Seshadri (one of the DLR testers) promises regular binaries and weekly source drops in his blog entry on the DLR release.

GUI Automation: Building the Framework (3)

After a hiatus, the GUI Automation blog continues the series on the automated testing of Windows GUI applications. This entry uses the Win32 API to interact with a list box. As usual source code is provided for download:
In the entry Lukas makes an important point about any testing framework:

We do not test the list box component. We test the application.

When testing an application you don't need to test the functionality provided by the operating system or the frameworks you're using; you test your application logic.

Example code for selecting an item in a list box from the application under test (is SUT for "System Under Test" a commonly used acronym?):

def Select(self, aItem):
""" select an item from list box
@aItem - string with item to select
if aItem not in self.items:
raise Exception("Item '%s' not in list box" % aItem)
pos = self.location
# click on the first item to focus the list box
Win32API.MouseClick(pos[0] + (pos[2]/2), pos[1] + 3)
# send Home to be sure we are on the first item
# (we could be scrolled down a little)
# simulate pressing down arrow until we find the item
# we should find it because it is among self.items
while self.value != aItem:

Friday, November 21, 2008

A Whole Bunch of Stuff: Part II

More IronPython and DLR related stuff collected over the last few weeks.
This looks like a very interesting blog entry, and the only reason it is here rather than having a post to itself is that it is in Spanish and so I can't tell you much about what it says... It is by Jacobnix and about using IronPython with Mandriva Linux and Mono.
Two patches to Mono (by Bill Holmes) allowing you to compile and use recent versions of IronPython 2. This is great news as the version of IronPython 2 included with Mono (from FePy) is 2.0 alpha 5 - which is pretty out of date now.
Two new recipes in the IronPython Cookbook (both by Davy Mitchell I believe).
This StackOverflow question yielded several answers, including this example IronPython code for working with the Microsoft SQLServer database:
import clr
from System.Data.SqlClient import SqlConnection, SqlParameter

= 'data source=; initial catalog=; trusted_connection=True'
= SqlConnection(conn_string)
= connection.CreateCommand()
.CommandText = 'select id, name from people where group_id = @group_id'
.Parameters.Add(SqlParameter('group_id', 23))

= command.ExecuteReader()
while reader.Read():
print reader['id'], reader['name']

This blog entry is in Japanese, so I have no idea what it is about (I would really like to know)! All I know is that if you download the example application and run it with IronPython it complains about you not being logged in to the IRC channel and giant WPF teddy bears float down your screen! The program is called 'irc-wankumer.py' which is intriguing.
A French firm called LeeBeLLuL have a large web application written almost entirely in IronPython. One of their developers recently posted to the mailing list:

"I developed an application with LeeBeLLuL that communicates with Google App Engine in SOAP. I mainly use the DataStore, process are done on the PC. I think GAE is an effective platform with good response time, whose implementation is easy with SOAP."

Again, I have no idea what is actually going on - but the page linked to has quite a few examples of working with XML (presumably SOAP as they also have a big WSDL definition) from IronPython.
You've just missed my colleague speaking at the Oredev developer conference in Sweden: "Pumping Iron: Dynamic Languages on .NET". I'm mainly posting this link because his bio is fun and you can see from his photo how much weight he has gained recently...

Jonathan and I have a proposal to do an IronPython tutorial at PyCon 2009.

A Whole Bunch of Stuff: Part I

My backlog includes a lot of interesting snippets and blog entries that probably don't warrant a whole entry to themselves. There's a lot of good stuff in them, so I'm splitting them out into two separate entries.

A blog entry on using the IronPython 1 hosting API to call functions - including embedding it in ASP.NET pages.
This happened a while ago, but I missed it. Windows High Performance Computing Operating System is out (HPC Server 2008) - and it includes IronPython 'out of the box'!

"To tempt Unix users and coders in scientific programming languages, there is a built-in POSIX shell, support for IronPython, IronRuby and Fortran. Microsoft is also developing new tools such as the F# programming language and .NET Parallel Extensions."

"Much of the legacy code that developers may need to support is Linux-based, he says. Mendillo notes that support for Iron Ruby, Iron Python, Fortan and a built-in Posix-compliant shell should help many developers bridge to non-Windows environments."
I noted recently that the Intellipad tool, part of the Oslo framework, is scriptable with IronPython. Jon Flanders has a blog entry showing how to write new commands for IPad using IronPython.
One of the things I didn't mention in the recent entry on Silverlight 2 is that a version for Windows Mobile has been planned. The version of .NET targetting Windows Mobile (and the XBox 360) is the Compact Framework - and this doesn't include the 'Reflection.Emit' (code generation and introspection) APIs needed by the Dynamic Language Runtime. This unfortunately means that Silverlight 2 for Windows Mobile won't be able to run applications written in IronRuby or IronPython.
As the Dynamic Language Runtime forms the basis of both the IronPython and IronRuby projects (and currently slightly out of sync versions of the DLR are included in the downloads for both of these projects - making it hard to create projects that target both languages), and the DLR will be part of .NET 4, it really needs its own home. That home is a project page on the Codeplex Open Source project hosting site. This page is little more than a placeholder currently, but it notes:

"The Dynamic Language Runtime enables language developers to more easily create dynamic languages for the .NET platform. In addition to being a pluggable back-end for dynamic language compilers, the DLR provides language interop for dynamic operations on objects. The DLR has common hosting APIs for using dynamic languages as libraries or for scripting in your .NET applications. This project provides one stop shopping for the DLR components, our open source implementations of IronPython and IronRuby, documentation, and samples."

"This project is currently under construction, and we're targeting our first release of DLR v0.9 in November. We will be releasing simultaneously with IronPython v2.0. You can see all the DLR code in the IronPython Project's latest RC release and weekly source pushes. Our code is also available on IronRuby's site with daily source pushes."

Thursday, November 20, 2008

The Microsoft Dynamic Languages Team Blogroll

The dynamic languages team at Microsoft are relatively small, but have an extremely high proportion of bloggers! (The obvious conclusion is that dynamic language enthusiasts tend to be better communicators...)

Oleg Tkachenko lists them on his blog:
For the record, they are:
We're trying to keep track of them on the People in IronPython page of the IronPython Cookbook.

Wednesday, November 19, 2008

Silverlight 2 and Dynamic Languages

Well my backlog is logged so far back that I haven't even blogged about the final release of Silverlight 2.

In case you've been living under a rock for the last year, Silverlight 2 is a browser plugin from Microsoft. It is similar to Flash (aimed at games, media streaming and rich internet applications) and is cross-platform (Mac OS X and Windows - the officially blessed Linux port Moonlight by the Mono guys is making good progress though) and cross browser (IE 7+, Safari & Firefox 2+). Unlike Flash it can be programmed with a choice of languages, and through the Dynamic Language Runtime it can be programmed in Python, Ruby and Javascript.

Silverlight 2 final is now out, and according to Scott Guthrie has now been installed on over 100 million consumer computers.

Naturally Jimmy Schementi, who maintains the Dynamic Language Support for Silverlight, released an updated version of the Silverlight Dynamic Languages SDK (sucky name - more on this in a bit):
In preparation for my talk at the PyWorks conference I updated my IronPython Web IDE (tool for experimenting with the Silverlight APIs from Python in the browser) and Try Python (interactive Python interpreter in the browser) for Silverlight 2:
Of course if you're interested in building internet applications with Silverlight then you will want the extended controls that come as part of the Visual Studio Tools for Silverlight 2 (this works with Visual Studio Professional or the free Visual Web Developer Express). The assemblies that come with the tools include the data grid, extra controls like the date picker and various other useful APIs.

Even better is the Silverlight Toolkit. This is by Microsoft, but Open Source (living on Codeplex and with Unit Tests). As it is a separate project it can have a separate release cycle, including experimental components and being updated more frequently than Silverlight itself.

The toolkit includes charting components plus new controls covering styling, layout, and user input.

Since these releases Jimmy Schementi has been far from idle. His latest blog entries track what he has been up to:

Though, for certain scenarios, running scripts in a VB/C# application would be useful. For example, a shopping application that has a bunch of business rules, like "when someone has three items in their cart that all have to do with cooking, give them 10% off." These type of rules can change all the time, and traditionally you'd either store the rules in a database and implement a engine to understand the rules, or hand-code them yourself and have to redeploy the system every time you want to change them. Or, you could save yourself the hassle and store the rules as Python or Ruby code, and then host the DLR in your application to run the code. Want to update the rules? Just update the code, nothing more.
Embedding an IronRuby REPL (interactive interpreter) in a Silverlight application.
This is the good one! Jimmy posted this email to the IronRuby and IronPython mailing lists:

First and foremost, I want to thank anyone who has used the bits on http://codeplex.com/sdlsdk, and accepting my bullshit version of open-source. While getting monthly binaries/sources is nice, it should be about working on the project together ... not just me throwing stuff over the wall to you. That's changing, now ...

Oh, and remember me complaining about the crappy "sdlsdk" name ... well, I'm trying to get rid of that acronym ...


Above the public repository for the DLR integration in Silverlight. The following post explains what's in there, what's not, what's git, and how to contribute: http://blog.jimmy.schementi.com/2008/11/agdlr-silverlight-dlr-open-source.html

My first order of collaboration is this simple new feature, "console=true": http://blog.jimmy.schementi.com/2008/11/repls-in-silverlight.html. If you like this, please feel free to look at what's been done, and if you want to fix something that doesn't yet work correctly, I won't stop you.

Also, as I mentioned in a previous mail, I want to make the filesystem->XAP/isolatedstorage metaphor stronger, so feel free to experiment with that as well. Over the next week I'll get some website-presence/wiki/etc, and we can run this project up and running. There are still some hurdles I need to clear with getting contributed code back into our internal codebase, and shipping on Codeplex, but there are no problems with keeping things on GitHub for now.

Let me know if there are any question. I know I've been a bit silent on the Silverlight front, but take this as me making it up to you.

The resulting discussion also revealed where the Silverlight development tool Chiron got its name from:

Yep, Ag is Silver … made pretty obvious by my little logo for it.

As far as Chiron. It's a planetoid between Saturn and Uranus. The port that Chiron.exe runs on by default, 2060, is Chiron's "object" number. It was derived from the Cassini ASP.NET Web server that Dmitry Robsman wrote. Cassini was a probe mission to explore the moons of Saturn, and Chiron was initially thought to be a moon of Saturn.

Plus this from Michael Letterle:

More importantly, it's also the name of one of Jonathan Coulton's songs: "Chiron Beta Prime".

Because of this I knew how to pronounce the name :)