Wednesday, July 29, 2009

Mono builds of IronPython (and IronRuby)

Ivan Porto Carrero, when he's not writing IronRuby in Action, has been working on ASP.NET MVC integration with dynamic languages. His main focus has been IronRuby, but a lot of the core work (the DLR hosting API integration) applies equally to IronPython. Jeff Hardy has recently taken up the mantle of working on the IronPython integration.

Anyway, that is all by the way of an aside. In the process of doing this Ivan has been building IronPython and IronRuby for Mono. He posted this email to the IronPython mailing list:
I've added the ironpython mono package to the ironruby mono CI server. It is slightly different from the windows package it doesn't have the licenses included nor does it have the 64bit builds and the pyc.py file. The tutorial is also not in the github repository so I couldn't include that either.

you can download the packages here: ironruby.colliertech.org/
The continuous integration server is maintained by CJ Adams-Collier, and it also has a prettier interface that gives you information about recent builds.

CJ has been busy creating Debian packages for Mono 2.4.2 (the version you want if you are running IronPython) and both IronPython and IronRuby. He gives some details in a recent blog entry:
I’ve helped get the mono-2.4.2 debs moving. The mono-api-diff tool was removed after the 2.2 branch, so I grabbed it from the attic, dusted it off and patched it for use by meebey. The solution is sub-optimal, but at least he’s able to use it get things moving again.
On the subject of Mono compatibility, Miguel de Icaza (Mono lead developer for Novell) has blogged about an interesting side effect of the Moonlight project (Mono port of Silverlight):
For as long as we remember, most new versions of IronPython, IronRuby or the Dynamic Language Runtime exposed new missing functionality in Mono.

After a major release of any of these tools that deeply exercise the internal Reflection.Emit support and the runtime we would implement the missing features and ship a new Mono version.

As part of the Microsoft/Novell collaboration on Silverlight for Linux, a couple of months ago, we received from Microsoft the test suite for the Silverlight class libraries.

We have been working on fixing all of the issues exposed by the test suite. The test suite exposed bugs in Mono and missing features that are necessary for Silverlight in general, as well as the DLR and the DLR-based languages like IronRuby and IronPython.

We are pretty excited about the progress and the increased compatibility of Mono with Microsoft's .NET.
Completely off the subject now, and by way of final word, if you are interested in seeing IronPython support in Visual Studio 2010 then please vote up the following Microsoft Connect issue. Anyone can rate it or comment, you just need a Live ID.

Tuesday, July 28, 2009

IronPython Training in Stockholm, September 23rd-24th

I'll be presenting a two day training session in Stockholm (the training is in English) with addskills in September (23rd-24th). It is aimed at .NET developers looking to use IronPython for application development, scripting, embedding, testing or just as another useful tool. It will be a comprehensive training session for those with .NET experience who are interested in making practical use of IronPython. There will even be some IronRuby examples covered.
This course is about how to make the most of dynamic languages like IronPython and IronRuby on the .NET framework; with a particular focus on IronPython. The dynamic language runtime, which is being incorporated into .NET 4.0 and is the basis of IronPython and IronRuby, enables a new class of language to run on the .NET framework. In the last few years dynamic languages have gained a reputation for increased developer productivity and being easy to learn. These new languages for the .NET framework have potential applications in everything from scripting tasks to application development to embedding in .NET programs as ready made scripting engines.

Topics covered will include:
  • IronPython and the interactive environment (the REPL)
  • Why dynamic languages? (how Python and Ruby differ differ from statically typed languages)
  • The Python language
  • Multiple programming paradigms: object oriented, functional and metaprogramming
  • Working with the .NET framework
  • Development tools including IronPython in Visual Studio
  • Testing with IronPython
  • Dynamic Silverlight applications
  • Embedding the DLR (IronPython and IronRuby) in .NET applications
  • Interacting with dynamic objects and the dynamic keyword in C# 4.0
  • Practical tips, tricks, and participants' questions

Sunday, July 26, 2009

Teaching IronPython: D520 Course Notes (Week One)

Tony Andrew Meyer has now started teaching course D520 ("Programming") at Northtec. He's using IronPython in Action as course material (see IronPython in Action goes to college) and has written up his search for an IDE for his students.

The course is now starting and he is promising to post his notes online as he goes:
Since I decided to use IronPython as the programming language for teaching D520 at Northtec, I’ve planned on putting my course material online so that anyone else planning on using IronPython in teaching can make whatever use of it they can. There won’t be a huge amount of material, especially in this first year, and especially since I managed to find an excellent textbook to use, but there will be some exercises, assignments, an exam, and so forth. Each year I teach a course I add new material, and while some material is replaced or removed, usually the old material stays, so the amount of material gradually increases.
Week one of the course has now happened and Tony has written up a post-mortem:
As promised, here’s my material from the first week of “D520: Programming” (in IronPython). I have the students a set of revision exercises [PDF], a course outline [PDF], and some brief notes [PDF]. The notes have four sections (this pattern will continue): which chapters of the textbook are covered this week (and a couple of sentences that summarise them or point out which parts are important to us), the tools that are required this week (since this is the first week, this section is large, covering installation of Adobe Reader, IronPython itself (including putting it on the PATH), and several IDEs (as previously covered), including configuration), key points, and example code (the examples that I plan to use in class). For anyone interested (chiefly: me in about nine months time, when I’m planning the 2010 course), here’s a summary of the first week. It’s rather long (2100+ words) – the summaries of future weeks should be shorter.The students seemed fine with the choice of textbook, and that there was one. I expected more grumbling about the price, but perhaps they just kept that to themselves. There did seem to be a moderate amount of interest in the ebook version over the print copy. The real test of the textbook starts next week, since none of the students were organised enough to buy the text before the first class, and so hadn’t seen it or read the first two chapters, which we covered. They are expected to have at least skimmed through Chapter 3 before next week’s class.

A Good Mix 17: MUD, the Python for .NET that never was, Intellisense for IronPython, SciPy and Silverlight

Yet another selection of articles and projects on IronPython and the Dynamic Language Runtime from around the web.
This is the gitorious project page for a C# project:
Chiroptera is a MUD client written in C# and uses IronPython as a scripting language. It runs on Windows and on Linux. Windows version has a graphical user interface. Linux version has a text interface with 256 color support.
Back way in the past, before 1.0, there was a previous Microsoft project to bring Python to the .NET framework. Unfortunately .NET pre-1.0 wasn't a good platform for dynamic languages and the project was never released. This article (from December 2000) is an interview with Mark Hammond who was the programmer on the project.
Mark Hammond is familiar to most Python programmers because of his excellent development of the PythonWin environment and the PythonCOM extensions. And for the same reasons that we look up to Mark, Microsoft also looks up to Mark. They decided to contact him for help on their implementation of Python for .NET. According to Mark, a working version of Python for .NET should be available Real Soon Now.
Mertz: I can't help but worry that Microsoft will try to use proprietary extensions and enhancements in a familiar "embrace, extend, extinguish" strategy. In other words, I fear that Python for .NET might not actually be very good for Python in the long term.

