IronPython URLs

In the latest release of Resolver One we improved startup time by about 20-30%. Most of the startup time in Resolver One is spent in importing Python modules, which is considerably more expensive in IronPython 1 than it is in CPython (even when compiled in binary form). We achieved most of our speedup by delaying the creation of certain objects until they are needed (if ever), and other standard techniques for performance improvement. There is good news for IronPython 2. Binary compilation is much more efficient as we can compile multiple packages into a single binary and then ngen (pre-JIT), making imports faster. Whilst exploring how to improve our startup time Kamil Dworakowski experimented with a system for performing parallel imports on multiple threads. Kamil's Parallel Import Project for IronPython IronPython doesn't have the same import lock as CPython, so you need to ensure that parallel imports don't pull in the same modules simultaneously or some of the impo

Jeff Hardy has been working on getting Django to run on IronPython, or at least that is part of what he has been working on. This includes his project NWSGI : NWSGI is a .NET implementation of the Python WSGI specification using IronPython. It is implemented as an ASP.NET HttpHandler. The main goal is to provide an easy path for running Python web applications/frameworks (such as Django, Trac, etc.) on IIS7. He recently released a new version of NWSGI: NWSGI 0.6 Released This release has some possibly breaking changes and a whole host of new features. There is also an installer available along with the zip archive. New features in this release: The major new feature is IIS7 management integration, including a UI editor. It makes configuring NWSGI a breeze from the command line ( appcmd ) or from the UI. The IIS7 integration is only available through the installer. There is one minor feature addition: wsgi.file_wrapper is now supported for faster file transfers. It uses HttpResponse.

Dave Fugate is an IronPython tester. In the blog entrry he talks about how source code from the Microsoft internal development repositories is synced to the TFS repository on Codeplex . Two Source Code Repositories for IronPython In particular he addresses the issue as to why all the commits to the public repository have the astonishingly helpful checkin message " Latest sources migrated to CodePlex TFS ", rather than actually telling you anything useful about what has changed. He also explains how their processes have changed, enabling them to do code syncs to the public repository more often. (Something that is very useful for us at Resolver Systems as we port Resolver One to IronPython 2. We are using the new source drops daily so that we can pick up problems as quickly as possible.)

Following swiftly on heels of the IronPython 2 RC 2 and DLR 0.9 is a new release of Ironclad. Ironclad is an Open Source project by Resolver Systems , and is an implementation of the Python C API in C#. It allows you to use Python C extensions from IronPython, and our goal is to be able to use Numpy within Resolver One spreadsheets. The latest release is version 0.7 and includes several major advances since the last release. Ironclad 0.7 Release Announcement Download Windows Binaries for Release 0.7 Ironclad Discussion Group Major advances in the release include: Huge chunks of numpy can now be imported and used Lots of the numpy tests now pass (from core, fft, lib, linalg and random subpackages) - the distribution includes a test runner that runs the tests we have enabled so far Major performance improvements (several orders of magnitude faster in some areas) Ironclad works with IronPython 2 RC 2 and it no longer creates a separate Python engine, nor does it break the importing of .N

IronPython 2.0 Release Candidate 2 has just been released. This fixes several bugs identified in RC1 (several of these reported by Resolver Systems as we port Resolver One to run on IronPython 2). Download IronPython 2 RC 2 IronPython 2 RC 2 Release Notes Barring the discovery of any major new bugs, the intention is for IronPython 2 final to be released within 2 weeks! Bugs fixed in this release include: 19350: Missing restrictions on index operation against user defined type 11733: time.timezone has different semantic than in cpython 19675: subclasses of float have trouble with __int__ and __str__ 19656: Module Name Lookup Broken 19678: in operator calls __getitem__ on class that has __len__ and __iter__ defined 19665: operator.isSequenceType(NewStyleClass) broken 19130: One hour error in IPY implementation of time.mktime and time.gmtime Along with this release, the Dynamic Language Runtime has a new home - and a separate release (version 0.9) has been made. The example DL

After a hiatus, the GUI Automation blog continues the series on the automated testing of Windows GUI applications. This entry uses the Win32 API to interact with a list box. As usual source code is provided for download: Building the Framework (3) In the entry Lukas makes an important point about any testing framework: We do not test the list box component. We test the application. When testing an application you don't need to test the functionality provided by the operating system or the frameworks you're using; you test your application logic. Example code for selecting an item in a list box from the application under test (is SUT for "System Under Test" a commonly used acronym?): def Select(self, aItem): """ select an item from list box @aItem - string with item to select """ if aItem not in self.items: raise Exception("Item '%s' not in list box" % aItem) self.guiat.Activate() self._CheckVisibility()

