IronPython URLs

IronPython 2 uses Dynamic Language Runtime expression trees, which have been merged with LINQ expression trees. These have extension methods and IronPython itself also uses extension methods. These need the .NET 3.5 compiler, but if you provide an ' ExtensionAttribute ' type then the compiled assemblies still work with .NET 2 (extension methods are effectively a compiler trick). Unfortunately the ' ExtensionAttribute ' type supplied with IronPython 2 clashes with the version in .NET 3.5 if your project also references the System.Core assembly. The latest release candidate of IronPython solves this problem by providing a fifth assembly. Harry Pierson (DevHawk) gives us the details: The Fifth Assembly The important details are: In IronPython 2.0 Beta 5, there were four DLLs that implement IronPython: IronPython.dll IronPython.Modules.dll Microsoft.Scripting.dll Microsoft.Scripting.Core.dll In our RC1 release, we’ve added “The Fifth Assembly”: Microsoft.Scripting.Extensio

The Microsoft PDC conference is in full swing and there are various pieces of IronPython / Dynamic Language Runtime related news adding to the backlog of things I need to post. (C# 4 becoming a dynamic language through the DLR, preview of IronPython integration in Visual Studio 10 and so on.) One interesting snippet is that the Intellipad tool, part of the Oslo framework, is scripted with IronPython. Oslo is a modelling platform " that aim to significantly simplify designing, building, managing and scaling service-oriented and composite applications that can span from the enterprise to the Internet ". It includes a new declarative language called "M" " for working with data and building domain models ". UPDATE: Martin Fowler has a new blog entry covering Oslo in more depth . Intellipad is inspired by Emacs, and in fact had the codename "Emacs.NET". It is user scripted with IronPython instead of Lisp. Online material is hard to find, but this p

IronPython 2.0 Release Candidate 1 has just been released. IronPython 2 is the version of IronPython that is built on the Dynamic Language Runtime, and targets Python 2.5. Along with the new release candidate the team notes: If no major issues with the RC are reported, we hope to ship the final 2.0 release in around a month’s time. Anyone planning to move to 2.0 please try the RC and let us know of any issues you find. IronPython 2 RC1 Release Notes Download IronPython 2 RC1 Python Standard Library Not Included in the msi Installer As well as fixing around 40 bugs (making more than 500 bug reports that have been closed since IronPython 2 went into alpha), there are a few new things in this release. Firstly, the MSI installer now has an option to ngen (pre-JIT) the installed binaries. Ngen’ing the dlls gives a significant startup performance boost. The option is turned off by default but if no issues are reported, it will be enabled by default in a future release. The last couple of be

This Saturday Harry Pierson (Program Manager for IronPython) is giving a talk on Dynamic Languages on .NET at the Southern California Code Camp Community: Pumping Iron: Dynamic Languages on .NET (Calling it SoCal makes me think of William Gibson, but there you go.) 10:00 AM - Saturday, October 25, 2008 IronRuby | IronPython | DLR As you may know, Microsoft is developing IronPython and IronRuby, .NET implementations of the popular open-source programming languages Python and Ruby. While it’s clear that Microsoft wants to attract existing Python and Ruby developers to .NET, the role of IronPython and IronRuby for existing .NET developers is less clear. What value is there for a .NET developer in learning IronPython? What are the tradeoffs between IronRuby and a more traditional .NET language like C# or VB? Harry Pierson, new PM for IronPython, will discuss where dynamic . languages fit in the.NET developers toolbox.

Crack.NET is a runtime debugging and scripting tool that gives you access to the internals of any .NET desktop application running on your computer. Crack.NET allows you to walk the managed heap of another .NET application, inspect all kinds of values on objects, and even manipulate those objects via IronPython scripts. Crack .NET Homepage Download from Codeplex Article on Crack .NET (word document) Once you find an object or type that you're interested in, you can manipulate it, and others, by writing and executing an IronPython script. Crack.NET was built against version 1.1.2 of IronPython.DLL and IronMath.DLL.

1.0 Beta 1 that is. Yesterday IronScheme 1.0 Beta 1 was released. IronScheme is a rewrite of IronLisp, and aims to be an R6RS conforming implementation of Scheme based on the Microsoft Dynamic Language Runtime. This new language implementation allows you to write .NET applications in Scheme or embed Scheme as a scripting language. It also opens up the possibility of Python and Scheme (and other dynamic languages) interoperating through the DLR. This release includes a Visual Studio (SP1) plugin and is the creation of the author of the Open Source .NET xacc ide which has Scheme support. IronScheme From the 1.0 Beta 1 release notes : Notably lacking for R6RS call/cc only supports outward continuations Differences all raise's are continuable in the sense they can be caught no tail calls in dynamic-wind Extras a generic load procedure for toplevel R6RS files many extras procedures and macros in (ironscheme) library, mostly provided by psyntax syntactic CLR integration, automatic conve

I've got a backlog of links to post; normal service will be resumed shortly... In the meantime here a few snippets that may be of interest. Through the ' Pyc ' compiler sample, which uses ' clr.CompileModules ' under the hood, IronPython 2 can compile Python code to binary assemblies. These assemblies can be ngen'd (pre-JITed) making imports roughly three times as fast as from a Python sourcecode file. This is great because IronPython import performance is sloooow... In the latest beta (2 beta 5) compiling packages was broken, meaning that we couldn't build and test a binary distribution of Resolver One running on IronPython 2. This problem was supposed to have been fixed in the latest codeplex source code drop , so today I tested it out. The first thing I had to do was build IronPython 2 from sources on a machine that has .NET 3.5 installed, but not Visual Studio 2008. It took me a while to find precisely the right magic command line invocation to build in

Silverlight Release Candidate 0 is out, this means that the old versions of IronPython and the Dynamic Language Runtime don't work with the new version. Silverlight includes a cut down version of the .NET framework called the Core-CLR. IronPython and DLR have to be compiled against the Core-CLR assemblies for the version of Silverlight you are targeting. But IronPython is Open Source, so you can just compile it against the new Silverlight assemblies right? Jimmy Schementi explains: Compiling the DLR, IronRuby, and IronPython for ANY version of Silverlight " Of course! Everything should just work, since there were no major breaking changes in Silverlight that affect the DLR between Beta2 and RC0. So, you hacked up the csproj files to point at mscorlib.dll, system.dll, etc in the new Silverlight install directory (C:\Program Files\Microsoft Silverlight\2.0.30923.0), compile, and it builds fine. Then you try to run an app ... " Next you need to make a simple change to your d

Noel O'Blog reports on the recent OpenBabel release that explicitly supports IronPython. OpenBabel, IronPython and ADME filtering OpenBabel is: " a chemical toolbox designed to speak the many languages of chemical data. It's an open, collaborative project allowing anyone to search, convert, analyze, or store data from molecular modeling, chemistry, solid-state materials, biochemistry, or related areas. " The OBDotNet release comes with instructions on how to use it from IronPython: First of all, unzip the OBDotNet distribution, and set the environment variable BABEL_DATADIR to point to the data folder contained within. If running IronPython in the unzipped OBDotNet folder, you can use the following to initialise OBDotNet: >>> import clr >>> clr.AddReference("OBDotNet") Otherwise, you need to need to: (1) add the OBDotNet distribution folder to the PATH environment variable (2) include the full path to the OBDotNet.dll when adding the