Planet IronPython

A Little Bit of Python is an occasional podcast on Python related topics with myself, Brett Cannon, Jesse Noller, Steve Holden and Andrew Kuchling. The website is in progress and apparently nearly ready, thanks to Jesse and various other people who we will thank as soon as it is done. ... [233 words]

I hate doing releases. I haven't managed to automate the whole process (I should probably work on that), although setup.py sdist upload certainly helps. ... [290 words]

discover is a test discovery module for the standard library unittest test framework. Test discovery is built into unittest in Python 2.7 and 3.2. ... [335 words]

UPDATE: A simpler version of these instructions is available on the django-ironpython Bitbucket page.

This guide will explain how to setup and attempt to run the Django test suite on IronPython. Once the test suite runs, it should be much easier to fill in the parts of Django that don't work properly.

What You'll Need

It's not terribly difficult to set this up, but there are quite a few pieces.

• IronPython 2.6 – use the installer so that you get the standard library as well.
• Django trunk – an SVN checkout for now; if you have Mercurial, you can get it from django-ironpython.  Following the hg repo will get you my IronPython fixes.
• adonet-dbapi – For the sqlite3 module implementation – MS SQL is a future target, but not right now (use the "get source" link if you don't have hg installed).
• System.Data.SQLite – used by the sqlite3 module (just download the binary zip; no need to install)
• 1 cup flour…

Getting Started

First up, install IronPython and checkout the Django trunk and adonet-dbapi somewhere. I'll use %USERPROFILE%\Documents\Repositories\django\ and %USERPROFILE%\Documents\Repositories\adonet-dbapi\ in these examples. Next, create a "DLLs" folder in the IronPython install folder and drop System.Data.SQLite.dll into it (this way IronPython will automatically reference it).

The next step is to prepare the Django test suite. This requires you to create a small Django app that contains things like database settings. The full instructions can be found on Alex Gaynor's blog, or you can download it and unzip it (I'll assume %USERPROFILE%\Documents\Repositories\django-test\).

Running the Tests

OK, command prompt time – if you're not comfortable with the command prompt, this won't be for you.

set PATH=%PATH%;C:\Program Files (x86)\IronPython 2.6
set IRONPYTHONPATH=%USERPROFILE%\Documents\Repositories\django\;%USERPROFILE%\Documents\Repositories\adonet-dbapi\abapi;%USERPROFILE%\Documents\Repositories\django-test\
set DJANGO_SETTINGS_MODULE=django_test.settings

Now, make sure you're in the django directory and run the test cases:

cd %USERPROFILE%\Documents\Repositories\django\
ipy tests\runtests.py -v 1

So far, so good.

The Problems