Hammond: Well, if .NET becomes a significant force, then having a Python implementation that targets it can only help Python, much in the same way that JPython helps Python by targeting the JVM.
This project is in Japanese so it's hard to know exactly how, but ironpythoneditr aims to provide intellisense support for IronPython. The ever wonderful google translate renders the page thusly:
IronPython is IntelliSense.
.NET Framework to use in IronPython dynamic language. C# and VB.NET to IronPython classes and can help you, you can embed scripts in the application, it will become hard to use or not use for any object or method. So, IronPython has developed a taste for the intelligentsia.
Downloading the project it uses IronPython 1.0 (even though the latest release is this month) and includes an example Windows Forms console type program with autocomplete for object members.
Two articles by John Cooke on using SciPy with Python. He includes a plug for using Ironclad to use SciPy with IronPython:
IronPython cannot use SciPy directly because much of SciPy is implemented in C and at this time IronPython can only directly import modules implemented in Python. However, the Ironclad package enables IronPython to use SciPy. See Numerical computing in IronPython with Ironclad for details.
A turkish article on working with Silverlight and IronPython. Includes some nice examples of styled UI elements in XAML.

Saturday, July 25, 2009

Running IronPython 2.6 with Python stack frame support

IronPython 2.6 has Python stack frame support. Python stack frame support has a performance cost, but allows code that uses sys._getframe(), plus the standard library pdb debugger, to work.

To run IronPython 2.6 with stack frame support you need to use one of two command line switches, -X:Frames or -X:FullFrames. In an email on the IronPython mailing list Dino Veihland (core IronPython developer) explains the difference:
-X:FullFrames promotes all local variables into the heap. So you can always crawl the stack and look/change them for all methods.

-X:Frames only creates the frame objects and if something happens to make us promote local variables (e.g. a closure, or a call to locals(), exec, eval, dir(), vars()) then the local variables will be available for that specific method.

A Good Mix 16: Metaprogramming, Talks, PyDev, Excel and Testing

Another selection of articles, audio recordings and blog entries on IronPython collected from around the web.
Slides and code from a talk by Kevin Hazzard on metaprogramming on the .NET framework using C# 4.0 and IronPython.
The title of my presentation was "How I Learned to Love Metaprogramming" and it concerns Dynamic Language Runtime architecture, performance of dynamic typing and Python to C# integration. The slides and source code are linked below. I will be giving this talk again in September at the Charlottesville .NET User Group meeting. Both of the demos require C# 4.0 which is available in Visual Studio 2010.
  • Demo One - shows how to do XML parsing using a fluent interface based on a DynamicObject derivation in C# 4.0
  • Demo Two - shows how the Level 0, 1 and 2 CallSite and ActionBinder caches perform. UPDATED: I added a demo on 30 June 2009 that shows how the DLR 0.9 compares by invoking dynamic code through the DLR hosting APIs, thereby bypassing the CallSite caching mechanisms. The results are very instructive, showing that the DLR's polymorphic inline caching can yield a 250000% increase in performance. You read that correctly: a two hundrend fifty thousand percent increase in performance.
Recordings of talks from EuroPython 2009 are now available (in the hippy friendly ogg format). Several of the talks were on IronPython and Python on .NET. These include:
Several of the talks also have slides available from the recorded talks page. There are various other interesting talks, including one on a Visual Studio Vim plugin and several on alternative implementations of Python including Jython, PyPy and HotPy.
Support for IronPython in Eclipse through the Pydev extensions was recently announced. Pydev 1.4.7 is the first released version of Pydev with IronPython integration:
The major features (Iron Python integration and the new way of running as unit-test / running the current editor with the configured nature) were previously discussed in a previous post and are now available in this release.

Note that the Iron Python debugger is still not available in this release, but it seems that the next release of Iron Python will have the sys.settrace() support, so, there's a chance that the next Pydev version has a debugger for it.
A short entry showing IronPython code for interacting with Excel:
I thought I would share another Iron Python snippet I hacked together a few weeks ago. The PrintTables method accepts a OleDbConnection to the spreadsheet and returns a list of Excel Table (Sheet) names.
Ranorex is a .NET tool for automated testing of web and GUI applications, including support for IronPython. They have a new example for Data Driven Testing. The sample is in C#, VB.NET and IronPython.
In this tutorial you will create a simple recording and perform the same operations with multiple sets of data. You will use a data table (Excel CSV) with a set of parameters so that you can run your recording several times using a different set of data.

Thursday, July 23, 2009

IronPython 2.6 Beta 2 Released (performance, ctypes, frames and more)

Hot on the heels of IronPython 2.0.2 is a new release - the second and hopefully final beta of IronPython 2.6.

The big new features in IronPython 2.6 are:
  • Python 2.6 compatibility
  • The __clrtype__ metaclass for data binding and attribute support
  • Implementation of the ctypes module
  • Support for Python stack frames and sys.settrace, which means the pdb debugger works
  • Better performance through adaptive compilation
  • Faster startup
In the announcement of the release Dave Fugate had this to say about the timetable for IronPython 2.6:
At this point we are essentially feature complete from a CPython 2.6 perspective, and look forward to making available IronPython 2.6 Release Candidate 1 within the next couple of months. As such, we’d very much like everyone to try out this release and report back any major problems you may encounter so we can fix them in time for the first release candidate. Any bugs that you find can be reported via Codeplex.
The release notes:
The primary focus of Beta 2 was bug fixing: a whopping 215 bugs were fixed in this release. The majority of these were fixes to standard CPython built-in modules with IronPython runtime fixes coming in at a close second. Some of the higher profile work items include:
  • The implementation of the sys module was improved so that you can now utilize CPython’s pdb module in basic scenarios to debug IronPython sessions provided you pass the –X:Frames or –X:FullFrames options to ipy.exe
  • 374 Implement _ctypes module
  • 20051 Re-raising exception causes loss of traceback
  • 18770 Support type inference on generic methods and improve function conversions - better LINQ support
  • 15399 'frame' object has no attribute 'f_back'
  • 17465 Implement rest of binascii module (package)
  • A bug was fixed in our build scripts that was leaving several working CPython standard modules out of our MSI installations. These included a few modules under the distutils package, two modules under encodings, code, codeop, and the io modules
A very visible new feature added to this release is that ipy.exe is now strictly a 32-bit only assembly. That is, it gets executed as a 32-bit CLR process on both x86 and x64 operating systems. ipy64.exe, despite what its name might imply, is a platform agnostic assembly matching the old behavior of ipy.exe in the sense that it gets executed as a 32-bit process on 32-bit OSes and 64-bit on 64-bit OSes. Why this change you ask? Quite simply put IronPython users with 64-bit OSes will see around a 33% improvement to IronPython startup time under ipy.exe!

Silverlight users: a new version of Silverlight, namely Silverlight 3.0, is required to build the “Silverlight Release” or “Silverlight Debug” configurations of IronPython.sln. Please update your Silverlight installation accordingly by visiting www.microsoft.com/silverlight if you intend to build IronPython from sources.

