You are viewing knowbody

Mon, Apr. 12th, 2010, 11:26 am
Top Three Reasons to Upgrade to .NET 4.0 Today

Startup Time for IronPython 2.6.1 for .NET 4.0 is 30% Faster




Where exactly is this improvement coming from?  Well we don't know quite yet.  Our first bona fide .NET 2.0 SP1 versus .NET 4.0 IronPython perf suite run occurred less than two weeks ago!  An educated guess is that at least a small portion of this improvement stems from the fact that Microsoft.Scripting.Core.dll is actually part of the .NET 4.0 framework.  Any ways, you can see more of the performance characteristics of IronPython running under both these .NET releases here


Beautiful is better than Ugly and Simple is Better than Complex

.NET 2.0 SP1 versus .NET 4.0 DLR Hosting APIs
 
The screenshot above shows a small C# snippet of code utilizing a Python module both as a .NET 3.5 application (top) and as a .NET 4.0 application (bottom).  Both of these snippets have been diffed to highlight differences in red. 

It should be blindingly obvious that the bottom snippet is far more readable due to the use of C# 4.0’s new dynamic type.  What the hell’s an “IDynamicMetaObjectProvider” supposed to be any ways?  In any event, our DLR and IronPython hosting APIs are adhering more to the Zen of Python with each release.


Python and Ruby Play Nice Together

Command Prompt
 
In the Command Prompt session above, I’ve created a trivial Ruby class, RubyPC, which provides a factorial method, fact, in rbfactorial.rb.  From there, I started an IronPython interactive session and directly called into the rbfactorial Ruby script via our clr builtin Python module.  Let’s see you do that from other implementations of Python:-)

IronPython 2.6.1 for .NET 4.0 and IronRuby 1.0v4 are the first two major releases of these dynamic languages that share the same Dynamic Language Runtime pedigree.  The end result of this is that they interop together quite nicely out of the box with one small caveat:  you just need to copy “IronPython-2.6.1-Src\IronPython-2.6.1\Config\Signed\App.config” from the source or binary zip file releases to “%ProgramFiles%\IronPython 2.6 for .NET 4.0\ipy.exe.config” and/or “%ProgramFiles%\IronPython 2.6 for .NET 4.0\ipy64.exe.config”.  This configuration file tells IronPython which version of IronRuby it needs to load, and we simply forgot to include this file in the IronPython MSI installer. 


NOTES

Tue, Mar. 24th, 2009, 09:21 am
Building IronPython/IronRuby against the latest Silverlight 2.0 Release

Anyone who’s tried to build the “Silverlight Release” configuration of IronPython.sln in the past month or so may have hit the following issue:

C:\Tmp\IronPython-2.6A1\Src>msbuild /p:configuration="Silverlight Release" IronPython.sln
Microsoft (R) Build Engine Version 3.5.30729.1
[Microsoft .NET Framework, Version 2.0.50727.3053]
Copyright (C) Microsoft Corporation 2007. All rights reserved. 

Build started 3/24/2009 8:44:33 AM.

#...

Project "C:\Tmp\IronPython-2.6A1\Src\IronPython.sln" (1) is building "C:\Tmp\IronPython-2.6A1\Src\Microsoft.Scripting.Core\Microsoft.Scripting.Core.csproj" (4) on node 0 (default targets).

error CS1685 : Warning as error : The predefined type 'System.Runtime.InteropServices.DefaultParameterValueAttribute' is defined in multiple assemblies in the global alias; using definition from 'C:\Tmp\IronPython-2.6A1\Src\Microsoft.Scripting.Core\Stubs.cs'

#...

The quick way to fix this is to replace all occurrences of “2.0.31005.0” with “2.0.40115.0” throughout IronPython/DLR sources before building the *.sln file. The reason why is as follows - the somewhat cryptic error message above stems from the fact that the DefaultParameterValueAttribute is not only implemented by the CLR (see http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.defaultparametervalueattribute.aspx), but it’s also implemented by the DLR in Microsoft.Scripting.Core\Stubs.cs! Looking at Stubs.cs, you’ll notice that strangely this type is only available under Silverlight. This actually makes perfect sense as the CLR shipping with Silverlight 2.0 has been stripped down a bit to conserve disk space and does not provide an implementation of DefaultParameterValueAttribute

So why is msbuild getting confused about which version of DefaultParameterValueAttribute to use? Unfortunately, msbuild does not report a quite useful tidbit of information – the Silverlight assemblies (e.g., C:\Program Files\Microsoft Silverlight\2.0.31005.0\coreclr.dll) referenced by IronPython/DLR C# project files under the “Silverlight Release” configuration don’t exist on disk.  msbuild then defaults to looking for types in the Desktop CLR which most definitely has DefaultParameterValueAttribute implemented.  There are a couple of reasons C:\Program Files\Microsoft Silverlight\2.0.31005.0 might not exist:

1.      You’ve never installed Silverlight on your machine. The solution to this should be pretty obvious

2.      You’ve upgraded from Silverlight 2.0 RTM to Silverlight 2.0 GDR1. Doing this removes the C:\Program Files\Microsoft Silverlight\2.0.31005.0 directory expected by IronPython/DLR projects files and adds C:\Program Files\Microsoft Silverlight\2.0.40115.0. The fix here is to update all references of “2.0.31005.0” throughout IP/DLR sources to “2.0.40115.0” or whatever newer version of Silverlight 2.0 you’re running

3.      You’ve installed Silverlight somewhere other than C:\Program Files\Microsoft Silverlight. Again, you’ll need to update all references throughout IP/DLR sources

Thu, Feb. 12th, 2009, 10:26 am
All Quiet on the 'Iron' Front

Our internal source control system for IronPython is being taken offline for a few days to get some upgrades, and there's also a big office shuffle within our group starting today.  This basically means two things to the outside world:
  1. No new source updates to the IronPython or DLR CodePlex source repositories until next week when the internal source control system comes back online
  2. Expect slower response times for messages posted to the IronPython/IronRuby/DLR mailing lists.  We won't even have the capability of remotely logging into our machines at Microsoft tomorrow