More IronPython and DLR related stuff collected over the last few weeks. IronPython en Mandriva 2009 This looks like a very interesting blog entry, and the only reason it is here rather than having a post to itself is that it is in Spanish and so I can't tell you much about what it says... It is by Jacobnix and about using IronPython with Mandriva Linux and Mono. PATCH: System.Type.FindMembers return type PATCH: System.IO.TextReader.Null implementation Two patches to Mono (by Bill Holmes) allowing you to compile and use recent versions of IronPython 2. This is great news as the version of IronPython 2 included with Mono (from FePy ) is 2.0 alpha 5 - which is pretty out of date now. IronPython Cookbook: XML Settings File IronPython Cookbook: Reading Eventlogs Two new recipes in the IronPython Cookbook (both by Davy Mitchell I believe). Accessing mssql with Python or IronPython This StackOverflow question yielded several answers, including this example IronPython code for working wit

My backlog includes a lot of interesting snippets and blog entries that probably don't warrant a whole entry to themselves. There's a lot of good stuff in them, so I'm splitting them out into two separate entries. Calling IronPython Functions from C# A blog entry on using the IronPython 1 hosting API to call functions - including embedding it in ASP.NET pages. Microsoft Announces Windows HPC Server 2008 Windows High Performance Computing Goes Mainstream This happened a while ago, but I missed it. Windows High Performance Computing Operating System is out (HPC Server 2008) - and it includes IronPython 'out of the box'! " To tempt Unix users and coders in scientific programming languages, there is a built-in POSIX shell, support for IronPython, IronRuby and Fortran. Microsoft is also developing new tools such as the F# programming language and .NET Parallel Extensions. " " Much of the legacy code that developers may need to support is Linux-based, he sa

The dynamic languages team at Microsoft are relatively small, but have an extremely high proportion of bloggers! (The obvious conclusion is that dynamic language enthusiasts tend to be better communicators...) Oleg Tkachenko lists them on his blog: The Microsoft Dynamic Languages Team Blogroll For the record, they are: John Lam – IronRuby PM Harry Pierson – IronPython PM Jimmy Schementi – PM for Silverlight integration Shri Borde – dev lead for the team Dave Remy – PM lead fro the team Oleg Tkachenko – Visual Studio integration Dave Fugate – IronPython tester Curt Hagenlocher - IronPython/IronRuby dev Jim Hugunin – architect for the team, DLR and Visual Studio languages Tomas Matousek – IronRuby dev Srivatsn Narayanan – IronPython/IronRuby tester Jim Deville – IronRuby tester Dino Viehland – IronPython dev We're trying to keep track of them on the People in IronPython page of the IronPython Cookbook.

Well my backlog is logged so far back that I haven't even blogged about the final release of Silverlight 2 . In case you've been living under a rock for the last year, Silverlight 2 is a browser plugin from Microsoft. It is similar to Flash (aimed at games, media streaming and rich internet applications) and is cross-platform (Mac OS X and Windows - the officially blessed Linux port Moonlight by the Mono guys is making good progress though) and cross browser (IE 7+, Safari & Firefox 2+). Unlike Flash it can be programmed with a choice of languages, and through the Dynamic Language Runtime it can be programmed in Python, Ruby and Javascript. Silverlight 2 final is now out, and according to Scott Guthrie has now been installed on over 100 million consumer computers. Naturally Jimmy Schementi, who maintains the Dynamic Language Support for Silverlight, released an updated version of the Silverlight Dynamic Languages SDK (sucky name - more on this in a bit): Dynamic Languages

Saveen Reddy has posted examples of automating Visio from three different languages - C#, F#, IronPython. The code samples are short, and remarkably similar. The examples all do the same thing: launch Visio 2007, create a new doc, and draw a rectangle with the text “Hello World” . Visio Automation: Three Hello World Samples – C#, F#, and IronPython The IronPython is: import sys import clr import System clr.AddReference("Microsoft.Office.Interop.Visio") import Microsoft.Office.Interop.Visio IVisio = Microsoft.Office.Interop.Visio visapp = IVisio.ApplicationClass() doc = visapp.Documents.Add("") page = visapp.ActivePage shape = page.DrawRectangle(1, 1, 5, 4) shape.Text = "Hello World"

i-Dialogue now supports scripting with Python through IronPython. iDialogue is an SaS (Software-as-Service) system integrated with the Salesforce CRM. They call it a 'Customer Experience Management' system (marketing tools). i-Dialogue Now Supports Python Basic Python Demonstration Mike Leach was new to Python, and he likes it: After only a few days of playing with Python, I see now what others have been raving about. Web developers will really enjoy using Python with Dialogue Script: Cleaner code. Easier to read and manage No need for thick IDEs. Too often, an IDE like Eclipse or Visual Studio stands between you and the desired solution. Dialogue Script development is 100% browser-based (yes, it even works in Chrome!) Agile business rules management. Work side-by-side with business users and apply business rules directly in web pages Dynamic typing