It'll bomb immediately on an assertion failure. Django does not like the fact that on IronPython str == unicode and thus their lazy evaluation doesn't work immediately (see issue #1 for details). Comment out that assertion, and it fails again – and I haven't fixed this one yet. Stay tuned.

This obviously doesn't account for empty lines, comments, etc., but it works:)

function get-numlines($filter) {
    $num_lines = 0
    ls -recurse -filter $filter |% {gc $_.FullName | measure-object} | % {$num_lines+=$_.Count}
    return $num_lines
}

get-numlines *.py

This post applies to any ASP.NET app that uses .aspx files, whether WebForms or MVC. When you write an aspx/ascx/master file (I’ll just say aspx for here on, but it applies to all), it gets compiled dynamically by the ASP.NET runtime.  Note that this is true whether you use a Web Site or a Web Application Project (WAP).  While in a WAP, most of the code is built by Visual Studio, the aspx pages themselves are always built dynamically . Normally, when you work with aspx files, you only need to worry about what you write in there, and the specifics of what ASP.NET generates under the cover are somewhat of an implementation details.  However, in some cases it’s pretty useful to look at the generated code, either to learn exactly...(read more)

We have just released our first preview of Moonlight 3.0.

This release contains many updates to our 3.0 support, mostly on the infrastructure level necessary to support the rest of the features.

In the release:

• MP4 demuxer support. The demuxer is in place but there are no codecs for it yet (unless you build from source code and configure Moonlight to pick up the codecs from ffmpeg).
• Initial work on UI Virtualization.
• Platform Abstraction Layer: the Moonlight core is now separated from the windowing system engine. This should make it possible for developers to port Moonligh to other windowing/graphics systems that are not X11/Gtk+ centric.
• The new 3.0 Binding/BindingExpression support is in.
• Many updates to the 3.0 APIs

The above is in addition to some of the Silverlight 3.0 features that we shipped with Moonlight 2.0.

For the adventurous among you, our SVN version of Moonlight contains David Reveman's pixel shader support:

From Silverlight Parametric Pixel Shader.

I will be arriving in Brussels on Saturday Morning for the FOSDEM conference. We have an activity-packed day on Sunday of all-things-mono.

This is the current schedule, pretty awesome!

Feedback requested: My plan is to do a state-of-the-union kind of presentation on Mono, but if you have a specific topic that you would like me to present on, please leave a comment, I will try to prepare for that.

See you in Brussels!

I recently did an interview on Python with the Pardus Linux magazine. Pardus Linux is a distribution developed in Turkey (by the Turkish National Research Institute of Electronics and Cryptology) with the goal of being usable by "normal" people rather than just geeks. ... [3716 words]

Currently, programs IronPython is not particularly easy to debug – they Python code gets mixed in with the code for IronPython itself and can be hard to follow. This is the first of a few tricks to make debugging easier.

Trigger a Breakpoint

This is my favourite and most used technique – I sometimes wish Python had the equivalent of JavaScript's debugger keyword to make it easier to use. The trick is to use the System.Diagnostics.Debugger.Break() function to insert a breakpoint in your code – when the breakpoint is hit, Windows will offer to launch a debugger for you. Also make sure that you launch IronPython with the –X:Debug switch, or it will be next to impossible to debug.

Insert the following line where you want to trigger the breakpoint:

import System.Diagnostics; System.Diagnostics.Debugger.Break()

Windows will then open the following dialog (if you have Visual Studio installed; I don't have a machine without VS to see what it looks like otherwise):

I prefer to use VS for debugging, so I'll open a  new instance of Visual Studio 2008.

Browsing the Call Stack

Now, we'll need to go looking for the actual Python code in the call stack. Open the call stack browser, and you'll see something like this:

There are a few things to note here, especially if you're not familiar with the VS debugger:

• Each line represents a call stack frame (a function call, basically).
• The yellow arrow is the current execution location; this is our breakpoint.
• Faded-out lines are frames that do not have any debug information available. They can be ignored.
• Lines beginning with "Snippets.debug" are the actual Python stack frames we are looking for. Double click on those lines to open up the source for those files in the Visual Studio editor.

Once the Python source is loaded in the editor, you can inspect variable values by hovering over them with the mouse, just like in any other Visual Studio language. To find the calling stack frame, you'll have to skip over several IronPython frames to find the next Python frame.

A better experience would elide the IronPython frames; perhaps Harry Pierson's debugger work could be applied to improve it. That, and other Visual Studio improvements for IronPython, are another project entirely.

A Little Bit of Python is an occasional podcast on Python related topics with myself, Brett Cannon, Jesse Noller, Steve Holden and Andrew Kuchling. We still don't have our own website although that is due to land any day now. ... [172 words]

iPad - Inspirational Hardware

As a software developer, I find the iPad inspirational.

Apple's iPad is not a new idea. They are not the first ones to think of a tablet and as many blogs have pointed out the Apple iPad is not everyone's dream machine, the hardware is lacking gadgets and the software is not that amazing.

Five elements come together to revolutionize software:

1. Price
2. Multi-touch centric development
3. Standard hardware available for consumers
4. Apple's AppStore
5. Large form factor.

The iPhoneOS is a multi-touch centric operating system. For years application developers have been subjected to the tyranny of the mouse and keyboard. This has been the only input technology that developers could reliably depend on and expect to be available on the user's system. Any software that requires different input mechanism sees its potential market reduced.

The mouse is a great device for certain class of desktop applications. But it has also led to applications that are incredibly frustrating to use. Software for editing music and audio is cumbersome. Find the target, drag it, move it, find the other button, click it, scroll, drag, click. Anyone that has used Garage Band to try to play along knows this. The same applies to software to paint or draw. The mouse and keyboard are poor substitutes for using your hands.

On the iPhone, and now the iPad, the situation is reversed. Multi-touch is the only input mechanism that developers can depend on. Apple's iPhone helped create a community of developers that think in terms of taps, pinches and twirls instead of clicks, double-clicks and right-clicks. It is no longer an after thought. It is no longer a feature that is added if there is enough time in the schedule or enough budget. It is the only option available.

Taps, pinches and twirls allow us to use the full expression of our hands to drive an application. And it is not just any multi-touch, it is multi-touch over the same surface where the application is providing feedback to the user. Software that respond to user input in the same way that a physical object responds to our physical contact is the key to create new user experiences.

This is a whole new space in which we can research, a new space that we can explore and where we can create a whole new class of computer/user interactions. With the new form factor, we can now create applications that just made no sense on the iPhone.

It is fascinating.

The standardized hardware means that software developers do not have face testing their software with dozens of combinatorial options. There are only a handful types of systems. If the software works on the core systems, they will work on all consumer devices. Standardized hardware is at the core of the success of the console gaming market, developers test and develop against a uniform platform. Price is the cherry on top of the cake, this device will be mass produced and the affordable price means that it will have a deep reach.

The possibilities for new computer/user interactions are no longer dampened by this market reality. As developers, a new door to invention and innovation has been opened for us. No longer will software developers have to cripple their user experiences based on the mouse and keyboard.

For the past couple of years I have had some ideas for some software that I wanted to build on a touch-based computer, but the specter of having a small user base for my experiments always discouraged me. Ever since I heard the rumors about Apple producing a tablet computer I have not cared about what the device looked like, or what the software stack for it was going to be. I wanted to try new touch-based UI ideas, I have dozens of ideas that I want to try out. And with Mono, I get to do it in my favorite language.

24 hours after we got the iPad SDK we completed the support for the iPad for MonoTouch!

To get started with iPad development, go to http://monotouch.net/iPad and follow the instructions.

Let the iPad# hacking begin!

Nice new releases of software that I use in the last few days.

Banshee 1.5

A new Banshee release, now supports new device syncing options, audiobooks, eMusic and GIO for non-local files. Gabriel has more details as well.

Now with a fully self-contained Mono and Gtk+ stacks on OSX. On the OSX note, I recommend Michael Hutchinson's blog entries on how to package your Gtk# app for use in OSX as well as his article on how to make your Gtk# app integrate with OSX. Both based on the lessons of bringing MonoDevelop and MonoDoc to OSX.

Jeroen Frijters released his IKVM.Reflection API. His API could be very useful for Reflection-Emit compiler writers, perhaps we could even use it in Mono's C# compiler to solve our long standing issues with Reflection. More research is needed on this area.

Maurits Rijk has published a new version of GIMP# his Mono-based plugin engine that lets you write plugins in any Mono supported language. There are samples in C# 3, F#, Boo, Nemerle, Oxygene, IronPython, Java/IKVM and Visual Basic.

Sandy released a new version of Tomboy, now supports exporting data in HTML format to the clipboard and jump Lists on Windows 7.

This is a collection of thoughts and a summary of a mailing list conversation about LINQ support in IronPython. The IronPython team (which seems to be just Dino & Dave at this point) seemed receptive to the idea; it's just a matter of resources. Therefore, please vote on the linked issues so that they can get their priorities straight.

There are two key parts to LINQ support: extension methods and expression trees. Each is useful on its own, but both are required to really take advantage of LINQ.

Extensions Methods

An extension method is a way of adding a function to a class without editing the class, or providing a default implementation for a class implementing an interface. LINQ is almost entirely composed of extension methods on the IEnumerable<T> and IQueryable<T>interfaces, so supporting them in IronPython is critical to supporting LINQ and many other interfaces. In this case I'm only talking about IronPython being able to c0nsume extension methods, not create them.

In C#, an extension method is made available by a using directive for the namespace containing a static class that contains the method. For example, the Enumerable class is in the namespace System.Linq and contains about half of LINQ's extension methods. To use this class from C# requires only:

using System.Linq;

The Python equivalent of this would be:

from System.Linq import *

Now, this style is frowned upon in Python circles because it pollutes the namespace unnecessarily. A more Pythonic equivalent would be:

from System.Linq import Enumerable

When doing an import, IronPython would have to check if Enumerable contains any static methods marked with ExtensionAttribute and add them to the list of possible methods to resolve for the applicable type. I actually tried to implement this at one point, but haven't had the time to finish it up.

The issue for this is CodePlex #17250 - Support for LINQ extension methods.

Expression Trees

An expression tree is an abstract, language-independent representation of a piece of code that can be more easily parsed and transformed than the raw code it was generated from. From the expression tree, the LINQ provider (such as LINQ to SQL) determines how to convert it into a query in its target language (such as SQL). The DLR actually uses "expression" trees as well (a superset of the LINQ classes that support statements as well as expressions), which are compiled into IL code and then executed.

In C# (and VB), lambda expressions are convertible to expression trees. Python also has lambda expressions, and these should also be convertible to expression trees – in particular, expression trees that exactly match what would be created by the C# compiler for an equivalent lambda, which is what every existing LINQ provider would expect.

The issue for this is CodePlex #26044 - lambda should be convertible to Expression<...>.

Another Mono-race, in 24 hours we are aiming to:

• Support the iPad SDK from Apple (freshly baked and published).
• Add MonoDevelop support for it.

Djlawler: Created page with 'You can compile an IronPython class to a DLL and then use IronPython hosting in c# to access the methods (this is for IronPython 2.6 and .Net 2.0). Create a c# program like this…'

---

Djlawler: Created page with ' using System; using IronPython.Hosting; using Microsoft.Scripting.Hosting; // we get access to Action and Func on .Net 2.0 using Microsoft.Scripting.Utils; …'

---

Djlawler:

---

Djlawler: Created page with 'You can compile an IronPython class to a DLL and then use IronPython hosting in c# to access the methods (this is for IronPython 2.6 and .Net 2.0). Create a c# program like this…'

---

Following up to my previous post on IronPython worker roles, I'm going to discuss how to implement web roles using IronPython. The code discussed here is on bitbucket, as usual.

There are currently two ways to implement IronPython web roles on Azure: using the ASP.NET Dynamic Language Support or using NWSGI. Someday I hope the IronRubyMVC project matures to be an option as well.

Using ASP.NET Dynamic Language Support

This example can be found in the PyWebRole folder of the project.

First, you'll need to download the ASP.NET Dynamic Language Support (ASP.NET DLS) files. Next, create a standard C# web role and delete all of the .cs files except WebRole.cs. After that, there's really not much to it – drop the assemblies from the ASP.NET DLS package into the project's bin folder and add the following bits to the web.config file (alternatively, just copy the Web.config from the project):

<configSections>
    <!-- Add this to the existing <configSections> element -->
    <section name="microsoft.scripting" type="Microsoft.Scripting.Hosting.Configuration.Section, Microsoft.Scripting, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" requirePermission="false"/>
</configSections>

<system.web>
    <!-- Replace the existing <pages> element (if any) -->
    <pages compilationMode="Auto" pageParserFilterType="Microsoft.Web.Scripting.UI.NoCompileCodePageParserFilter" pageBaseType="Microsoft.Web.Scripting.UI.ScriptPage" userControlBaseType="Microsoft.Web.Scripting.UI.ScriptUserControl">
        <controls>
            <add tagPrefix="asp" namespace="System.Web.UI" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
            <add tagPrefix="asp" namespace="System.Web.UI.WebControls" assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
        </controls>
    </pages>
</system.web>

<system.webserver>
    <modules>
        <!-- Add this to the existing <modules> element -->
        <add name="DynamicLanguageHttpModule" preCondition="integratedMode" type="Microsoft.Web.Scripting.DynamicLanguageHttpModule"/>
    </modules>
</system.webserver>

<!-- Add this whole section -->
<microsoft.scripting debugMode="true">
    <languages>
        <language names="IronPython;Python;py" extensions=".py" displayName="IronPython 2.6" type="IronPython.Runtime.PythonContext, IronPython, Version=2.6.10920.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    </languages>
</microsoft.scripting>

From here, just follow the directions on the ASP.NET DLS page and in the package to create an ASP.NET Dynamic Language site.

NWSGI

First, download NWSGI 2.0. Next, deploying NWSGI to Azure is exactly the same as deploying it to any other server using xcopy. That's about it. You can see this example in the PyHelloWorld folder of the project.

Now What?

Unfortunately, now you're pretty much on your own. So far, none of the big Python web frameworks work 100% on IronPython, there is no Python library to access Azure's storage tables, blobs, or queues, and the .NET storage client library relies on LINQ support (which IronPython doesn't have, yet).

Personally, I plan to implement the data access in C# and call that from IronPython, running my own web framework. We'll see how it goes.

$1000 and a trip to MIX 2010!

 

9 days left, an counting, to enter your minimalist creation into the MIX 10K Smart Coding Challenge. Do anything you want, it just has to be less than 10 kilobytes of source code. You can use HTML5, or Silverlight, and also use Ruby or Python through Gestalt (learn more about the entry rules). You can win a free trip to MIX and up to $1000 in cash (learn more about the prizes).

Check out the already submitted apps for inspiration; they are starting to look really awesome.

As an added bonus, I’m part of the MIX 10K Judge Panel! Since I work on IronRuby and IronPython, and wrote/maintain Gestalt, I’ll be “very happy” if I you submit a Ruby or Python app. Of course I won’t be biased against JavaScript or C# based apps, but just sayin’ … ;)

Entries will be accepted through January 29, so …

#mix10k_enter, #mix10k_enter:link, #mix10k_enter:visited { border-bottom: #666 3px solid; border-left: #666 3px solid; padding-bottom: 10px; background-color: #444; margin: 10px 50px 20px 0px; padding-left: 10px; padding-right: 10px; display: block; color: white; font-size: 24px; border-top: #666 3px solid; border-right: #666 3px solid; padding-top: 10px; } #mix10k_enter:hover { background-color: #555; text-decoration: none; }Enter your app right now »

Note: this is based on ASP.NET MVC 2 RC , and will not work on earlier builds.   The quick pitch: make your User Controls as cool as built-in render helpers! The goal of this post is to show you how to change the way MVC user controls are called from something like this: <%= Html.Partial("~/Views/Shared/gravatar.ascx", new { Email = "foo@bar.com", Size = 80 }) %> To something that looks just like a built-in render helper (like Html.TextBox(…)): <%= Html.Gravatar("foo@bar.com", 80) %>   The current model for User Controls in MVC If you have used ASP.NET MVC, you probably know that you can use User Controls (.ascx files) to provide partial rendering. For example, the default MVC app has a Site...(read more)

Pysco is a specializing compiler (a kind of JIT) for Python written by Armin Rigo. The difficulty of maintaining and extending psyco was one of the motivating factors behind the inception of PyPy. ... [191 words]

Thanks to everyone that participated in the campaign to nominate me for a C# MVP award, when I got back to Boston I found on my piles of email that I am now part of the program.

This is Pretty Sweet(tm). This will be a great opportunity to build more bridges with Windows developers and show them that there is an ECMA CLI life in the other side of the OS spectrum.

Looking forward to the group picture!

This year we will have a Mono Room at the FOSDEM Conference in Brussels. The FOSDEM conference is held on the weekend on February 6th and 7th.

Ruben and Stephane organized the room and the speakers for the it. has posted the finalized schedule for the Mono activities at FOSDEM on Sunday.

Here is the schedule, there are some pretty interesting talks:

09:00 - 09:15	Opening (Ruben Vermeersch, Stéphane Delcroix)
09:15 - 10:00	MonoDevelop (Lluis Sanchez Gual)
10:00 - 11:00	The Ruby and .NET love child (Ivan Porto Carrero)
11:00 - 12:00	Mono Edge (Miguel de Icaza)
Lunch Break
12:45 - 13:15	The evolution of MonoTorrent (Alan McGovern)
13:15 - 13:45	Image processing with Mono.Simd (Stéphane Delcroix)
13:45 - 14:15	ParallelFx, bringing Mono applications in the multicore era (Jérémie Laval)
Coffee Break
14:30 - 15:30	Building The Virtual Babel: Mono In Second Life (Jim Purbrick)
15:30 - 16:00	Moonlight and you (Andreia Gaita)
16:00 - 16:30	OSCTool - learning C# and Mono by doing (Jo Shields)
16:30 - 16:45	Smuxi - IRC in a modern environment (Mirco Bauer)
16:45 - 17:00	Closing (Ruben Vermeersch, Stéphane Delcroix)

Curiosity has finally got the better of me and I've started looking into Windows Azure again. It's matured quite a bit since I looked at it last year and now looks like a pretty solid platform to work with.

Aside from using NWSGI to write a web role (which I'll show later), I wanted to see if it was possible to write a worker role in Python. Happily, it is, and it's not that complicated. In fact, it's pretty similar to how NWSGI works – load up a Python file and run some functions.

Worker Role Requirements

A standard C# worker roles requires three functions: OnStart, OnStop, and Run:

public class PyWorkerRole : RoleEntryPoint
{
    public override bool OnStart() { /* ... */ }
    public override void OnStop() { /* ... */ }
    public override void Run() { /* ... */ }
}

This can be mapped to a Python module in a fairly straightforward fashion:

def start():
    return True

def run():
    pass

def stop():
    pass

This has some advantages and disadvantages compared to using a class, but I like it for its simplicity.

The Implementation

Azure requires an actual .NET class to implement a worker role, so we create one that hosts the IronPython engine. This is a good example of how to embed IronPython to run very simple scripts. The core IronPython hosting function is shown here; for the rest, see the files linked below.

private void InitScripting(string scriptName)
{
    this.engine = Python.CreateEngine();
    this.engine.Runtime.LoadAssembly(typeof(string).Assembly);
    this.engine.Runtime.LoadAssembly(typeof(DiagnosticMonitor).Assembly);
    this.engine.Runtime.LoadAssembly(typeof(RoleEnvironment).Assembly);
    this.engine.Runtime.LoadAssembly(typeof(Microsoft.WindowsAzure.CloudStorageAccount).Assembly);                 
    
    this.scope = this.engine.CreateScope();
    engine.CreateScriptSourceFromFile(scriptName).Execute(scope);             
    
    if(scope.ContainsVariable("start"))
        this.start = scope.GetVariable<Func<bool>>("start");
    
    this.run = scope.GetVariable<Action>("run");
    
    if(scope.ContainsVariable("stop"))
        this.stop = scope.GetVariable<Action>("stop");
}

First, we create a ScriptEngine and add some useful assemblies;  then we create a Scope to execute in; then we actually execute the script. Finally, we try to pull out the functions and convert them to C# delegates; run is required but start and stop are optional. Those delegates are called from the C# wrapper (from Run, OnStart, and OnStop, as appropriate).

The rest of the file is pretty much taken from the worker role template, so I'll leave it out.

Doing Actual Work

Now, a worker role needs some actual work to do – usually, reading items from a queue and processing them. Happily, the Azure StorageClient library is perfectly usable from IronPython.

from Microsoft.WindowsAzure import CloudStorageAccount
from Microsoft.WindowsAzure.StorageClient import CloudQueueMessage, CloudStorageAccountStorageClientExtensions

def run():
    account = CloudStorageAccount.FromConfigurationSetting("DataConnectionString")
    queueClient = CloudStorageAccountStorageClientExtensions.CreateCloudQueueClient(account)
    queue = queueClient.GetQueueReference("messagequeue")

    while True:
        Thread.Sleep(10000)

        if queue.Exists():
            msg = queue.GetMessage()
            if msg:
                Trace.TraceInformation("Message '%s' processed." % msg.AsString)
                queue.DeleteMessage(msg)

The only catch is that CreateCloudQueueClient is an extension method, so it must be called as a static method on the CloudStorageAccountStorageClientExtensions class.

Using the Code

To actually use the code, create a C# worker role as per usual, but replace the generated class file with PythonWorkerRole.cs (see below). Next, add the IronPython assemblies as references to the project. Then, create a string setting for the role (under the Cloud project's Roles folder) called ScriptName and set it to the name of the script file. Finally, add a .py file to the worker role and ensure that (under 'Properties') its 'Build Action' is 'Content' and 'Copy to Output' is 'Copy if Newer'.

The code can be downloaded from my PyAzureExamples repository, including zip archives of it. It includes the PyWorkerRole project and the Cloud Service project.

I was thinking about the Python object model, in part as a result of my post on The Python Class Statement. Python is a really easy language to learn, but it also has advanced features like its protocols, descriptors and metaclasses, that make the full object model pretty complex - and that's before you start looking at the corner cases. ... [539 words]

Python classes are created at runtime, usually when you execute a script, or import the module they are defined in. Class creation is done primarily with the class statement. ... [889 words]

I've just released ConfigObj 4.7.0 and validate 1.0.1. ConfigObj is an easy to use configuration file reader and writer module. ... [576 words]

PyCrypto is a Python cryptography package originally created by Andrew Kuchling and now maintained by Dwayne C. Litzenberger. For a while I've been hosting Windows binaries for version 2.0.1. ... [126 words]

David Reveman has just posted a fascinating patch that debuts the support of pixel shaders in Moonlight.

David's patch uses Gallium, and he says:

The current implementation uses gallium's softpipe driver but hooking up the llvm driver as well should be a minor task and give significantly better software performance.

[...]

My current approach is to focus on getting all these things working in software first. By using a OpenVG backend for cairo we can incrementally move to using gallium and hardware for all rendering.

I have switched all my accounts over to engrstehpens

I have reposted all these blogs to my new blog!

Unicode is a rabbit-warren of complexity; almost fractal in nature, the more you learn about it the more complexity you discover. Anyway, all that aside you can have great fun (i.e. ... [554 words]

Chris Toshok has landed the changes necessary to abstract Moonlight's engine from the platform.

The platform abstraction layer lives in moon/src/pal and the Gtk+ interface lives in moon/src/pal/gtk.

This is a necessary step to bring Moonlight to non-X11 powered GUI systems.

I'm helping to organise the Python Language Summit that precedes the PyCon Conference this year. One of the first topics we'll be discussing is "Python 3 adoption and tools and the Python language moratorium" which will include representatives of the major Python implementations telling us the current state of their implementation and their plans or progress for supporting Python 3. ... [561 words]

To get the latest build of T4MVC: Go to T4MVC page on CodePlex   I just posted build 2.6.10.  There were also a few builds in between since I last blogged about 2.6, so this post describes some of those changes (full history here ).   Fluent route value API As you probably know, T4MVC uses a pattern where the route values are encapsulated using a pseudo-call to a controller action, e.g. Html.ActionLink("Delete Dinner", MVC.Dinners.Delete(Model.DinnerID)) This adds the controller, the action and the method parameters to the route values in a convenient way with no hard coded strings. But in some situation, you may need to add extra values to the route that don’t exist in the action method.  Now you can do it as follows...(read more)

In 2009 I made 312 posts on IronPython-URLs, a bit short of an average of one a day that it looked like I might manage earlier in the year.

According to google analytics there were more than 112 thousand page views to a total of 2042 pages on the blog. An average of over three hundred page views a day. Feedburner estimates that this blog has around eight hundred readers. Many of those will read the articles via RSS or Planet Python and rarely visit the website.

It's interesting to note that of the most popular articles in 2009 (most page views) several of them are to do with choice of IDE or using IronPython with Visual Studio. The question of which IDE to use with IronPython is still alive and well:

1. New Sample: Writing a DLR Language in C# or IronPython  (May 2009, 1892 page views)
2. IronPython in SharpDevelop 3.1 and Converting C# to IronPython  (May 2009, 1412 page views)
3. C# Becomes a Dynamic Language...  (December 2008, 1164 page views)
4. Python is the easiest language in which to do interesting things  (February 2009, 1150 page views)
5. Python Support in Visual Studio  (June 2009, 1119 page views)
6. Another IDE for IronPython? Eclipse and PyDev  (July 2009, 1077 page views)
7. Davy's IronPython Editor  (January 2009, 1032 page views)
8. Jeff Hardy: Django, Zlib and easy_install on IronPython (January 2009, 949 page views)
9. Writing an IronPython Debugger  (March 2009, 816 page views)
10. Running Python from C#  (September 2008, 789 page views)

My recent post Does Microsoft Take Dynamic Languages Seriously looks a bit at how much work it would be to get IronPython support in Visual Studio, and there have been a couple of interesting posts on this topic since. IDEs and IronPython is a topic that is likely to continue to be of interest in 2010 as well.

This is the blog entry I had nearly finished when I started messing around with Mock on Saturday. Started by Tarek Ziade, five short questions on you and Python in 2009 (or in this case me and Python)... ... [1050 words]

In the last few days I've run into several things I didn't know about Python. Not necessarily bad or wrong, just new to me. ... [593 words]

I have taken it on myself to try and expand and inspire people’s view of what a web application can do.  In this installment I’m leveraging Silverlight 4 and Matlab to build a simple Matlab console.

Again I am using COM automation to communicate with Silverlight.  Why would anyone want to do this? Well, I’m slowly porting some Matlab code to c# so it is nice to check my code by communicating with Matlab.  Matlab also has an insane amount of its own functions so if you wanted to build a neural network but use Silverlight to display and distribute your code then Silverlight 4 is for you!

using System;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Input;
using System.Windows.Interop;

namespace SLMatlab
{
    public partial class MainPage : UserControl
    {
        dynamic matlab;
        public MainPage()
        {
            InitializeComponent();
            input.IsEnabled = false;
            output.IsEnabled = false;
            Install.Visibility = Visibility.Collapsed;
            if (Application.Current.InstallState != InstallState.Installed)
            {
                MessageBox.Show("To run this, this application must be installed, Please click install.");
                Install.Visibility = Visibility.Visible;
                Connect.IsEnabled = false;
            }
            else if (!Application.Current.IsRunningOutOfBrowser)
            {
                MessageBox.Show("This application is installed but is running inside the browser. Please launch this from the desktop!");
                Connect.IsEnabled = false;
            }
        }

        private void Connect_Click(object sender, RoutedEventArgs e)
        {
            try
            {
                matlab = ComAutomationFactory.CreateObject("Matlab.Application");
                matlab.Visible = 0;
                input.IsEnabled = true;
                output.IsEnabled = true;
            }
            catch { }
            
        }

        private void input_KeyDown(object sender, KeyEventArgs e)
        {
            try
            {
                if (e.Key == Key.Enter)
                {
                    dynamic result = matlab.Execute(input.Text);
                    input.Text = "";
                    output.Text = result.ToString() + Environment.NewLine + output.Text;
                }
            }
            catch { }
        }

        private void Install_Click(object sender, RoutedEventArgs e)
        {
            App.Current.Install();
        }
    }
}

<UserControl x:Class="SLMatlab.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">

    <Grid x:Name="LayoutRoot" Background="White">
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"></RowDefinition>
            <RowDefinition Height="Auto"></RowDefinition>
            <RowDefinition Height="Auto"></RowDefinition>
            <RowDefinition Height="*"></RowDefinition>
        </Grid.RowDefinitions>
        <Button Name="Install" Content="Install" Grid.Row="0" Click="Install_Click"></Button>
        <Button Name="Connect" Content="Connect" Grid.Row="1" Click="Connect_Click"></Button>
        <TextBox Name="input" Grid.Row="2" KeyDown="input_KeyDown"></TextBox>
        <TextBox Name="output" Grid.Row="3"></TextBox>
    </Grid>
</UserControl>

So, I'm most of the way through one blog entry, my tax return is due, I have a PyCon talk to write and I have a release of ConfigObj [1] just waiting for me to finish updating the docs. Naturally then I should mess around implementing new features for Mock. ... [1166 words]

Jcao219:

---

Another collection of IronPython and DLR related articles from around the web. A fine way to end 2009.

• SLog: Silverlight Logging

A nascent project to Port Log(4|5)J from Java to C# with the goal of usefulness in Silverlight, especially for IronPython.

• A WPF Picture Viewer
• NotifyIcon to use from IronPython

 Two Japanese blog entries, both by sasakima-nao. As with previous entries the code examples are very readable. The first is a simple WPF picture viewer (nice penguins) and the second shows how to create a NotifyIcon and ContextMenu in the taskbar (with Windows Forms classes).

• Python-Ruby (and a little bit of soap)

This blog entry is in Russian, but I think there are enough code examples for it to be useful for those of us who don't speak Russian. As I've mentioned before the promise of the Dynamic Language Runtime is that dynamic languages can interoperate and share libraries. This is exactly what this blog entry shows: using the Ruby soap/wsdlDriver from Python.

The cool thing is that this is done with a helper / wrapper library, that looks like it could be used to expose virtually any Ruby module / class that can be accessed through IronRuby to IronPython. Using his ruby module, the code looks like this:

from ruby import _import_, get_class
_import_('soap/wsdlDriver')
Soap = get_class('SOAP::WSDLDriverFactory')

client = Soap('http://localhost1/Service1.asmx?WSDL').create_rpc_driver()
client.HelloWorld(None)

• I've Been Bitten By... IronPython

Marcus McElhaney has discovered IronPython and likes it. The reasons he gives are:

1. I can very easy use everything I know about the .Net Framework, VB.Net, and  C#
2. I can run IronPython in Visual Studio
3. I can reference ESRI's  ArcObjects libraries in  Visual Studio and IronPython

What's even more gratifying is that he has been exploring IronPython through IronPython in Action and likes that too. A slight misspelling gives rise to my favourite quote about IronPython in Action:

IronPython In Action is probably the best Python book I have ever pickled up because it also explains a lot of not just Python but also about .Net.

If any book deserved to be pickled up, this is it... Have a great 2010.

Hard. Very hard.

Michael Foord has a good post about whether Microsoft cares about dynamic languages. Some people [who?] believe that because IronPython/IronRuby don't have full support in Visual Studio 2010 that Microsoft doesn't care about dynamic languages.

I think I can safely say that adding full, high-quality support for IronPython to Visual Studio would require at least a couple of man-years of work. The rabbit hole goes pretty deep when you consider all of the functionality that VS offers, not to mention the difficulty of doing IntelliSense well. I estimate they'd have to at least double the IronPython team to get full support into VS11. IronRuby would require the same commitment.

Also, IronPython and IronRuby have only recently got to the point where I would consider them production-ready. Thus, getting IronRuby or IronPython into VS2010 was never realistic.

Now, if they don't have some support in VS11 (VS2012?), well, that's a different story. At least the IronPython extensions should be pretty mature by then.

I'm very pleased to announce the release of the final version of NWSGI 2.0. It's been a long road since it was first shown as "NWSGI 1.1 Preview1" way back in March. Since then most of the code has been overhauled to make maintenance easier and improve performance. IronPython has also come  a long way; the 2.6 release is a fantastic piece of work with much better performance and compatibility than 2.0. Both IronPython and NWSGI are reaching the point where it will soon be feasible to run most Python web apps with little to no modification – I'm hoping by this time next year that everything will "just work".

What's New

NWSGI 2.0 is mostly a lot of little changes that add up to a much better experience:

• Easier configuration: In v1.0 there were different ways to configure NWSGI depending on your configuration. Now there is only one way to do it. The ambiguous options with multiple meanings are gone, and new options added to support the extra optional features of IronPython 2.6.
• Better management UI: The new management UI is both easier to use and easier to maintain.
• Performance improvements: NWSGI will now cache the WSGI callable and associated modules instead of reloading it each time. IronPython 2.6 is also much faster then 2.0.

More Information

My blog posts from earlier in the year are still relevant:

• Installation & Usage
• Configuration Changes
• Configuration Details
• Disptaching & Advanced Dispatching
• Removing URL Warts

I'll be moving the information in these over to Codeplex soon, so that it's easier to find.

Please let me know what you think of the new release, and what it's being used for – I'm always curious to hear what people think.

My belief is that the answer to the question in the title of this entry is an emphatic yes. Microsoft have poured a lot of money into IronPython, IronRuby and the Dynamic Language Runtime and have demonstrated a consistent commitment since the inception of IronPython. What they haven't done is build full support into their premier development tool, Visual Studio. The reason for this is that it is a very difficult problem. Visual Studio is built around statically typed languages. Features like intellisense, refactoring and code navigation all rely on having type information which is absent in languages like Python and Ruby. (The way they are implemented in Visual Studio requires that information I mean.)

What Microsoft have done is provide example integration in the form of IronPython Studio, which frankly sucks. Many important features are fragile, broken or missing altogether. Good IDEs like PyDev and Wing do provide these features, so it is definitely possible - it just requires a lot of work from scratch.

Microsoft have however added intellisense for Javascript, particularly for jQuery, into Visual Studio. Javascript is of course a dynamic language, but without having tried the integration I can't tell you how well it compares to using a good Python IDE. I believe that Microsoft would like to add support for dynamic languages to Visual Studio and that it will come eventually. Really they have a lot to lose by not doing it.

Now they have a good platform for dynamic developers to use, which they give away free, but the tools they charge for don't really support them. This puts them in a position of either bringing developers to their platform but not being able to make any money, or having their existing developers stay with their platform but losing dependence on the toolset. Neither option looks much good for Microsoft.

(NOTE: for those who can't wait for official Microsoft support and have Visual Studio 2010, try Jeff Hardy's IronPython for Visual Studio Extensions.)

Anyway, K. Scott Allen sees things a little differently and I understand his frustration:

• Is Microsoft taking Dynamic Languages Seriously?
  

Consider this …

IronPython got underway in July of 2004. Five years later it appears IronPython is still not a candidate to be a first class language in the .NET framework and tools. You can vote on this issue.

Microsoft first released IronRuby at Mix in 2007. Nearly three years later it appears IronRuby is still not a candidate to be a first class language in the .NET framework and tools. You can vote on this issue.

A first class language is deployed when the full .NET framework is installed. It’s as easy to find as csc.exe. It’s not a language you have to ask the IT department to install separately. It’s not a language that requires you to jump out of Visual Studio to edit or run.

Most of all, a first class language doesn’t require justification to higher powers. A first class language is pre-certified and stamped with a seal of approval. It’s as easy to use in the locked-down big corporate setting as the company paper shredder.

Of course here we are talking about Microsoft as if it was a single entity with a single intention. The reality of course is that Microsoft is a huge company with many divisions and even more individuals working there. In all likelihood the vast majority of Microsoft employees have never heard of IronPython. The relevant division is the programming languages group, which includes Visual Studio development, and where the majority of employees who are developers probably have heard of IronPython if not actually used it... Adding official dynamic languages support to Visual Studio would require substantial investment of time and effort, so even if everyone in this department was determined to add support it would still be dependent on forces from other parts of the company who have other needs and priorities...

Last week I uploaded version 0.4 of the IronPython Extensions for Visual Studio to BitBucket and the Visual Studio Gallery. This release includes a couple of new features and some minor performance improvements to the old features.

What's New

Squiggles! The editor will now underline inconsistent tabs (mixing tabs and spaces) and syntax errors. It doesn't currently display a tooltip explaining what the underline is for, or offer any automatic fixes, but those should be coming soon.

Also new is an interactive console for use in Visual Studio. The advantage this has over a normal IronPython console is that it will syntax-highlight the console history. Eventually I'd like to have it pull the colour scheme from the editor.

What Else is Included

This release includes the features of the previous release – syntax highlighting and outlining of classes and functions – but I've improved the performance of both to make the editor a little snappier (not much, mind you – ever try running a profiler on all of Visual Studio?).

What's Next

Besides some minor changes to all of the existing features that I'd like to make, there are two big pieces missing: a project system and IntelliSense. IntelliSense is the more interesting of the two, so I think I'm going to tackle it next. If anyone wants to tackle the project system, let me know and I'll give you some pointers.

Ironclad is a compatibility layer that allows you to use Python C extensions with IronPython. Ironclad is open source and development has been funded by Resolver Systems and it is integrated into Resolver One to allow you to use Numpy within Resolver One spreadsheets.

Ironclad works by implementing the Python C API in a combination of C#, C and Python. Although Ironclad only works on 32 bit Windows at the moment the implementation has been done in such a way that porting it to run on other platforms (with Mono) and 64 bit would be relatively easy. Patches welcomed!

Recent development has changed the implementation to use gcc-xml to access and transform the Python C source code. By reusing as much of the original implementation as possible it minimizes the amount that needs to be 'hand-coded'. It leaves only a (moderately) small core that would need to be reimplemented if Jython, PyPy (or other implementations) wanted to reuse Ironclad. The C# would need to be re-coded in Java or RPython, using the platform's native FFI instead of PInvoke on .NET. The advantage of reusing Ironclad is that difficult problems, like handling the Global Interpreter Lock and matching reference counting to different garbage collection strategies, are already solved (well, for some value of solved...).

Anyway, that is all by way of introduction. William Reade, core developer of Ironclad, has just announced Ironclad 2.6 RC. This is a release candidate of Ironclad targeting IronPython 2.6.

• Ironclad 2.6.0rc1 released
  

I'm very happy to announce the latest release (candidate) of Ironclad, the 120-proof home-brewed CPython compatibility layer, now available for IronPython 2.6!

No longer need .NET pythonistas toil thanklessly without the benefits of bz2, csv, numpy and scipy: with a simple 'import ironclad', (most parts of) the above packages -- and many more -- will transparently Just Work.

Get the package from:
    http://code.google.com/p/ironclad/

...and get support from:
    http://groups.google.com/group/c-extensions-for-ironpython

...or just ask me directly.

I'm very keen to hear your experiences, both positive and negative; I haven't been able to test it on as many machines as I have in the past, so your feedback is especially important this time round*.

Cheers
William

* I'd be especially grateful if someone with a newish multicore machine would run the numpy and scipy test scripts (included in the source distrbution) a few times to check for consistent results and absence of weird crashes; if someone volunteers, I'll help however I can.

William has recently started blogging. I recommend browsing the few entries he has already posted, particularly this rant on static typing and this post on .NET marshalling, but his latest is of particular interest:

• Spare batteries for IronPython

As we all know, Python comes with batteries included in the form of a rich standard library; and, on top of this, there are many awesome and liberally-licensed packages just an easy_install away.

IronPython, of course, includes *most* of the CPython standard library, but if you're a heavy user you might have noticed a few minor holes: in the course of my work on Ironclad, I certainly have. Happily for you I can vaguely remember what I did in the course of bodging them closed with cow manure and chewing gum; here then, for your edification and delectation, is my personal recipe for a delicious reduced-hassle IronPython install, with access to the best and brightest offered by CPython, on win32.

More IronPython and DLR related projects, articles and news from around the web.

• Embedded IronRuby and IronPython in Silverlight with Multiple Source Files

A  nice example of embedding both IronPython and IronRuby in a single C# project. As an added bonus the project is a Silverlight project so you can add both Python and Ruby scripting to applications that run in the browser.

• slimtune: A free profiling and performance tuning tool for .NET applications

IronPython 2.6 has useful new hooks for profiling and debugging IronPython code. Unfortunately most 'standard' .NET tools don't know how to use these, and if you attempt to profile IronPython code (particularly in an embedded environment) you have to work hard to get useful information about performance of your Python code. It's nice to see a new (and open source) tool that is designed to work with IronPython:

SlimTune is a free profiler and performance analysis/tuning tool for .NET based applications, including C#, VB.NET, IronPython, and more. It provides many powerful features, such as remote profiling, real time results, multiple plugin-based visualizations, and much more. The source code is available under the terms of the MIT License.

SlimTune is currently in the prototyping phase of development, but a preview release is available for testing and feedback is welcome. Both x86 and x64 targets are supported, but only sampling based profiling is available in the release.

• Future of Managed JScript

When IronPython 2 and the Dynamic Language Runtime were announced one of the three Microsoft developed languages that ran on the DLR was JScript. Managed JScript was an implementation of ECMAScript (otherwise known as Javascript) and touted as a useful bridge for porting 'traditional-ajax' applications to run on Silverlight. Unfortunately as the DLR evolved JScript languished and there was no official word on its fate.

In this post on the DLR Codeplex forum Bill Chiles (DLR Program Manager) gives the bad news:

The DLR JScript was experimental for informing the design of the DLR (expression trees, interop, callsites, hosting, etc.).  The JS we released with asp futures and the Silverlight dynamic sdk became very old and unserviceable as the DLR continued evolving for release in CLR 4.0.  Unfortunately, there are no plans at this time to develop and release a DLR-hostable JScript.

• IronPython SHGetFileInfoW is ctypes

A Japanese blog entry showing example code using the new implementation of ctypes in IronPython 2.6. ctypes is the Python FFI and in IronPython it is built on top of PInvoke, the .NET FFI. ctypes is used for calling into native code, like the Win32 API. Calls SHGetFileInfoW, which "Retrieves information about an object in the file system, such as a file, folder, directory, or drive root."

• IronPython on deviantART

No idea what this has to do with the implementation of Python for .NET, but IronPython is the username of someone on the alternative community art site deviantART. Some pretty nice computer generated art, and who knows - maybe they were created from Python...

IronPython and the Dynamic Language Runtime make it almost ridiculously easy to add scripting to .NET applications.

In recent weeks several examples of using IronPython to add scripting or interactive shells to .NET applications have been posted by the .NET community:

• Command-line scripting of IronPython code in AutoCAD

This post was heavily inspired by the code presented by my old friend Albert Szilvasy during his excellent AU class on using .NET 4.0 with AutoCAD.
...
In this post we’ll take Albert’s technique and implement a command-line interface for querying and executing IronPython script. This approach could also be adapted to work with other DLR languages such as IronRuby, of course.

Here’s the updated C# code which now not only implements PYLOAD functionality, but also a PYEXEC command.

•  Scriptability via the DLR and PostSharp

 Making an application scriptable (particularly in a static language) has historically been difficult. With the advent of the DLR (Dynamic Language Runtime) on the .NET platform it becomes almost trivial to add scripting support to any application. For a recent project I needed the ability to add scripting hooks throughout the application and coupling the DLR with PostSharp AOP attributes made this effort pretty straightforward. Here’s how it was done.

• Revit Python Shell
• Introducing RevitPythonShell
  

According to wikipedia: "Autodesk Revit is Building Information Modeling software for Microsoft Windows, currently developed by Autodesk, which allows the user to design with parametric modeling and drafting elements.  Building Information Modeling is a Computer Aided Design (CAD) paradigm that allows for intelligent, 3D and parametric object-based design."

Jeremy Tavik blogs about working with the Revit API, and in this post he discusses a Python Shell for Revit that created by Daren Thomas with IronPython:

Daren Thomas of the Professur für Gebäudetechnik, Institut für Hochbautechnik at the technical university ETH Zürich has published a Python Shell for Revit. It was implemented using IronPython and is used to automate the running of daily tests of a building energy analysis package. Hosting IronPython via a Revit plug-in is a now solved problem. Daren's intention is to continue publishing samples of what you can do with it pretty regularly in the future.

The source code is available under the GNU General Public License v3 from a Subversion repository on code.google.com. It is documented, though there is currently little other stand-alone documentation. One would probably want to look for the IExternalApplication entry point and go from there. What the application does is:

Add a button to the Revit ribbon to start the python shell.
Execute a python script entered in a text box, with output going to a separate window.

Daren describes one of the main scripts like this: it "will open up an interactive interpreter loop known as a REPL that will let you explore the Revit API. And by explore, I mean type a statement, hit enter, see the results, carry on. It doesn't get easier as this!"

• Scripting ADAM with IronPython

IronPython is an implementation of the Python language for the .NET framework, using the new Dynamic Language Runtime (DLR) as language services layer on top of the Common Language Runtime (CLR). The DLR's reusable hosting model makes it extremely suitable to add scripting capabilities to existing products.

In this post we'll create an ADAM command line utility that will allow us to run IronPython scripts against an ADAM application.
...
Our command line tool will expose a single command, RunScript, that will take in ADAM connection information and a path to a Python file to execute:

As I explained we're writing a Silverlight application that communicates with our Django server and exchanges a lot of json with it. Unfortunately, due to what is apparently just an oversight, the codecs module is incomplete for IronPython on Silverlight. ... [539 words]

Tarn Barford is an Australian blogger and programmer who uses IronPython. He's created a Google App Engine site for experimenting with IronPython in the browser (through Silverlight).

• PythonSilverScripting: Scripting Python Silverlight Applications
  

PythonSilverScripting lowers the barriers to building Silverlight applications so anyone from high school kids to seasoned programmers can have fun writing Silverlight applications in Python from within a browser!

Below is a simple script that creates a Silverlight application, sets the background blue and adds a TextBlock element with the text "Hello World".

He's also blogged about the new site, including his future plans for it:

• Creating Silverlight apps in the browser

PythonSilverScripting is based on crazy idea I have that it should be possible to make Silverlight applications in Python on the web. No tools, no SDKs.. just a browser (and obviously the Silverlight browser plug-in).

I've played around a bit with Silverlight and Dynamic Languages here and there and thought it was probably possible. When I got a chance I looked into it and found I was able to build working XAPs by zipping up plain text IronPython code, the IronPython DLR assemblies, an xml application manifest file and all the additional resources such XAML, images and more source.

All I needed was a web server that could zip files. Google App Engine with Python is good fun and I was able to get this working prototype together in an evening. I'd like to build the features to support building bigger projects (more source files, XAML documents, images and assemblies). On the other hand I'd also like to build features to share, discuss and rate scripts. We'll see how it goes.

I recently wrote an article for the UK MSDN (Microsoft Developer Network) newsletter called Why IronPython? This article made it into the collection of the thirteen best technical articles of 2009:

You can download these articles as a free ebook in XPS or PDF format, or read it online:

• FREE MSDN Flash eBook of the best 13 technical articles of 2009

The UK MSDN Flash developer newsletter contains great short technical articles written by UK developers both inside Microsoft and in the broader developer community. This eBook pulls together these great articles in one place. There are thirteen articles in this second edition covering Python, Inversion of Control, Behavior Driven Development, Silverlight and more.

The MSDN Flash newsletter is run by Eric Nelson. He also has a podcast and we recorded an episode together about Python, IronPython, PyCon and various other topics:

• MSDN Flash Podcast 018 – Michael Foord discusses IronPython

A great chat with Michael Foord, author of IronPython in Action, on why a C# or Visual Basic .NET developer should look at also investing time in learning and using IronPython. Michael wrote an article on IronPython for the November 18th 2009 UK MSDN Flash newsletter:

“One of the new features in .NET 4.0 is the dynamic keyword, building on the Dynamic Language Runtime. A major reason for dynamic is to enable easier interaction with dynamic languages like IronPython. But if you're a dyed in the wool C# or VB.NET programmer why should you be interested in IronPython? 
…
IronPython is a .NET implementation of the popular open source programming language Python. Python is an expressive language that is easy to learn and supports several different programming styles; interactive, scripting, procedural, functional, object oriented and metaprogramming. But what can you do with IronPython that isn't already easy with your existing tools? …”

• Cube Steak or beef steak that you tenderize
• Salt and Pepper
• Buttermilk
• Egg
• Flour
• Oil

Begin heating oil as soon as the meat is tenderized. Take tenderized steak (cube steak) and salt and pepper both sides to taste. Dip meat in flour to cover on both sides. Shake off excess. Beat egg into buttermilk. Dip flour covered meat in egg mixture covering well. Dip meat back into flour. Test oil by dropping a small drop of water in it. If it splatters, it is hot enough. Place meat into hot oil and fry on one side until brown. Turn meat and cook on other side until brown. Check for doneness. Turn and fry some more if needed. Sometimes a salt and pepper the flour too. I use bacon fat for deer steak or any wild meat. I like it for beef too, but it is not always available.

Django includes the useful management command syncdb for creating the database tables and columns used by your application. If you add new tables (model classes) then re-running syncdb will add them for you. ... [712 words]

I blogged previously about the limited built-in support for JSON in Django (Python web framework), and how I got around it by first using the wadostuff json encoder and then modifying the one built in to django-piston. Well, it turned out that json was still a bottleneck in our application. ... [812 words]

The UK, in common with countries like France, has a separate 'tax' to pay for the public television stations. In the UK these stations are run by the British Broadcasting Corporation who also collect the Television License fee. ... [949 words]

This is a preliminary post about a new project I just finished (a variation of CoffeeTrack). I wanted to test the new capabilities of Silverlight 4 and push the boundaries of what people think of as a web application.  I made a point to not have a server portion of my application.  This application only requires SL4 and a COM library (trying to avoid).

I wanted to be able to control my lights from the internet.  This system takes twitter posts (now possible in SL4) and interprets them as commands and commands the Arduino via COM automation. Once a command is received the web cam snaps a photo and posts that to twitter to confirm the results.

The Arduino code is DEAD simple. The Arduino is linked to a wireless light controller found at Walmart for $10. I found one online that is similar.  I used relays to close the switches.

const int ledPin1 = 13; // the pin that the LED is attached to
const int ledPin2 = 12; // the pin that the LED is attached to

int incomingByte;      // a variable to read incoming serial data into

void setup() {
  // initialize serial communication:
  Serial.begin(9600);
  // initialize the LED pin as an output:
  pinMode(ledPin1, OUTPUT);
  pinMode(ledPin2, OUTPUT);
}

void loop() {
  // see if there's incoming serial data:
  if (Serial.available() > 0)
  {
    // read the oldest byte in the serial buffer:
    incomingByte = Serial.read();
   Serial.println((char)incomingByte);
   if (incomingByte == '0') {
      digitalWrite(ledPin1, HIGH);
      delay(1000);
      digitalWrite(ledPin1, LOW);
      Serial.println("Lights are off");
    }
    else if (incomingByte == '1') {
      digitalWrite(ledPin2, HIGH);
      delay(1000);
      digitalWrite(ledPin2, LOW);
      Serial.println("Lights are on!");
    }
  }
}

 

The Silverlight 4 code is a combination of many, many different libraries. I was able to successfully talk to twitter as long as I ran as an out of browser application (dumb client access policy).  I used the FJCore library to encode images to Jpeg. Special thanks to VisiFire for some helpful code using FJCore. I spent about 3 days working with the code from this post (which works in a Console App).  Once I figured out how the encodings worked I was able to update a photo on twitter via Silverlight.  The rest of the code I stole from CoffeeTrack (stay tuned!).

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.IO;
using System.Xml.Linq;
using System.Text;
using System.Threading;
using System.Windows.Threading;
using System.Net.Browser;
using System.Windows.Media.Imaging;
using FluxJpeg.Core.Encoder;
using FluxJpeg.Core;

namespace XmasLightController
{
    public partial class MainPage : UserControl
    {
        DispatcherTimer t = new DispatcherTimer() { Interval = new TimeSpan(0, 1, 0) };
        byte[] currentImage = null;
        string value = "";
        public MainPage()
        {
            InitializeComponent();
            t.Tick += new EventHandler(t_Tick);
            //t.Start();
            MakeRequest();
            //UpdateTwitterImage();

        }

        void t_Tick(object sender, EventArgs e)
        {
            MakeRequest();
            
        }


        private void MakeRequest()
        {
            HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create(new Uri("http://twitter.com/statuses/user_timeline/uwstephens.atom?&count=1"));
            request.BeginGetResponse(new AsyncCallback(ReadCallback), request);
            WriteText("Contacting twitter");
        }


        int currentcommand = 0;


        private void ReadCallback(IAsyncResult asynchronousResult)
        {
            this.Dispatcher.BeginInvoke(delegate()
            {
                t.Stop();
         
            });
            WriteText("Recieved response from twitter");
            HttpWebRequest request = (HttpWebRequest)asynchronousResult.AsyncState;
            HttpWebResponse response = (HttpWebResponse)request.EndGetResponse(asynchronousResult);
            using (StreamReader streamReader1 = new StreamReader(response.GetResponseStream()))
            {

                string resultString = streamReader1.ReadToEnd();
                XDocument doc = XDocument.Parse(resultString, LoadOptions.SetBaseUri | LoadOptions.SetLineInfo);
                List<XElement> elems = doc.Elements("entry").ToList();
                StringBuilder sb = new StringBuilder();
                int oldcommand = currentcommand;
                foreach (var a in doc.Descendants().ToList())
                {
                    if (a.Name.LocalName == "entry")
                    {
                        if(value!=a.Value)
                        {
                            UpdateTwitterImage();
                        }
                        value=a.Value;
                        if (a.Value.ToLower().Contains("action"))
                        {
                            currentcommand = 1;
                        }
                        else if (a.Value.ToLower().Contains("cut"))
                        {
                            currentcommand = 2;
                        }
                        else if (a.Value.ToLower().Contains("snap"))
                        {
                            currentcommand = 3;
                        }
                    }
                }

                this.Dispatcher.BeginInvoke(delegate()
                {
                        if (currentcommand == 1)
                        {
                            WriteText("Start command received");

                            input.Text = "1";
                            SendMessage();
                            UpdateTwitterImage();

                        }
                        else if (currentcommand == 2)
                        {
                            WriteText("Stop command received");
                            input.Text = "0";
                            SendMessage();
                            UpdateTwitterImage();

                        }
                    
                });

                this.Dispatcher.BeginInvoke(delegate()
                {
                    t.Start();
                });

            }

        }

        public void WriteText(string txt)
        {
            this.Dispatcher.BeginInvoke(delegate() { this.outputWindow.Text += Environment.NewLine + txt; });
        }

        public void UpdateTwitterImage()
        {
            WriteText("Updating image");
            if (currentImage == null) { return; }
            String avatarUrl = "http://twitter.com/account/update_profile_image.xml";
            String file = "xmas";
            string imageType = "png";
            WebRequest.RegisterPrefix("http://", System.Net.Browser.WebRequestCreator.ClientHttp);
            string contentBoundaryBase = DateTime.Now.Ticks.ToString("x");
            string beginContentBoundary = string.Format("--{0}\r\n", contentBoundaryBase);
            var contentDisposition = string.Format("Content-Disposition:form-data); name=\"image\"); filename=\"{0}\"\r\nContent-Type: image/{1}\r\n\r\n", file, imageType);
            var endContentBoundary = string.Format("\r\n--{0}--\r\n", contentBoundaryBase);

            byte[] fileBytes = null;
            Encoding encoding = Encoding.UTF8;

            MemoryStream test = new MemoryStream();
            byte[] data = encoding.GetBytes(beginContentBoundary);
            test.Write(data, 0, data.Length);
            data = encoding.GetBytes(contentDisposition);
            test.Write(data, 0, data.Length);
            data = currentImage;
            test.Write(data, 0, data.Length);
            data = encoding.GetBytes(endContentBoundary);
            test.Write(data, 0, data.Length);
            fileBytes = test.GetBuffer();

            var req = (HttpWebRequest)HttpWebRequest.Create(new Uri(avatarUrl, UriKind.Absolute));
            req.ContentType = "multipart/form-data;boundary=" + contentBoundaryBase;
            req.AllowReadStreamBuffering = true;
            req.Method = "POST";

            req.UseDefaultCredentials = false;
            req.Credentials = new NetworkCredential("uwstephens", "-");
            File.WriteAllBytes(@"C:\Users\michael\Documents\test.txt", fileBytes);
            req.BeginGetRequestStream(delegate(IAsyncResult result)
            {
                Stream reqStream = req.EndGetRequestStream(result);
                reqStream.Write(fileBytes, 0, fileBytes.Length);
                //reqStream.wr(fileBytes, 0, fileBytes.Length);
                reqStream.Close();
                req.BeginGetResponse(delegate(IAsyncResult result1)
                {
                    WriteText("Image updated");
                    if (req.HaveResponse)
                    {
                        try
                        {
                            WebResponse resp = req.EndGetResponse(result1);
                            WriteText(resp.Headers["status"]);
                        }
                        catch (Exception e) { WriteText(e.Message); }
                    }
                }, req);

            }, null);
        }

        VideoCaptureDevice webcam = null;
        CaptureSource captureSource = null;
        private void loadCamera_Click(object sender, RoutedEventArgs e)
        {
            webcam = CaptureDeviceConfiguration.GetDefaultVideoCaptureDevice();

            if (CaptureDeviceConfiguration.RequestDeviceAccess())
            {
                captureSource = new CaptureSource();
                captureSource.VideoCaptureDevice = webcam;
                captureSource.Start();
                captureSource.AsyncCaptureImage(snap);
            }
        }

        public void snap(WriteableBitmap b)
        {
            
            currentImage = GetImageStream(b).GetBuffer();
            webcamImg.Source = b;
            File.WriteAllBytes(@"C:\Users\michael\Documents\test\test.png", currentImage);
            captureSource.AsyncCaptureImage(snap);
            
        }

      
        /// <summary>
        /// Reads raster information from WriteableBitmap
        /// </summary>
        /// <param name="bitmap">WriteableBitmap</param>
        /// <returns>Array of bytes</returns>
        public static byte[][,] ReadRasterInformation(WriteableBitmap bitmap)
        {
            int width = bitmap.PixelWidth;
            int height = bitmap.PixelHeight;
            int bands = 3;
            byte[][,] raster = new byte[bands][,];

            for (int i = 0; i < bands; i++)
            {
                raster[i] = new byte[width, height];
            }

            for (int row = 0; row < height; row++)
            {
                for (int column = 0; column < width; column++)
                {
                    int pixel = bitmap.Pixels[width * row + column];
                    raster[0][column, row] = (byte)(pixel >> 16);
                    raster[1][column, row] = (byte)(pixel >> 8);
                    raster[2][column, row] = (byte)pixel;
                }
            }

            return raster;
        }

        /// <summary>
        /// Encode raster information to MemoryStream
        /// </summary>
        /// <param name="raster">Raster information (Array of bytes)</param>
        /// <param name="colorSpace">ColorSpace used</param>
        /// <returns>MemoryStream</returns>
        public static MemoryStream EncodeRasterInformationToStream(byte[][,] raster, ColorSpace colorSpace)
        {
            ColorModel model = new ColorModel { colorspace = ColorSpace.RGB };
            FluxJpeg.Core.Image img = new FluxJpeg.Core.Image(model, raster);

            //Encode the Image as a JPEG
            MemoryStream stream = new MemoryStream();
            FluxJpeg.Core.Encoder.JpegEncoder encoder = new FluxJpeg.Core.Encoder.JpegEncoder(img, 100, stream);
            encoder.Encode();

            // Back to the start
            stream.Seek(0, SeekOrigin.Begin);

            return stream;
        }

        /// <summary>
        /// Get image MemoryStream from WriteableBitmap
        /// </summary>
        /// <param name="bitmap">WriteableBitmap</param>
        /// <returns>MemoryStream</returns>
        public static MemoryStream GetImageStream(WriteableBitmap bitmap)
        {
            byte[][,] raster = ReadRasterInformation(bitmap);
            return EncodeRasterInformationToStream(raster, ColorSpace.RGB);
        }

        dynamic com;

        private void serialConnect_Click(object sender, RoutedEventArgs e)
        {
            com = System.Windows.Interop.ComAutomationFactory.CreateObject("ActiveXperts.ComPort");
            dynamic count = com.GetDeviceCount();
            StringBuilder sb = new StringBuilder();

            com.Device = "COM1";
            com.Open();
            MessageBox.Show(com.GetErrorDescription(com.LastError));
            string buffer = "";
            System.Threading.Thread t = new Thread(new ThreadStart(delegate()
            {

                while (1 == 1)
                {
                    com.Sleep(200);
                    buffer = com.ReadString();
                    if (buffer == "") { continue; }
                    serialOutput.Dispatcher.BeginInvoke(delegate()
                    {
                        serialOutput.Text += "\r\n" + buffer;
                    });
                }
            }));
            t.Start();
        }



        void SendMessage()
        {
            if (com != null)
            {
                foreach (char c in input.Text)
                {
                    com.WriteByte((byte)c);
                }
                input.Text = "";
            }
        }

        private void input_KeyUp(object sender, KeyEventArgs e)
        {
            if (e.Key == Key.Enter)
            {
                SendMessage();
            }
        }

    }

}

More Mono proof of concept extensions to C#.

As part of the list of things I would like to see in C# is support for tuples in the language. They would show up in a few places, for example, to return multiple values from a function and assign the results to multiple values at once.

In recent versions of the framework there is a new datatype called Tuple, it is used to hold N values, the Tuple for N=2 looks like this:

	public class Tuple<T1, T2> {
		public Tuple (T1 v1, T2 v2);
		T1 Item1 { get; set; }
		T2 Item2 {get; set; }
	}
	

The tuple patch extends the C# language to allow multiple variables to be assigned from any Tuple, like this:

	(user, password, host, port, path) = ParseUri (url);
	

The above would assign the four values to user, password, host, port and path from the call to ParseUri. ParseUri would be declared like this:

	Tuple<string, string, string, int, string> ParseUri (string url);
	

Future Work and Ideas

In addition to handling Tuples, I would like to extend this to support collections and IEnumerables as well, for example:

	(section, header) = my_array;
	

The above would store my_array [0] in section, and my_array [1] in header.

If the last element of a tuple is a collection, it could store the rest of the values from the collection or enumerable in the last element:

	(query, page, other_options) = Request.QueryString;
	

The above would store the first item in the QueryString into query, the second into page, and the rest into the other_options array.

Tuple creation syntax:I would like to add nicer support for creating Tuples as return values, it could just mirror the assignment syntax.

	ParseUri ()
	{
		...
		return (user, password, host, port, path);
	}
	

Handling well-known types: In addition to Tuple, ICollections and IEnumerables, perhaps the compiler should know about older versions of Tuple like DictionaryEntry.

Using statements: Today the using statement is limited to a single resource, with multi-valued return types, it could handle multiple resources at once, like this:

	using (var (image, audio, badge) = iphoneApp.GetNotifications ()){
	    // use IDisposable image
	    // use IDisposable audio
	    // use trivial int badge
	}
	

As I mentioned a few days ago, there is a new covenant form Microsoft for Moonlight, it has been posted.

Cena Linuxera/Monera hoy (Diciembre 22) en el bar/restaurante del Covadonga a las 7pm. Para todo p�blico (incluso talibanes).

Direcci�n: Puebla 121 cerca de el Metro Insurgentes.

Myself and several co-conspirators have started an 'occasional podcast' on all things Python, and the first two episodes are now online. The podcast is called A Little Bit of Python and stars: Michael Foord (me, author of IronPython in Action and maintainer of unittest) Andrew Kuchling (creator of PyCrypto and one of the python.org webmasters) Steve Holden (PSF chairman) Dr. ... [404 words]

The Dynamic Language Runtime is a framework for writing dynamic languages that run on the .NET framework, with the two "Microsoft sponsored" languages being IronPython and IronRuby. There is also IronScheme, a community project hosted on Codeplex.

The promise of the DLR is not just that it makes implementing dynamic languages possible, but also that through the DLR .NET languages can interoperate. This includes IronPython and IronRuby (etc) interacting with C#, F# and VB.NET (the supported and statically typed Microsoft .NET languages) but also the reverse (statically typed languages interoperating with dynamically typed languages) and dynamically typed languages interoperating amongst themselves. All very incestuous.

As far as I know this is still unique amongst the modern polyglot runtimes (.NET and Mono, the JVM, LLVM, Parrot and so on).

Whilst IronRuby in particular has been changing very rapidly (IronRuby has only recently reached 1.0 RC 1) it has been hard to get versions of both languages built on the same version of the DLR. However recent builds have tended to include compatible versions of the other language, making it a bit easier.

IronShay (Shay Friedman) has written a blog entry demonstrating how IronPython and IronRuby can share code and use each others libraries:

• Executing IronPython Code from IronRuby

 One of the advantages of the Dynamic Language Runtime (DLR) is the fact that it makes sharing code between the languages that are written on top of it (and on top of the CLR as well). Therefore, it is possible to share code between IronPython and IronRuby (and any other DLR language as well like IronScheme).

This means that IronPython libraries can be used from IronRuby code and vice versa. Ruby on Rails in Python? Django in Ruby? feels like the end of days, isn’t it? perhaps we should really start preparing to year 2012…

In this post I’ll show you how to run simple IronPython code from IronRuby so you can take it and do whatever your imagination guides you to.

This is a short article I wrote for the UK MSDN Flash newsletter (a Microsoft newsletter for developers). Unfortunately the online versions of these newsletters aren't being updated at the moment; so instead of linking to it I'm reproducing it here.

Why IronPython?

One of the new features in .NET 4.0 is the dynamic keyword, building on the Dynamic Language Runtime. A major reason for dynamic is to enable easier interaction with dynamic languages like IronPython. But if you're a dyed in the wool C# or VB.NET programmer why should you be interested in IronPython?

Much of the discussion here applies to other dynamic languages, including IronRuby, but Python is my particular area of expertise.

IronPython is a .NET implementation of the popular open source programming language Python. Python is an expressive language that is easy to learn and supports several different programming styles; interactive, scripting, procedural, functional, object oriented and metaprogramming. But what can you do with IronPython that isn't already easy with your existing tools?

The first entry in the list of programming styles is 'interactive'. The IronPython distribution includes ipy.exe, the executable for running scripts or programs that also doubles as an interactive interpreter. When you run ipy.exe you can enter Python code that is evaluated immediately and the result returned. It is a powerful tool for exploring assemblies and learning how to use new frameworks and classes by working with live objects.

The second reason to use IronPython is also the second programming style in the list; scripting. Python makes an excellent tool for generating XML from templates, automating build tasks and a host of other everyday operations. Because scripts can be executed without compilation experimentation is simple and fast. Python often creeps into businesses as a scripting language, but beware it spreads!

One of the big use cases for IronPython is for embedding in applications. Potential uses include user scripting, adding a live console for debugging, creating domain specific languages where rules can be added or modified at runtime or even building hybrid applications using several languages. Python has several features, like the ability to customise attribute access, that make it particularly suited to the creation of lightweight DSLs. IronPython has been designed with these uses in mind and has a straightforward hosting API.

There are many areas where dynamic languages are fundamentally different from statically typed languages, a topic that rouses strong opinions. Here are a few features of IronPython that make it easy to develop with:

• No type declarations
• First class and higher order functions
• No need for generics, flexible container types instead
• Protocols and duck-typing instead of compiler enforced interfaces
• First class types and namespaces that can be modified at runtime
• Easier to test than statically typed languages
• Easy introspection (reflection without the pain)
• Problems like covariance, contravariance and casting just disappear

The best way to learn how to get the best from IronPython is my book IronPython in Action. I've also written a series of articles aimed at .NET developers to help get you started including Introduction to IronPython, Python for .NET Programmers and Tools and IDEs for IronPython.

Happy experimenting!

Michael Foord

We have discussed in the past adding support to C# to support string interpolation. I have cooked a patch that allows C# developers to embed expressions inside strings, like this:

	var a = 'Hello {name} how are you?';
	

Single quotes are used for strings that will have expressions interpolated between the braces. The above sample is equivalent to:

	var a = String.Format ("Hello {0} how are you?", name);
	

Currently the patch supports arbitrary expressions in the braces, it is not limited to referencing variables:

	var a = 'There are {list.Count} elements';
	

This notation can be abused, this shows a LINQ expression embedded in the string:

	var a = 'The {(from x in args where x.StartsWith ("a") select x).FirstOrDefault ()} arguments';
	

I am not familiar with what are the best practices for this sort of thing in Python, Ruby and other languages. Curious to find out.

Update: after the discussion on the comments the syntax was changed to use $" instead of the single quote to denote a string that will be interpolated. Now you will write:

	var a = $"There are {list.Count} elements";
	var greeting = $"Hello {name} how are you?";
	

The updated patch is here.

First, I’ll start with a little disclaimer: this post is not about whether using dynamic is better/worse than static typing. Instead, it’s about making it more convenient to use dynamic if you choose to go that route . Clearly, some people dislike dynamic, as you can see in the comments in that post from Phil Haack , and for the most part, all the key arguments for/against have been made. So anyway, let’s proceed… Recently, a few people have experimented with extending their view pages from ViewPage<dynamic>. The idea is to then be able to access model data using the more convenient dynamic syntax. e.g. check out this thread on StackOverflow, as well as Phil’s post I mention above. One limitation that people are hitting is that you can...(read more)

A little hidden feature from our release of MonoDevelop 2.2 and Mono 2.6 earlier this week was MonoDevelop's support for debugging Moonlight applications:

Moonlight debugging is a feature that came together very recently, but we delayed Mono and MonoDevelop's release to make sure that we shipped with it.

To debug, merely open your Moonlight/Silverlight project, set some breakpoints, and run your program (F5). Your app will be debugged.

I did a quick screencast and annotated it:

Today we are making a few of announcements:

• Moonlight 2 is complete: Moonlight 2, our open source implementation of Silverlight 2 is done.
• An updated collaboration agreement between Microsoft and Novell to bring Silverlight 3 and 4 to open source Unix.
• Microsoft has an updated patent covenant that will covers third party distributions.

Update: Sean Michael Kerner covers the announcement and talks to Brian Goldfarb from Microsoft.

Update 2: New covenant from Microsoft has been posted.

2.5 API

Moonlight 2 is a superset of Silverlight 2. It contains everything that is part of Silverlight 2 but already ships with various features from Silverlight 3:

• Silverlight 3 Pluggable Pipeline, this allows developers to hook into the media decoding pipeline at various points:
  • Data fetching (this is how adaptive streaming and smooth streaming are supported). Test it out at Experience Smooth Streaming.
  • Demuxing (this is how the Moonlight Ogg container can be fed into Moonlight and Microsoft's Silverlight).
  • Codecs (this is how our Vorbis and Dirac support work on both Moonlight and Microsoft Silverlight).
• Easing animation functions
• Partial out-of-browser support
• Writable bitmaps
• Some of the new databinding features of XAML in Silverlight 3

We are moving quickly to complete our 3 support. Microsoft is not only providing us with test suites for Moonlight but also assisting us in making sure that flagship Silvelright applications work with Moonlight.

When it comes to prioritization of Silverlight 3 features, we are going to focus on getting the major applications that users want to use first. Sunday Night Football, the Winter Olympics and Bing's Photosynth support.

Smooth streaming works really well. Visit the site and test the immediate seek, and play with the bandwidth limiter to see how Silverlight/Moonlight can adapt the video quality based ont he bandwidth available:

Moonlight 2

Moonlight 2 is the result of love and passion to bring the Silverlight runtime to Linux.

Moonlight 2 engine consists of 142,000 lines of C/C++ code and 320,000 lines of C# code (125,000 lines of code came from Microsoft's open source Silverlight Controls).

Moonlight is built on top of Mono 2.6 runtime, Cairo and Gtk+ and today supports Firefox on Linux. We are hard at work to support Google Chrome on Linux as well.

Updated Patent Covenant

We worked with Microsoft to make sure that Moonlight was available to everyone on Linux and BSD.

Culturally, we started on two opposite ends of the software licensing spectrum. The covenant that was issued for Moonlight 1 and 2 covered every user that used Moonlight, but only as long as the user obtained Moonlight from Novell. This is a model similar to how Flash is distributed: there is a well-known location where you get your plugin.

The open source world does not work that way though. In the open source world, the idea is to release source code and have distributions play the role of editors and curators and distribute their own versions of the software.

Microsoft's intention was to expand the reach of Silverlight, but the original covenant was not a good cultural fit. We worked with the team at Microsoft (Brian Goldfarb and Bob Muglia's teams) to make sure that the covenant would cover the other Linux distributions.

The new patent covenant ensures that other third party distributions can distribute Moonlight without their users fearing of getting sued over patent infringement by Microsoft.

There is one important difference between the version of Moonlight that will be available from Novell and the version that you will get from your distribution: the version obtained from Novell will have access to licensed media codecs.

Third party distributions of Moonlight will be able to play unencumbered media using Vorbis, Theora and Ogg inside Moonlight (and Silverlight), but for playing back other formats, they will have a few options:

• Negotiating directly with the media codec owners a license (MPEG-LA, Fraunhofer).
• Negotiate access to Microsoft's Media Pack with Microsoft.
• Plug-in GStreamer or another commercial codec license into their Moonlight implementations.
• Update: Use a hardware provided decoder like VDPau.

Moonlight 3 and Moonlight 4 Collaboration Agreement

As readers of my blog know, the Silverlight 4 feature set is something that is very interesting to me.

If our experience with the positive feedback that we have gotten from MonoDevelop is of any indication Silverlight 4 will enable a whole new class of cross-platform .NET application development to take place. Like nothing we have seen before.

We are thrilled to be working with Microsoft to make sure that we can improve, fix and fine tune Moonlight to meet those requirements and to do so in a purely open source fashion.

Update: Team Silverlight blogs.

Hello, google. I would like to introduce you to our chat logs. Chat logs, google. Google, chat logs.

We will discuss things here such as Mono, GNOME and Debian. We may even use it to talk about work on the DLR project stuff.

About nine months ago we released MonoDevelop 2.0 and Mono 2.4. Today we are releasing the much anticipated upgrades to both. Mono 2.6 and MonoDevelop 2.2.

For those in a hurry, binaries and source are available from:

• Mono Download page.
• MonoDevelop Download page.

And if you want a quick mnemonic to remember this release, just think debugger! and cross platform.

The Mono team and contributors worked on this release like we have never worked before. Thanks to everyone that reported bugs, filed feature requests, contributed code and helped newcomers with Mono.

Mono 2.6 highlights:

• WCF client and server, the subset exposed by Silverlight 2.0.
• LLVM support, to improve performance on server/computational loads.
• Continuations/Co-routine framework Mono.Tasklets (background info)
• LINQ to SQL using DbLinq.
• New Soft Debugger, integrated with MonoDevelop on Unix and OSX (background).
• System.IO.Packaging.
• csharp shell now supports auto-completion (press tab to complete)
• xbuild can now build most msbuild projects.
• Mono debuts a verifier and security sandbox (used by Moonlight).
• More complete 3.5 API coverage.
• This release includes Microsoft's open sourced ASP.NET MVC, ASP.NET AJAX and Microsoft's Dynamic Language Runtime.
• Faster and slimmer.

MonoDevelop 2.2 highlights (screenshots here and here):

• MonoDevelop code is now LGPLv2 and MIT X11 licensed. We have removed all of the GPL code, allowing addins to use Apache, MS-PL code as well as allowing proprietary add-ins to be used with MonoDevelop (like RemObject's Oxygene).
• User interface improvements: the first thing that MonoDevelop users will notice is that we have upgraded the UI to fit modern ideas. We borrowed ideas from Chrome, Firefox, Visual Studio, Eclipse and XCode.
• ASP.NET MVC support, you can now develop, debug and build ASP.NET MVC applications from MonoDevelop.
• New T4 Macro processor (Text Template Transformation Toolkit) integrated directly into the IDE (Mono's T4 is also available as a reusable library for use and abuse in your own programs).
• Moonlight Project Support: you can now build, debug and run Moonlight applications using MonoDevelop.
• New MacOS and Windows support. Check our feature matrix for details.
• New Debugger support allows debugging Console, Gtk#, ASP.NET, iPhone and Moonlight applications.
• Extensive text editor improvements:
  • Dynamic abbrev (Just like Emacs' Alt-/)
  • Code generator (Alt-Insert)
  • Acronym matching
  • Code templates
  • Block selection
  • C# Formatter
• New refactoring commands:
  • Inline Rename (see screenshot).
  • Resolve Namespace
  • Rename Refactoring with Preview
  • Extract Method
  • Declare Local Variable
  • Integrate Temporary Variable
  • Introduce Constant
  • Move Type to Own File
  • Remove Unused Usings
  • Sort Usings
  • Create/Remove Backing Store
  • Keybindable Commands
• Python add-in has graduated to be a supported plugin, includes code completion, syntax checking, method and class locator and code folding.
• iPhone development plugin.

The team is on #mono, #monodev and #monodevelop on irc.gnome.org fielding any questions you might have.

Update: the diffstat results for Mono 2.4 to 2.6 on a 2 million line patch:

 7208 files changed, 1392400 insertions(+), 440016 deletions(-)

About a million lines of new code in Mono.

For MonoDevelop the patch is 750,000 lines and:

 2427 files changed, 464284 insertions(+), 120124 deletions(-)

Roughly 300k lines of new code.

This is part of a RubyConf 2009 series:
Overview | What sets IronRuby apart? | Sneaking Ruby to the top / Embedding IronRuby | Project status

It’s been a long ride – starting in 2007 when IronRuby was introduced running in Silverlight. Things started out slowly, but for the last year we’ve moved pretty quick, have gotten great feedback, and IronRuby is due for another bump:

We’ve exceeded our goals for 1.0, and still plan on further excess before 1.0 is final. Let’s dive into our top goals: performance, compatibility, and CLR integration.

We’ve been tracking performance against MRI 1.8.6, which though isn’t a final performance goal, it’s a good measure of performance for a 1.0. In the next major release we’ll start tracking MRI 1.9. In general we’re a significantly faster than MRI, but still a tad unacceptable compared to JRuby – that needs to be fixed before 1.0.

We measure compatibility against RubySpec, as well as some popular Ruby libraries (only the top-used ones are shown here). We’re over 90% for every group of tests. In practice, compatibility is being tested against almost every library we can get our hands on, which is a ton, so I feel confident IronRuby 1.0 will be a very compatible Ruby implementation.

As I said in a previous post, this compatibility measure is against 1.8.6; IronRuby does not yet suppor 1.9 completely, though we may quickly change our opinion on this.

CLR integration is very flushed out, supporting using all CLR classes, calling all methods, properties, etc, generics, inheritance, and all the other CLR features exposed to managed languages such as C# and F#. The only missing hole is generating actual CLR types and backings for Ruby types, though we feel this is an OK feature to ship without, because the work-arounds are simple. However, it will be a priority to fix in the next major release.

With RC1 being released, RC2, 3, etc. will come as the community reports issues that we all agree must be fixed by 1.0 final. As far as the core team’s priorities, we want to fix startup and throughput performance issues, as well as get through the backlog of bugs.

After 1.0 is released, we’ll probably take a bit of a break, but then look to do some features we didn’t get to finish in 1.0, as well as Visual Studio Integration, since it’s the highest voted feature for VS2010:

Download the IronRuby 1.0 RC1 and let us know what you think! You can submit any issues you find to the CodePlex site. Thanks!

Thanks to Jimmy Schementi (the new IronPython PM, Ruby lover and all round good guy) IronPython has a new website. And as said best on Reddit, it doesn't look like Microsoft made it. The site has links to documentation, community resources and online IronPython examples using Silverlight (including Try Python).

• IronPython gets a long overdue website!
• IronPython.net

CodePlex will continue to be the tool we use for project management and releases, but all end-user information will be on IronPython.net. Also, the .com domain still points at the super-old site, but will redirect to this site shortly.

The most notably addition is the .NET Integration Documentation, a thorough set of examples and descriptions of using IronPython with .NET. Considering this is IronPython’s main purpose, it’s amazing we got away with having hardly no documentation for this long … I guess the .NET integration is just that intuitive :) Anyway, please give it a read and let us know if you have any suggestions.

In previous blog entries Lukáš Čenovský looked into Databinding and WCF Services with IronPython 2.6. This uses the new __clrtype__ feature in IronPython 2.6 to interact with .NET features that previously couldn't be done with IronPython.

In this follow up blog entry Lukáš shows how to saved the IronPython interface in an assembly with a config file.

• WCF Service in pure IronPython with config file

I was wrong when I wrote in the last post that the IronPython service cannot be saved into an assembly. It can. Which opens a way to use .config file to configure the service.

The interface is the same as in the previous version. The only difference in the service to the previous version is in the ServiceHost initialization - we omit the service configuration parameters because they are in the .config file. I also changed the clr namespace.

This is part of a RubyConf 2009 series:
Overview | What sets IronRuby apart? | Sneaking Ruby to the top / Embedding IronRuby | Project status

Imagine you’re building a program to help create animations, visualizations, and other interactive applications. The requirements are simple:

1. 2D rendering surface with simple primitive shapes
2. Simple animation support – callbacks for each frame and each object on the canvas
3. User-loadable “macros” for drawing and animating

A .NET developer can easily code up the first two requirements in C#, but implementing the third will be tricky. What does a macro look like? How do I discover them? How can I make it interactive? Why is this so hard!? This scenario requires the user to input some data, and the program must make an animation out of it; the data of your program is the code. Here are the options most .NET developers would come up with:

• Domain specific language – people usually cop out here and make it XML-based, which happens to produce the most human-unreadable code ever. This DSL could also be GUI-based, but you won’t get any programmers interesting in extending your app that way.
• Completely punt on the interactivity and require the macros be .NET DLLs.
• Find a way to use C# interactively - either using CodeDom to compile and run C# code dynamically (much like ASP.NET does), or code-generate a valid C# class from the snippet, compile it to a DLL (aka shell out to csc.exe), loading that DLL, and finally reflecting over that DLL to call the user’s code. This is, of course, ignoring the question of whether C# is a good macro language or not. It’s worth noting that Mono supports hosting it’s C# compiler, so you could do more dynamic things with C# through Mono.

Given all that talk about Ruby before, let’s try using IronRuby to write these macros. Here’s a C# app to start from:

SketchScript starter on GitHub (zip)

For the lazy, get the finished app’s source code (zip), and a binary build (coming soon).

The starter app does ABSOLUTELY NOTHING; just a Window with a Canvas and a bunch of textboxes for coding. Keep in mind this is just a demonstration, and this app could have been written entirely in Ruby, but the point is to show .NET developers how powerful an embedded scripting language can be.

Setting up your environment

.NET developers have choices for development environments: mainly Visual Studio or SharpDevelop, or even the command-line and text-editor (I left out MonoDevelop since Mono doesn’t support the Windows UI stuff I’m doing, but a future version will be able to run in Mono). I’ll be using Visual Studio 2010 Beta 2 for this walkthrough’s screenshots and examples, specifically because it C# 4 has special dynamic language features, but you can also use C# 3 with Visual Studio 2008 (free version here), or just stick to a text-editor and MSBuild.

If you’re using .NET 4.0, sketchscript\sketchscript.sln is the solution file you want to use. The .NET 3.5 version is sketchscript\sketchscript3.5.sln, but seriously, try out .NET 4.0.

I haven’t tested it out in VS2008 yet, so please bare with me. If you’re feeling adventurous, you can fork my git repo, get it working in VS2008, and I’ll pull your changes in.

Adding references to IronRuby

If you downloaded SketchScript from the above link, you’ll find four DLLs required for embedding IronRuby in the sketchscript\ironruby directory. Add those as references to the sketchscript.csproj:

In case you’re curious about what each DLL is: IronRuby.dll is the IronRuby compiler, while IronRuby.Libraries.dll is the core libraries of Ruby. Microsoft.Dynamic.dll are the APIs that IronRuby depend on for DLR compiler features, and Microsoft.Scripting.dll is the DLR Hosting API.

If anyone who has used IronRuby before is thinking there are missing DLLs, then you’re right. IronRuby’s Microsoft.Scripting.Core.dll has been integrated into .NET 4.0 as the new System.Core.dll. This also removes the need for Microsoft.Scripting.ExtensionAttribute.dll.

Embedding IronRuby

Now let’s get that code window working; first add some using statements at the top of MainWindow.xaml.cs:

And some fields to hold onto the scripting engine anywhere in the MainWindow class:

Now initialize the scripting engine; add this code to the Loaded event action, after setting the OutputBuffer but before the KeyBindings() call (around line 71):

And lastly let’s run the code when Ctrl-Enter is pressed. Since that’s already set up for us, all we need to do is add this code in the RunCode method, right at the "TODO" comment around line 92:

And that’s it! Now you’ll be able to run some actual Ruby code:

Interacting with the host application

Though Ruby code can run, there is no obvious interaction with the host application. That black void of a canvas on the left would be completely useless if it wasn’t accessible from Ruby code, so add this single line to the Loaded event action, before the KeyBinding() call:

Note: if the host application didn’t do this, it would still be possible to get to the canvas from Ruby code, but the script writer would have to do it themselves:

So, as a general rule-of-thumb, have your host program decide what parts to extend to script code, and have the script code only use that object-model, though their may be ways around it.

Trying it out

Now that there’s a way to draw on the canvas, play around with drawing random things on the screen. Here’s a little script I’ve been playing with:

Which draws this:

Ooo, pretty! So without much effort we have a very extendable application. Before you get carried away playing around with making pretty things, there’s one more thing to do to make this app really awesome …

Animation support

While animations could still be built with IronRuby’s native thread support or WPF animations directly from Ruby code, it’d be nice for the host to provide some simple animation support, like a callback that fires for every frame, and even a way to attach animations to any object.

The host currently supports these two callbacks, but they need to be wired up. Add the following code at the bottom of the Loaded event action, before the call to KeyBindings():

And also add this call at the end of the RunCode method:

Lastly we need to implement CatureAnimationCallbacks, by looking for special method names to get a hold of. Look for each_frame as the EachFrame action, and each_object as the EachObject func.

Now 30-times-a-second the host will try to call each_frame, and it will call each_object once for each element on the canvas, store the return value on the actual element, and then try to call an update method on that stored object 30-times-a-second. This lets you either run random animations, or specific behavior for objects.

A good animation example is bouncing, so let's run the script that produced all the squares first, and then run the following code to make them all bounce.

And now it should look something like this:

There are more goodies to run in the features directory, but try writing your own fun little animations. Jim Deville ported the tutorial from Jeff Casimir’s Code of Art talk, which is pretty fun to play with, so if you make your own please post a comment with a screenshot and code!

circle.rb

 

And there you have it, IronRuby embedded to do interesting things. In case you missed any steps along the way, here's the full diff against the initial download.

Next stop, IronRuby’s status and roadmap.

This is part of a RubyConf 2009 series:
Overview | What sets IronRuby apart? | Sneaking Ruby to the top / Embedding IronRuby | Project status

Let’s be honest: not everyone uses Ruby. I know, it hurts to hear, but it’s the truth. To get a general idea of how bad it really is, let’s look at indeed.com’s job trends for Ruby, Python, Java, and .NET, and assume that’s a good measure of usage:

Holy crap! Regardless of the actual numbers, we all know what this graph is saying to be true. But why are dynamic language’s so under-used? Aside from the obvious, like fear of something different, the dynamic language community hasn’t sufficiently answered the “why” questions to the other camp, like “Why should I use Ruby if I already know .NET?”, and “why even bother.” Our answer has always been “Productivity, expressiveness, blah, blah, blah”; that turns out to be a horrible way to sell dynamic languages to people who love C# or Java for it’s productivity and expressiveness. =) However, their fears are justified; Ruby’s main usage today is for stand-alone apps (mainly websites, but there are some client apps), so they assume Ruby can’t be use it in their existing environment.

Let’s solve this!

Let’s make it easy for those programmers at the top of the graph to use the languages at the bottom of the graph. Ruby gets to expand its ecosystem, and enterprise developers get a great dynamic language to use. Ruby is nicely position for this specific scenario since implementations of Ruby exist for both Java and .NET, so Ruby’s usage could become more on-par with Java and .NET. And here’s the way we make this happen: .NET and Java developers can easily embed Ruby into their existing applications for scripting.

All this also applies for Python, and IronPython is forging this path along with IronRuby. This talk was for a Ruby crowd … I hope you understand Michael :). But don’t worry, Dino Viehland has already begun brainwashing .NET developers for Python.

Also, since I work on IronRuby, I’ll be talking about this in relation to IronRuby and .NET from now on, though the same arguments work for JRuby and Java (and Jython). Check out the embedding JRuby page, and also how all this work in Jython.

The .NET people reading this might be smiling, but the Ruby people want to vomit … (maybe partly because of .NET, but in all seriousness) … because of the word “scripting”. I know, I too hate the negative associations “scripting” has; when I first started working at Microsoft I was openly against naming a component “Microsoft.Scripting”, but who listens to the new guy? For those who don’t get it, “scripting” makes these amazing languages sound like they are only useful for little toy things, and not for real work. Anyway, this plan takes advantage of that misconception, so don’t look at it as such a bad thing. :)

Why and How?

Ok, .NET developers, stop reading … you’ll ruin the surprise! Just kidding. I love you. Read on …

Since .NET developers see Ruby as a scripting language, it’s not a stretch to convince them that Ruby is good for embedding into their applications as a extensibility feature; allowing customize their application with bits of Ruby code. Here’s where all the Trojans jump out of the wooden horse. Getting Ruby into existing .NET applications is a much easier way for those developers to learn and use Ruby, rather than asking them to build a new app from scratch, or just look at tutorials, docs, etc, without having a good reason to. If .NET developers want to look at Ruby for use in their existing projects, then we’ve succeeded; it’ll then be pretty obvious that they can do real things with these so-called scripting languages. They’ll probably start using Ruby to prototype new features in their existing system, and then either keep that code as Ruby, or port some of it to their main language. Keep in mind, the goal isn’t to steal people from .NET – they would have left long ago like many of the Ruby community did – it’s to make Ruby co-exist with these more “enterprise” systems, and overall make software development fun again for everyone.

But how do .NET developers really benefit from having a scripting language they can use from their current environments? Three words: No More XML. XML seemed to be the solution to all .NET developer’s problems since it was a way to make their environments more dynamic. It is easy to parse and walk XML, making it also easy to attach some meaning to seemingly meaningless angle-brackets. One could implement anything using this technique, even logic. Which is why XML became a dynamic language and meta-programming tool for .NET. But really XML is a work-around to these static languages lacking the ability to be treated as both code and data.

Being able to use your code just like your data is liberating. For example, running Ruby code from just at string:

IronRuby supports the DLR Hosting API, a language-neutral script hosting API for .NET. For instance, supporting another is just as easy as changing the 2nd line to "IronPython".

Imagine doing this with XML; you’d have to somehow encode what element and field you want to modify, along the value to update it to, and then use something like reflection to interpret the XML and do the work. And that’s just for this simple example of setting the text of a TextBlock. So using a real programming language allows for endless extensibility-possibilities. Ruby is especially interesting since it can be simple enough for non-programmers, but powerful enough for adding full features.

Software which allows simple extensibility, like Firefox and Rails, tend to always create an ecosystem of extensions around them, which end up being one of the most compelling features of the program. Maybe that next app could be yours?

Next up, an example of embedding IronRuby for graphics.

Jeff Hardy is a big cheese in the IronPython world. One of his older projects is NWSGI, an implementation of the Python WSGI (Web Server Gateway Interface) specification for .NET. This allows Python WSGI applications to run on IronPython and be served by IIS.

One of his newer projects is an extension of Visual Studio 2010 (still in beta) to provide Python syntax highlighting and IronPython support.

Jeff has recently announced progress in both projects.

• NWSGI 2.0 Release Candidate 2 

The final release candidate of NWSGI 2.0 is now available. Except for version numbers, this is what will become NWSGI 2.0 as soon as IronPython 2.6 is released.

NWSGI 2.0 Release Candidate 2 includes all of the features of NWSGI 2.0 Release Candidate 1, and adds support configuring tracing, lightweight scopes, and the profiler. It is built against IronPython 2.6 RC3.

The following issues are fixed in this release:

• Add configuration option for Profiler
• Add configuration option for Lightweight Scopes
• Add configuration option for tracing

• IronPython Extensions for Visual Studio 2010
• IronPython.VisualStudio on BitBucket
• IronPython.VisualStudio on the Visual Studio Gallery

 Lately, I’ve been experimenting with the new editor APIs in Visual Studio 2010 to build some simple extensions to make Python editing a little better. Helpfully, IronPython exposes most of the complicated infrastructure (the tokenizer) to make the job easy. The documentation for the new editor APIs is still a bit weak; hopefully that will improve by the final release. In the meantime, the examples are the best source of information. There also a series of blog posts by an Mike Feingold about the NDjango editor for VS2010 that form a great end-to-end example.

Download & Installation
Download IronPython Extensions for Visual Studio 2010 (and the source code; Ms-PL as always) from my BitBucket repository or from the Visual Studio Gallery (direct link). For direct downloads, just run (double-click) the .vsix file to install it into Visual Studio. Otherwise, you can use the extension manager (search for "IronPython") and install it directly from Visual Studio.

Features
The extensions provide three features so far: syntax highlighting, brace matching, and outlining.

In the future I'm planning on adding project support, templates, and (most difficult of all) IntelliSense.

IronPython 2.6 is finally out! IronPython 2.6 is a new version of IronPython targeting compatibility with Python 2.6. As well as the new language and library features that come with Python 2.6, IronPython 2.6 has new features for improved performance, general Python compatibility and better .NET integration. It's a great release; congratulations and thanks to the IronPython team.

• Download IronPython 2.6
• IronPython Samples for IronPython 2.6 
  
• Performance Comparison: IronPython 2.6 Final and CPython 2.6

 IronPython 2.6 final is identical to release candidate 3. Features new to IronPython in version 2.6 include:

• The __clrtype__ metaclass for data binding and .NET attribute support
• Implementation of the ctypes module
• Support for Python stack frames and sys.settrace, which means the pdb debugger works (and better debugging from the .NET side)
  
• Better performance through adaptive compilation
• Faster startup

There are several changes to the samples in IronPython 2.6. These include two new samples:

CommentChecker
Not only will this sample show you how to utilize Word's spell checking functionality from IronPython; it'll also make your own Python code better! You see, this sample processes Python files looking for code comments that contain misspellings. Once these mistakes have been identified Word is utilized again to present you with the correct spellings. All of this is tied together with an elegant, user-friendly interface constructed from .NET's Windows Presentation Framework.

ClrType
The ClrType sample shows how to define a class in IronPython with required CLR members. Normally, a class definition in Python does not map directly to a unique CLR type. This is because the semantics of classes are different between Python and the CLR. For example, in Python it is possible to change the base types just by assigning to the bases attribute on the type object. However, the same is not possible with CLR classes. Hence, IronPython implements Python classes without mapping them directly to CLR types. Using the ClrType sample you’ll be able to define CLR fields, properties, class-level attributes, and declare strongly-typed methods.

Pyc, the IronPython compiler, is no longer available as a sample as "it was incorporated directly into IronPython releases as a tool".

The full IronPython 2.6 release notes:

We’re proud to announce the release of IronPython 2.6 final. This is a major release with improvements across all areas of IronPython. Significant changes include: 

• Updating the language and standard library to match CPython 2.6
• Improved .NET integration
• Updating to the latest version of the DLR
• Adding previously missing CPython features and fixing bugs
• Performance improvements in particular startup time improvements

Python 2.6 support includes a large number of new features which include support for the new bytes and byte array types (PEP 3112), decorators for classes (PEP 3129), advanced string formatting (PEP 3101) which will feel familiar to .NET users and integrates nicely with IFormattable, print as a function (PEP 3105), Abstract Base Classes (PEP 3119), support for binary literals, along with lots of other minor features and changes.

IronPython also continues to improve .NET integration in this release. We’ve added the __clrtype__ method to types which enables deep integration via meta-classes with the .NET type system. There are also a number of smaller changes such as supporting IDisposable in for loops matching the behavior of other .NET languages. This release also includes the latest version of the DLR and fixes a number of issues related to cross-language dynamic interop. Not to be left out there’s improvements in Silverlight integration by supporting Python code in HTML script tags.

We’ve also continued to improve Python compatibility by adding missing features and fixing bugs. In this release we’ve added support for the ctypes module which provides interop with native code in a compatible way across Python implementations. We’ve also implemented sys.settrace to provide support for the pdb module and other Python debuggers. This release also changes how we support sys.getframe: a fully working version is now available by a command line option; when not enabled sys.getframe doesn’t exist at all. This release also fixes over 400 bugs removing a large number of smaller incompatibilities.

As always we’ve also continued to improve performance, and this release primarily focuses on improving startup time. The IronPython installer now pre-compiles (ngens) IronPython during installation on both 32-bit and 64-bit platforms. Modules are now interpreted initially and hot functions are compiled for faster import times. A number of other code paths that used to involve runtime code generation have been optimized to be contained within the pre-compiled IronPython binaries. We’ve also made a number of smaller changes which improve performance in other areas such as adding constant folding.

This is an initial rough post, but I have managed to get Silverlight 4 beta talking to an ActiveXperts COM+ interface that talks to an Arduino over a serial connection.

Here is my first attempt to do a video of it. Looks like I’m going to need to learn how to make a screencast.

 

 

 

The C# code.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Net;
using System.Windows;
using System.Windows.Controls;
using System.Windows.Documents;
using System.Windows.Input;
using System.Windows.Media;
using System.Windows.Media.Animation;
using System.Windows.Shapes;
using System.Windows.Interop;
using System.Text;
using System.Threading;

namespace TestSerial
{
    public partial class MainPage : UserControl
    {
        public MainPage()
        {
            InitializeComponent();
        }

        private void button1_Click(object sender, RoutedEventArgs e)
        {
            if (App.Current.InstallState == InstallState.NotInstalled)
            {
                App.Current.Install();
            }
        }
        dynamic com;
        private void button2_Click(object sender, RoutedEventArgs e)
        {

           com=ComAutomationFactory.CreateObject("ActiveXperts.ComPort");
            dynamic count = com.GetDeviceCount();
            StringBuilder sb = new StringBuilder();
            
            List<dynamic> devices = new List<dynamic>();
            for(int i=1;i<=9;i++)
            {
                devices.Add("COM" + i);
            }

            for (int i = 0; i < count; i++)
            {
                    devices.Add(com.GetDevice(i));
                
            }
            devicelst.ItemsSource = devices;
            
        }

        private void button3_Click(object sender, RoutedEventArgs e)
        {
            //string device = devicelst.SelectedItem.ToString();
            if (devicelst.SelectedItem == null) { MessageBox.Show("Please pick a port"); return; }
            com.Device = devicelst.SelectedItem.ToString();
            com.Open();
            MessageBox.Show(com.GetErrorDescription(com.LastError));
            string buffer = "";
            System.Threading.Thread t = new Thread(new ThreadStart(delegate()
            {

                while (1 == 1)
                {
                    com.Sleep(200);
                    buffer = com.ReadString();
                    if (buffer == "") { com.Close(); return; }
                    tb.Dispatcher.BeginInvoke(delegate()
                    {
                        tb.Text += "\r\n" + com.ReadString();
                    });
                }
            }));
            t.Start();
        }


    }
}

The Xaml.

<UserControl x:Class="TestSerial.MainPage"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
    xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
    mc:Ignorable="d"
    d:DesignHeight="300" d:DesignWidth="400">

    <Grid x:Name="LayoutRoot" Background="White">
        <Grid.ColumnDefinitions>
            <ColumnDefinition></ColumnDefinition>
            <ColumnDefinition></ColumnDefinition>
            <ColumnDefinition></ColumnDefinition>
        </Grid.ColumnDefinitions>
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"></RowDefinition>
            <RowDefinition Height="Auto"></RowDefinition>
            <RowDefinition></RowDefinition>
        </Grid.RowDefinitions>
        <Button Content="Install" Height="23" HorizontalAlignment="Left" Name="button1" VerticalAlignment="Top" Width="75" Click="button1_Click" Grid.Row="0"/>
        <Button Content="Get Devices" Height="23" HorizontalAlignment="Left"  Name="button2" VerticalAlignment="Top" Width="75" Grid.Row="1" Click="button2_Click"/>
        <ComboBox Name="devicelst" Grid.Row="1" Margin="1,0,0,0" Grid.Column="1"></ComboBox>
        <Button Content="Connect" Grid.Column="3" Grid.Row="1" Height="23" HorizontalAlignment="Left" Name="button3" VerticalAlignment="Top" Click="button3_Click"/>
        <TextBox Name="tb" Grid.ColumnSpan="3" Grid.Row="2" VerticalScrollBarVisibility="Visible"></TextBox>
    </Grid>
</UserControl>

/*
  ASCII table
Prints out byte values in all possible formats: 
* as raw binary values
* as ASCII-encoded decimal, hex, octal, and binary values
For more on ASCII, see http://www.asciitable.com and http://en.wikipedia.org/wiki/ASCII
The circuit:  No external hardware needed.
created 2006
by Nicholas Zambetti
modified 18 Jan 2009
by Tom Igoe
<http://www.zambetti.com>
*/
void setup()
{
  Serial.begin(9600);

  // prints title with ending line break
  Serial.println("ASCII Table ~ Character Map");
}

// first visible ASCIIcharacter '!' is number 33:
int thisByte = 33;
// you can also write ASCII characters in single quotes.
// for example. '!' is the same as 33, so you could also use this:
//int thisByte = '!'; 

void loop()
{
  // prints value unaltered, i.e. the raw binary version of the
  // byte. The serial monitor interprets all bytes as
  // ASCII, so 33, the first number,  will show up as '!'
  Serial.print(thisByte, BYTE);   

  Serial.print(", dec: ");
  // prints value as string as an ASCII-encoded decimal (base 10).
  // Decimal is the  default format for Serial.print() and Serial.println(),
  // so no modifier is needed:
  Serial.print(thisByte);     
  // But you can declare the modifier for decimal if you want to.
  //this also works if you uncomment it:

  // Serial.print(thisByte, DEC); 

  Serial.print(", hex: ");
  // prints value as string in hexadecimal (base 16):
  Serial.print(thisByte, HEX);    

  Serial.print(", oct: ");
  // prints value as string in octal (base 8);
  Serial.print(thisByte, OCT);    

  Serial.print(", bin: ");
  // prints value as string in binary (base 2)
  // also prints ending line break:
  Serial.println(thisByte, BIN);  

  // if printed last visible character '~' or 126, stop:
  if(thisByte == 126) {     // you could also use if (thisByte == '~') {
    // This loop loops forever and does nothing
    while(true) {
      continue;
    }
  }
  // go on to the next character
  thisByte++; 
}

I felt like an archaeologist trying to formulate a theory of what had happened there. I loved the feeling of trying to put together the story from a partial puzzle.

The patent infringement lawsuit against Apple was a list of accusations and patent lists that Nokia claims that Apple infringes with their iPhone. But behind the background information provided in the legal document and the list of ways in which Nokia felt Apple had wronged them, it was difficult to put together a narrative. Scanning the discussion forums for clues did not lead to anything significant beyond the superficial analysis.

As a software developer, and in particular a Linux software developer, I have mixed feelings about this lawsuit. Apple has not been exactly a model citizen when it comes to interoperability between Apple and Linux products while Nokia has embraced Linux, embraced open source development and contributed to the universal pool of software. But I also found myself enjoying using my iPhone and building software for the iPhone.

I wanted to give both companies the benefit of the doubt. What had happened between these two companies that had forced Nokia to sue Apple?

There were various possibilities.

The lack of immediate response from Apple suggested that they were caught unprepared, but that was just a small chance. Probably the companies had been on negotiations and these negotiations broke off when they could not reach an agreement. The iPhone had taken the world by surprise, nobody had seen it coming and nobody had envisioned that Apple would not merely do an incrementally better phone, but it would be many times better than anything available at the time.

When Apple launched the iPhone, Steve Jobs wanted everyone to know that iPhone's innovations were patented and that Apple planned to prevent others from copying those ideas.

Apple's response to Nokia is a very educational document. It reads as a crash course on patent litigation when it lays out Apple's strategy for their defense. It is also a crash course on the patent system and how corporation work with international bodies to develop technology. But most importantly for me, it fills some the gaps of what happened behind the scenes.

We do not know yet which company approached the other first about patent infringement. It could have been someone on Nokia's board that decided to extract some revenue from their patents to compensate for their business losses or it could have been initiated by Apple's team notifying Nokia that their new phones used some idea from their phones.

What does emerge from Apple's reply is that Nokia tried to use the patents that they had pledged to license under reasonable terms to get themselves rights to Apple's juicier iPhone innovations. Nokia's pledged patents might be formidable patents and key to the implementation of certain cellular and WiFi communications, but by being pledged under F/RAND terms to various industry consortia they lost a significant amount of value. But what they lost in value, they made up in volume. This is in stark contrast with Apple's un-pledged, pristine, fully proprietary patents that Nokia and everyone but China are trying to get rights to.

I've very happy to announced that we've officially released IronPython 2.6!  This is a great release which brings us up to date with the stable CPython 2.x branch, greatly improves startup time performance, continues to improve our support for deep .NET integration, adds major new features like pdb and sys.settrace support, and as usual we've fixed a ton of bugs along the way.  It's also identical to RC3 in every way so if you've already installed RC3 you're ready to go!  If not you can download it now from CodePlex: http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12482

Here's the full release notes if you'd like more details about what's changed:

 Hello Python Community,

We’re proud to announce the release of IronPython 2.6 final.  This is a major release with improvements across all areas of IronPython and can be downloaded from http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=12482.  Significant changes include:

·         Updating the language and standard library to match CPython 2.6

·         Improved .NET integration

·         Updating to the latest version of the DLR

·         Adding previously missing CPython features and fixing bugs

·         Performance improvements in particular startup time improvements

Python 2.6 support includes a large number of new features which include support for the new bytes and byte array types (PEP 3112), decorators for classes (PEP 3129), advanced string formatting (PEP 3101) which will feel familiar to .NET users and integrates nicely with IFormattable, print as a function (PEP 3105), Abstract Base Classes (PEP 3119), support for binary literals, along with lots of other minor features and changes.

IronPython also continues to improve .NET integration in this release.  We’ve added the __clrtype__ method to types which enables deep integration via meta-classes with the .NET type system.  There are also a number of smaller changes such as supporting IDisposable in for loops matching the behavior of other .NET languages.  This release also includes the latest version of the DLR and fixes a number of issues related to cross-language dynamic interop.  Not to be left out there’s improvements in Silverlight integration by supporting Python code in HTML script tags.

We’ve also continued to improve Python compatibility by adding missing features and fixing bugs.  In this release we’ve added support for the ctypes module which provides interop with native code in a compatible way across Python implementations.  We’ve also implemented sys.settrace to provide support for the pdb module and other Python debuggers.  This release also changes how we support sys._getframe: a fully working version is now available by a command line option;  when not enabled sys._getframe doesn’t exist at all. This release also fixes over 400 bugs removing a large number of smaller incompatibilities.

As always we’ve also continued to improve performance, and this release primarily focuses on improving startup time.  The IronPython installer now pre-compiles (ngens) IronPython during installation on both 32-bit and 64-bit platforms.  Modules are now interpreted initially and hot functions are compiled for faster import times.  A number of other code paths that used to involve runtime code generation have been optimized to be contained within the pre-compiled IronPython binaries.  We’ve also made a number of smaller changes which improve performance in other areas such as adding constant folding.

Finally we’d like to thank everyone who reported issues and helped make this a better release:  Anders M. Mikkelsen, Dan Eloff, Zachc, yamakox, vernondcole, VAks, tscottw, tonyandrewmeyer, tomwright, TomasMatousek, tkamiya, timers, srivatsn, sopeajw, saveenr, sanxiyn, rridge, ronniemaor, quirogaco, pythonfoo, pysunil, pm100, pl6306, paulfelix, orestis, olegt, oldman, NDHUMuscle, mycall, mmaly, mmacdonaldssfcu, maplpro, luntain, llaske, lbaker, Lawouach, laurionb, laughingboy, kurhan, kuno, kowenswp, klrohe, kevgu, jmesserly, jlunder, jdhardy, jbevain, jackeyoo, hhonisch, gz, gjones, fwereade, deadalusai, daveremy, Seo Sanghyeon, CurtHagenlocher, chaghi, cgravill, cartman, bobarnso, atifaziz, ashcor, alvanet, Helmut, fuzzyman, fabiofz, Eloff, RuiDC, Kevin Chu, Kyle Howland-Rose egonw, davec, dungen, dsblank, cjacobs, dmajnemer, leppie, Mark Rees, soulfry, tatwright, ufechner and wilberforce.

Thank you for your continued support of IronPython.

The IronPython Team

 

Marek has just announced that Mono's C# compiler 4.0 is complete.

To try it out, get the modules mono and mcs from our Anonymous Subversion Repository and build Mono like this:

	$ mkdir $HOME/mono4
	$ ./autogen.sh --prefix=$HOME/mono4 --with-profile4=yes
	$ make && make install
	

This is part of a RubyConf 2009 series:
Summary | What sets IronRuby apart? | Sneaking Ruby to the top / Embedding IronRuby | Project status

First a little background for those new to IronRuby …

IronRuby is a Ruby 1.8.6-compatible implementation, with support for some 1.9 features like string encodings. IronRuby is built on-top of the Common Language Runtime, so certain runtime-specific Ruby features are not supported on IronRuby, like callcc, ObjectSpace, and native extensions. However, local-continuations are coming, and we are considering FFI post-1.0 to support native code.

IronRuby runs on the CLR (2.0 SP1+) and Mono (2.0+), so IronRuby runs on a ton of platforms, including Mac OS and Linux. IronRuby also runs in the browser with Silverlight and Moonlight, a 4MB runtime which allows you to use Ruby to build “rich internet applications” … basically anything doing vector-graphics, webcam, audio, etc in the browser.

To at least prove IronRuby runs on the Mac, here’s IronRuby installing the activerecord gem:

Yay =P I spoke in-depth about this at OSCON this year, so if you’re interested in how IronRuby runs cross-platform, please read my OSCON 2009 post.

While “IronRuby running everywhere” is a great bullet-point, when would you use it instead of another implementation? I’ll briefly mention a few Windows-focused reasons, but the focus will be on things that work regardless of your platform.

One of IronRuby’s goals is to be the premiere Ruby implementation for Windows. Any type of development possible on Windows should be great on IronRuby; GUI, console, DirectX, etc. And some of these benefits also go cross-platform; for example using .NET’s WinForms for GUI apps will let you run the same app on Window and Linux.

Even systems management tasks can benefit from IronRuby – a scripting language that Windows developers can use for anything – like all the languages that come standard on Mac OS and Linux distributions.

Web developers can also use IronRuby to deploy their Ruby-based apps on: IIS is a great web-server, and IronRuby will make it easy for Windows shops to justify using Ruby on Rails or any other Ruby-based web framework. An interesting factoid: 51% of traffic on wiki.rubyonrails.org is from Windows users (data source: Matt Aimonetti and the Rails Core Team) – I’m not quite sure what that means, but at a minimum it means people who have an interest in Rails are using Windows.

Ruby in the browser

One of the great features of IronRuby is it’s ability to run in the browser. Unfortunately there isn’t a ton of information about how to do this, but a nice set of documentation is being prepared for when the new IronRuby site goes live. Here’s a sneak peak into how easy it is to run Ruby in the browser:

The code in the “text/ruby” script-tag is actually running in the browser -- it's not sending the code to the server or anything like that. Ruby can be used to build HTML-only apps (an Flickr photoviewer example walkthrough), full vector-graphics-based apps (the IronRuby tutorial), or a combination of both. These apps can also be run out of the browser; this post shows the above tutorial running as a native Windows desktop app. In the browser, this requires Silverlight for Mac OS and Windows, or Moonlight for Linux.

Great, it’s easy, but what can I do with it? Right now, the best source of documentation for this is my Back to Just-Text with Silverlight paper. A place-holder page for where all this info will be is http://ironruby.com/browser, but like I said, there is much more to come. The Gestalt project has a ton of cool samples and information as well, but most of this will eventually live on the actual IronRuby website.

For demos I showed during the talk, see http://github.com/jschementi/rubyconf2009/tree/master/gestalt.

Other than this being some cool technology, how could it actually be useful? I would not recommend porting all your JavaScript to this, but this is useful anywhere you need to show graphs, charts, anything visually oriented, or really anything where the browser feature-set isn’t enough. Rather than writing in ActionScript for Flash, you could use Ruby and Silverlight. Once you have a good reason to require Silverlight for a page, then it opens up the possibilities for using Ruby in the browser for things you used to use JavaScript for. For example, imagine writing both your server and client code in Ruby, and even reusing code between the two.

It may not be the only way to run Ruby in the browser, but it’s the most web-friendly. It’s worth noting that JRuby lets you write Ruby inside a Java applet, but that requires Java to be installed. While Java still has more market-penetration than Silverlight, Silverlight’s tiny size makes this an irrelevant point for me. Also, Silverlight is installed on 45% of the connected internet machines, so Silverlight’s market share is briskly increasing.

Also, HotRuby lets you write Ruby which compiles down to JavaScript or Flash, and while the demos are very impressive, the implementation is very not completed, and hasn’t been updated for almost two years. HotRuby requires the Ruby source code to be compiled on the server with YARV, and then the serialized bytecode is run on the client with a JavaScript VM for Ruby (which is the incomplete part). It’s a promising project if someone picks it back up.

Considering those alternatives, IronRuby’s script-tag development and just-html deployment make it the best experience for writing Ruby browser apps currently.

Anyway, I’ll write more about this when I can point you at a real website that shows what all this can really do.

Next stop, sneaking Ruby to the top.

This is part of a RubyConf 2009 series:
Summary | What sets IronRuby apart? | Sneaking Ruby to the top / Embedding IronRuby | Project status

Now that the turkey has settled and I’m back in Seattle, I’m finally getting around to writing about my time at RubyConf 2009 in Burlingame, CA (not San Francisco, liars! ;)). I spoke about IronRuby, got to meet a bunch of the other implementers, and overall had a great time. Jim Deville also got to come along for free, since Microsoft was a Silver sponsoring of RubyConf – next year we should sponsor the internet-connections since everyone using Chad’s room’s wireless was, well, fun … but no promises ;)

My talk was all about how IronRuby is extending the reach of Ruby. The two areas I focused on was “running in the browser” and “scripting existing applications.” And all that was sandwiched with a overview of the project and a status update. All content from the talk can be found in my RubyConf 2009 GitHub repo, but I’ll walk you through the talk with a couple of posts:

• What sets IronRuby apart? (brief highlight of Silverlight support)
• Sneaking Ruby to the top
  • Embedding IronRuby
• Project status

Here’s a direct-link to slides if you want them.

Everyone else’s talks

Here’s my strategy for attending talks: open laptop and code until the speaker catches my attention. When bored, go back to coding, and repeat. I got nothing done at RubyConf; irritating and refreshing at the same time. Maybe it was the shotty wireless, but I’ll stick with saying the talks were awesome. Here’s what I liked:

Keynote - Yukihiro Matsumoto

Matz outlined a new language called ZEPT: A general-purpose dynamic language which is great for distributed programming and metaprogramming. After explaining this very familiar language in some detail, he then turned it around and essentially said, “Wait, it’s Ruby! Kinda.”

While Ruby’s syntax is great for metaprogramming and DSLs, it needs work for distributed programming to be really great, but this is being worked on. Ruby currently has most of the building blocks for distributed programming, like lambdas, enumerators, and continuations, and things like a lazy-array are planned for future versions of Ruby. He closed with, “You can create the future of programming by working on Ruby,” and that there are more advances in internal DSLs in Ruby’s future.

Code of Art (Jeff Casimir)

Jeff handed out actual paper for his talk, so he gets props for that. He demoed ruby-processing, a port of the Java Processing library for making fancy graphics and visualizations; it uses JRuby. The main demo was a very simple “click-and-make-a-random-sized-circle” … so simple I had to rip it off for my talk. So, I sent Jim off with my demo to hack it up, and now we’re close to having a full 2D-only-port of ruby-processing for IronRuby. More about that later though.

FFI – creating cross engine gems (Jeremy Hinegardner)

FFI, Foreign Function Interface, is a DSL for describing C-libraries in Ruby; very similar to writing a header file. A benefit of using writing an C-extension based on FFI is that it should be compatible with many ruby engines, as the compatibility burden is placed on the ruby engine rather than the extension implementer. Supporting FFI will be a reality for IronRuby after 1.0; I’ll put this on the project’s TODO list. Anyone interested in starting an FFI implementation for IronRuby?

Embracing Collaboration with JRuby and JavaScript(Jon Crosby)

Jon’s talk got me smiling, since it’s the same problem I tried to solve with IronRuby on the client and server, but decided a Rails-specific solution was just good for a demo. He started his talk out with “browser plugins are not an option” … crap =P. Jon walked through his design process, until landing on a solution that basically cuts Ruby out completely and uses JavaScript to build both the client and the server portions of a webapp, sharing implementations and data. Wow, that’s one way to do it. :)

JRuby Everywhere!(Charles Nutter & Thomas Enebo) – slides

MacRuby: Ruby for your Mac (Laurent Sansonetti) – slides?

Rubinius in One Act OR Rubinius: A War on Two Fronts (Evan Phoenix) – slides

Rippin’ off Python (Chris Wanstrath)

I actually didn’t get to see this since it was at the same time as my talk. I saw someone say on Twitter that this was one of the best attended talk at RubyConf. Jerk :)

Ruby Mutants (Charles Nutter) – slides

Charlie talked about Duby and Surinx, his Ruby-derivatives. Duby is a statically typed Ruby-like language, while Surinx is a dynamic-typed language which depends on invokedynamic. Duby’s nice in that it’s not very JVM-specific (other than the backend), so an upcoming project of mine will be to write a CLR backend for this – having a Ruby-like language that is basically a facade on the CLR will fill in a lot of the holes we have with IronRuby, and hopefully influence some future IronRuby work – just like JRuby is planning.

Other Thoughts

No implementers care about Ruby 1.8.6 anymore; Ruby 1.9 is the focus for all future work. MacRuby isn’t even supporting 1.8.6. So why should IronRuby support it? Granted, JRuby supports 1.8.6, as well as other 1.9 features, but they have been a “real” implementation for a while. When IronRuby actually starts to get production apps, do we really think Rails 3.0 (which is Ruby 1.9 focused) won’t be standard by then? Personally I think IronRuby should re-evaluate it’s reasons for supporting Ruby 1.8.6; if we support 1.9, compatibility will get better as time goes on … where as supporting 1.8.6 is a sure-fire way to ensure a decrease level of compatibility in the future if we don’t keep up. Thoughts?

Also I got to meet Matt Aimonetti, of the “Pr0n Star” fiasco, but I’ll let that slide :) He’s seems genuinely excited about using Ruby in the browser with Silverlight, and also has always offered his help with promoting IronRuby on Rails; he interviewed me on the Rails blog not too long ago. I look forward to seeing greater collaboration between the rest of the Ruby community on IronRuby, and hopefully this is the start.

