IronPython Updates
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 release mode rather than debug, so here it is:
>C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild /p:configuration=release IronPython.sln
It is the property ('/p:') setting that sets the build configuration to release instead of the default debug build.
The good news is that compiling packages works. Even better, compiling packages with sub-packages works. Unfortunately, compiling packages with sub-packages with sub-sub-packages is broken - so we still can't test a binary distribution of Resolver One. At least there is time for it to be fixed before the final release.
Speaking of final release, there is still no official date but there was a hint of a rumour of something being prepared for PDC (October 27-30th) so it may not be far off.
Curt Hagenlocher (IronCurt) let some more good news slip on the mailing list today. Apparently the RC1 installer for IronPython "will have the option of GACing and/or NGENing IronPython". Cool.
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 release mode rather than debug, so here it is:
>C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild /p:configuration=release IronPython.sln
It is the property ('/p:') setting that sets the build configuration to release instead of the default debug build.
The good news is that compiling packages works. Even better, compiling packages with sub-packages works. Unfortunately, compiling packages with sub-packages with sub-sub-packages is broken - so we still can't test a binary distribution of Resolver One. At least there is time for it to be fixed before the final release.
Speaking of final release, there is still no official date but there was a hint of a rumour of something being prepared for PDC (October 27-30th) so it may not be far off.
Curt Hagenlocher (IronCurt) let some more good news slip on the mailing list today. Apparently the RC1 installer for IronPython "will have the option of GACing and/or NGENing IronPython". Cool.
Comments
Post a Comment