Thanks to everyone in the IronPython Community who reported bugs and provided valuable feedback. We really do appreciate your input which helps to make every release of IronPython better than the last.
In a rare blog entry Dino Veihland (core IronPython developer) comments on two releases in one week:
This was a good week for IronPython - we've released not one but two new versions!

The first release was IronPython 2.0.2 which just includes bug fixes for issues which have been particularly irritating to our users. This is a very minor release and doesn't include breaking changes. Probably the most significant fix is that we've fixed ngen on 64-bit platforms. Previously when you would install 2.0 and enable ngen it would only ngen the binaries for 32-bit assemblies. Now we'll ngen for 64-bit which should help users running on 64-bit see much faster startup times. I hope that this will make 2.0 much more usable until we get the really big improvements that 2.6 brings.

And speaking of 2.6 the other release this week was our 2nd and final beta. 2.6 is shaping up to be an exciting release. We've significantly improved the startup time of IronPython - this has been our number one requested change. We've implemented more standard modules and other missing functionality to be closer to CPython. This includes the new ctypes module, support for sys.settrace and pdb, as well other new functionality that 2.6 has introduced such as the underlying support for the io module. And finally we've added a bunch of new features to improve .NET interop as well - we've now got support for generic method type inference and added the core support that will enable using .NET attributes and in general working better w/ .NET when static types are expected. I'm pretty excited about this release and can't wait to get the final version out - so please try out this beta and let us know if you run into any issues.

Five Reviews of IronPython in Action

In the last couple of weeks a whole stack of people have posted reviews of IronPython in Action. Here's a brief summary of five of them:
Jason Baker is a Python developer for Zeomega:

"In summary, if you’re a developer wanting to work with Windows technologies using Python there’s no question: go and buy IronPython in Action. Right now. If you’re wanting to develop IronPython applications for various platforms or don’t want to tie yourself to just Microsoft technology… still go and buy IronPython in Action. There are still some holes that can be filled, but all in all, this is a pretty solid book."
Mike Hadlow is a well known .NET developer from the UK:

"It’s a very well written and crafted book, with an easy to read conversational style. I find many programming books quite hard work, but this one was a pleasure."
Mark Bloodworth is a Microsoft Architect Evangelist with an interest in dynamic languages:

"If you’re interested in the DLR and IronPython, this book is worth reading. It’s a very good introduction – and will serve as a useful reference when you come to start your next foray into IronPython. And if you’re not interested in the DLR and IronPython, reading this book may just change your mind."
Doug Hellmann is a well known Python programmer and blogger:

"I recommend this book for any Windows developer interested in learning about Python, and for Python developers looking into deploying an application under Windows. If you don't fall into either of those groups, I can still recommend that you pick up a copy for some excellent advice on general programming topics and the solid example code."
Darrell Hawley is a Microsoft C# MVP and Python enthusiast, which makes IronPython an obvious attraction to him.

"Pythonistas will find the book offers quick introductions to a number of Microsoft technologies such as Windows Forms, WPF and ASP.NET. .NET developers will get the chance to see technologies they’re already familiar with expressed in a completely new fashion."

"IPiA avoids the trap of simply being a brochure of Microsoft technologies using “IronPython” in place of “C#” and “VB.NET”. Instead, the authors mix in chapters on development techniques ranging from the familiar - such as unit testing and mocking – to the more exotic such as metaprogramming. As .NET developers wind their way through the book, they’ll begin to appreciate the differences between the static and dynamic worlds – a crucial step toward wide ranging acceptance."

"If you’re curious about what IronPython can do for you, IronPython in Action is well worth your time."

Øredev 2008 - Cool Languages - Pumping Iron: Dynamic Languages on .NET (video)

Last year Jonathan Hartley delivered a talk at the Øredev conference on IronPython and dynamic languages on the .NET framework. A video of his talk is now up on viddler:
Pumping Iron: Dynamic Languages on .NET
Jonathan Hartley, Resolver Systems, UK

As you may know, Microsoft is developing IronPython and IronRuby, .NET implementations of the popular open-source programming languages Python and Ruby. While it's clear that Microsoft wants to attract existing Python and Ruby developers to .NET, the role of IronPython and IronRuby for existing .NET developers is less clear. What value is there for a .NET developer in learning IronPython? What are the tradeoffs between IronRuby and a more traditional .NET language like C# or VB?
Jonathan also took some pictures at the conference.

Wednesday, July 22, 2009

Gestalt: Ruby, Python & XAML in your HTML pages

Silverlight makes it possible to script the browser with Python and Ruby (IronPython and IronRuby of course), but the experience is very different to working with Javascript. That could all change thanks to a new project from MIX Online Labs called Gestalt.
Gestalt is a library released by MIX Online Labs that allows you to write Ruby, Python & XAML code in your (X)HTML pages. It enables you to build richer and more powerful web applications by marrying the benefits of expressive languages, modern compilers, AJAX & RIAs with the write » save » refresh development model of the web.
Amongst its features it promises:
Make way for Ruby & Python, JavaScript!
Gestalt lets you write Ruby & Python within script tags (or linked scripts) right in your (X)HTML pages allowing you to do everything and more you've been used to doing in the page with JavaScript.

Transparently compiled and blazing fast
When a user visits a page that uses Gestalt, we harness the power of the Dynamic Language Runtime (DLR) to transparently compile any Ruby, Python & XAML blobs before running the scripts.

"Look, Ma. No tools!"
You need nothing more than a text editor to build your web pages. Since we like TextMate, we decided to release a bundle for it that gives you productive features like XAML tab completion & more.
The short version is that Gestalt allows you to write code in script tags in your html pages (or loading external scripts) specifying Python or Ruby as the language. By including a specific Javascript file that activates Silverlight this code, which has full access to the browser DOM, is executed with the Dynamic Language Runtime.

Jimmy Schementi gives more details and some specific examples in a blog post:
A simple Ruby-based web page using Gestalt would look like this:
Gestalt adds “ruby” and “python” to the languages supported by the <script> tag. You can also include other files rather than writing the code in the HTML page:
<script> tag. You can also include other files rather than writing the code in the HTML page: My first reactions when hearing about this project was “Holy crap, wow, they got Ruby and Python running in the browser, that’s freakin’ awesome!” But I work on the Silverlight integration with IronRuby and IronPython, already letting you write Ruby and Python in the browser instead of JavaScript. Hmm. Not to my surprise, Gestalt uses IronRuby and IronPython in Silverlight to accomplish this. But damn, wouldn’t it be awesome if this is how the world worked?
Miguel de Icaza also has a blog entry on Gestalt and its place in the Mono world:

This addresses a part of Silverlight's story that I always felt was less than ideal. Without the Gestalt script, developers using Ruby or Python had to package their software on a ZIP file before sending down to the client.

All four pieces (Gestalt, the Dynamic Language Runtime, IronRuby and IronPython) are open source technologies that run on either Microsoft's Silverlight or our own open source Moonlight.