Overall it was a blast, see you all next year!!

Recently, a customer asked us if it was possible to develop and debug a VB/C# extension with Visual Studio 2010 (and the 2010 SDK), but still have a binary that also works with VS 2008. This is indeed possible, but it requires some hacking of your project file to get it set up.

One nice thing about this solution is that you can easily switch between targeting 2008 and 2010 by simply changing the startup project between the package project and the VSIX project.

Setup machine with VS 2008 SP1 + VS2008 SDK 1.1 + VS2010 Beta 2 + VS2010 Beta 2 SDK

1. In VS 2008 : create a VB or C# VSPackage
   • (optionally) Build/F5 to verify that it builds/loads as expected in 2008 Experimental Hive
   • Close VS 2008 Instances
2. Launch VS 2010, open the solution, and proceed with project upgrade wizard
3. Unload the VSPackage project, edit the project file, and add the following target after the Imports statements at the bottom:

   <Target Name="PkgdefProjectOutputGroup" Outputs="@(PkgdefOutputGroupOutput)">  
     <RegPkg ItemToRegister="$(TargetPath)"  
       ProductVersion="$(TargetVSVersion)"  
       RegistrationRoot="$(__InternalTargetRoot)"  
       SDKVersion="$(VsSDKVersion)" 
       UseCodebase="true" 
       OutputFile="$(IntermediateOutputPath)$(TargetName)_.pkgdef"
       Unregister="false" 
       UseVS2005MPF="$(__InternalUseMPF80)" />     
     <ItemGroup> 
       <_PkgdefOutputGroupOutput Include="$(IntermediateOutputPath)$(TargetName)_.pkgdef" /> 
     </ItemGroup> 
     <ItemGroup> 
       <PkgdefOutputGroupOutput Include="@(_PkgdefOutputGroupOutput->'%(FullPath)')" /> 
     </ItemGroup> 
   </Target>

