Python Programming, news on the Voidspace Python Projects and all things techie.

IronPython Studio: Problems, Victory and Compiled Binaries

After much pain I have finally got IronPython Studio working, fortunately it was worth the effort.

IronPython Studio is an IDE based on the Visual Studio Shell. Visual Studio 2008 allows you to create (and freely distribute) applications built on top of the Visual Studio shell, and IronPython Studio is an 'example' of this - so the source is available to play with if you have the full version of Visual Studio 2008. Whilst I haven't abandoned what I consider to be more featureful Python editors like Wingware's Wing IDE, IronPython studio does have a few tricks up its sleeve that makes it useful for IronPython development.

The first trick, which I didn't appreciate until I got IronPython Studio working properly, is that it produces compiled binaries from IronPython projects. It comes with both WPF and Windows Forms designers which generate Python code. You can either use that code directly or compile the project into an executable.

Last but not least, IronPython Studio has debugger support - including setting break points in IronPython code. As conventional (!?) Python debuggers don't work with IronPython this could come in useful (despite my general antipathy towards debuggers there are times when they are invaluable).

So why did I have such problems getting IronPython Studio working? Partly poor instructions and partly down to the fact that I have had several versions of Visual Studio installed on this XP box (ranging from Visual Studio 2003, through several versions of 2005 and 2005 express up to 2008 betas and 2008 express).

Just in case anyone else has difficulties, here are the problems I had and how I overcame them. (Thanks to the guys - especially corysama - over on the IronPythonStudio forum).

First of all the installation instructions aren't massively clear. The steps you need are:

Download and install the Visual Studio X redistributable from: Visual Studio Extensibility After you run the Install for the MS VS 2008 Shell Isolated Mode Redistributable, you must then go to the folder ("C:VS 2008 Shell RedistIsolated Mode") and click on: "vsshellisolated_enu.exe" to actually install the redistributable runtime. Install IronPython Studio

After doing this I found that attempting to build a project gave me an "Object reference not set to an instance of an object" error (a particularly frustrating and hard to track down exception whenever we have encountered it in Resolver).

The readme that comes with IronPython Studio (which of course I didn't read) actually explains this. You need to register the IronPython CodeDom provider for the compilation to work (as explained by Aaron Marten on the VSX team).

Unfortunately for Windows XP these instructions are just plain wrong (being charitable I assume they are for Vista and they have just forgotten that most people still want to run XP!). The instructions tell you insert the new XML "Under the root <configuration> node" (in machine.config ). Instead you should place it between the <system.web> and <system.serviceModel> nodes. The config XML will look like this:

</providers> </roleManager> </system.web> <system.codedom> <compilers> <compiler language="py;IronPython" ...> </compilers> </system.codedom> <system.serviceModel> <extensions>

By now I had completely screwed my system and even attempting to use the WPF designer gave me the following error:

The Microsoft.VisualStudio.Internal.WPFFlavor.WPFPackage, Microsoft.VisualStudio.WPFFlavor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a ({B3BAE735-386C-4030-8329-EF48EEDA4036}) did not load because of previous errors. For assistance, contact the package vendor. To attempt to load this package again, type 'appenv /resetskippkgs' at the command prompt.

Needless to say appenv doesn't exist, but with a combination of clues and guesswork I figured out that it was referring to the studio executable. Running IronPythonStudio.exe /resetskippkgs restored the designer.

After this I was now getting a really weird error:

Could not load file or assembly 'IronPython, Version=1.1.0.0... or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Now it is failing to load IronPython at all when I attempt to build! It turns out that it has located the IronPython assemblies that were installed along with the Visual Studio 2005 SDK - which were an older version! I haven't actually solved this problem (it must be picking up the location from some environment variable or registry entry set by the VS 2005 SDK), but manually copying the right assemblies into the build directory fixes it and I can design and debug to my heart's content. phew

Interesting Stuff

A mixed bag.

You must read this fantastic review of upgrading from Vista to Windows XP:

It is wonderfully written and ends:

To be honest there is only one conclusion to be made; Microsoft has really outdone themselves in delivering a brand new operating system that really excels in all the areas where Vista was sub-optimal.

An interesting quote from the latest blog entry of Resolver developer Jonathan Hartley:

I'm a firm believer that the winners write history, and have on more than one occasion pondered the lofty ideals of the founding fathers as a superb marketing spin to popularise an act of treason.

Internet Explorer 8 passes the Acid Test 2! (A fairly stringent web standards compliance test.) Firefox doesn't do that (well not sure about version 3, but version 2 doesn't.):