Kevin Hazzard presented at the Philly Code Camp about mixing DLR (Dynamic Language Runtime) based languages with statically typed languages like C#. Mixing Static and Dynamic Languages for Philly Code Camp " The gist of this presentation is that it's possible to mix the Dynamic Language Runtime (DLR) into statically-typed, early-bound languages like C# to make them much more flexible. In this talk, I demonstrated how a ShoppingCart being filled with Products can adjust discount rates based on marketing rules written in an external Domain Specific Language (DSL). In this case, my DSL was really just Python. I chose to use Python because the syntax is so simple and clean. It's so light, it doesn't get in the way. It's not a real DSL, of course, but by injecting .NET objects into a ScriptScope on a ScriptRuntime (all DLR hosting terms), the Python syntax acting on those injected types looks an awful lot like a language for managing product discounts. " Slides and

A Japanese blogger shows off how to use the GeckoFX (Firefox) Windows Forms WebBrowser control from IronPython. This allows you to embed webpages in Windows Forms applications using the Gecko rendering engine. GeckoFX WebBrowser Control from IronPython The example code uses the winforms sample that comes with IronPython: import sys sys.path.append("(IronPythonTutorial") import winforms from System.Windows.Forms import * f = Form() f.Text = "GeckoFX" f.Show() import clr clr.AddReference("Skybound.Gecko.dll") from Skybound.Gecko import * Xpcom.Initialize("(Firefox 3") browser = GeckoWebBrowser() browser.Parent = f browser.Dock = DockStyle.Fill browser.Navigate("about:robots")

An example of uploading a file to a website from IronPython: Uploading a File with IronPython This is an example of a class in IronPython that can upload a file to a web site. This is a port from a codeplex example (except without cookies...but the addition should be trivial). It uses the WebRequest class. Points to note are: 1) the parameter query_string is of type NameValueCollection , 2) the parameter url must be a valid URI (e.g. www.somewebsite.com/somepage), 3) the parameter content_type can be 'multipart/form-data'.

The Scientific C# blog looks at using another "mature open source cheminformatics api" from C# and IronPython: The java Chemistry Development Kit . Using the CDK with the .NET Framework and Mono As it is a Java library, using it from .NET is a novel idea... The blog entry shows you how to compile the library for .NET using IKVM , an implementation of Java for .NET. The command line magic to compile CDK for .NET is: ikvmc -assembly:cdk_dotnet -target:library yourcdkjar.jar This produces a .NET assembly. An example of using the library from IronPython: import clr clr.AddReference("cdk_dotnet.dll") clr.AddReference("IKVM.OpenJDK.ClassLibrary.dll") from org.openscience.cdk import Molecule from org.openscience.cdk.smiles import SmilesParser #import the whole package for brevity from org.openscience.cdk.qsar.descriptors.molecular import * from org.openscience.cdk.qsar.result import DoubleResult tpsa = TPSADescriptor() logP = XLogPDescriptor() smiles = SmilesPars

My boss has a blog ! Even better, he's actually writing entries occasionally. He recently answered a question on the Joel on Software discussion board about whether or not a new company should consider using IronPython: Why Use IronPython? He cites the advantages of IronPython as: All of the .NET libraries are available. UIs look nice. I’ve never seen a pure traditional Python application that looked good, no matter how advanced its functionality. We use a bunch of third-party components - for example, Syncfusion’s Essential Grid - without any problems. Reasonably decent multithreading using the .NET libraries - CPython, the normal Python implementation, has the problem of the Global Interpreter Lock, an implementation choice that makes multithreading dodgy at best. We can build our GUI in Visual Studio, and then generate C# classes for each dialog, and then subclass them from IronPython to add behaviour. (We never need to look at the generated code.) When things go wrong, the CL

I've published series of articles on the functional testing of GUI applications. It is based on a talk that I gave at PyCon UK . Functional Testing of Desktop Applications The user interface toolkit used for the examples is Windows Forms driven from IronPython. The examples are available for download, and test a small program called "MultiDoc", the example application from chapters 4-7 of IronPython in Action . The techniques and testing patterns used in the articles are not tied to IronPython at all. The topics and principles discussed are relevant to the testing of all desktop applications, whichever framework you are using (almost...). Topics covered include: The why and how of functional testing - including the processes and infrastructure you need around them Basic principles of practical testing Common problems and ways to overcome them