4. Reload the VSPackage project
5. Add a VSIX Project to the solution (From Visual C#\Extensibility or Visual Basic\Extensibility in the New Project Dialog)
   • Note: You do not have to distribute your package in a VSIX container. This is simply a requirement for registering and debugging in the VS 2010 Experimental Instance.
6. Add a Project Reference from the VSIX Project to the VSPackage project
7. Unload the VSIX project, edit the project file, and add the following inside the <ProjectReference> node:

   <IncludeOutputGroupsInVSIX>
     BuiltProjectOutputGroup;  
     PkgdefProjectOutputGroup  
   </IncludeOutputGroupsInVSIX> 
   <IncludeOutputGroupsInVSIXLocalOnly> 
     DebugSymbolsProjectOutputGroup 
   </IncludeOutputGroupsInVSIXLocalOnly>

8. Reload the VSIX Project
9. Right-click the VSIX Project node and “Set as Startup Project” (if you wish to run/debug the package under VS2010)
10. F5 to debug the package running in the VS2010 Experimental Instance with VS2010

In preparation for the final IronPython 2.6 release, the project finally gets a nice homepage: IronPython.net!

CodePlex will continue to be the tool we use for project management and releases, but all end-user information will be on IronPython.net. Also, the .com domain still points at the super-old site, but will redirect to this site shortly.

The most notably addition is the .NET Integration Documentation, a thorough set of examples and descriptions of using IronPython with .NET. Considering this is IronPython’s main purpose, it’s amazing we got away with having hardly no documentation for this long … I guess the .NET integration is just that intuitive :) Anyway, please give it a read and let us know if you have any suggestions.

