Hosting IronPython 2.0 Alpha 6 via the DLR

A new blog entry from Ryan Dawson showing how to host IronPython 2.0 in a .NET application. It also talks about some of the changes coming in the IronPython 2 hosting API:

• Hosting IronPython 2.0 Alpha 6 via the DLR
  

DLRPad on Codelplex

The DLRPad is a Silverlight application for creating WPF (XAML) apps and scripting them with IronPython or IronRuby. This is now hosted on Codeplex:

• DLRPad on Codeplex
• Announcement
  

Hosting IronPython 1.1

Ryan Dawson has a great blog entry on the hosting API for IronPython 1.1. He intends to follow it up with embedding examples for the IronPython 2 alphas as well:

• Hosting IronPython 1.1

UPDATE: Ryan is new member of the DLR team. He has also done a Hello World Blog Post, explaining his intention to blog more about IronPython and the DLR.

A Meme Tracker in IronPython

Dare Obasanjo has been learning Python, or more specifically IronPython so that he can port Sam Ruby's 'Meme Tracker' to run on .NET:

• Interested in "Python for C# Developers?"
  
• A Meme Tracker in IronPython
  

IronPython and Python Stack Frames

One incompatibility between IronPython and CPython that is unlikely to go away, is that IronPython does not have Python stack frames. IronPython is implemented on the CLR, which has its own stack frames that are very different to the Python ones.

This means that tricks with 'sys._getframe()' and friends will never work with IronPython.

JRuby, for Ruby compatibility, does use frames. Charles Nutter (one of the JRuby devs) has been experimenting with a frameless approach that yields faster execution:

• Experimenting with Frameless Execution
  

(A paragraph near the bottom of that blog entry.) Python stack frames are seen as an implementation detail, and if you want your code to run across implementations then you shouldn't interact with them directly (does PyPy use Python stack frames?). Even though it is almost always a hack, we have missed them occasionally at Resolver. The notes from Charles sheds light on the IronPython design decision.

DLR Hosting Spec

The IronPython team have been firming up the hosting API for IronPython and DLR languages.

They have published an early spec, available via John Lam's website:

• DLR Hosting Spec
  

SharpDevelop: IronPython AddIn Internals

The SharpDevelop team have created an IronPython language binding for the SharpDevelop IDE. This (like the Visual Studio SDK) is an example of creating new language bindings:

"This is a tutorial about how to create a language binding for SharpDevelop using the IronPython addin as an example. As well as covering how to create a language binding it will also look at how the addin used IronPython. The source code for the IronPython addin is available at the end of this tutorial."

• IronPython AddIn Internals
  

DLR Pad - interactive programming with XAML and DLR

Stefan Dobrez writes:

"This post is about a tool that I have build. It is called DLR Pad. In one sentence it allows you to rapidly create simple XAML based applications and script against them with dynamic language of your choice."

The blog entry shows (another) Silverlight IDE like tool that can be used for experimenting with IronPython and XAML in Silverlight. You can also download the DLR Pad:

• DLR Pad - interactive programming with XAML and DLR
  

Mike Stall Learns Python

Mike Stall has just joined the IronPython / DLR team at Microsoft. Before this he was working on the CLR debugging team (and is an expert on the subject).

As he is now working on IronPython, Mike thinks it might be a good idea to learn Python. He is finding 'Learning Python, by Mark Lutz, a useful resource:

• Learning Python
  

First IronPython Book

As you may know, I' writing a book on IronPython for Manning: "IronPython in Action". The next third of the book is about to go for a review and will then be available in the early access program.

It won't make it as the first IronPython book though, there is already a Japanese one.

• English Translation of "IronPython" Page
  
• Original Page
  

Boo, Java, .NET and IronPython

A blogger called Tomo wondered about which .NET language to choose Boo (a mighty fine language) or IronPython. He came down in favour of Boo, and an interesting discussion ensued in the comments:

• Boo at Koans of Code

The very next thing he tried was taking the Java class library for SWT (the user interface library) and compiled them into a .NET dll with IKVM. He then used them from Boo and IronPython, which worked!

• Language Frenzy

This is an interesting coincidence, as a few days ago Rodrigo announced on the Boo blog about boojay - a compiler that emits Java bytecode from Boo:

• Introducing Boojay

NWSGI - WSGI ASP.NET HttpHandler

Today Jeff Hardy announced on the IronPython list, the first release of NWSGI, an implementation of WSGI compliant server for IronPython 2.0. written in C# as a ASP.NET HttpHandler.

Currently it runs simple WSGI applications but has problems with the larger Python web frameworks due to bugs in IronPython 2.0 and NWSGI. Hopefully as IronPython 2.0 matures and Jeff continues to work on NWSGI, the will become less of an issue.

An implementation of a WSGI server for IronPython 1.0 is available with FePy

Multiple Python Engines in IronPython

One of the features of IronPython 1 that Resolver uses, which isn't currently available in IronPython 2, is the ability to create multiple isolated Python engines. The IronPython team have just announced that this feature will make it into IronPython 2:

• Multiple Python Engines in IronPython 2
  

LOLCode on the DLR

Martin Maly, as part of his TechEd talk on the Dynamic Language Runtime, showed an implementation of an exciting new language (LOLCode) that he hacked together whilst travelling. John Lam has made the source code to this available on his blog and Martin has contributed a write-up on the LOLCode site:

• LOLCode on the DLR (with download)
• My Commentary (with some build instructions)
• Intro to LOLCode on the DLR
  

Hosting IronRuby with the DLR

The DLR (Dynamic Language Runtime) hosting API is still changing, in fact (according to Dino Viehland) it is now hosting API feature week.

Despite this, Tomas has written a great article on the DLR hosting API and IronRuby. Much of it is applicable to IronPython of course:

• Hosting IronRuby with the DLR
  

Unicode Strings & Localization plus IronPython and the Standard Library

We recently had a strange bug from a Turkish user, that uncovered an issue with Unicode strings and the Python decimal module (when used from IronPython). The easiest fix is a simple modification to 'decimal.py', and Dino (an IP developer) says that Microsoft are looking at shipping the Python standard library with IronPython to make this kind of modification easier (a big step for Microsoft):

• Resolver Goes Multinational, Real World Problems with Resolver, IronPython Localization Issues and an Important Announcement
  

More IronPython News from TechEd

This week I've been at TechEd Barcelona, and as well as demoing Resolver, I've done some interviews and been to some IronPython talks:

• TechEd Podcasts and Interviews
• IronPython Demos: Sho & Silverlight
  

IronPython 2.0a6

There is a new version of IronPython 2 out, 2.0a6:

• Release notes of IP2a6

This version fixes several bugs and is the first under the new public license. See the release notes for full details.

The release also includes a toy language implementation, ToyScript, that is an example dynamic language targetting the Dynamic Language Runtime. Martin Maly (one of the IP & DLR developers) has done a talk, at TechEd Barcelona, on the DLR that walked through part of toyscript and introduced a new DLR language - lolcode:

• The Dynamic Language Runtime
  

Calling IronPython from C# with Delegates

A blog entry by 'Coding the Markets' on wrapping a "C# WinForms object in a Python dictionary".

• Calling IronPython from C# Using Delegates
  

Embedding IronPython in WPF C#

A Code Project article on embedding IronPython (1.1 from the looks of it) in a C# WPF application:

• Embedding IronPython in WPF C#