Steve Yegge has posted a long blog entry on why code size is a bad thing (and touting Javascript as the 'Next Big Language' again...):

Most of that entry is a very long winded way of saying 'code is a liability' (which I vehemently agree with). In trying to track down the origin of this phrase I came across this blog entry: Code is a Liability. It starts:

I have thought for a long time that code is liability, and that viewing code as a liability has the power to transform our art.

One of his commentors disagrees and replies with a parody:

I have thought for a long time that legs are liability, and that viewing legs as a liability has the power to transform our gait.

It is hilarious: Sadly, most companies have to deal with heaping, shaggy mounds of legs. [...] They have to be reviewed (hopefully in an efficient way like pairing). [...] Having more legs will typically slow development, and will certainly reduce your ability to walk.

Tim answers in the comments with what I think is a great summary:

I didn't say code was bad. I said it is a liability. By that I mean that it costs, and that the costs recur, and that the costs are proportionate to the volume of the code.

Jeff Attwood also has a great blog entry: The Great Browser JavaScript Showdown.

This makes use of the new WebKit JavaScript benchmark: SunSpider. WebKit is the open source rendering engine behind Safari, and using SunSpider we can (apparently) get a good idea of the comparative performance of JavaScript across browsers. Firefox is worse than you might imagine (I only knock it because I love it)...

In the last two iterations (four weeks) at Resolver, we have completed 32 user stories and defects. I'm pretty sure that this is a record for us and is a sign that the core functionality has solidified. I'm working on the find dialog (not really a dialog though) at the moment. There should be a fresh beta, with some great usability improvements, out very soon.

I had to blog about this video: Bubble 2.0. I'm sure a lot of you have seen it, but if you haven't it is very funny.

Statlib, a Python stats library that has come out of the phenomenally successful Python Project for the Google Highly Open Participation Contest, has changed license. It is now available under the MIT license which means we can (and probably will) use it with Resolver.

Parrot 0.5.1 (the Virtual Machine intended to run Perl 6, but also targeting many other dynamic languages) is now out. The Python for parrot implementation is called 'Pynie' and the release notes include: punie and pynie language implementations using PCT and NQP whatever that means... It sounds like progress but Perl6 is still well behind Python 3...

Speaking of Perl, there was another very interesting post by Jeff Atwood a couple of days ago: Nobody Cares What Your Code Looks Like.

This is a look at the dilemma (and maintenance nightmare) that the Bugzilla team are facing - because their codebase is written in Perl...

Oh and some personal news to finish with. I've just had the mortgage agreement through for my first house. If everything goes well (a big if...) then I will be moving house in January...

Resolver, IronPython and the Python Papers and the One Minute Screencast

Volume 2, Issue 4 of the Python Papers is now out. This has an interview with me about IronPython and IronPython in Action (including an extract from the book).

It also has an interview with Giles Thomas (our CTO and overlord-in-chief) about Resolver Systems. The interview has some interesting facts about our development processes, why Resolver chose Python and how we have found it.

Giles has also put together a new screencast : Resolver explained in one minute

I think he does a good job of capturing the real value of Resolver.

The news that Resolver will be free for Open Source and personal use has been attracting some attention:

Big Resolver News: New Beta, Release Date and Resolver Free for Personal Use

A new Resolver newsletter has just been fired off to all of our beta users, and it contains three pieces of important news. The most important one is:

Resolver One (the desktop client) will be free for personal and open source use!

This is especially good, as even though it was our intention I wasn't sure how quickly we would be able to put this in place. We will also have commercial versions and a version for the financial services industry. We are still working on the pricing model, but being able to make Resolver free for many users is fantastic. You can read the announcement to see that I'm not making this up.

In the same announcement you will read that we have set a date for releasing version 1.0: 15 January 2008. This is scarily close, but as a step towards this goal we have also just released a new beta. Improvements in this beta include:

You can hide columns/rows by dragging their width/height to zero. Double-click them to show them again.

We handle non-DD/MM/YYYY dates correctly.

Fixed Defect 36 - Hitting escape gives invalid text in the formula bar.

Fixed Defect 109 - Cut/Paste and Clear Contents commands do not update formula bar.

Since the Resolver beta went public we've now had more than 1,000 downloads. We've also done a 'more traditional press release' about the release of Resolver: http://www.prleap.com/pr/107089/

There will (almost certainly) be another beta shortly. New features and defect fixes that have been checked in or are nearly ready include:

Currency formatting

A 'check for updates' dialog

Separate scroll position, current cell and selection per worksheet

Defect fix: text formulae are offset when pasted

Defect fix: pasting arrays doesn't offset formulae

Fixed a memory leak (this relates to disposing of old documents and probably isn't an issue for most users but was a problem for our functional test suite that merrily creates a horde of documents)

Printing of worksheets that span multiple pages

Saving of formatting when exporting to excel

Plus several other features and defect fixes that are on the list of 'essentials' before we hit 1.0.

Resolver Tips: Using Compiled Modules and Integration with Google Spreadsheets

Now that Resolver is in the hands of a larger number of people, we are starting to see some interesting use cases and tips and tricks emerge. These are a couple of recent ones:

How to Import Google Spreadsheets into Resolver This example uses the Google Spreadsheet API to import google spreadsheets into Resolver worksheets.

Using Compiled Python With Resolver Using byte-compiled Python code is one way of preventing your end users from tampering with the source code and creating maintenance nightmares. One user wanted to do this with Python modules used by his spreadsheets. This entry walks through using the ability of IronPython 1.1 to create compiled assemblies from Python modules with Resolver spreadsheets.

For more tricks and tips, Resolver Hacks is the place to go of course.

Resolver as XP Pairing Tool

At Resolver Systems we follow the XP practise of pair programming. This has several key benefits, which include:

Higher code quality without the need for code review

Less distracted developers! (even when tired or having an off day)

Much more fun!

Easier to mentor inexperienced developers and integrate new hires (and interns)

Collective code ownership (and distributed knowledge of the code base)

In order to really effectively distribute knowledge of the codebase we swap pairs daily. User stories will be 'owned' by a single developer, but they will pair with a different person each day. This works very well in practise, but can mean that choosing pairs in our stand-up meeting becomes a bit like a popularity contest as we try to work out who will pair with whom...

To remove the awkwardness from this, Christian (one of our two Australian developers) created a simple 'pair-choosing' spreadsheet. Yet another opportunity for us to dog-food Resolver.

Simply enter into the appropriate cell ranges the available developers and the pairs who last worked together, and it will generate a pairing arrangement for today. If there are an odd number of developers it will randomly assign one of them to spiking.

ACCU 2008 Conference: Dynamic Languages on .NET

I've just heard that my talk proposal for ACCU 2008 has been accepted. This is a UK (Oxford) Software development conference that was originally focussed on C/C++, but in recent years has had a rich dynamic languages track. This year dynamic language sessions are 'mainstream', and functional languages are the 'interesting outsiders' with their own track.

In 2007 Mark Shuttleworth was one of the keynote speaker and in 2006 one of the keynote speakers was a certain gentleman, Guido van Rossum.

My talk will be ninety minutes long. As ACCU is a relatively formal conference, this is slightly scary!

However ninety minutes is long enough to get into some real detail, including demonstrating Resolver and showing off the power of Python.

Talk abstract:

IronPython is the first of a new wave of dynamic languages for the .NET framework.

Dynamic languages are gaining in popularity, and with IronPython and the DLR Microsoft are committed to making the CLR a good platform for dynamic languages. Not only this, but they can also be used with the new platform: Silverlight the browser plugin.

Dynamic languages increase developer choice, enable new programming paradigms for the .NET framework, and provide a readymade scripting engine solution for .NET languages.

In this talk I will explore the following talks:

Why dynamic languages?

The story of IronPython and the DLR

IronPython on .NET (interacting with the CLR)

Multiple programming paradigms on .NET (functional, procedural, OOP, metaprogramming)

Dynamic languages on Silverlight

Embedding IronPython in .NET languages

Archives