There’s a ton left to do!

This site is very much a shell of what it could be, and I’d love for the IronPython community to help out here. Here are a few things I’d like to add to the site in the very near future; please let me know if you’d lie to help out, or have other ideas:

• Who’s using IronPython? A list of companies, public websites, and any type of application which use IronPython, in any way, would be a great addition to the site. If you’re taking a large dependency on IronPython, I’d also love to have a more in-depth write up posted about you: Resolver Systems should definitely be on this list :)
• Many more code-snippets for the front-page which show IronPython’s strengths. Maybe a random code snippet every time you refresh, or a auto-cycling with some simple navigation to pause and go back-and-forth between them.
• Better organization of community articles: the IronPython community produces an enormous amount of documentation through blogs, articles, screencasts, and other mediums on the web. The IronPython website could never replicate this, so let’s make it a place to organize this information, grouping documentation together by topic and linking to the original author’s site.

Hope you like the new website!

Voy a Mexiquito lindo estas vacaciones de Diciembre.

Si quieren que nos reunamos para hablar de software libre, Mono, Linux, Moonlight, Silverlight, C# o para discutir por que La Mancha ya no escribe o el ultimo blog del Jetas mándenme un correo para ponernos de acuerdo.

This was fast! Wallace B. McClure has written the first e-book on getting started with Mono on the iPhone with MonoTouch.