IronPython 2.0.2 Released

Work on IronPython 2.6 progresses (there is even a new page that appeared overnight comparing the performance of the as-yet-unreleased 2.6 Beta 2 to CPython 2.6.1).

In the meantime there has been a bugfix release on the stable IronPython 2.0 branch - IronPython 2.0.2 has just been released.
This release is a minor update to IronPython 2.0.1, which in turn is a CPython 2.5-compatible release running on the .NET platform. Our priority was to make IronPython 2.0.2 a bugfix release that remains backwards-compatible with IronPython 2.0.1. In particular, we focused on issues the IronPython community brought to our attention through codeplex. As such, there have been important improvements on the compatibility and stability of IronPython as summarized below.
Detailed change summary:
  • 21577 – binascii.crc32 doesn't accept one argument.
  • 20616 – wrong TypeError message when invoking "str.join": implicit parameter 'self' not counted
  • 19665 – 2.0.2: operator.isSequenceType(NewStyleClass) broken
  • 20087 – 2.0.2: Null Value Exception in COM interop
  • 21445 – DLR: There is a dead loop in CallSite.UpdateAndExecute(), which leads to IronPython 2.0.1 hang.
  • 22001 – 2.0.2: Ngen IronPython.msi option doesn't work on 64-bit platforms?
  • 22094 – 2.0.2: StringException leaked to Python via sys.exc_info()
  • 22239 – 2.0.2: modules aren't isolated
  • 20634 – hex_codec needs to be imported before hex decode can happen
  • 20302 – codecs.lookup errors with uppercase encoding names
  • 20051 – Re-raising exception causes loss of traceback
  • 4565 – Support all encodings CPython does for _codecs.encode and _codecs.decode
  • 20603 – os.walk(‘’) doesn’t work
  • 21929 – os.listdir does not accept empty path
  • 17235 – dir(System.ArgIterator) broken
Silverlight users: A new version of Silverlight, specifically Silverlight 3, is required to build the “Silverlight Release” or “Silverlight Debug” configurations of IronPython.sln. Please update Silverlight accordingly if you intend to do so.

Monday, July 20, 2009

Using IronPython in WPF to evaluate expressions

IronPython makes a ridiculously good expression evaluator, and for some reason it seems to get used a lot for adding dynamic features to WPF. For example see Using IronPython for Converters in Silverlight and Binding Dynamic Types with WPF.

This Code Project article, by Sacha Barber, uses IronPython with WPF to evaluate mathematical expressions from C#.
I have just read a little book on IronPython and thought it a pretty cool language. What I especially liked was the fact that it can be hosted in .NET as a script. This gave me an idea, wouldn't it be cool if we could use IronPython as a script to evaluate mathematical expressions for us and return a value.

Think javascripts eval function, which is missing from C# (at least it is right now, it may be part of C# 4.0 who knows). So with this thought in mind I whipped up a small proof of concept and was actually very pleased with the results, so much so I have turned it into this article.

You may be asking why would I possibly want to use a mathematical expression in WPF. Well here is one common usage, you have a UI element that you want to be as wide as its container - some magic number, this is something you could do with a standard IValueConverter, but what if you want another expression, you would need another IValueConverter implementation. That ain't cool.

So lets have a look at what I came up with.

I have come up with 2 options a MarkupExtension and a IMultiValueConverter implementation.

Python and Farseer: 2d Physics in Silverlight

Silverlight is a Microsoft browser plugin competing with Flash for rich internet applications and games (amongst other things). The most interesting thing about Silverlight, to me at any rate, is that it allows client-side web applications that run in the browser to be written in IronPython - including full access to the browser DOM.

Silverlight is now maturing, with version 3.0 released only recently. Silverlight runs natively on Windows and the Mac on Firefox, Safari and Internet Explorer browsers. The Mono version for Linux, Moonlight, has reached the level of compatibility where it is capable of running DLR applications - like my IronPython examples.

There are now lots of interesting open source libraries for developing Silverlight applications. One of them is the Farseer Physics Engine:
The Farseer Physics Engine is an easy to use 2D physics engine designed for Microsoft’s XNA and Silverlight platforms. The Farseer Physics Engine focuses on simplicity, useful features, and enabling the creation of fun, dynamic games.
Tarn Barford has posted a blog entry on developing Silverlight applications with IronPython and Farseer - including a demo with source code available:
I limited the example for this post to a very simple, but interactive 2d physics demo. Clicking any of the objects in the simulation creates a spring between the object and the mouse cursor until the mouse click is released or leaves the simulation view area.

The Farseer physics engine is a lot of fun to use, it’s easy to get into and you can do some really cool stuff with it.

The source code is sent as plain text and compiled (or interpreted) on client. As the XAP is just a normal zip file, it can unzipped by almost any zip tool. Inside is all the plain text source code, compiled assemblies and manifest file.

It’s awesome to be able to develop Silverlight applications with physics libraries using a high level language and light weight development environment. Happy hacking.



Sunday, July 19, 2009

IronPython editor postscript (Eclipse and NetBeans)

Tony Andrew Meyer did a comprehensive blog entry on choosing an IronPython editor for teaching. In it he reviewed 7 IDEs and Python editors for use with IronPython. He's posted an update to this where he tries out NetBeans plus the combination of Eclipse and PyDev.
I earlier tried various editors I was considering using to teach IronPython. One of the glaring omissions was Eclipse/PyDev, which has built-in support and is a very well-known IDE (particularly in the Java community). The main reason that I skipped Eclipse was that when I was searching for an IDE to use professionally about five years ago I tried Eclipse (for Python, C, and C++ development) and I really hated it – the IDE was very slow (especially to launch), it was very Java-centric, and just didn’t suit me at all. I’d briefly tried Eclipse before that as well, with similar results.

Over the last few days, I decided that I was probably being unfair, and since this was a choice for my students rather than for me personally, I really ought to try Eclipse (with the PyDev extensions). I also noticed recently a post about using IronPython with NetBeans – I’d heard of NetBeans before, but only in a Java development context, and since I stay as far away from Java development as I can, I had no experience with NetBeans at all.

A Good Mix 15: SharpDevelop, IronRuby, Mono and Scripting

More blog entries, articles and podcasts on IronPython and the Dynamic Language Runtime.
Discussing IDEs for IronPython is all the rage at the moment, and it is great that tool support is finally improving (and at an impressive pace). This post is by a developer called Mandar Vaze extolling the virtues of SharpDevelop for working with IronPython.
In my first post about IronPython, I documented how installing IronPython Studio was painful (Needed Visual Studio shell, which in itself was confusing). When I started with IronPython I did not know about any other IDE, hence I went ahead with IronPython Studio. But later I came to know about SharpDevelop.
IronRuby, the evil-twin of IronPython, has had a new release on the road to version 1.0. Jimmy Schementi announces and explains the release:
Performance has been a major focus to this release, getting startup time quicker and optimizing built-in types. There has been more progress with Ruby compatibility (Cucumber works!) and .NET interop. Silverlight binaries are back in the release, and there are a couple of samples to help you learn IronRuby.

