Showing posts from 2008

End of Year Selection

A few months ago I got behind on posting interesting IronPython related links. I've caught up a lot, but a whole bunch of interesting stuff happened in November and December that I haven't reported yet. Some of that will have to wait for another day, but we'll end the year with a selection of some of the snippets from the last couple of months. IronPython Cookbook A couple of new recipes in the IronPython Cookbook , by Davy Mitchell and Atif Aziz: Process Monitor - demonstrates how to write a small utility in IronPython that monitors a process and re-launches it if it dies. How to Play a Wav - this short example plays a WAV format sound file using System.Media.SoundPlayer . Speech Synthesis in IronPython Another short example of how to use IronPython to make your computer speak like a robot: Speech Synthesis in IronPython Other Assortments IronPython in Bazaar - an import of the IronPython sources onto launchpad. Useful if you want to use a DVCS (Distributed Ver

Pumping Iron: Dynamic Languages on .NET

The esteemed Mr Tartley recently stepped into the shoes of Harry Pierson (Microsoft IronPython PM) and spoke about dynamic languages on the .NET framework at the Øredev conference in Malmö, Sweden. He has posted the slides and notes online, based on Harry's presentation but delivered with Jonathan's irrepressible style (and with the audience's reaction inline). Pumping Iron: Dynamic Languages on .NET The talk is an exploration of the differences between static and dynamically typed languages, plus some of the specific language features of Python and IronPython. My favourite part is where he discusses the cost of compile time checking. Those who advocate the benefits of statically typed languages often discuss what losing compile time checks costs, what they don't talk about so often is what keeping them costs: " So let’s examine what we’re really talking about losing when we have no compile-time type checks. As we’ve noted, type safety really does catch and

NWSGI 1.0 Released

Jeff Hardy announced today the 1.0 release of NWSGI, a Web Server Gateway Interface (WSGI ) for IronPython. " I'm very pleased to announce the release of NWSGI 1.0. NWSGI is an implementation of the WSGI specification (PEP 333) for IronPython. It is implemented as an ASP.NET HttpHandler and is supported on IIS 6 and IIS 7 (and should work on any other ASP.NET-capable web server). NWSGI allows the integration of Python applications with existing ASP.NET facilities such as caching, sessions, and user management. " NWSGI 1.0 can be downloaded from Release/ProjectReleases.aspx? ReleaseId=18995 . More details are available at 2008/12/nwsgi-10.html In the blog entry Jeff notes that NWSGI is a "nearly-complete" implementation of the WSGI specification. On deployment he says: " NWSGI fully supports xcopy deployment and medium trust environments (with the caveat that parts of the Python standard library

IronPython and the Spark View Engine

The Spark View Engine is " a view engine for Asp.Net MVC and Castle Project MonoRail frameworks. The idea is to allow the html to dominate the flow and the code to fit seamlessly ". It now supports IronPython: IronPython on the Spark View Engine About Iron Python IronPython is a dynamic language runtime (DLR) based implementation of Python. Spark scripting is based on assemblies in the 2.0 Release Candidate 1 binary zip. Other good resources are the Python documentation and the Python site itself. The support for the DLR is very Asp.Net MVC centric. If there's an interest in expanded Castle MonoRail support, please speak up in the discussion group . Creating a new project A standard Asp.Net MVC web application is always a great starting place. First, add references to the following assemblies: Spark.dll Spark.Python.dll Spark.Web.Mvc.dll Spark.Web.Mvc.Python.dll And the following from the IronPython release which are available in the Spark bin\dependenc

OWL BASIC parser and abstract syntax tree

The first programming language I ever used was a version of BASIC on the BBC Microcomputer (over 20 years ago and counting). It did use line numbers, but had procedures and subroutines and allowed you to do structured programming including recursion. Having a programming language built into the machine made it incredibly simple to start hacking - and it even included an assembler so you could embed assembly language in basic programs. A lot of games on the machine started with a shell of basic that would bootstrap the game actually written in assembler. Robert Smallshire has been working on an implementation of BBC Basic written in IronPython: OWL BASIC parser and abstract syntax tree " Other personal projects, of both a software and familial nature have taken priority lately over my project to implement a BBC BASIC-a-like compiler for the .NET CLR, now called OWL BASIC in honour of the owl logo of the BBC’s Computer Literacy Project. " This blog entry is mainly focused o

Introducing IronPython

Harry Pierson wrote an article on IronPython for the CoDe magazine. Initially it was behind a paywall, but now the whole article is available to read: Introducing IronPython " One of the somewhat frustrating aspects of C# is the amount of structure that gets forced on the developer. Some of the structure is related to static typing, such as specifying variable types and casting operators. However, there are also no stand-alone functions in C#, much less just a bunch of code in a simple script. All functions have to be attached to an object, meaning the simplest implementation of “hello, world!” in C# looks like this ": class Program { static void Main() { System.Console.WriteLine("Hello, World"); } } Contrast that with the Python version: print "Hello, World” "Obviously, you don’t judge a language completely by its implementation of “hello, world”. But the point is that Python scales well with complexity." His conclusion: "Between

C# Becomes a Dynamic Language...

This post is a bit late - in fact this news was announced several months ago at this year's Microsoft Professional Developer's Conference . At the PDC the Dynamic Language Runtime was demonstrated - along with the news that it will be part of .NET 4.0. Both Visual Basic 10 and C# 4.0 will have dynamic elements that make use of the Dynamic Language Runtime. In a blog entry after the conference Jim Hugunin links to Channel 9 videos of his talk on the DLR and Anders Hejlsberg's talk on the way C# is changing. Dynamic Language Runtime Talk at PDC C# 4 will allow you to use objects dynamically through a new static declaration. A new keyword that allows you to statically declare dynamic objects! Objects that are declared as dynamic will have operations on them (attribute lookups, method calling, indexing, numerical operations and so on) done through the DLR. The intarwebz were awash with the news. Here is a selection of the most interesting and informative responses that I

IronPython 2 Final Released

IronPython 2 final (or Release To Web in Microspeak) is finally out. IronPython 2 targets Python 2.5, is built on top of the Dynamic Language Runtime and runs on .NET 2 SP1, Mono 2.2 and Silverlight. Download IronPython 2 IronPython 2 Release Notes This release of IronPython includes improvements in many feature areas such as better .NET interop support and hosting Python from managed code. There have been many other major improvements as well. The most notable are: An MSI installer for Windows platforms which includes parts of the CPython 2.5 standard library IronPython assemblies targeting Silverlight and tools such as Chiron to improve the Silverlight dynamic development experience The addition of more C-based standard modules such as cmath and _winreg Significant improvements in importing compatibility and features Distribution of IronPython under the Microsoft Public License which has been approved by OSI Performance improvements. On that note, a new Wiki page has been created

Try Python and IronPython Web IDE Updated for Silverlight 2

I still haven't got around to posting updated versions of my IronPython and Silverlight 2 articles and examples . (However the IronPython in Action early access version does cover the final version of Silverlight 2.) What I have done is put online updated versions of Python in the Browser (an interactive Python interpreter that runs in an HTML textarea) and the IronPython Web IDE (a tool for experimenting with the Silverlight APIs live from IronPython - pre-loaded with examples). Try Python and IronPython Web IDE Updated for Silverlight 2

IronPython is the new IValueConverter, IMultiValueConverter

A blog entry on using IronPython to create a DSL (Domain Specific Language) to evaluate expressions in WPF XAML (the XML used to describe user interfaces for Windows Presentation Foundation and Silverlight): IronPython is the new IValueConverter, IMultiValueConverter "Applying simple mathematical operations inside WPF DataBindings has always been a non-trivial task. By default the {Binding} or MultiBinding syntax does not allow the use of arbitrary expressions inside the Path. " "There are several cases where you would like to do a little bit of math inside of the {Binding} expressions. " "This requires the use of a converter that would do the actual mapping of values to the bounds of the Canvas. " "Ideally you would want the complete flexibility of a scripting language inside of your Binding expressions. Note however that there is a tendency to over-use / abuse a scripting functionality. That however is for the team to decide what level of sanity

IronPython and [Insert MSFT Technology Here] (Starting with WPF)

Back in November (yes, I'm still behind on my posts but catching up), Harry Pierson (IPy PM) announced his decision to write a series of posts on how to use IronPython with a range of different Microsoft technologies: IronPython and [insert MSFT Technology Here] Making good on his promise he starts with 6 posts on using the WPF (Windows Presentation Foundation) GUI toolkit with IronPython. IronPython and WPF Part 1: Introduction In the first part he starts a WPF based photo viewer for his wife's Windows Live photo collection. " Turns out building this app in IPy was fairly straightforward, with a few pitfalls. I wasted half a day digging thru data binding before realized that data binding against IPy objects works out of the box - but only if you type the case of the property correctly (Title != title)... " " Over the next several posts, I’m going to show you all the code for this app. It’s pretty small, only about 50 lines of app-specific python code + 50 lin

Welcome David DiCato to the IronPython Team

Shri Borde (IronPython/IronRuby dev lead) just posted this to the IornPython mailing list: Please welcome David DiCato to the IronPython team. He has his first shelveset in the Snap queue ( queue.__init__ calls clear) already. You should hopefully hear more from him in the mailing list. Here is his intro in his own words. " Hi everyone, I’m David DiCato, the new Dev on the IronPython team. I grew up in Surf City (i.e. Huntington Beach, CA) and moved just 50 miles north to go to school in Pasadena. At Caltech, I earned my BS in Computer Science, applied to Microsoft after a short break, and the rest is history. Although I have never touched a surf board, I like to dabble in snowboarding, as well as piano, guitar and biking, although I’m good at none of these things. I’m also a big fan of music, incl. classic rock, punk and electronic, and film, incl. Kubrick, Hitchcock and Scorsese. " Welcome to David. He doesn't seem to have a blog yet, but he has been warned that as

Silvershell 0.6 Released

Dan Eloff has announced the release of Silvershell 0.6. (Also known as Python/E - Python Everywhere!). Silvershell Google Code Project Page Silvershell is an interactive Python interpreter (for Python 2.5 as it is based on IronPython 2) with two clients (implemented in pure Python). It runs in the browser with Silverlight 2 or on the desktop with a WPF (Windows Presentation Foundation - which means it won't run on Mono) User Interface. It is much more polished than my Python in the Browser , with features including: Saving of preferences Autocomplete and call tips The ability to switch processing to a background thread Here is the announcement that Dan posted to the IronPython mailing list: " New in this release is the ability to run on the desktop with WPF, execution of code in background threads, and a scratchpad canvas for playing with UI controls. " " There are still some bugs lurking in the intellisense code, and I'll be following soon with a bugfix r

IronPython + F# + Parallel + Async = A Kittehz Brekfst

Concurrency with threading can be a tricky subject, particularly amongst the Python community . Nick Hodge has a blog entry on using the .NET Parallel Extensions to write concurrent libraries in F#, and then using them from IronPython: IronPython + F# + Parallel + Async = A Kittehz Brekfst Whilst thread-safety, dead-locks, queues and other nasties are nasty, Microsoft sees the world of n-cores as a software problem to be solved, not ignored. Both at a low-level and a high-level, well constructed and debugged Parallel libraries are appearing to make the splitting of tasks easier. IronPython implements the Python language on the DLR and subsequently on the CLR, but this does not automagically provide IronPython with threading and parallelism. Nor could I suggest that IronPython is the silver-bullet for clean parallelism with Python. Various projects such as ParallelPython (including cluster support), Stackless Python and the recent python-multiprocessing package are appearing to mov

LiveFX using IronPython

Ori Amiga is the group program manager of the Live Framework development platform. He has started a blog, and in his first entry he demonstrates how to use the LiveFX SDK from IronPython. According to the website: "The Live Framework is the uniform way for programming Live Services from a variety of platforms, programming languages, applications and devices. Consume and combine Live Services to build applications that span across digital devices and the web." LiveFX using IronPython Download and install the latest IronPython console from [here] Grab the sample file from [here] Edit the file and change the line sdkLibsPath = r"..\LiveFrameworkSDK\Libraries\.Net Library" to reflect the path where you’ve installed the LiveFX SDK .NET libraries Launch the IronPython console from the command line: [ ipy.exe -X:TabCompletion ] At the console, you can now type something like: import LiveOE livefx = L

Checking Type Contract from IronPython

Ronnie Maor blogs about testing a C# interface interface that is implemented in IronPython. As Python is generally much more relaxed he needs to ensure that IronPython honours the type contract of the interface it is implementing. He tests this by testing the Python code through the C# interface (which will complain loudly if you use the wrong types) - making the calls via reflection. Checking Type Contract from IronPython " One thing I wanted to test is that my class implements the C# interface correctly in terms of methods' signatures. Otherwise IronPython throws an exception when it tries to map the arguments to the python method, or when it tries to convert the return value. However, my tests are in python, and calls to the object from python don't go through the type checking/conversion parts. " " To overcome this, I call the methods using .NET reflection, which mimics a C# call more accurately and goes through the type checking code. Here's the utilit

IronPython in Action Update and a Review

IronPython in Action , the book co-written by myself and Christian Muirhead, is still wending its way towards actually being available in the shops. It's currently going through copy editing and technical review. The copy editor is doing a fantastic job of fixing all our grammar and punctuation and generally making the book a better read for those who are bothered by errant commas and semi-colons. Dino Veihland is very kindly acting as our technical reviewer; and is also doing a marvellous job. Meanwhile, for those who don't want to wait, the full text of the book (pre-copy editing and without the appendices - but still awesome) is available via the Manning Early Access Program . This gets you a PDF version now, and a hardcopy when the book hits the trees. The early access version has just been updated to cover the latest versions of the IronPython 2 hosting API, ASP.NET IronPython integration and Silverlight 2: IronPython in Action Early Access Update Davy Mitchell has been

Adding References to Assemblies in IronPython

The 'first point' of interoperation between Python code and the .NET framework is the clr module. This allows you to dynamically add references to .NET assemblies in order to be able to import classes from the namespaces they contain. The clr module has a bewildering array of different functions for adding references to assemblies, and each of them have slightly different semantics and use cases. Dino Veihland (IronPython Developer) recently posted a very useful explanation to the mailing list: clr.AddReference(str) will first try Assembly.Load and then try Assembly.LoadWithPartialName - this should mean that trying with the strong name won't do anything because LoadWithPartialName will do that for you. This is kind of the one-stop shopping for loading assemblies in the GAC or the app base. If those don't work it will also ultimately search sys.path when the load fails. clr.AddReference(asm) will just add the assembly that you've already loaded - this i

IronPython and Parallel Imports

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 i

WSGI on .NET and in the Cloud

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 HttpRespo

Two Source Code Repositories for IronPython

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.)

Ironclad 0.7 Released

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 .

IronPython 2.0 RC 2 and DLR 0.9 Released

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 D

GUI Automation: Building the Framework (3)

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._CheckVisibil

A Whole Bunch of Stuff: Part II

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

A Whole Bunch of Stuff: Part I

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

The Microsoft Dynamic Languages Team Blogroll

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.

Silverlight 2 and Dynamic Languages

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 Languag