This is a short e-book, 42-pages in size, but it is also very cheap, it is only 6.99 USD and will help you get started in no time with MonoTouch.

Here is the table of contents:

Table of Contents

iPhone Requirements 2

Development Strategies 3

Web Development with ASP.NET 3

MonoDevelop and MonoTouch 4

Visual Studio .NET ➪MonoDevelop 4

Classes in MonoTouch 4

What Is MonoTouch? 4

Namespaces and Classes 5

Introduction to Development on the Mac with MonoDevelop 6

Interface Builder 8

Outlets 10

Actions 14

Deploying to an iPhone 15

Mapping 17

MKMapView 17

The Application 18

Annotating the Map 20

Debugging 21

Interacting with Other Applications 22

UIPicker 22

NSUrl 24

UIAlertView 26

UITableView 26

DataSource 27

Binding Data to a UITableView 29

Customizing UITableView 30

Accelerometer 33

Settings 34

Things to Watch Out For 37

Resources Used 38

Stephane and Ruben are chairing the first Mono-developer room at the upcoming FOSDEM 2010.

Ruben writes:

As of now, you can submit your talk proposals! We want to make this a fun room and we want to accomodate all kinds of talks. For that reason, one thing we're experimenting with is having dynamic timeslots. Only want 15 minutes? That's okay! Need an hour? We'll see if we can squeeze it in! The most important factor is that it's interesting and fun.