Most of these descriptions are from Tomas's very detailed code review emails, so thanks Tomas! For more detailed information, please see the CHANGELOG (which includes all commit messages for the release ... not just "syncing to head of tfs")
  • Lazy method compilation
  • CLR member enumeration
  • Generic-Method Parameter-Inference
  • Testing C# with Cucumber
  • Silverlight building and updated binaries
  • Samples
    On the subject of IronRuby, here's an interesting post on using .NET libraries - which needless to say is just as simple as from IronPython.
    Whilst my example below is extremely trivial, it shows how you might make use of any existing libraries within your Ruby scripts. This same technique applies to any .NET libraries, whether they’re custom, part of the framework, or created by your gran. I don’t think I really need to sell it in – but I love the flexibility that this provides.
    A short new recipe on the IronPython Cookbook created by Domingo Aguilera. It shows how to find the local IP address of a machine using the Python socket module.
    Slides of an IronPython / Mono presentation given to the San Luis Obispo .NET User Group. The presentation and demos (including embedding IronPython in C# applications) was given entirely from an Open Source stack: using Ubuntu, Mono, Monodevelop etc.
    A Hanselminutes podcast on developing Banshee on the Mono platform. The Banshee Project is a cross-platform Media Player. It's a Mono Application that runs on Linux, Mac OS X and Windows. The discussion includes how Banshee is scripted with the Dynamic Language Runtime.

    Saturday, July 18, 2009

    Getting started with IronPython – Part 4: MiniMax algorithm

    Dror Helper continues his series on getting started with IronPython programming. He has been creating an example game and after his last entry on unit testing he moves onto adding some simple AI logic:
    As part of my quest to learn how to program in Python I’ve decided to implement a simple Minimax algorithm.

    The algorithm is simple and relies on a elementary principle – each turn you will choose the best move and your opponent will choose the worst move for you. By building a search tree with a limited depth we can then choose each time either the maximum result possible or the minimum result according to the player’s turn.

    You can read more about Minimax algorithm in Wikipedia – or continue reading and learn it from my implementation.

    A Good Mix 14: Open Source, XML, XNA and more

    Another selection of blog entries and articles on IronPython and the DLR.
    A Korean translation of a presentation about the future of Open Source at Microsoft by Harry Pierson, the IronPython program manager. IronPython, and its two companion projects IronRuby and the Dynamic Language Runtime, are at the forefront of pushing the adoption and acceptance of open source in the corporate behemoth we all know and love.
    bridge is an open source Python library for handling XML that works with CPython and IronPython. Its homepage describes it as: "a Python XML library trying to provide a high level and clean interface for manipulating XML documents."

    bridge allows you to write code dealing with XML that will run unmodified on both CPython and IronPython. Most common Python packages for dealing with XML rely on C extensions not available on IronPython (except through Ironclad) although the FePy project contains an implementation of pyexpat wrapping .NET functionality.
    This is a presentation by Fredrico Cicchi from the third PyCon Italy (although the presentation is in English). It is about using IronPython as a scripting language in a game written using the Microsoft XNA Framework. XNA can be used for creating games that run on the PC or on the XBox 360 although the XBox doesn't yet support IronPython as it uses the .NET Compact Framework that is missing the Reflection.Emit APIs that IronPython depends on. XNA is used by professionals and hobbyists alike for game creation. The presentation includes a demo of an IronPython console running inside an XNA game for debugging and prototyping.
    Digipede is a distributed .NET computing platform (grid computing) with support for IronPython. Channel 9 is a website for videos and interviews on Microsoft technologies.
    I went to Microsoft’s Mountain View office last week, where I did an interview with William Leong, Microsoft ISV Evangelist. We talked about Digipede’s market, products, and the need for grid computing in businesses of all sizes. We even talked about IronPython, and how a last-minute addition to a recent version of our software has been driving new business for us.
    A short tutorial showing how to get started with creating IronPython applications that run in the browser through the Silverlight browser plugin and the Chiron development tool.
    Some example code from Greg Bray on using the System.Speech.Synthesis.SpeechSynthesizer class to make IronPython speak.

    Friday, July 17, 2009

    Choosing an IronPython editor for teaching

    As outlined in IronPython in Action Goes to College, Tony Andrew Meyer is teaching a programming course and using IronPython in Action as course material. Part of his preparation is deciding which IDE to use in the course - a choice that is not entirely straightforward for IronPython.

    Tony has done a long and thorough blog entry going through all the possibilities. The editors he looks at are: Notepad++, IronPython Studio, SharpDevelop 3.0, SharpDevelop 3.1b1, Wing IDE 101, Davy's IronPython Editor, Visual Studio under experimental hive and Komodo Edit.
    The Northtec D520 “Programming” course is changing to IronPython (from Visual Basic) this year, so I have to figure out what editor/IDE the students should use. In some ways, Visual Studio would be ideal, since they need to get exposed to that during the course (and it’s an excellent IDE, with a really great form designer), but since there isn’t any real IronPython support in Visual Studio (hopefully coming in 2010), it’s not really a viable option. Instead, they’ll start with a simpler editor, and then briefly learn how to use Visual Studio’s form designer and subclass the forms in IronPython (as described in IronPython in Action).

    The requirements here are a bit different than when selecting an editor/IDE for actual development work. Firstly, it needs to be free (at least for educational use), and it needs to be reasonably simple to use the basic functionality (since these are first-year students). Code-completion isn’t necessary (on the one hand, it helps them out while they are learning – on the other, they rely a little too much on it), nor is a built-in debugger, or support for complex projects.

    I considered seven different editors/IDEs...

    ...

    Conclusion
    Unfortunately, there isn’t a clear winner. My recommendation will be that the students spend the first half of the course using a text editor: if they are comfortable continuing to use Notepad++, then that makes the most sense. If they are willing to try a new tool, then I would recommend Komodo Edit (or DIE if they want something that just works without having to do any additional configuration). When the time comes to start learning how to use a graphical form designer, then I would recommend that they install the Visual Studio SDK and add IronPython support under the “Experimental Hive”, although they’ll also learn how to use standard Visual Studio and subclass C#/Visual Basic forms in IronPython. It seems like they could then continue to use the “Experimental Hive” for the rest of the semester (even for Console projects), although they would know how to fall back to the previous tools if necessary.
    Tony didn't try out Eclipse with PyDev (which may have added IronPython support after he started the exercise or it may be that using IronPython 2.6 isn't an option for Tony). It would be really nice if MonoDevelop had IronPython support so that it was a viable possibility.

    An email regarding MonoDevelop was just posted to the IronPython Mailing List:
    MonoDevelop is the IDE of choice for .NET languages on Linux. But currently there's no IronPython support for it. There are a couple starting points available in the svn sources, but someone would need to take a fresh look at it and write a new IronPython binding.

    Anyway, if there's any initiative to increase IronPython use on non-Windows platforms, this might be one way to help that.

    Some references--

    IronPython for build scripting

    Python is ideal for tasks like automating build processes. Similarly, in a .NET environment IronPython is a valuable tool. Steve Gilham has been putting IronPython to work in his current project.
    Following on from the earlier post with the snippet about generating GUIDs -- and covering a good chunk of what's been occupying me since...

    I have ended up in charge of the build system for the current project at work. This started out with one framework that used a number of custom projects inside a solution to perform unit test, FxCop and coverage analysis, with a lot of magic happening in post-build steps, including direct calls to Wix command-line utilities. Another team had developed a better separated MSBuild-based system, which split out things like the analysis and installer building from the assembly-building solution. We can argue the merits of taking the unit tests out of every checking compile; but separating out the installer build does have a significant benefit in terms of cycle time for a recompilation.

    Frankensteining the two together was an interesting task; and IronPython has been a valuable component of the mix. As I noted quite a while ago, the convenience of an XCOPY install on a machine with a current .net installation (any build or dev machine), and the access to the full APIs makes for a powerful tool during a build -- it's not just the fact that you get better string manipulation than a batch file, or can easily spawn off a call to source control to get a synch-level value to stamp an assembly with.

    Thursday, July 16, 2009

    Interoperability Happens: Ted Neward Reviews IronPython in Action

    Ted Neward is a well known .NET developer. He has been reading IronPython in Action and posted a review of it.
    Ted Neward doesn't have unqualified praise for the book, but he seems to like it - even getting over his prejudice for 'the whitespace issue' (block structure by indentation in Python).

    Here are some things he liked about IronPython in Action:
    • The focus is on both .NET and Python, and doesn't try to short-change either the "Python"-ness or the ".NET'-ness by trying to be a "Python book (that happens to run on .NET)" or a ".NET book (that happens to use Python for code samples)". The authors, I think, did a very good job of balancing the two, making this the book to get if you're in that area on the Venn diagram where "Python" overlaps with ".NET".
    • Part 2, "Core development techniques", starts down the "feed you the Python Kool-Ade" pretty quickly, heading straight into Chapter 4 ("Writing an application and design patterns with IronPython") without much of a pause for breath. The authors get into duck typing, protocols, and Model-View-Controller within the first four pages, and begin working on a running example to highlight some of the ideas. (Interestingly enough, they also take a few moments to point out that IronPython on Mono works, and include a couple of screen shots to that effect as we go, though I personally wonder just how many people are really going down this path.) I like the no-holds-barred, show-you-the-code style, but only because they also take time throughout the prose to talk about some of the concepts at work underneath and laced throughout the code. "Show me then tell me" is a time-honored tradition, but too many authors forget the "tell me" part and stop with code. These guys do a good job of following through.
    • The chapters in Part 3, "IronPython and advanced .NET", form an interesting collection of how IronPython can fit into the rest of the .NET stack, demonstrating how to use IronPython with WPF, ASP.NET, and IronPython's crowning glory, Silverlight. If you're into front-end stuff, this is the section where I think you're going to have the most fun.
    • The chapters in Part 4, "Reaching out with IronPython", is I think the most important part of the book, showing how to extend IronPython (chapter 14) with C#/VB extensions (similar to how a C-Python developer would extend Python by writing C code, but much much simpler) and the opposite—how to embed IronPython inside of existing C#/VB applications (chapter 15), which is really an exercise in using the DLR Hosting APIs. While the discussion in chapter 15 is good, I wish it'd had a bit more thorough discussion of how the DLR could be hosted regardless of the scripting language, though I admit that's pretty beyond the scope of this book (which is focused, after all, entirely on IronPython, and as a result should stay focused on how to host IPy).
    The things he doesn't like about the book include too many footnotes, the things we don't cover and the fact that we don't introduce testing until chapter 7. The point about testing is fair. He would have liked to content on WCF and more on SOAP-based web services, WF, and several more of the Microsoft database access technologies (there is pretty much a new one every year - it can be hard to know which one is currently in vogue but ADO.NET has weathered well). We would have loved to have covered some of these topics, the question is which chapters to remove in their place...

    Microsoft.Scripting.Debugging

    For IronPython users interested in tool support the big new feature in IronPython 2.6 is the support for Python stack frames and all that comes along with it. Not a small part of this is that pdb, the standard library Python debugger, will work with IronPython - yay!

    Harry Pierson (IronPython program manager for Microsoft) has a new blog entry detailing the new assembly that will come with IronPython 2.6 (but will actually be part of the Dynamic Language Runtime) to support this:
    If you’ve compiled IronPython from source recently, you may have noticed a new DLL: Microsoft.Scripting.Debugging. This DLL contains a lightweight, non-blocking debugger for DLR based languages that is going to enable both new scenarios as well as better compatibility with CPython. Needless to say, we’re very excited about it.

    ...

    Of course, we hide all this DLR Debugger goo from you in IronPython. Python already has a mechanism for doing traceback debugging – sys.settrace. Our ITraceCallback, PythonTracebackListener, wrapps the DLR Debugger API to expose the sys.settrace API. That makes this feature a twofer – new capability for IronPython + better compatibility with CPython. Instead of needing a custom tool (i.e. ipydbg) you can now use PDB from the standard Python library

    For those hosting IronPython, we also have a couple of static extension methods in our hosting API (look for the SetTrace functions in IronPython\Hosting\Python.cs). These are simply wrappers around sys.settrace, so it has the same API regardless if you access it from inside IronPython or from the hosting API. But if you’re hosting IronPython in a C# application, those extension methods are very convenient to use.

    This debugger will be in our regular releases of IronPython as of 2.6 beta 2 which is scheduled to drop at the end of this month.

    So the new APIs mean better debugging (potentially) for all DLR languages, better debugging for IronPython developers and better debugging for those embedding IronPython.

    Shortly after this blog entry, Seo Sanghyeon (maintainer of FePy - the community edition of IronPython) posted this email to the IronPython mailing list:
    Now I updated FePy's NAnt build file to include newly introduced Microsoft.System.Debugging.dll
    So we're looking good for a long awaited fresh release of FePy when IronPython 2.6 is released.

    Tuesday, July 14, 2009

    Simon Segal: A WPF IronPython REPL and messaging with NServiceBus

    Simon Segal has been building an Entity Framework tool with built-in IronPython scripting support. Part of this has involved creating quite a fully fledged interactive Python interpreter as a WPF GUI component. This turns out to be quite a useful tool on its own.
    So to move forward with the WPF user control console project I decided to refactor it to support IronPython. Mark has jumped in just recently and started to contribute by adding the new “cached commands”, which offer up / down arrow repeat command behaviour such as found on a DOS console. You will also notice from the screenshot above I have imported the entire System namespace to demonstrate that it is possible (using the environment menu) to print the entire state of the default scopes current set of variables.
    I have recently been working with NServiceBus quite a bit and whilst I was working on a WPF IronPython Console - User Control / Window, it occurred to me that it would be a useful tool in testing and monitoring behaviour of my services whilst running under NServiceBus. Let’s have a look at the simplest of examples by configuring up an IBus and publishing messages using Udi’s PubSub sample.

    ...

    The other thing to note in the code above is that the configuration code from the PubSub sample is removed and what now remains is to create and run an instance of the IronPython Application Shell, effectively embedding IronPython into my NServiceBus publisher. Once this is done we are all set to start scripting our services and NServiceBus. If I run this code above I expect to see the the IronPython Application Scripting Window pop up ready for action.




    Monday, July 13, 2009

    Bazaar on IronPython

    The IronPython team are extremely interested in IronPython's compatibility with CPython. One easy way of finding incompatibilities (bugs) is running large Python applications on IronPython. Jeff Hardy has done a lot of work on this front by running Django and setuptools with IronPython, and now the Bazaar (Distributed Version Control System written in Python) team are joining in the fun.
    In short, see the attached patch for getting bazaar to run on IronPython. It only passes a subset of the tests, but can do some of the basics like creating a new repo, adding and diffing, and committing the changes. This is not intended for merging, many of the changes are addressing interpreter bugs and differences rather than problems with the code. However there are a number of issues raised that might be of interest to bazaar developers.

    Having nibbled round the edges of the bzrlib.osutils module, I wanted a task that would serve as an excuse to look over the platform related code as a whole. I'd downloaded IronPython some months back and not had cause to play with it, and seeing that Adrian Wilkins investigated this a year ago and wrote up some helpful tips, it seemed achievable.

    My basic strategy was to get selftest working then deal with categories of test failures. I mostly used IronPython 2.0.0 though I tried the first 2.6 beta towards the end, which threw up a few extra issues, but may have been a better choice to start as it's less compiling-the-world slow on every invocation. There's still work to be done to make bazaar generally usable under IronPython, and fair bit of low hanging fruit (for instance I left warnings about terminal encodings untouched as a useful progress indicator).
    This threw up a bunch of issues in IronPython. As usual Dino (and team) worked their magic and posted the following reply to the IronPython mailing list a matter of days later:
    With this morning's source push all of these should be fixed now except for the zlib and re.RE_Pattern issues.

    Guido van Rossum on IronPython in Action (he doesn't like Windows Forms but Davy Mitchell does)

    Guido van Rossum is the creator of Python and its Benevolent Dictator for Life (BDFL). He is employed by google and not known for his love of the Windows platform. That aside I sent him a copy of IronPython in Action and he has reviewed it. As you can tell from the title of his blog entry it isn't a typical review, but he does say some very nice things about the book:
    Seeing a book like IronPython in Action, by Michael Foord and Christian Muirhead, is another milestone for IronPython. This is a solid work in every aspect, and something nobody using IronPython on .NET should be without. The book is chock full of useful information, presented along with a series of running examples, and covers almost every aspect of IronPython use imaginable.

    There are some introductory chapters -- some fluff about .NET and the CLR, an introduction to Python, and an introduction to with .NET objects from IronPython. The Python introduction has a slight emphasis on differences between IronPython and CPython, though there aren't enough to fill a chapter. This is a good thing! The chapter does a pretty good job of teaching Python, assuming you already know programming. In general, the book is aimed solidly at professional software developers: unless you are paid to do it, why would anyone want to get intimate with Windows?
    Unfortunately reading the early chapters that go through developing a simple Windows Forms example application seems to have given Guido terrible flashbacks to a brief period of C++/Win32 development and the rest of the article becomes somewhat a rant about the Microsoft / Windows programming experience.

    I chose a Windows Forms application because it makes a quick visual and cross-platform example application (Pro IronPython also starts with a winforms example app). More important to the early chapters than the specific winforms API is creating a structured application (Model-View-Controller etc) with Python - alongside introducing Python language features like first class functions and showing the way round .NET APIs such as System.Xml and so on.

    This aside I think Guido is a little unfair to Windows Forms, it's certainly no worse than other GUI toolkits I've used, and whilst a little verbose in places is generally quite good. Ironically the only examples of pixel positioning in the book (that I can recall anyway...) is to demonstrate how much easier the visual designer can make some aspects of GUI development...

    Davy Mitchell disagrees with Guido's assessment of Windows Forms:
    During his review of ‘IronPython in Action’ Guido describes programming WinForms as ‘still looks incredibly tedious to create the simplest of UI’. This is a little unfair. Let me make my case. Firstly MS are not looking to make IronPython a major desktop application language – it could have been but is not in VS2010 with a GUI editor. For now the focus is elsewhere. So if you work with desktop applications and IronPython things are a bit ‘by hand’. Having been hacking various desktop tools, experiments and oddities for several years, I feel qualified by experience to say it is a pretty good state compared with wxPython, Tkinter and some of the web frameworks.
    Note that IronPython in Action does demonstrate how to use the Visual Studio winforms designer with IronPython, and discusses when it is better to use a designer and when to handroll code.

    Also note that alternative UI toolkits for IronPython are available. WPF is one which is Windows only (and as well as a chapter in the book is discussed in the comments on Guido's blog). Through Mono, although the Windows compatible ones work with .NET as well, you also have the choice of:

    Monday, July 06, 2009

    A Good Mix 13: ActiveRecord, Guids and Strings (etc)

    Another selection of IronPython snippets and articles from around the web.
    The Active Record pattern is a pattern for working with databases named by Martin Fowler and popularised by Rails: "The interface to such an object would include functions such as Insert, Update, and Delete, plus properties that correspond more-or-less directly to the columns in the underlying database table." Creating classes where the shape of the class corresponds to the shape of a database table is particularly easy with dynamic languages. This Chinese blog entry demonstrates the pattern with IronPython hosted in C#.
    Blog entries by Steve Gilham have made frequent appearances here on IronPython-URLs, although I believe it has been a while since the last one. This entry isn't specifically about IronPython - but the example code is in IronPython. He shows a couple of example functions he uses in his build scripts to solve the following problem: "In recent weeks I've had the problem of wanting to generate GUIDs that are distinct, but are repeatable -- in particular for things like COM class UIDs, and for installer component IDs, for a project using a lot of generated code."
    A post by Robert Smallshire on the differences between bytestrings and unicode strings on CPython and IronPython. Although he gets the details for Jython wrong (at least for the latest version) he does show useful example code for converting between byte arrays and strings for IronPython.
    Another post from an IronPython-URLs regular, Sarah Dutkiewicz (The Coding Geekette): "The language junkie in me spoke on Python to the .NET group, and of course, leave it to me to remember to tie in IronPython - the .NET implementation of Python". This post has the slides and example code from her Python 101 for .NET developers presentation.
    The competition amongst IDEs supporting IronPython is hotting up. SharpDevelop is still one of the best and this entry is about making sure your IronPython projects have access to the right version of the Python standard library. Although the technique suggested here works fine I did add a comment:
    Adding a specific absolute location to sys.path makes your application dependent on IronPython 2 being installed in that specific place (e.g. on x64 Windows IronPython will be installed in "C:\Program Files(x86)\IronPython 2.0.1\Lib").

    I prefer to include the standard library, or just the parts I need, within my project.

    Simple Python Testing in Silverlight with unittest

    Jimmy Schementi is the program manager for the Silverlight dynamic languages integration. He has an unhealthy interest in IronRuby, and created a very impressive IronRuby tutorial that is part of the latest release. It's always nice when he does something with a Python focus, and a recent blog entry of his is particularly good - testing in Silverlight with IronPython and the unittest module.

    Since doing a post about Ruby testing of Silverlight applications, I’ve felt a bit guilty about leaving Python fans in the dark. However, like Ruby, it takes very little work to run Python unit test frameworks in Silverlight, since IronPython is a very compatible implementation of Python. Though my results aren’t as exhaustive as the IronRuby examples, here’s one simple example:

    http://github.com/jschementi/europycon2009


    Saturday, July 04, 2009

    Another IDE for IronPython? Eclipse and PyDev

    A common question with IronPython is which IDE to use. Many .NET developers will immediately look for IronPython integration with Visual Studio but there are much better options.

    Up until now the front runner has been SharpDevelop with debugger, Windows Forms designer and even C# to IronPython translation. Other viable alternatives are Wing IDE and Netbeans.

    Another alternative has just arrived - and it is an unexpected one: Eclipse, through the PyDev extensions. The features it supports for IronPython are impressive.
    One of the major features in this release is the IronPython integration. Note that it requires IronPython 2.6 (earlier versions are not supported because of the lack of sys._getframe()).

    In that integration, code-completion should be working for the .NET libraries and other dlls. For the .NET libraries, just make sure that the library you're using is listed in the forced builtins -- I believe all libraries should be there already, but it could be that some default library is missing.

    To use code-completion for other libraries, the code must be compiled as a dll (because Pydev does not recognize C# nor VB) and that dll must have the exact same name of the namespace it contains (e.g.: if you want to do "import iTextSharp", the dll must be named iTextSharp.dll -- the case of the file important there) and the folder containing that dll must be added as a source folder (or external source folder) -- which is the same thing for python compiled extensions.

    Most features should be working fine with IronPython, with the most notable exception being that the debugger is not supported (that's because in this version, IronPython still doesn't provide sys.settrace(), so, there's no API to work on for python debugging).
    So it looks like the new frame support in IronPython 2.6 are already paying off in improved tools. Once sys.settrace is implemented (coming soon) the story will get even better.

    Thursday, July 02, 2009

    NWSGI: Configuration and Dispatching

    NWSGI, as I may have mentioned before, is the creation of Jeff Hardy and is "a .NET implementation of the Python WSGI specification for IronPython. It is implemented as an ASP.NET HttpHandler for use with IIS 6 and 7". The goal is to be able to run Python applications like Django, Trac and Pylons on IronPython. It can also be used on the Microsoft Azure (cloud computing) platform.

    Version 2 is now in beta, and with it come several important changes. In a series of blog entries Jeff has been explaining these changes; and these four entries focus on configuring and dispatching.
    For the most part, NWSGI can be used without any configuration. All you have to do is create a .wsgi file, throw it in a directory, let IIS know what’s going on, and you’re good to go! Of course, if it was always that easy, configuration wouldn’t exist. To really work with NWSGI, you need to understand its configuration. It helps if you’re already familiar with web.config files; if not, check this out (but hurry back!).

    NWSGI uses .NET’s built-in configuration system (System.Configuration), so the first thing that needs to be done is to let the .NET Framework know about the custom NWSGI configuration section.
    NWSGI has a fairly simple task: given a URL, call some Python code that produces some output. The devil, as always, is in the details.

    What is WSGI?

    NWSGI is an implementation of the Python WSGI specification (PEP 333). WSGI is the Web Server Gateway Interface, “a simple and universal interface between web servers and web applications or frameworks”, as defined in PEP 333.

    OK, so what does that mean?
    Let’s say we’re dealing with a much larger Python application, coolapp, that is installed at C:\coolapp-1.1\. Unfortunately, coolapp doesn’t provide a ready-made .wsgi file for us, but it does provide a function (coolapp.dispatchers.wsgi_application) that we can use by writing a little wrapper that looks something like:

    import sys
    sys.path.append("C:\coolapp-1.1")
    import coolapp.dispatchers.wsgi_application
    application = coolapp.dispatchers.wsgi_application

    We could save this as coolapp.wsgi and follow either of two methods from last time, but since we’re not doing anything fancy in the wrapper, NWSGI provides a shortcut.
    The normal procedure for configuring NWSGI leaves an unsightly URL wart: the URL must contain the .wsgi file. There are two ways to get rid of that wart: URL rewriting and wildcards.

    When using URL rewriting, the web server changes ("rewrites") the incoming URL into something NWSGI can understand. IIS 7 has a URL rewriting extension to do just that. It's quite easy to use, too.

    Wednesday, July 01, 2009

    IronPython in Action Goes to College

    Thanks to the wonder of Twitter I've heard about two different college courses that will be using IronPython in Action as course material next semester. One is Sargeant Reynolds College in America, with a course taught by Kevin Hazzard, and the other is Northtec in New Zealand with a course taught by Tony Meyer.

    IronPython is an ideal language for learning programming, it has the great combination of an easy to learn general purpose programming language (Python) with a programming environment which is widely used in commercial development (the .NET framework). Not only these factors, but it is easy to teach good programming practise with Python; things like well structured code, testing, computer science theory including elements of functional programming and so on.

    I exchanged emails with Tony who explained why he is using IronPython in Action:
    The course is (unimaginatively) titled "Programming" (not my doing!). It's at NorthTec at the Whangarei campus (a couple of hours north of Auckland). It's the second programming course in their Bachelor of Applied Information Systems degree. We switched the first course from VB to Python a couple of years ago, but left this one as VB (because it's their introduction to Visual Studio and .NET).

    Early last year I started work convincing people that IronPython would be a good choice, since they can continue with a language they (somewhat) know, but still get the intro to the Microsoft toolchain (plus, I hate VB, and dislike teaching in a language I never use in practice). I was expecting that I'd have to continue on without a textbook, until I saw that IronPython in Action was coming out.

    BTW, while it's not like there is much choice in the way of books, yours is an excellent fit. The first section is a good Python refresher and .NET introduction. I introduce unit testing to them in the course, and the book handily has a chapter on that. They do a lot of sysadmin work later in their degree, so the chapter on using IronPython / PowerShell is great. They do ASP.NET stuff later on as well, so that'll be a good reference at that time (I don't expect I'll have time to cover that myself). I introduce them to databases and (since a couple of years ago) web services, and there's a chapter on that. Silverlight is an interesting example, and something I expect they'll be interested in given the later web development work, and there's an introduction to that.

    Basically, you couldn't have done a lot better if I'd commissioned it! Thanks! - it certainly has made redoing the course material much simpler than if I was working completely from scratch.

    As I mentioned in my tweet, I'll put my course material online at some point in the next couple of weeks (it's not quite finished) in case anyone else is interested in it.