There have been a few new projects using IronPython announced recently, plus Seo has been working on getting Ironclad to run on Mono.
Ironclad
Ironclad is a project to get Python C extensions working with IronPython. Although the project was created with a cross-platform implementation in mind, it is currently Windows only. Seo Sanghyeon has just posted the start of a patch for Mono compatibility to the Ironclad mailing list. He is hoping that the Mono port will pass the Ironclad test suite within a week.
sysevlog.py
More of a script than a project, but still cool. It receives Unix syslog packets and store them as Windows eventlog - in 44 lines of IronPython.
mysecs
Joseph Jude has started an IronPython project called 'mysecs' to track how much time he spends in different applications. It is a desktop and web web applications to "measure/analyse time spent in a day":
ryPDF Report Tools
Ryan wrote a Python PDF report generation tool in Python (and then lost the source code!). He needed something similar to use from VB.NET, so he rewrote it in IronPython.
richbrowser
This project has been around for a while, but I've never posted about it. It is a "Rich Browser Platform" that provides an extensible "tabbed web browser by default and plugin architecture". There are no releases made but you can checkout from the subversion repository. Although the project is written in C#, the '0.3' code supports IronPython.
Sunday, August 31, 2008
Silverlight Dynamic Languages SDK 0.3 Released
adodbapi 2.2 ready for IronPython
Vernon Cole announced that with the release of adodbapi version 2.2, it will now run with either IronPython 2.0 or CPython. adodbapi makes it easy to use Microsoft ADO for connecting with databases and other data sources.
You can get it at http://sourceforge.net/projects/adodbapi.
You can get it at http://sourceforge.net/projects/adodbapi.
Saturday, August 30, 2008
NVidia FX Composer 2.5: Scripted with IronPython
This is old news, but something that I've only just discovered. NVidia FX Composer 2.5 is scripted with IronPython. FX Composer 2.5 (Windows only I guess) is a "powerful integrated development environment for shader authoring".
The home page has screenshots and more details:
From the FX Composer User Guide (PDF):
"Scripting in FX Composer is typically accomplished using the Python scripting language. The implementation of Python used is IronPython 1 from Microsoft. IronPython supports all of the standard python syntax & library, with the additional advantage that it is implemented in a .NET language. This means that python scripting in FX Composer can call the rest of the FX Composer engine without additional work. It is important to note that none of the core functionality of FX Composer requires Python. The scripting is implemented entirely using a plugin (FXComposer.UI.Python), and in theory any scripting language that could communicate with the FX Composer engine could be used."
The user guide contains details of the FXComposer namespaces and examples of scripting with Python (including hooking into editor functionality like Undo/Redo and creating graphics objects like a torus).
The home page has screenshots and more details:
From the FX Composer User Guide (PDF):
"Scripting in FX Composer is typically accomplished using the Python scripting language. The implementation of Python used is IronPython 1 from Microsoft. IronPython supports all of the standard python syntax & library, with the additional advantage that it is implemented in a .NET language. This means that python scripting in FX Composer can call the rest of the FX Composer engine without additional work. It is important to note that none of the core functionality of FX Composer requires Python. The scripting is implemented entirely using a plugin (FXComposer.UI.Python), and in theory any scripting language that could communicate with the FX Composer engine could be used."
The user guide contains details of the FXComposer namespaces and examples of scripting with Python (including hooking into editor functionality like Undo/Redo and creating graphics objects like a torus).
Measuring IronPython Performance Part III
Dave Fugate has written part 3 of his guide to measuring IronPython performance. In this entry he discusses things that can affect performance - not just different versions of .NET, but even security patches (!) can make a difference.
Interestingly, due to practical limitations, the dynamic languages team only test on various configurations of Vista. This is despite the fact that, however much Microsoft wishes otherwise, most of their customers are still going to be using it with Windows XP...
Vista comes with .NET 3 as standard - but IronPython itself only depends on .NET 2 (with Visual Studio 2008 you can set the version of .NET you are targeting when you compile). Specifically, IronPython 2 depends on .NET 2 SP1,which is actually more recent than .NET 3 - Service Pack 1 came out in November 2007.
At Resolver Systems we are selling Resolver One into financial organisations, some of whom are technologically conservative, so it is possible that the requirement for .NET 2.0 SP1 will affect our ability to move to IronPython 2. As IronPython 2 is still in beta it is something we haven't yet evaluated (although we have ported Resolver One to IronPython 2 to test there would be no major problems when we do make the change).
On the other hand, the .NET 2 service pack did fix some bugs on the Common Language Runtime (which is why IronPython depends on it). For example, it means that running IronPython code in an AppDomain with reduced privileges now works.
From the article:
As a concrete example, the following measurements were taken from a single 32-bit Vista machine under .NET 3.5 and .NET 3.5 SP1:
The moral of this story is to always include every machine setup detail you can think of when reporting performance results. Some things you might not expect to impact performance actually do.
Interestingly, due to practical limitations, the dynamic languages team only test on various configurations of Vista. This is despite the fact that, however much Microsoft wishes otherwise, most of their customers are still going to be using it with Windows XP...
Vista comes with .NET 3 as standard - but IronPython itself only depends on .NET 2 (with Visual Studio 2008 you can set the version of .NET you are targeting when you compile). Specifically, IronPython 2 depends on .NET 2 SP1,which is actually more recent than .NET 3 - Service Pack 1 came out in November 2007.
At Resolver Systems we are selling Resolver One into financial organisations, some of whom are technologically conservative, so it is possible that the requirement for .NET 2.0 SP1 will affect our ability to move to IronPython 2. As IronPython 2 is still in beta it is something we haven't yet evaluated (although we have ported Resolver One to IronPython 2 to test there would be no major problems when we do make the change).
On the other hand, the .NET 2 service pack did fix some bugs on the Common Language Runtime (which is why IronPython depends on it). For example, it means that running IronPython code in an AppDomain with reduced privileges now works.
From the article:
As a concrete example, the following measurements were taken from a single 32-bit Vista machine under .NET 3.5 and .NET 3.5 SP1:
- float comparisons were 37% faster under .NET 3.5 SP1
- nested for loops were 30% faster under .NET 3.5 SP1
- method invocations slowed down 26% under .NET 3.5 SP1
The moral of this story is to always include every machine setup detail you can think of when reporting performance results. Some things you might not expect to impact performance actually do.
Friday, August 29, 2008
IronPython on ASP.NET
A Zope programmer is attending an introduction to ASP.NET course. He does what any self-respecting Python programmer would do - and gets IronPython running with it. This blog entry creates a simple page using an 'aspx' view page, with the code behind in Python:
ADO.NET with IronPython for ASP.NET
The ARtyProg has posted an example of working with databases (specifically using ADO.NET) with IronPython and ASP.NET. The blog entry is little more than a big code example, but if you're looking for an example of ADO.NET or are getting started with ASP.NET for IronPython it should be useful:
It's good to see some blog entries of people using IronPython with ASP.NET (Christian has written a great chapter about it in IronPython in Action of course). Personally I feel ambivalent about ASP.NET. Its 'page-by-page' model seems to be fine for simple forms, but not a very good way of creating applications. ASP.NET MVC looks worlds better (Rails and Django even more so of course).
On the other hand ASP.NET is massively used (possibly the most widely used web development framework), and people aren't going to switch over to ASP.NET MVC in any great proportion for probably years to come. If they're going to use ASP.NET then they might as well at least use IronPython.
Although ASP.NET standard is still 'supported' (the MVC framework is still in beta), and probably will be for some time to come, Microsoft have been focusing their dynamic language integration on MVC and have been 'quiet' about development of the current IronPython integration into ASP. If more people are vocal about using it this could encourage them to be a bit more public about their plans.
It's good to see some blog entries of people using IronPython with ASP.NET (Christian has written a great chapter about it in IronPython in Action of course). Personally I feel ambivalent about ASP.NET. Its 'page-by-page' model seems to be fine for simple forms, but not a very good way of creating applications. ASP.NET MVC looks worlds better (Rails and Django even more so of course).
On the other hand ASP.NET is massively used (possibly the most widely used web development framework), and people aren't going to switch over to ASP.NET MVC in any great proportion for probably years to come. If they're going to use ASP.NET then they might as well at least use IronPython.
Although ASP.NET standard is still 'supported' (the MVC framework is still in beta), and probably will be for some time to come, Microsoft have been focusing their dynamic language integration on MVC and have been 'quiet' about development of the current IronPython integration into ASP. If more people are vocal about using it this could encourage them to be a bit more public about their plans.
RemLog: Back to Microsoft
Dave Remy blogs about his return to Microsoft - as lead program manager for the GO team (which includes languages like F# and IronPython).
"I had an informal meeting with Drew and, what do you know, the Visual Studio Languages Unit has a team called the “Growth Opportunities” (GO) team that is responsible for IronRuby, IronPython and emerging languages. They needed a Lead Program Manager. I took the position and now I am working on a truly great team with folks like John Lam (the face of IronRuby), Harry Pierson (DevHawk blogger, IronPython PM), Jimmy Schmenti (Dynamic languages PM, wrote the Silverline plugin), Tomas Matousek (most awesome IronRuby developer), Dino Viehland (most awesome IronPython developer), Jim Deville (IronRuby QA), Curt Hagenlocher (both IronPython and IronRuby developer), Jim Hugunin (Dynamic Language Runtime and IronPython Architect), Bill Chiles (Dynamic Language Runtime Program Manager) and many, many more."
(Via DevHawk)
"I had an informal meeting with Drew and, what do you know, the Visual Studio Languages Unit has a team called the “Growth Opportunities” (GO) team that is responsible for IronRuby, IronPython and emerging languages. They needed a Lead Program Manager. I took the position and now I am working on a truly great team with folks like John Lam (the face of IronRuby), Harry Pierson (DevHawk blogger, IronPython PM), Jimmy Schmenti (Dynamic languages PM, wrote the Silverline plugin), Tomas Matousek (most awesome IronRuby developer), Dino Viehland (most awesome IronPython developer), Jim Deville (IronRuby QA), Curt Hagenlocher (both IronPython and IronRuby developer), Jim Hugunin (Dynamic Language Runtime and IronPython Architect), Bill Chiles (Dynamic Language Runtime Program Manager) and many, many more."
(Via DevHawk)
Thursday, August 28, 2008
IronPython and Windows Workflow Foundation
Maurice de Beijer has a second example of embedding IronPython in VB.NET, this time with the goal of using it with Windows Workflow Foundation. Specifically he is using it with the workflow runtime services.
His examples are built on IronPython 2.0 Beta 4 and are available for download.
His examples are built on IronPython 2.0 Beta 4 and are available for download.
ViewModel Pattern extended with the Dynamic Language Runtime
Nikhil Kothari has been exploring design patterns for Silverlight applications. He ended up with verbose XAML and nearly recreating his own expression language. He solved this problem by embedding the Dynamic Language Runtime in his Silverlight application - with an 'InvokeScript' action that he could use with a dynamic language (in his case managed JScript) to simplify his view-model pattern.
"In my last post, I posted an implementation of the ViewModel or M-V-VM pattern for use in Silverlight applications. This pattern allows you to decouple your view presentation logic and data from the view, thereby facilitating independent development/design of your app as well as easier unit testing of your application code."
(Via DevHawk.)
"In my last post, I posted an implementation of the ViewModel or M-V-VM pattern for use in Silverlight applications. This pattern allows you to decouple your view presentation logic and data from the view, thereby facilitating independent development/design of your app as well as easier unit testing of your application code."
"I realized the Dynamic Language Runtime (DLR) would be a perfect fit. It is just the right designer-friendly glue that can be used to call into the bulk of the logic that is itself developed using statically compiled code that exists in the view model and the rest of the app. I could scope the use of the script down to a minimum by hosting the DLR to execute just script expressions. The DLR would also give me the benefit of using something like JavaScript, and potentially on any another scripting engine created to run on the DLR."
His blog entry has an example project to download and experiment with.(Via DevHawk.)
Wednesday, August 27, 2008
Easy Install on IronPython
Jeff Hardy (the NSWGI and Django on IronPython) has been trying to get easy install running with IronPython (2 beta 4).
He includes instructions which will get you as far as easy install downloading an egg and then failing to decompress it because of an incomplete zlib implementation (using the partial implementation that comes with FePy).
"setuptools is a critical piece of the Python ecosystem: it extends distutils, but more importantly it provides easy_install, which is used by almost every Python library and application to handle installation. Making easy_install work in IronPython would make it far easier to download and install Python libraries."
"The good news is that it's not too hard to get going; there are only a couple of bugs that need to be worked around. The bad news is that it can't work with any of the files that are downloaded, as the zlib module is shot."
I wonder if zlib would work with Ironclad? The Bz2 module already works with Ironclad.
He includes instructions which will get you as far as easy install downloading an egg and then failing to decompress it because of an incomplete zlib implementation (using the partial implementation that comes with FePy).
"setuptools is a critical piece of the Python ecosystem: it extends distutils, but more importantly it provides easy_install, which is used by almost every Python library and application to handle installation. Making easy_install work in IronPython would make it far easier to download and install Python libraries."
"The good news is that it's not too hard to get going; there are only a couple of bugs that need to be worked around. The bad news is that it can't work with any of the files that are downloaded, as the zlib module is shot."
I wonder if zlib would work with Ironclad? The Bz2 module already works with Ironclad.
Ironclad 0.5 Released - Use numpy from IronPython
Ironclad is an Open Source project created by Resolver Systems to allow you to use Python C extensions from IronPython. It is basically a reimplementation of the Python C API in C#.
William Reade, the main developer of Ironclad, has just announced the release of version 0.5.
There is still a lot of work to do, but this is great progress.
From the announcement:
Ironclad targets IronPython 2 and although the underlying techniques should be cross-platform it currently only builds on Windows. Mono / Linux hackers welcomed!
UPDATE: It turns out that _unicodesize is no longer used, and in response to us asking what it is for it has now been removed...
William Reade, the main developer of Ironclad, has just announced the release of version 0.5.
- Ironclad 0.5 Announcement
- Ironclad Project Homepage
- Download Ironclad Source and Windows Binaries
- Ironclad Mailing List
There is still a lot of work to do, but this is great progress.
From the announcement:
Our original goal for 0.5 was to import numpy, from IronPython, and do something with it. With one monstrous caveat, we have reached that goal; the problem is that you need to comment out line 532 of numpy.core.numerictypes.py before it'll import. That line reads "_unicodesize = array('u','U1').itemsize", and fails trying to construct a unicode array; however, since _unicodesize appears to be unreferenced, we feel reasonably comfortable ignoring it for now.
Once numpy is imported, you can create integer arrays and do a few things with them; of course, the number of things you can do is still dwarfed by the number of things you can't do. You can add, subtract and multiply integer arrays, and raise them to integer powers... and that's about it.
Ironclad targets IronPython 2 and although the underlying techniques should be cross-platform it currently only builds on Windows. Mono / Linux hackers welcomed!
UPDATE: It turns out that _unicodesize is no longer used, and in response to us asking what it is for it has now been removed...
Django on Jython, Python Implementations and Performance
Python is now in a very healthy position, with several major implementations: CPython, Jython, IronPython and PyPy. Python itself is very loosely specified (can anyone point me to the documentation for the __reversed__ method for example?). The specification is partly in the documentation and partly in CPython, which is called the 'reference implementation'.
This blog entry is about the different implementations of Python, which parts of Python are specification and which are implementation details and what it means to talk about the performance of Python in the light of the different implementations.
UPDATE: It turns out that documentation for __reversed__ was added to the Python 2.6 docs in January. However it (currently) incorrectly states that it is new in 2.6 when it was in fact new in Python 2.4.
This blog entry is about the different implementations of Python, which parts of Python are specification and which are implementation details and what it means to talk about the performance of Python in the light of the different implementations.
UPDATE: It turns out that documentation for __reversed__ was added to the Python 2.6 docs in January. However it (currently) incorrectly states that it is new in 2.6 when it was in fact new in Python 2.4.
Tuesday, August 26, 2008
Introduction to XAML and WPF with IronPython : Part Four
After a long break Davy Mitchell continues his tutorial series on using WPF (the Windows Presentation Foundation UI library - new in .NET 3) from IronPython.
This fourth entry creates a user interface with a stack panel, listbox and button. It creates the UI at runtime by reading in the XAML (an XML dialect for describing WPF UIs) and then hooking up the event handlers.
This fourth entry creates a user interface with a stack panel, listbox and button. It creates the UI at runtime by reading in the XAML (an XML dialect for describing WPF UIs) and then hooking up the event handlers.
- Introduction to XAML and WPF with IronPython : Part Four
- Blog entry with links to all four parts of the tutorial
Introducing IronPython: Code Magazine Article
Code Magazine has published an article on IronPython by the IronPython Program Manager: Harry Pierson.
The article is an introduction to Python and IronPython, including the history of IronPython and some examples of Python. It is aimed at C# and VB.NET developers.
Unfortunately the second page of the article is behind a paywall, but it looks like a great article if you have access.
Some highlights.
On block structure by indentation (lightweight syntax - nice):
"Python’s significant whitespace is one of those things developers tend to either love or hate. However, the use of significant whitespace does appear to becoming more popular. Both Boo and Cobra, two open source .NET languages, use a Python-inspired syntax, including significant whitespace. Furthermore, Microsoft’s new F# language includes an optional lightweight syntax mode that makes indentation significant, just like Python."
On dynamic typing:
"In any system of significant scale, there are essentially an infinite number of ways the application can be wrong. Type safe languages eliminate one of this infinite number of ways. The overwhelming majority of errors and bugs you might make when developing your system won’t be caught by a static type language compiler. If they could, then any application that compiled would automatically be bug free! You need some other mechanism to catch these other errors, typically automated unit tests. So while it’s true that static types do provide a safety net, it’s just not a very big one."
The article is an introduction to Python and IronPython, including the history of IronPython and some examples of Python. It is aimed at C# and VB.NET developers.
Unfortunately the second page of the article is behind a paywall, but it looks like a great article if you have access.
Some highlights.
On block structure by indentation (lightweight syntax - nice):
"Python’s significant whitespace is one of those things developers tend to either love or hate. However, the use of significant whitespace does appear to becoming more popular. Both Boo and Cobra, two open source .NET languages, use a Python-inspired syntax, including significant whitespace. Furthermore, Microsoft’s new F# language includes an optional lightweight syntax mode that makes indentation significant, just like Python."
On dynamic typing:
"In any system of significant scale, there are essentially an infinite number of ways the application can be wrong. Type safe languages eliminate one of this infinite number of ways. The overwhelming majority of errors and bugs you might make when developing your system won’t be caught by a static type language compiler. If they could, then any application that compiled would automatically be bug free! You need some other mechanism to catch these other errors, typically automated unit tests. So while it’s true that static types do provide a safety net, it’s just not a very big one."
Dave's Ramblings: Dave Fugate on Testing IronPython Performance
Dave Fugate is a tester on the IronPython team. The IronPython team has recently done some great work on IronPython 2 performance improvements and Dave has started blogging on how they measure IronPython performance.
His initial blog entry introduces himself and what he does (plus IronPython related topics he intends to blog about):
He has a two part blog entry on how they measure performance (the hardware infrastructure) and the results over time comparing 32bit to 64bit OSes.
Every checkin triggers a benchmark run that takes over six hours (running a combination of PyBench, PyStone and custom microbenchmarks) on custom OS install.
The second part compares performance (both PyStone and PyBench) for two identical machines - one running 32bit Vista and the other running 64bit Vista. Interestingly performance is worse for x64 architecture than it is for x86.
His initial blog entry introduces himself and what he does (plus IronPython related topics he intends to blog about):
He has a two part blog entry on how they measure performance (the hardware infrastructure) and the results over time comparing 32bit to 64bit OSes.
Every checkin triggers a benchmark run that takes over six hours (running a combination of PyBench, PyStone and custom microbenchmarks) on custom OS install.
The second part compares performance (both PyStone and PyBench) for two identical machines - one running 32bit Vista and the other running 64bit Vista. Interestingly performance is worse for x64 architecture than it is for x86.
IronPython 2 Integration in the SharpDevelop IDE
Matt Ward has integrated IronPython 2 Beta 4 into SharpDevelop 3. SharpDevelop is an open source IDE for .NET on Windows.
As IronPython 2 has reduced Code DOM support, the Windows Forms designer and code conversion (C# / VB.NET to Python) is currently disabled. Using the forms designer to create forms in C# and then using them from IronPython is easy though.
As IronPython 2 now supports static compilation, SharpDevelop can compile IronPython projects into executables or assemblies. SharpDevelop also has an IronPython console.
As IronPython 2 has reduced Code DOM support, the Windows Forms designer and code conversion (C# / VB.NET to Python) is currently disabled. Using the forms designer to create forms in C# and then using them from IronPython is easy though.
As IronPython 2 now supports static compilation, SharpDevelop can compile IronPython projects into executables or assemblies. SharpDevelop also has an IronPython console.
Monday, August 25, 2008
DLR Hosting API : Dynamic Variable Lookup with Embedded IronPython
The IronPython (and Dynamic Language Runtime) hosting API has been designed from the beginning to make embedding IronPython into other applications easy. It has some interesting capabilities to this end.
One of the basic classes in the hosting API is the ScriptScope. These represent module namespaces, and where name lookups from inside the Python engine are done. As well as creating and manipulating standard namespaces, they can be created with a 'backing store' that allows you to customize name lookup.
The DLR Hosting API blog shows how to use this technique to chain scopes and create a 'pseudo heirarchy'.
The hosting API can be used from .NET languages like C# and VB.NET, but it can also be used from IronPython to customize code execution in a hosted engine.
One of the basic classes in the hosting API is the ScriptScope. These represent module namespaces, and where name lookups from inside the Python engine are done. As well as creating and manipulating standard namespaces, they can be created with a 'backing store' that allows you to customize name lookup.
The DLR Hosting API blog shows how to use this technique to chain scopes and create a 'pseudo heirarchy'.
The hosting API can be used from .NET languages like C# and VB.NET, but it can also be used from IronPython to customize code execution in a hosted engine.
ASP.NET: Dynamically Creating Objects and Binding them to a Form
A new post from the IronPython Resource blog on using IronPython with ASP.NET. This blog entry focusses on the easy creation of forms with data binding. The technique used is based on an article for C# that uses reflection. Of course with the introspection capabilities of Python, there is no need for the reflection.
The example project is available for download and is easy to extend.
The example project is available for download and is easy to extend.
Saturday, August 16, 2008
Calling IronPython Functions from VB.NET
Maurice de Beijer is a VB.NET developer from the Netherlands. He has a particular interest in the Workflow Foundation and is interested in exploring it from IronPython. He has started his exploration by looking at creating Python functions and using them from VB.NET via the IronPython hosting API. As most examples of embedding IronPython are in C#, it is nice to see some examples in Visual Basic.NET.
He shows several code examples and is using IronPython 2.0 Beta 3. His code creates a class from VB.NET and then imports this into Python code. The Python subclasses the VB.NET class, and he can then pull this class out of the IronPython execution scope because he knows what type it is.
This is one of the ways of solving the 'type problem' when working with dynamic languages from statically typed languages like C# and VB.NET. Using dynamic operations exposed by the IronPython runtime you can then create instance of this Python class. It's actually easier than I made it sound; Maurice's example is very clear.
He shows several code examples and is using IronPython 2.0 Beta 3. His code creates a class from VB.NET and then imports this into Python code. The Python subclasses the VB.NET class, and he can then pull this class out of the IronPython execution scope because he knows what type it is.
This is one of the ways of solving the 'type problem' when working with dynamic languages from statically typed languages like C# and VB.NET. Using dynamic operations exposed by the IronPython runtime you can then create instance of this Python class. It's actually easier than I made it sound; Maurice's example is very clear.
ASP.NET: Beginning IronPython - Creating an Update Form (Part 4)
Part 4 of the IronPython on ASP.NET tutorial is out. This one works with the databases and Python classes from the previous tutorials, and creates a form along with the machinery to receive form submissions from the user. As always the code is available to download:
"In the next tutorial, we'll look at some dynamic features of Python to reduce code and decrease the time it takes to create a form. You can download both the IronPython and C# source codes below."
"In the next tutorial, we'll look at some dynamic features of Python to reduce code and decrease the time it takes to create a form. You can download both the IronPython and C# source codes below."
Thursday, August 14, 2008
Viewing Emitted IL
IronPython is a Python compiler. This means that it compiles Python sourcecode into IL (Intermediate Language), the bytecode of the Common Language Runtime. (Although that bytecode is interpreted, like the CPython compiled bytecode, .NET languages are typically called compiled languages because the IL can be compiled to native code by the .NET JIT compiler.) This IL remains heavily dependent on the main IronPython assemblies (and Dynamic Language Runtime assemblies in the case of IronPython 2) in order to implement the highly dynamic semantics of Python - but it is still compiled IL that is running.
This is done using the .NET 'Reflection.Emit' API to generate the IL (and the lack of this API in .NET Compact Framework is why we can't run IronPython code on the XBox 360 or Windows Mobile devices). It also means that you can use standard .NET debugging tools like 'windbg.exe' to introspect and debug your IronPython code in memory.
In his latest blog entry Curt Hagenlocher takes us through some of the techniques to do just this using a 'noninvasive debugging' technique:
This is done using the .NET 'Reflection.Emit' API to generate the IL (and the lack of this API in .NET Compact Framework is why we can't run IronPython code on the XBox 360 or Windows Mobile devices). It also means that you can use standard .NET debugging tools like 'windbg.exe' to introspect and debug your IronPython code in memory.
In his latest blog entry Curt Hagenlocher takes us through some of the techniques to do just this using a 'noninvasive debugging' technique:
Dynamic Languages on the CLR
For those of you who may have only recently realised that there are several dynamic languages that run on the Common Language Runtime, this article by Robert Sundstrom gives a nice overview. It covers the Dynamic Language Runtime (along with its two main languages IronPython and IronRuby) plus Silverlight. It also includes details of Phalanger, a .NET implementation of PHP that started as a students project at a Czech university and doesn't *yet* use the DLR.
"There are a lot of compilers out there and the number is increasing. This has been very interesting in the last few years because of the development frameworks, which has removed the borders between machine architectures. One of those frameworks is the .NET framework, which is Microsofts own competitor to other frameworks like the Java Platform. The .NET framework was designed to support multiple languages and let them co-exist as equal languages on the same platform sharing the same class and runtime library. There has been a lot of talk about dynamic languages on the CLR (the runtime engine of the .NET framework)."
UPDATE: One of the original Phalanger devs was Tomas Matousek who is now one of the main IronRuby developers. (Thanks to Curt Hagenlocher.)
"There are a lot of compilers out there and the number is increasing. This has been very interesting in the last few years because of the development frameworks, which has removed the borders between machine architectures. One of those frameworks is the .NET framework, which is Microsofts own competitor to other frameworks like the Java Platform. The .NET framework was designed to support multiple languages and let them co-exist as equal languages on the same platform sharing the same class and runtime library. There has been a lot of talk about dynamic languages on the CLR (the runtime engine of the .NET framework)."
UPDATE: One of the original Phalanger devs was Tomas Matousek who is now one of the main IronRuby developers. (Thanks to Curt Hagenlocher.)
Tuesday, August 12, 2008
Beginning IronPython - Creating a class (Part 3)
ASP.NET IronPython Resource continues the IronPython and ASP.NET tutorial with an introduction to creating Python classes and using them from within ASP.NET.
"In this tutorial we will be creating a sql table based class for a simple form. It will demonstrate how to create a class and reference it from a form."
"That's it for this tutorial. The next tutorial will go into something practical - creating and updating live data on a form. The code files can be downloaded below. Remember to change the connection string to point to an AdventureWorks database."
"In this tutorial we will be creating a sql table based class for a simple form. It will demonstrate how to create a class and reference it from a form."
"That's it for this tutorial. The next tutorial will go into something practical - creating and updating live data on a form. The code files can be downloaded below. Remember to change the connection string to point to an AdventureWorks database."
Monday, August 11, 2008
New IronPython Wiki Pages: IronPython People, Knol, SSIS and MP3 tags
There are five new wiki pages, across three different wikis (well - perhaps two wikis and a pseudo wiki) about IronPython.
There are three new pages on the IronPython Cookbook.
A page on the different people in IronPython. It includes notes on the different teams and Microsoft and their roles, plus the Resolver Systems guys and a few other folk who've made contributions to the IronPython community. If there is someone missing who you think ought to be there, please add them.
This is "a collection of utilities for programmatically controlling SQL 2005 SQL Server Integration Services (SSIS) packages with IronPython".
"This simple routine uses the Windows Shell to get MP3 file information from the tags. Due to the differences between Vista and XP different magic numbers are required to get the tags."
Knol is google's project for 'user created knowledge' - effectively a version of Wikipedia where articles are created by individuals or groups of individuals instead of being open to edits by anyone. As the articles appear under the name of the person who created them, you can have multiple articles on the same subject. Google hopes that the best articles will survive through a ranking / popularity system. I've started a Knol on IronPython, and whilst it is not complete I think it is already useful.
The PyCon UK talk schedule is now up and there is an IronPython Tutorial wiki page:
Christian Muirhead, Menno Smits and Michael Foord (me) will be running a half day IronPython tutorial on Friday 12th September as part of PyCon UK. We are all programmers at Resolver Systems and develop full time with IronPython. Christian and I are the authors of the soon-to-be-published IronPython in Action.
Between us we will have a Linux laptop, a Mac laptop and a Windows laptop and it is our intention to support you through the tutorial whichever operating system you run (so long as you have a recent version of Mono installed).
UPDATE: The wiki page also include Menno's notes on installing Mono 1.9 alongside an older version for Linux users.
The wiki page lists the pre-requisites for the tutorial (what you will need installed), the topics we intend to cover and has space for you to list any topics you are interested in that we haven't included.
There are three new pages on the IronPython Cookbook.
A page on the different people in IronPython. It includes notes on the different teams and Microsoft and their roles, plus the Resolver Systems guys and a few other folk who've made contributions to the IronPython community. If there is someone missing who you think ought to be there, please add them.
This is "a collection of utilities for programmatically controlling SQL 2005 SQL Server Integration Services (SSIS) packages with IronPython".
"This simple routine uses the Windows Shell to get MP3 file information from the tags. Due to the differences between Vista and XP different magic numbers are required to get the tags."
Knol is google's project for 'user created knowledge' - effectively a version of Wikipedia where articles are created by individuals or groups of individuals instead of being open to edits by anyone. As the articles appear under the name of the person who created them, you can have multiple articles on the same subject. Google hopes that the best articles will survive through a ranking / popularity system. I've started a Knol on IronPython, and whilst it is not complete I think it is already useful.
The PyCon UK talk schedule is now up and there is an IronPython Tutorial wiki page:
Christian Muirhead, Menno Smits and Michael Foord (me) will be running a half day IronPython tutorial on Friday 12th September as part of PyCon UK. We are all programmers at Resolver Systems and develop full time with IronPython. Christian and I are the authors of the soon-to-be-published IronPython in Action.
Between us we will have a Linux laptop, a Mac laptop and a Windows laptop and it is our intention to support you through the tutorial whichever operating system you run (so long as you have a recent version of Mono installed).
UPDATE: The wiki page also include Menno's notes on installing Mono 1.9 alongside an older version for Linux users.
The wiki page lists the pre-requisites for the tutorial (what you will need installed), the topics we intend to cover and has space for you to list any topics you are interested in that we haven't included.
IronPython 1.1.2 Released
Congratulations to the IronPython team for another great release. IronPython 1 targets Python 2.4 compatibility and version 1.1.2 is intended to be the last release of IronPython 1.
This release fixes around twenty issues from Codeplex and includes the implementation of the _winreg module plus some performance improvements.
Notable changes / bugfixes in this release include:
The following CodePlex Work Items were also closed:
This release fixes around twenty issues from Codeplex and includes the implementation of the _winreg module plus some performance improvements.
Notable changes / bugfixes in this release include:
- nt.unlink will now throw an exception if the file doesn’t exist, as it does in CPython
- The signature of IronPython.Runtime.Operations.Ops.Id() has changed and it now returns an object instead of long. This maps to the id() function in Python. Note that there is no change for Python caused by this and only code which is directly calling Ops.Id from a statically typed language like C# or VB will be affected
- Tuple hashing improvements - if you use tuples as dictionary keys you'll see a performance improvement from this
- Backport fix for compiled regular expressions - more performance improvements - compiled regexes weren't actually compiled previously
- Event handlers can cause circular references and leak memory - Nice to see this fixed, no need to manually unhook event handlers when disposing of UI objects now (hopefully)
The following CodePlex Work Items were also closed:
- 16368 1.1.2: nt.access is missing
- 15105 1.1.2: endpos is zero in IronPython 1.1.1
- 16337 1.1.2: Trivial: Implement float.__lt__(float)
- 16338 1.1.2: Using lambda in class definition will add
- 16342 1.1.2: calling base class __call__ invokes constructor instead
- 16343 1.1.2: problem with __slots__ and __init__ in new-style classes
- 16347 1.1.2: Trivial: popen shouldn't open new window
- 16348 1.1.2: Removes the inexistent file did not throw OSError in IP
- 16350 1.1.2: int() doesn't convert representable longs to int
- 16351 1.1.2: dict.update doesn't take keyword arguments - differs from CPython
- 16353 1.1.2: Trivial: int('0x20', 16) fails to parse, long too
- 16355 1.1.2: unpacking single element tuples in for-statement, listcomp and generator
- 16356 1.1.2: socket.getnameinfo(...) broken under Vista
- 16360 1.1.2: Class with slots and getattr not compatible
- 16363 1.1.2: Can't call method w/ nullable as 1st argument w/ greater than 5 arguments
- 16366 1.1.2: PyCF_DONT_IMPLY_DEDENT support in compile
- 16749 1.1.2 (Trivial): Modifier of PythonEngine.DefaultCompilerContext(..)
Sunday, August 10, 2008
IronPython in Chinese and Japanese
IronPython is doing well, it has taken me a week to catch up with all the blog posts in the wake of the 2.0 Beta 4 release. It isn't just in the English speaking parts of the world that IronPython is a hit though, which is good news for the Python and IronPython communities.
Here are two recent blog entries on IronPython in both Japanese and Chinese. They are both about the new features in 2.0 Beta 4. The first is about the new COM interop features, whilst the second shows off the COM interop (this one has understandable code examples of working with Excel) along with static compilation and an obligatory mention of the inclusion of the Python standard library.
Here are two recent blog entries on IronPython in both Japanese and Chinese. They are both about the new features in 2.0 Beta 4. The first is about the new COM interop features, whilst the second shows off the COM interop (this one has understandable code examples of working with Excel) along with static compilation and an obligatory mention of the inclusion of the Python standard library.
Saturday, August 09, 2008
ASP.NET IronPython Resource
ASP.NET is Microsoft's web programming framework. It is widely used and contends with PHP for the title of most used web framework. IronPython can be used with ASP.NET through IronPython ASP.NET Futures.
A new blog has started, called ASP.NET IronPython Resource, which has started a tutorial series on using IronPython with ASP.NET. There are currently two entries. The first gets you started creating new sites with either Visual Studio 2005 or 2008. It creates a "Hello World" application using the visual designer for the webform, and shows the IronPython code behind.
The second entry is a tutorial that shows connecting to a database with databinding to a gridview. The example project is available for download.
A new blog has started, called ASP.NET IronPython Resource, which has started a tutorial series on using IronPython with ASP.NET. There are currently two entries. The first gets you started creating new sites with either Visual Studio 2005 or 2008. It creates a "Hello World" application using the visual designer for the webform, and shows the IronPython code behind.
The second entry is a tutorial that shows connecting to a database with databinding to a gridview. The example project is available for download.
Friday, August 08, 2008
Django on IronPython with Jeff Hardy and NWSGI
Jeff Hardy is the creator of NWSGI, a .NET implementation of the Python WSGI web standard that recently reached version 0.4. For those who might not know, WSGI is modern web specification (like CGI all grown up) specifically for Python. It allows components of web applications to communicate.
Most Python web frameworks speak WSGI (pronounced wizz-gee), including the best known Python web framework Django (which is approaching a full 1.0 release). Jeff Hardy has been developing NWSGI by running Django on IronPython with the Cassini web server.
It seems like Django has become the standard 'compatibility-test' for Python implementations. Both Jython and PyPy have been working on improved Django compatibility performance, and Dino Viehland demonstrated Django on IronPython at this year's PyCon in Chicago.
Jeff has started a blog tracking the progress of Django with NWSGI, including any necessary patches. In the first two entries he describes getting the Django admin panel to run and in the third he talks about databases with IronPython and Django (both SQLite and MS SQL Server):
It is still an open question as to whether an unmodified Django will ever run on IronPython 2.X. Django 1.0 uses (or used to use last time I checked...) the difference between byte-strings and Unicode strings to determine whether it is serving text or binary data. IronPython has Unicode strings (and no byte-strings) so this strategy won't work without some other flag (or way of patching in a compatible 'bytes' type implementation). Jeff certainly seems to be making good progress though.
The fourth blog entry is the announcement of NWSGI 0.4, with a few more details:
Most Python web frameworks speak WSGI (pronounced wizz-gee), including the best known Python web framework Django (which is approaching a full 1.0 release). Jeff Hardy has been developing NWSGI by running Django on IronPython with the Cassini web server.
It seems like Django has become the standard 'compatibility-test' for Python implementations. Both Jython and PyPy have been working on improved Django compatibility performance, and Dino Viehland demonstrated Django on IronPython at this year's PyCon in Chicago.
Jeff has started a blog tracking the progress of Django with NWSGI, including any necessary patches. In the first two entries he describes getting the Django admin panel to run and in the third he talks about databases with IronPython and Django (both SQLite and MS SQL Server):
It is still an open question as to whether an unmodified Django will ever run on IronPython 2.X. Django 1.0 uses (or used to use last time I checked...) the difference between byte-strings and Unicode strings to determine whether it is serving text or binary data. IronPython has Unicode strings (and no byte-strings) so this strategy won't work without some other flag (or way of patching in a compatible 'bytes' type implementation). Jeff certainly seems to be making good progress though.
The fourth blog entry is the announcement of NWSGI 0.4, with a few more details:
Quick Notes on ScriptScope
One of the core classes in the IronPython 2 API is the ScriptScope. Internally, this represents a module namespace, so when customising the execution environment for an embedded IronPython engine you tend to use them a lot.
The DLR Hosting (and related stuff...) blog has posted some notes on the ScriptScope (and how to use them with the runtime and engine):
The DLR Hosting (and related stuff...) blog has posted some notes on the ScriptScope (and how to use them with the runtime and engine):
Thursday, August 07, 2008
Static Compilation of IronPython Scripts
One of the headline features in the new IronPython 2.0 Beta 4 release is that static compilation is back. IronPython is actually a Python compiler, it compiles Python code to in memory assemblies (that can then be JITed like any other .NET assembly). In IronPython 1, these assemblies could be saved to disk (as .exe or .dll files) and then imported from like normal Python files. This was the IronPython equivalent of CPython's 'pyc' compiled bytecode files.
UPDATE: The new 'pyc.py' sample demonstrating static compilation for IronPython 2 is now available for download.
This feature is curently used by Resolver Systems to do binary only distributions of Resolver One. It was initially missing from IronPython 2, and for a while it looked like it wouldn't make it back again - but thankfully it has now returned. This makes the transition for Resolver One from IronPython 1 to IronPython 2 (once it out of beta) an easier one - although the Resolver One codebase is heavily optimised for IronPython 1 and the performance profile of IronPython 2 is quite different, so it will still involve a lot of work.
Srivatsn is on the dynamic language team as a tester, and he also manages some of the releases. In this blog entry he looks at the new static compilation feature; how to use it and what it does.
There is also an InfoQ article on the new IronPython release that focusses on the new compilation feature:
UPDATE: The new 'pyc.py' sample demonstrating static compilation for IronPython 2 is now available for download.
This feature is curently used by Resolver Systems to do binary only distributions of Resolver One. It was initially missing from IronPython 2, and for a while it looked like it wouldn't make it back again - but thankfully it has now returned. This makes the transition for Resolver One from IronPython 1 to IronPython 2 (once it out of beta) an easier one - although the Resolver One codebase is heavily optimised for IronPython 1 and the performance profile of IronPython 2 is quite different, so it will still involve a lot of work.
Srivatsn is on the dynamic language team as a tester, and he also manages some of the releases. In this blog entry he looks at the new static compilation feature; how to use it and what it does.
There is also an InfoQ article on the new IronPython release that focusses on the new compilation feature:
Web-based DLR IDE with MDbg Debugger
Mitch Barnett has been working on a 'web-based programming collaboration system' called the Global System Builder. One component of this a web-based IDE for Dynamic Language Runtime languages.
Mitch has been experimenting with creating a web-based IronPython IDE based on the Javascript EditArea component. He has also been experimenting with MDbg for debugging IronPython code, although it looks like it has a way to go yet.
Mitch has been experimenting with creating a web-based IronPython IDE based on the Javascript EditArea component. He has also been experimenting with MDbg for debugging IronPython code, although it looks like it has a way to go yet.
IronPython: Batteries Included
The new release of IronPython includes (in the msi installer - which now works by the way) the Python standard library for the first time.
This is great news, and is the result of Harry Pierson pressing the Microsoft lawyers into submission so that they can make a 'dual-license' release - IronPython under the
Microsoft Public License and the Python standard library under the Python license.
This opens the way to patches to the standard library for IronPython compatibility. FePy (the IronPython Community Edition) has included several of these patches for some time.
Harry has more 'lawyer-time' ahead of him - so that IronPython can accept community contributions and submit patches back to core Python - but this is a great step.
At the moment the entire standard library is included, including modules that can never work because they rely on C extensions. In his latest blog entry Harry talks about the new 'batteries-included' approach for IronPython, and how it might develop.
This is great news, and is the result of Harry Pierson pressing the Microsoft lawyers into submission so that they can make a 'dual-license' release - IronPython under the
Microsoft Public License and the Python standard library under the Python license.
This opens the way to patches to the standard library for IronPython compatibility. FePy (the IronPython Community Edition) has included several of these patches for some time.
Harry has more 'lawyer-time' ahead of him - so that IronPython can accept community contributions and submit patches back to core Python - but this is a great step.
At the moment the entire standard library is included, including modules that can never work because they rely on C extensions. In his latest blog entry Harry talks about the new 'batteries-included' approach for IronPython, and how it might develop.
NWSGI 0.4 Released
To coincide with the release of IronPython 2.0b4, Jeff Hardy has released an updated version of NWSGI - version 0.4.
This version brings improvements to configuration and performance.
In the release announcement Jeff said:
IronPython itself has improved dramatically (kudos to the team for a fantastic job) and is now capable of running parts of Django, although some workarounds are still required. I can make it through the tutorial, and once I get some testing with 2.0b4 done I'll post patches as well.
I'm going to start testing against some other applications as well, and post the results on my blog as well as the compatibility pages on ironpython.info.
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.
This version brings improvements to configuration and performance.
In the release announcement Jeff said:
IronPython itself has improved dramatically (kudos to the team for a fantastic job) and is now capable of running parts of Django, although some workarounds are still required. I can make it through the tutorial, and once I get some testing with 2.0b4 done I'll post patches as well.
I'm going to start testing against some other applications as well, and post the results on my blog as well as the compatibility pages on ironpython.info.
Wednesday, August 06, 2008
IronPython 2.0 Beta 4 Released
The IronPython team has just announced the release of IronPython 2.0 Beta 4. IronPython 2 is the version of IronPython built on top of the Dynamic Language Runtime.
This is an important release, not just because of the number of new features and bugfixes, but because with it come changes to the way IronPython is packaged and what it is packaged with...
As well as the normal binary / source releases, IronPython 2b4 comes with an msi installer that also includes the Python 2.5 standard library. This is something the community has wanted for a long time, and opens the way for the Microsoft Dynamic Languages team to officially support some of the patches needed to enable some standard library modules to work with IronPython. It also makes IronPython a more 'complete' (and installable) version of Python.
IronPython 2 now requires .NET 2 Service Pack 1. If this isn't installed, the msi will prompt you. Unfortunately there is a bug with the currently released installer that will cause it to think that a machine with .NET 3 / 3.5 installed does not meet the requirements (even where .NET 2 SP1 is explicitly installed). Hopefully that will be fixed soon...
UPDATE: The msi bug has now been fixed.
Significant new features in this release include:
Bugs fixed (45 on codeplex plus 5 reported internally):
This is an important release, not just because of the number of new features and bugfixes, but because with it come changes to the way IronPython is packaged and what it is packaged with...
As well as the normal binary / source releases, IronPython 2b4 comes with an msi installer that also includes the Python 2.5 standard library. This is something the community has wanted for a long time, and opens the way for the Microsoft Dynamic Languages team to officially support some of the patches needed to enable some standard library modules to work with IronPython. It also makes IronPython a more 'complete' (and installable) version of Python.
IronPython 2 now requires .NET 2 Service Pack 1. If this isn't installed, the msi will prompt you. Unfortunately there is a bug with the currently released installer that will cause it to think that a machine with .NET 3 / 3.5 installed does not meet the requirements (even where .NET 2 SP1 is explicitly installed). Hopefully that will be fixed soon...
UPDATE: The msi bug has now been fixed.
Significant new features in this release include:
- Static compilation of python files is now supported again and the pyc.py sample has been updated to use the newer version.
- IDispatch-based cominterop is now the default mode as opposed to generating interop assemblies for interacting with COM components. This is a change that might break some existing scripts. One can switch back to the old behavior by setting the environment variable COREDLR_PreferComInteropAssembly. Read this blog for more details on this feature.
- Apart from the Silverlight binaries and Chiron, the templates and tools to create a barebones app are included as well. This is in the Silverlight\Script folder.
- Performance degrades that were reported in Beta 3 have been fixed.
Bugs fixed (45 on codeplex plus 5 reported internally):
- nt.popen(...) breaks where ... consists of cmd.exe commands
- globals().fromkeys(...) broken
- globals().Values enumerator broken
- Trivial: nt.tempnam("", None) broken
- Trivial: Remove exceptions.OverflowWarning
- New-style class dicts (dictproxy) cannot be used for C# methods with IDictionary parameters
- Negative: ipyw.exe run w/o args crashes
- 'dictproxy' object has no attribute 'copy'
- class.__dict__ (dictproxy) doesn't support .get
- repr() of a UserList containing another userList is wrong
- NaN == NaN
- DBNull should implement __nonzero__ that always returns false.
- IP implementation of _sha512 has extra module attributes
- Dir on textbox raises exception
- re.compile(...).match(...) does not permit certain integer pos/endpos keyword parameter values
- re.compile(...).match(...).groupdict() broken WRT to unnamed groups
- re.match(..., ...).regs is nearly always incorrect
- datetime.datetime.fromtimestamp() is not POSIX timestamp
- Trivial: Charset name
- datetime.datetime.utcfromtimestamp()
- datetime.datetime.isoformat() has no parameter
- nt.fstat(...) broken
- Python25: __hash__ returning longs broken on old style classes WRT CPython 2.5
- Trivial: IronPython converts -0x80000000 to a long (should be int)
- -X:TabCompletion broken in IP2.0A1 WRT simple variable expansion
- import socket
- TypeError: staticmethod is not callable when overriding __new__ in old+new derived type
- using the PropertyGrid class - SelectedObject issue
- new.classobj fails with "TypeError: __bases__ items must be classes (got type)"
- dict(...) broken on new style class dictionaries (dictproxy)
- IronPython should not implement weakref.proxy.__eq__
- nt.stat(someDirectory) is broken
- Trivial: Implement 'file(...).mode'
- Trivial: os.chmod followed by os.unlink fails
- os.umask does not exist
- Regular Expression incompatibility
- co_filename in code objects is None
- Trivial: help(clr.AddReference) not helpful
- tb_line member of Traceback objects is incorrect
- Valid regex under CPython will fail with IronPython
- time.timezone has different semantic than in cpython
- IronPython 2.0B2 cannot iterate over an IEnumerable returned from a C# method using yield
- Implement os.system (nt.system)
- cStringIO 1-arg .read() and .readlines() broken
- Trivial: id should return int or long, not Int64
- misc string related bugs from c-python25 test
- Implement warnings for -Qwarn and -Qwarnall
- StackOverflowException when exec "ao==7" for Ironpython, but Cpython can work
- Helper stubs shown in Python stack traces
Tuesday, August 05, 2008
TechZulu: Mike Vincent on IronPython & IronRuby
INETA is an international .NET association providing support to .NET user groups worldwide. This TechZulu video interview with Mike Vincent of INETA (7 1/2 minutes) is about IronPython and IronRuby on .NET, Silverlight and Moonlight.
GUI Automation: Building the Framework (1)
Lukas Cenovsky continues his series on the functional testing of GUI applications with IronPython on the GUI Automated Testing Blog.
He has already covered the basics, how to access a winforms application that we want to test, run it in a separate thread, and simulate user input. In this entry he takes a more methodical look at some of the components involved in testing a winforms application and starts to build up a testing framework (source available):
He has already covered the basics, how to access a winforms application that we want to test, run it in a separate thread, and simulate user input. In this entry he takes a more methodical look at some of the components involved in testing a winforms application and starts to build up a testing framework (source available):
Monday, August 04, 2008
Resolver Systems: A Python Success Story
One of my colleagues, the newly nuptialed Mr. Jonathan Hartley, decided that working through summer was definitely not what cool cats should do - and promptly disappeared to the states for a sabbatical. Still, he hasn't entirely frittered the time away on fun and sunning himself and he can prove it because he's written up a 'Python Success Story' which is now part of the collection on the Pythonology Website run by Wingware. This tells the story of Python at Resolver Systems, including how and why we chose IronPython - and how that choice worked out so well for us.
- IronPython at Resolver Systems (Jonathan's Blog entry)
- IronPython at Resolver Systems: Python Learns New Tricks
Resolver Systems is a two year-old start-up based on the outskirts of London's financial district. Our first product, Resolver One, is a desktop and web-accessible spreadsheet aimed primarily at the financial services market. It is written entirely in IronPython, and directly exposes end-users to Python, both as expressions in cell formulae, and as an embedded scripting language which provides programmatic access to spreadsheet content.
Resolver One launched in Spring of 2008, by which time the team had grown to fourteen people, and the codebase to 40k lines of product and 140k lines of tests.
From the outset, it was clear that it would be good to use an existing language as our embedded scripting language, rather than inventing one. A dynamic language would confer appropriate type semantics on the spreadsheet formulae...
IronPython Post 2.0 Roadmap Clarifications
A couple of weeks ago, Harry Pierson (IronPython PM) posted a roadmap outlining Microsoft's plans for supporting Python 2.6 and 3.0 - once IronPython 2.0 (which targets Python 2.5) is out of beta. He also discussed the plans for future IronPython and Visual Studio integration (something that Curt Hagenlocher was originally hired for - but he couldn't resist the lure of working on IronRuby as well and another new hire - Oleg Tkachenko will be focussing on the VS integration for both IronPython and IronRuby).
As the core Python developers will be maintaining Python 2.X and 3.X in tandem for a while, whilst the community transitions over to Python 3, I asked if IronPython would do the same - or whether IronPython 2 would be left behind once work on IronPython 3 begins. Another commentor, Francois, was keen to know whether the Visual Studio integration would require users to purchase Visual Studio - or whether they would be able to use the Express version or the VSx Shell as is the case with IronPythonStudio.
Harry answers both these questions in his roadmap clarifications blog entry:
As the core Python developers will be maintaining Python 2.X and 3.X in tandem for a while, whilst the community transitions over to Python 3, I asked if IronPython would do the same - or whether IronPython 2 would be left behind once work on IronPython 3 begins. Another commentor, Francois, was keen to know whether the Visual Studio integration would require users to purchase Visual Studio - or whether they would be able to use the Express version or the VSx Shell as is the case with IronPythonStudio.
Harry answers both these questions in his roadmap clarifications blog entry:
Sunday, August 03, 2008
July 2008 Richmond Meet and Code Notes
Kevin Hazzard blogs about the recent Richmond .NET meetup, where he presented his 'ProxyGen' tool. This is an IronPython tool for calling SOAP based webservices:
The only magic here is in some dynamic code generation that my ProxyForWsdl class does by downloading the WSDL contract and building classes for services, operations and data contracts.
Python scripts making use of this magic can be embedded into C# applications. The blog entry shows screenshots and example scripts, plus an example that embeds IronPython in C#. All the code is downloadable.
Of course what he should be doing is writing the whole application in IronPython...
The only magic here is in some dynamic code generation that my ProxyForWsdl class does by downloading the WSDL contract and building classes for services, operations and data contracts.
Python scripts making use of this magic can be embedded into C# applications. The blog entry shows screenshots and example scripts, plus an example that embeds IronPython in C#. All the code is downloadable.
Of course what he should be doing is writing the whole application in IronPython...
Saturday, August 02, 2008
Module Testing with Python
One of the great advantages of dynamic languages in general, and Python in particular, is that they tend to be much easier to test than statically typed languages.
Not only that, but the IronPython interactive interpreter makes it very easy to manually test C# assemblies - creating instances and calling methods of your .NET classes.
James McCaffrey demonstrates IronPython for 'ad-hoc' testing of some classes from a poker library. He emphasises the value of Python for automated testing.
Not only that, but the IronPython interactive interpreter makes it very easy to manually test C# assemblies - creating instances and calling methods of your .NET classes.
James McCaffrey demonstrates IronPython for 'ad-hoc' testing of some classes from a poker library. He emphasises the value of Python for automated testing.
Friday, August 01, 2008
OLE Automation support ON in IronPython 2.0 Beta 4
IronPython 2.0 beta 4 isn't out of the door yet, but already the team are blogging about some of the new features. Shri Borde has a new blog entry about OLE Automation with IronPython, without having to rely on interop assemblies. This makes for easier automation of Excel, Word and any other COM enabled Windows applications.
In previous versions of IronPython trying to doing this without the Primary Interop Assemblies available would try to generate them on the fly (which could take several minutes). But with IronPython 2.0 BEta 4 it should work fine through IDispatch. Shri provides some details of how it works in practise, how it works under the hood, and some of the known issues (including how to turn it off if it causes any problems!).
In previous versions of IronPython trying to doing this without the Primary Interop Assemblies available would try to generate them on the fly (which could take several minutes). But with IronPython 2.0 BEta 4 it should work fine through IDispatch. Shri provides some details of how it works in practise, how it works under the hood, and some of the known issues (including how to turn it off if it causes any problems!).
Curt Hagenlocher: This... is... Dynamic!... and StackOverflowException in IronPython
Curt Hagenlocher, the newest (well... as far as I know) member of the IronPython team has started blogging as Iron Curt.
He has two blog entries already. The first explores stack overflow in IronPython (which is a catchable error in Python), and how it maps to the underlying Common Language Runtime (where it is generally an unrecoverable error). By default IronPython doesn't catch stack overflows (sys.recursionlimit is set to MaxInt), because there is a performance overhead in monitoring the frame depth to catch the exception. Curt explores the issues around this for IronPython.
In the second entry he takes this further by looking at CLR exception filters (through the eyes of some VB.NET) to show why they can't be used for IronPython exception handling.
This is part of what it means to be dynamic. Take the power and use it wisely.
He has two blog entries already. The first explores stack overflow in IronPython (which is a catchable error in Python), and how it maps to the underlying Common Language Runtime (where it is generally an unrecoverable error). By default IronPython doesn't catch stack overflows (sys.recursionlimit is set to MaxInt), because there is a performance overhead in monitoring the frame depth to catch the exception. Curt explores the issues around this for IronPython.
In the second entry he takes this further by looking at CLR exception filters (through the eyes of some VB.NET) to show why they can't be used for IronPython exception handling.
This is part of what it means to be dynamic. Take the power and use it wisely.
Subscribe to:
Posts (Atom)