So send in your proposals, be it large earth-shaking projects, or little hackery experiments that make you giggle with hacker joy, we want to hear it. We have the complete Sunday to schedule. Still have questions? Email me: ruben @ savanne be.

The submission form is here, go fill it in now! (Send in your proposals before December 20)

See you there!

Gestalt is a project by Mix Online to use Silverlight and the Dynamic Language Runtime to allow you to script web pages with Python or Ruby instead of with Javascript.

• The Gestalt Project

DLR.js is a library released by a collaborative effort between the Dynamic Language Runtime team and MIX Online Labs. This JavaScript library allows you to write Ruby, Python & XAML code in your (X)HTML pages. It enables you to build richer and more powerful web applications by marrying the benefits of expressive languages, modern compilers, AJAX & RIAs with the write » save » refresh development model of the web.

 Gestalt has reached a significant milestone with the release of version 1.0 and a widget pack. It has matured to the point where you can do really crazy things like run Rails *in your browser*. Probably not specifically useful, but it shows what it is capable of:

• Introducing Gestalt 1.0 and the Gestalt Widget Pack

A few months ago, we released Gestalt beta as a MIX Online lab.  Gestalt began as an exploration—a way to bring Ruby and Python to the web browser.  Today, we’re delighted to announce that Gestalt has been updated to version 1.0. It's now part of IronRuby 1.0 and IronPython.

What’s new in Gestalt 1.0? Gestalt Beta -- plus more!

• Supports bundling of Ruby and Python files using each language’s convention.  You can now (for example) package and run Rails on your client!
• Allows you to dynamically load assemblies (only downloads what you need)
• Integrated with the Dynamic Language Runtime
  Simplified and streamlined model for creating Gestalt apps.
• No jQuery dependency.
• Support for remote references to Gestalt
• Visual Studio debugging support
• A browser console for debugging and manipulating Gestalt
• Rich error reporting
• Built-in support for loading external assemblies and content
• Support for running multiple instances of Gestalt on the same page

They also have a longer blog entry discussing the thinking behind Gestalt and what it makes possible. Perhaps worth drawing out from this article is the following: "By adding a <script>
tag to the top of your HTML file, you can automatically enable use of HTML5-compatible video and audio tag syntax."

• Gestalt Grows Up
  

Last week, we discussed the fact that Microsoft invests heavily in both HTML5 and Silverlight, two technologies that other companies would have you believe are mortally opposed.  Our commitment to both was underscored this week by our announcements about IE9 and Silverlight 4.

When we launched Gestalt beta less than 4 months ago, our goal was to demonstrate a really simple idea: that a proprietary plugin like Silverlight complements and advances the standards-based web.  With today’s launch of Gestalt 1.0 and the first few widgets in the Gestalt Widgets Pack, I’d like to drill deeper into this underlying philosophy of Gestalt.

To get the latest build of T4MVC: Go to T4MVC page on CodePlex   One of MVC 2's major new features is the support for breaking up a large application into "Areas". This works by following a structure that looks like: Root folder Models Views Controllers Areas NerdDinner Models Views Controllers Blog Models Views Controllers So basically you still have your top level Models/Views/Controllers folders, and in addition to that you can have an arbitrary number of “Areas”, each having their own set of Models/Views/Controllers folders. Starting with MVC 2.6, T4MVC lets you use areas in much the same way it lets you access top level items.  e.g. you can now write: <%= Html.ActionLink("Delete Dinner", MVC.NerdDinner...(read more)

C#の場合、多重継承はインタフェースを使うことになりますが、実装クラスへの委譲を書くのがちょっと面倒です。一方、Pythonは実装の多重継承ができるのでこれを利用して委譲の手書きを手抜きできないか試してみました。 まずは、多重継承させるインタフェースを用意します。 using System; using System.Collections.Generic; using System.Linq; using System.Text; namespace IronPythonSampleLib { p ...

Up until now, most things related to T4MVC were happening through my various blog posts about it.  And while that was sort of working ok for a while, it was also less than ideal for a couple reasons. First, there was no single place to go to in order to get information about it.  You’d basically have to go through the various posts that describe the various features as they were added.  And as the number of posts grew, so did the pain involved in doing that. The second issue is that there was no good place to discuss it, ask questions and report issues.  So all of those things were mostly just happening organically as comments in my various posts, which really doesn’t work so well.  Blog Post comments don’t support threading...(read more)

Try Python is an online interactive Python tutorial using IronPython and Silverlight. The source code is available and open source and the tutorial material is written in a subset of the ReStructured Text markup.

Noel Baoilleach has taken this a step further by creating his own version, including the Webel library library and a tutorial on using it with interactive examples.

• Cheminformatics Tutorial using Python and Silverlight
• Try Python with Cheminformatics Tutorial

Recently I introduced Webel, a Python cheminformatics module that runs entirely on web services. One of the advantages of such a module is that it can be used in places where it is difficult to install a traditional cheminformatics toolkit. Like in your browser.

After some little work, I present Try Python...with Cheminformatics. This adds Webel as well as a short tutorial that introduces many of its features. With a few more tutorials that cover SMILES, InChI and so on in more detail, this could be useful for teaching purposes as well as bridging the gap to having students develop their own Python scripts that use the CDK, OpenBabel or the RDKit.

 Personally I think the Cheminformatics version of Try Python would be improved by the removal of the Python tutorial parts (only part 6 is Cheminformatics specific - making it a bit harder to find!). Creating custom tutorials using Try Python as a base is *fairly* easy (I'm sure it could be easier): it could be a great way of creating online examples of working with .NET or Python libraries.... I hope more people try this out.

Lately, I’ve been experimenting with the new editor APIs in Visual Studio 2010 to build some simple extensions to make Python editing a little better. Helpfully, IronPython exposes most of the complicated infrastructure (the tokenizer) to make the job easy. The documentation for the new editor APIs is still a bit weak; hopefully that will improve by the final release. In the meantime, the examples are the best source of information. There also a series of blog posts by an unknown author Mike Feingold about the NDjango editor for VS2010 that form a great end-to-end example.

Download & Installation

Download IronPython Extensions for Visual Studio 2010 (and the source code; Ms-PL as always) from my BitBucket repository or from the Visual Studio Gallery (direct link). For direct downloads, just run (double-click) the .vsix file to install it into Visual Studio. Otherwise, you can use the extension manager (search for "IronPython") and install it directly from Visual Studio.

Features

The extensions provide three features so far: syntax highlighting, brace matching, and outlining.

In the future I'm planning on adding project support, templates, and (most difficult of all) IntelliSense.

Although I've left Resolver Systems I still follow closely what they're up to. Resolver One, the IronPython powered spreadsheet with the programming model right at its heart, is an innovative and unique product [1] that deserves to flourish. ... [400 words]

The most important piece of news from last week's PDC was Microsoft's decision to turn Silverlight into the universal platform for building cross platform applications.

The upcoming version of Silverlight will no longer be a Web-only technology. It will now be possible to build full desktop applications with Silverlight.

Desktop Silverlight applications differ from the standard Silverlight in a few ways:

• Full access to the host file system, like any other .NET application would have.
• None of the socket connectivity limitations that are present on the sandboxed versioned of Silverlight. Full network access (we should build a MonoTorrent UI for it!)
• Built-in Notifications API to show up bubbles to the user when they need to interact with the application.

Although Moonlight has supported this mode of operation since day one, turning this into a standard way to develop applications was going to take a long time. We would have needed to port Moonlight to Windows and OSX and then we would have to bootstrap the ecosystem of "Silverlight+" applications.

But having Microsoft stand behind this new model will open the gates to a whole new class of desktop applications for the desktop. The ones that I was dreaming about just two weeks ago.

This was a big surprise for everyone. For years folks have been asking Microsoft to give Silverlight this capability to build desktop apps and to compete with Air and it is now finally here. This is a case of doing the right thing for users and developers.

Desktop Tools in Silverlight?

Now that this technology is available, perhaps it is a good time to start a movement to create a suite of Silverlight-based desktop applications.

The benefits to me are many:

• .NET applications that actually look good. In the past your choices were basically of Gtk# or Winforms, neither one really designed for this graphic-designer driven world.
• We can join forces with Windows/MacOS developers to create the next generation of desktop applications.
• Developers can tap into the large ecosystem of third-party controls that exists for Silverlight.

For the Moonlight team, this means that there is a lot of work ahead of us to bring every Silverlight 3 and 4 feature. I think I speak for the whole Mono team when I say that this is exciting, fascinating, challenging and feels like we just drank a huge energy boost drink.

If you want to help, come join us in the #moonlight or #mono channels on the IRC server at irc.gnome.org.

Silverlight 4

There are many other great features in Silverlight 4, but none as important as Silverlight becoming a universal runtime for the CLR. This is a revolution.

If you are curious about all the new tactical features of the revolution, check Tim's Complete Guide to the new Silverlight Features.

If you have the time, watch Scott's keynote's presentation where he introduced the new features (he starts at 1:02). I loved the use of HTML as a Silverlight brush (paint with HTML and even Flash). If you have time, these are some great sessions on Silverlight:

• Microsoft Silverlight 4 Overview: A good intro, repeats a lot from Scott's keynote.
• Improving and Extending the Sandbox with Silverlight 4: Joe Stegman's presentation on the revolution.
• RIA Services: The technique that lets you "remove four acronyms" from your development, mindblowing.

Droolingly yours,
Miguel de Icaza.

In association with Holdenweb I'll be taking an IronPython training course on January 21st in New York. Booking site for the IronPython Master Class The details of the course: Michael Foord is an early adopter of IronPython, having used it for (among other things) the creation of the Resolver One Python-driven spreadsheet product. ... [597 words]

The implementation of the next version of ConfigObj is now complete. All that is remaining is for me to update the documentation and package the release. ... [522 words]

GTK# is a managed interface to the GTK user interface library. GTK# is part of the Mono project, but it can also be used from .NET on Windows.

In this blog entry, another one from Steve Gilham, he illustrates using GTK# from both IronPython and C# by porting some C# examples.

• “Hello GTK#” from the latest IronPython and F#

A little post to record a short bit of spiking with GTK# as UI toolkit, porting the simple C# examples from here to my preferred .net languages. Neither of these explorations are totally novel -- there are examples in either language to Google, but not all of them recorded all the details of the slight rough spots that needed a little working (and they were often not at all recent, either).

For IronPython 2.6 latest with GTK# 2.12.9-2, running the programs as ipy Program.py.

The dynamic nature of the language means we can lose a lot of the declaration clutter. We just have to explicitly reference the main GTK# assembly (which is GAC'd by the GTK# installer), and away we go.

The final release candidate of NWSGI 2.0 is now available. Except for version numbers, this is what will become NWSGI 2.0 as soon as IronPython 2.6 is released.

NWSGI 2.0 Release Candidate 2 includes all of the features of NWSGI 2.0 Release Candidate 1, and adds support configuring tracing, lightweight scopes, and the profiler. It is built against IronPython 2.6 RC3.

The following issues are fixed in this release:

• Add configuration option for Profiler
• Add configuration option for Lightweight Scopes
• Add configuration option for tracing

More IronPython and DLR related projects, articles and news from around the web.

• Alpha-encoding file versions

 Steve Gilham shows how to generated encoded version strings for installers using IronPython:

When building installers the UpgradeVersion must have a unique property value that is an installer public property (upper-case alpha). So, what better way of adding uniqueness than making it have the form "product name + product version" with the version suitably encoded...

So, a script for turning a file version (4 x 16bit ints) encoded as a System.Version into a short alpha string, assuming that Major and Minor will be small, and that common approaches are to step Build, to use a stepped Build plus date-stamped Revision, or a timestamp Build and Revision.

• C# + IronPython: вызов методов

An article on IronPython, and in particular using IronPython from C#, in Russian.

• IronSharePoint Source Code Available

 A while ago Christian Glessner announced the start of the IronSharePoint project: showing how to develop SharePoint applications with IronPython. Well, he hasn't released anything but there is now code available for download from the Codeplex site. Could be worth exploring if you work with SharePoint...

• Passing the Torch

 Since early 2007 John Lam has been working for Microsoft as program manager of IronRuby, the implementation of Ruby on the Dynamic Language Runtime. Up until almost eleven months ago that is. John quietly transferred to a 'secret' project within Microsoft, a project that has also claimed Curt Hagenlocher (IronCurt). As they are *close* to being able to announce the secret project John has made his departure from the IronRuby team official and handed over the reigns to Jimmy Schementi who was previously only in charge of the integration between dynamic languages and Silverlight. Now Jimmy is doing both.

• World's Worst Paint Program

 Dino Veihland presented on IronPython and the Dynamic Language Runtime at the recent PDC conference. Part of his talk featured the "World's Worst Paint Program", which from Dino's description includes both IronPython and IronRuby code. He has made this available for download from the IronPython Codeplex Site.

 This is built using Visual Studio 2010 Beta 2 and the IronPython CTP for that release - so you'll need to download both of those.  I've also included the Python and Ruby code that I used during the demonstration in a file called code.txt.  The paint program it's self is in the final form at the end of the demo.

Face detection in images is very cool (and perhaps a little bit scary), and with the help of Emgu CV it can be done from IronPython.

Emgu CV is a cross platform .Net wrapper to the Intel OpenCV image processing library. Allowing OpenCV functions to be called from .NET compatible languages such as C#, VB, VC++, IronPython etc. The wrapper can be compiled in Mono and run on Linux / Mac OS X.

This blog entry from Clark Updike shows how.

• Face Detection "Hello World" in IronPython using Emgu CV and OpenCV

 A couple notes compared to the Emgu wiki version--I was able to get everything working without having to disturb the IronPython install (I didn't copy any files into the IronPython start directory). I simply linked used sys.path to add the locations where the dll's live. Also, I did explicit import for everything. It's a bit more work to figure out what needs to be imported, but it avoids namespace pollution issues. Also, the img.Draw line needed a few tweaks. I had to drop the [float] bit from the original. And with the original version, I was also getting an error on this same line, saying:

TypeError: expected MCvBox2D, got MCvAvgComp

I was able to work around this by passing in the ".rect" rectangle attribute to the Draw method (I'm guessing the api has evolved since the 1.4 Emgu version used for the original). Lastly, I was getting to objects detected--so I used parameters to the detector to only get the single face in the image (basically by telling it to use a larger minimum detection size, minSearchScale). Anyway, now it works the way I was hoping.

One of the important new features in IronPython 2.6 is the __clrtype__ metaclass.The __clrtype__ metaclass allows you to create a real .NET class that backs your Python classes. This is important because there are many .NET features that *require* a real .NET class: which includes databinding and implementing WCF services (Windows Communication Foundation).

The problem with __clrtype__ is that it requires dealing with low level details; namely building the class yourself from IL bytecode. Harry Pierson and Shri Borde have been working on a library (clrtype.py) to make this simpler.

Lukáš Čenovský has looked at this before but hit limitations with what clrtype made possible. In three new blog entries he demonstrates how to use __clrtype__ with databinding in WPF and Silverlight and to implement WCF services.

• INotifyPropertyChanged and databinding in IronPython WPF

 INotifyPropertyChanged is important interface for building WPF or Silverlight applications using M-V-VM concept (MSDN article).

In simple language, you have a Model which provides access to your data (e.g in database, files, web, etc.). Then you have a ViewModel that access data in the Model via Model's interface and provides data to a View which is XAML file with UI layout. Linkage between ViewModel and View is done by binding that utilizes PropertyChanged event to properly update all UI elements.

I have found two examples how to implement INotifyPropertyChanged interface in IronPython. The first one uses __setattr__ hook. Personally, I don't like it - it is not clear and easily readable code. The second one is better because it uses properties. But you have to write self.OnPropertyChanged("my_property_name") for every property. Not ideal.

That's why I sit down and write a notify_property.

•  INotifyPropertyChanged and databinding in Silverlight

This article uses the updated clrtype module to apply the databinding technique to Silverlight. The cool thing is that I'm already using this technique for databinding with the Silverlight Toolkit DataGrid in my new job. No more stub C# proxy classes, yay!

• WCF Service in pure IronPython

 Even using __clrtype__ you still couldn't use WCF (for creating and consuming web services) from pure IronPython because it requires *creating* interfaces, which couldn't be done. With the latest improvements to clrtype it is now possible.

I wrote about implementing WCF service in IronPython a couple of weeks ago. Meanwhile I pushed Shri a little bit with the clrtype.py and he has implemented ClrInterface metaclass there so we can create the whole WCF service in IronPython now.

The IronPython interface implementation is straightforward.

Also switching from C# interface to IronPython interface is easy.

To get the latest build of T4MVC: Go to download page on CodePlex   MVC 2 Beta introduces two nice helpers called Html.RenderAction and Html.Action.  Phil Haack described them in detail on his blog , so you may want to read through that before reading this post. Basically, they’re two additional methods that follow the standard MVC pattern of passing the controller name and action name as literal strings, and the action parameters as anonymous objects.  e.g. Copying from Phil’s example, if you have an Action like this: public ActionResult Menu(MenuOptions options) { return PartialView(options); } You can write this in your View: <%= Html.Action("Menu", new { options = new MenuOptions { Width=400, Height=500} })%>...(read more)

IronPython 2.6 is the up-and-coming version of IronPython targeting compatibility with Python 2.6. As well as the new features in Python 2.6, IronPython 2.6 has several important new features specific to IronPython. These include:

• The __clrtype__ metaclass for data binding and .NET attribute support
• Implementation of the ctypes module
• Support for Python stack frames and sys.settrace, which means the pdb debugger works
• Better performance through adaptive compilation
• Faster startup

IronPython 2.6 Release Candidate 3 has just been released. The hope is that this will be the last release candidate before the final release:

• IronPython 2.6 Release Candidate 3 Release Notes and Download

We’re pleased to announce the third and hopefully final release candidate of IronPython 2.6. Release Candidate 3 only includes Silverlight-related changes pertaining to some incompatibilities between 2.6 RC1 and RC2. Those who utilize IronPython for non-Silverlight scenarios will happily find virtually no churn from RC2. We strongly encourage everyone interested in Silverlight to test out this release ASAP because we plan on releasing IronPython 2.6 final in a week if no major new regressions are detected.

Two more articles from Ibrahim Kivanc, the Turkish blogger who has written several articles on IronPython and Silverlight. Both of these articles are in English.

• IronPython 2.0 and Access to .NET Libraries
  

IronPython 2.0 version now runs on DLR (Dynamic Language Runtime). DLR is a platform on .NET which is host Dynamicly typed languages on it. Now Dynamic Languages Communicate eachother and C#,VB, COM Objects, .NET Libraries.

IronPython, with 2.0 version runs on DLR (Dynamic Language Runtime); it’s a platform like CLR architecture. It’s host for Dynamic Languages on .NET. With this architecture Dynamic Languages now faster then running on CLR and easily communicate with other .NET objects!

•  IronPython WPF Error

In my opinion IronPython Studio is not stable enough for production use. It does have the advantage of being integrated in Visual Studio so some people can't resist trying it out. (You can read my write-up of IronPython Studio at: IronPython Tools and IDEs.)

If you insist on trying out IronPython Studio there are various minor trials and tribulations for you to overcome; using the WPF designer is one of them. In this article Ibrahim explains how to jump over this particular hurdle and get the WPF designer working in IronPython Studio.

http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=36150

This release contains a few small Silverlight fixes, with basically zero changes to the Desktop version of IronPython. Hopefully third time's a charm.

I've uploaded the World's Worst Paint Program, as seen in my PDC talk, to IronPython's CodePlex site:

 http://ironpython.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=28125#DownloadId=93331

 This is built using Visual Studio 2010 Beta 2 and the IronPython CTP for that release - so you'll need to download both of those.  I've also included the Python and Ruby code that I used during the demonstration in a file called code.txt.  The paint program it's self is in the final form at the end of the demo.

To get the latest build of T4MVC: Go to download page on CodePlex   T4MVC build 2.5.00 brings a couple of fun new features that I’ll describe in this post.  I can’t take too much credit for them as they came from users who suggested them to me, and helped out getting the code going.   Support for multiple output files Up until now, T4MVC.tt has always generated a single file, which is the T4MVC.cs that you see get nested under it in VS.  And normally, this is the way T4 templates work: they just generate one file.  But last week I got an email from Stuart Leeks who pointed me to a new blog post from Damien Guard that describes a nice way to get around this description.  All of Damien’s logic is very nicely encapsulated...(read more)

As I mentioned in my last entry I'm now working on a Silverlight application with Django on the backend. This means that we're using Django to serve json to the Silverlight application, so whilst we're using the Django ORM, url routing and authentication we aren't using its templating. ... [713 words]

Jimmy Schementi is the Microsoft program manager for the integration of dynamic languages (IronPython and IronRuby) and the Silverlight browser plugin. As well as dynamic languages, Silverlight applications can be written in .NET languages like C# and VB.NET - and these languages can embed IronPython.

Although embedding IronPython in a C# Silverlight application is initially straightforward (although a bit more verbose than embedding using the normal .NET framework / Mono as the ScriptRuntime needs to be configured), it gets painful fast. This is especially true when the Python code you execute needs to import anything, which has basically been broken on Silverlight for quite some time.

In his latest blog entry Jimmy looks at how embedding from Silverlight has got simpler recently, and also at fixing the import problems.

• Embedding IronPython in Silverlight - Importing

I’ve heard plenty of times on the IronPython Mailing List that embedding IronPython in Silverlight is easy at first, but then you fall off a cliff when trying to import, be it from a .NET namespace, the Python built-ins, or even other Python files. Let me clear some things up, and fix some code in the process.

Slight detour – Embedding in Silverlight 101
First off, Michael Foord has an article on his website about Embedding IronPython in Silverlight, which still works. However, that’s a ton of complicated code, all having to do with creating a ScriptRuntime instance correctly configured for Silverlight. To make this much less verbose, DynamicEngine.CreateRuntime (in the Microsoft.Scripting.Silverlight namespace) will create a ScriptRuntime all prepped for use in Silverlight; this significantly reduces the boilerplate hosting code:

More IronPython and DLR related projects, articles and news from around the web.

• Texas Holdem Hand Equity Calculation in IronPython

 Greg Bray has been experimenting with using Resolver One to write Texas Holdem calculating spreadsheets with IronPython. In this blog entry he shows the IronPython code for calculating hand equity:

This year I have been working in my free time to create easy to use Texas Holdem poker spreadsheets based on IronPython using Resolver One. These spreadsheets can be used to calculate Win/Tie/Loss odds, but some people like to use hand equity instead since it represents a player’s overall stake in the pot. Equity of 1.0 or 100% means that they will win the entire pot, where as equity of 0.5 (50%) or 0.25 (25%) means that they will split the pot with other players. You can again use Monte Carlo analysis to run a number of trials before all of the board cards are dealt to estimate a player’s current equity in the hand. This means that if during 4 trials I would win 2 of them and split the pot with one other player on the other 2, then my equity would be (1.0+1.0+0.5+0.5)/4 =  3/4 or 75%.

Calculating Win/Tie/Loss statistics on an independent player vs player basis is very simple, as the player’s pocket cards are evaluated against each opponent one at a time to show which opponent hands are stronger or weaker than your own. This does not take into account how the pocket cards of other opponents might change the odds, since in reality you usually play verse a table of opponents not just one opponent at a time. Changing the spreadsheet to work against the whole table would require changing the Monte Carlo simulation from a “row by row” analysis to a “table by table” analysis, where by you setup a table of opponents using a random hand for each player given the information that you have about their hand (AK, KK or QQ, Group1, etc..) and then generate a random 5 card hand based on the currently dealt cards.

• IronScheme 1.0 RC 1

IronScheme is an implementation of R6RS Scheme for .NET and Mono implemented on the Dynamic Language Runtime. You can either use it for writing .NET applications or for embedding into other applications to provide a Scheme scripting environment:

IronScheme provides 2 run modes: either via direct invocation on the commandline or via a REPL interactive environment.

IronScheme can also used an embedded scripting library in your .NET programs.

With 1.0 RC 1, IronScheme implements the entire R6RS Scheme standard, and only fail 4 of 8884 tests in the PLT R6RS test suite.

IronScheme runs on MS .NET and Mono. Unfortunately, it does not seem to work under 64bit on Mono.

Since the release of 1.0 Release Candidate 1 leppie has also written a blog entry demonstrating the use of the new dynamic keyword in C# 4.0 with IronScheme: IronScheme and C# 4’s new dynamic keyword

• In I go with Indigo, the new open source cheminformatics toolkit

Noel Baoilleach demonstrates using the open source Indigo cheminformatics toolkit from IronPython.

Charlie Zhu has already written an example application using C#. Rather than wait for CPython bindings, I installed IronPython and used it to access Indigo's .NET libraries (Dingo, in this case) to do a SMILES to png conversion.

• IronRuby 0.9.2

A new release of IronRuby, IronPython's red-headed cousin that is still on it's path to 1.0. Release Notes:

The IronRuby team is pleased to announce version 0.9.2! As IronRuby approaches 1.0, these 0.9.x releases contain important bug fixes and enhancements that IronRuby users request; this release fixes/closes 44 bugs. For more information see the "Bugs fixed" section, and the CHANGELOG.

This release is the first to give IronRuby a MSI-based installer for Windows. Try it out and let us know if it does not install on your system.

• bridge 0.4.0 release
• bridge homepage

Bridge is a "General purpose XML library for CPython and IronPython". It provides a common interface (Document, Element, Attribute, Comment and PI) for working with XML whether you are using CPython or IronPython.

Big personal news; I've changed jobs. After more than three years working with Resolver Systems I felt it was time to broaden my development experience. ... [347 words]

PyCon 2010, the annual international Python conference is coming soon (February 17th 2010 in Atlanta US). The schedule of talks is now up, and as usual there are several IronPython related talks.

• 67. IronPython Tooling

 By Dino Veihland, core IronPython developer:

One of the most popular requests for the IronPython team is tooling support. During this talk I’ll show you some of the existing tools available to help create IronPython applications. I’ll also look at the latest IronPython features which can help you debug, profile and improve your applications. I’ll also compare and contrast these with the solutions available for CPython that you may already be familiar with.

• 71. Python in the Browser

By Jimmy Schementi (Microsoft program manager for IronPython / IronRuby Silverlight integration):

You write your server code in Python because you want to. You write your browser code in JavaScript because you have to. But with IronPython and Silverlight, you can write your browser code in Python and leave JavaScript behind. This talk provides an overview of Silverlight for Python developers, including out of browser applications as well as the new “just text” model where Python code is embedded directly in HTML pages. Even if you develop on Linux or Mac, you can still take advantage of Silverlight in the browser.

As well as these talks the conference starts with a Virtual Machine (VM) summit, with attendees from the major implementations of Python plus those implementing other popular dynamic languages and Virtual Machines for dynamic languages.

Dave Fugate (IronPython tester and infrastructure guy) is also planning a Testing IronPython poster session.

After the summits are the tutorials and I will be repeating the IronPython tutorial I gave last year. If you're interested in getting some hands on experience of developing with IronPython then come along.

For those interested in alternative implementations of Python you will also appreciate these talks:

• 148. Pynie: Python 3 on Parrot

By Allison Randal of the Parrot Foundation:

Pynie is an implementation of Python 3 on Parrot. The goal of Pynie is to duplicate the pure-Python behavior of CPython 3.x, and perhaps eventually a C API compatibility layer. Parrot provides a set of compiler tools and core functionality common to many dynamic languages, so the core code of Pynie is lightweight. Pynie allows Python 3 libraries to be shared between multiple languages. This talk is an overview of the features Pynie currently supports and the work left to be done, together with an introduction to the internals of Pynie.

• 13. How and why Python is being used to by the Military to model real-world battlefield scenarios

By Mr. Eric Silverman (ALATEC Inc. / US Army):

Leveraging the power of Python, military analyst and software developers out at White Sands Missile Range in New Mexico have converted a closed-form model, which was developed for scripted Cold War scenarios, into a more sophisticated and adaptive system. COMBATXXI is a premium wargaming model, which now is poised to answer questions that have a direct effect on military operations currently in theater, in large part because of Python.

• 65. Extending Java Applications with Jython

By Frank Wierzbicki (core Jython developer):

Jython is an implementation of Python for the JVM. This talk covers the options available for integrating Jython and Java code, especially Java calling into Jython, since this is the trickier case. This talk will also cover some Java specific deployment options, such as deploying your Jython application as a jar file. Jar files allow you to package Java/Jython applications into a single archive. In many environments a user can click on a jar file to launch the contained application.

• 83. The speed of PyPy

By Mr. Maciej Fijalkowski (PyPy core developer):

The first part of the talk will cover PyPy's speed achievements resulting from the last year's work on the Just-In-Time Compiler. I'll present and discuss a number of benchmarks and compare against other Python-speed projects. I'll also cover the basics of how the JIT works and what sort of programs it can greatly speedup (and which ones it can't).

• 101. How to write cross-interpreter Python programs

By Mr. Maciej Fijalkowski (PyPy core developer):

This talk will cover basics about writing cross-interpreter
python programs. What to do and most of all what not to do. This will help you if you want at some point in time to
run program on for example Java platform or faster python
interpreter, but also if you want to keep it running between CPython releases.

• 189. The Ring of Python

By Holger Krekel (PyPy and py.test developer):

CPython 2.5/2.6/3.1, Jython, IronPython, PyPy, StacklessPython, UnladenSwallow, Cython ... what do we make of all these cool interpreter projects and versions? Where does competition help and where does it hamper?

This talk is for stirring discussion and thoughts on making the most out of wealth/curse of interpreters. I am also going to showcase and discuss 'execnet' one of my own related projects.

More IronPython and DLR related projects, articles and news from around the web.

• IronPython in Visual Studio 2010
• Screenshot of syntax highlighting

 Visual Studio 2010 doesn't come with IronPython support out of the box, but it does have extensive APIs for writing your own extensions. Jeff Hardy has taken up the challenge and has written a set of IronPython extensions for Visual Studio 2010 with syntax highlighting, regions etc. The project has binaries available: "Just double click the .vsix file to install."

• StackOverflow DevDays Cambridge Review
• Diary of a schwag hag
• Cambridge Stack Overflow Dev Days

At the end of October I attended the StackOverflow DevDays in Cambridge UK and spoke on Python and IronPython. I demonstrated .NET integration with IronPython by creating a simple Windows Forms application at the interactive interpreter. This was followed by going through Peter Norvig's Python Spell Checker as an example of concise Python code. Thanks to Ned Batchelder for the slides of his Boston presentation, which served as inspiration.

The links above are three reports from the day, the first two positive. My favourite quote being "It was a huge surprise that the Knuth-packing beardo in the front row turned out to be a Windows developer, demoing on IronPython". But like Jeff Atwood said in his closing presentation; if someone doesn't hate what you do then you're doing it wrong. The third reporter didn't enjoy my presentation "I wasn't too keen on this presentation. There were statements like "Dynamic Programming makes it easy to test" and "Dynamic Programming means I type less" that I didn't agree with and there was no follow up to back it up". (See the comments on that entry for my reply.)

• Identify the x64 Windows for IronPython 

A Japanese blog entry showing IronPython code (using WMI) for detecting whether your code is running on a 32bit operating system or a 64bit one.

• Intellisense for IronPython (IronPythonEditor)

Yet another release from the mysterious Japanese IronPython and Windows Forms project that we've covered before.

• django-xapper project

 'xap' files are the way you serve Silverlight applications. django-xapper is  a project to build and serve xap files from Django, making it easier to integrate Python on the server with Python on the client for projects using IronPython and Silverlight.

Xapper is a Django app to help facilitate the development of other Django apps that include Silverlight apps. In particular it is geared towards Silverlight apps implemented in IronPython or other dynamic CLR languages.

Xapper serves a similar function as Chiron, which is now distributed with the IronPython Silverlight binaries. Both these apps can dynamically generate Silverlight packages (.xap files) from a directory of files and serve it over HTTP upon request. This means that all you need to do to pick up the changes you've made to your Silverlight app is reload the page in your browser, making development of Silverlight apps much nicer. The main difference between Chiron and Xapper is that Xapper is oriented towards integrating with Django, while Chiron is a standalone web server oriented only towards development of the client-side app.

Arne's presentation on concurrent programming at Monospace ago has been published.