Planet IronPython

In the Visual Studio 2008 SDK, we have several samples (most notably, IronPythonIntegration) set up to use the ZipProject, ZipItem, and VSTemplate build actions to create template zip files.

Last week, I published a post on the Visual Studio Blog discussing how you could build templates from source files and package them up in a VSIX container using the new templates in the Visual Studio 2010 SDK.

We’ve been hearing questions about how to take an existing project (updated from Visual Studio 2008, still using ZipProject/ZipItem) and include the built zip files in the VSIX container.

Unfortunately, this doesn’t happen automatically for you. The reason is that the zip files are not specified as input files for building the VSIX container in the VSSDK build targets.

Fortunately, since MSBuild is a highly extensible system, we can make up for this with a little bit of project customization. Simply add the following to your C#/VB project file to get your existing templates included in the VSIX container:

<PropertyGroup>
    <GetVsixSourceItemsDependsOn>$(GetVsixSourceItemsDependsOn);GetVsixTemplateItems</GetVsixSourceItemsDependsOn>
</PropertyGroup>
<Target Name="GetVsixTemplateItems" DependsOnTargets="ZipProjects;ZipItems">
    <ItemGroup>
        <VSIXSourceItem Include="@(IntermediateZipItem)">
            <VSIXSubPath>ItemTemplates\%(IntermediateZipItem.Language)\%(IntermediateZipItem.OutputSubPath)\%(IntermediateZipItem.Culture)</VSIXSubPath>
        </VSIXSourceItem>
        <VSIXSourceItem Include="@(IntermediateZipProject)">
            <VSIXSubPath>ProjectTemplates\%(IntermediateZipProject.Language)\%(IntermediateZipProject.OutputSubPath)\%(IntermediateZipProject.Culture)</VSIXSubPath>
        </VSIXSourceItem>
    </ItemGroup>
</Target>

You will also need to add the following lines (as appropriate) to your source.extension.vsixmanifest:

<Content>
    <ProjectTemplate>ProjectTemplates</ProjectTemplate>
    <ItemTemplate>ItemTemplates</ItemTemplate>
</Content>

These lines each declare a root folder in your VSIX file that VS should examine for template files. Project template zip files will be placed in the ProjectTemplates folder inside the VSIX file. Item template zip files will be placed in (you guessed it)…the ItemTemplates folder inside the VSIX file.

I’m happy to announce that after the filing of an Intent to Package and nearly 2 years of work, IronRuby 0.9, IronPython 2.6b2, and the DLR are now in Debian. To my knowledge, this is the first package in Debian with direct and active upstream support from Microsoft.

Kudos for this release go to Jo Sheilds (package sponsorship & mentoring), Mirco Bauer (package sponsorship & mentoring), Matthias Klose (IronPython package review), Ivan Porto Carrero (IronRuby build/test support), Jim Deville (IronRuby build/test support), Jimmy Schementi (upstream point of contact @ Microsoft), Dino Viehland (IronPython build/test support), Michael Foord (IronPython build/test support), Marek Safar (mono c# compiler support), Ankit Jain (xbuild support), the folks on OFTC’s #debian-cli, Freenode’s #ironruby and GimpNet’s #mono, and the folks on the IronRuby and IronPython mailing lists.

This is my first package in Debian, too. I’m pretty ecstatic ;)

Last weekend I was very fortunate to speak at PyCon 2010 in Atlanta about writing browser-based applications in Python. A majority of the IronPython team was also there; Dino Viehland spoke about IronPython Tooling in a keynote slot, Dave Fugate gave a poster presentation about testing IronPython, and Bill Chiles was there for emotional support. It was also great to see Michael Foord, and also see how supportive the Python community is of IronPython.

Here’s the write-up from my talk:

Introductions and talk overview

I primarily work on IronRuby, but when it comes to web technologies I give IronPython love as well. Actually, I was an intern back when it was just the IronPython team, and when I started full-time I was doing exactly what this talk is about -- getting Python running in the browser -- so I'm really excited to be talking about this at PyCon.

You, the Python developer, use Python because you want to, but in the browser you use JavaScript because you think you have to. With IronPython you can write browser code in Python. I’ll only begin to answer "what can the browser bring to Python?" and "what can Python bring to the browser?" in this short overview; examples will be very simple (with the exception of a few flashy ones) to make sure you can get started immediately.

Follow along

• Watch the video of the talk from PyCon
• Get all the demos from GitHub (slides too) (view online)

Also, all information and documentation about this can be found the new ironpython.net/browser page:

Setting Expectations

“Python in the browser” is not Microsoft embracing and extending the browsers to support Python. In fact, this integration downloads python on demand, so there is no change required to the browser This is because Silverlight as the Python execution engine …

… and if you’re wondering “What is Silverlight?” …

Silverlight is a browser plug-in for Windows, and Mac OS (Novell makes a Linux version called “Moonlight”), which provide a managed execution engine for .NET-based programming languages in the browser, a rich set of vector-graphics-based UI features, and interop with the browser programming model and DOM. Go to http://silverlight.net for more information.

Hello, World

Let's start with the latter, and show the most obvious thing Python can bring to the browser: Python.

To develop a Python application in the browser, you just need your favorite text editor; so open it up, create a HTML file, reference dlr.js, and then you can use script-tags for running Python code:

And the Python code does what you'd expect:

Though, I’d strongly suggest against writing any real app with your python inline with HTML, as it then can’t be reused. Sticking your python code in a .py file and referencing it from a script-tag is preferred for separation-purposes.

Simple, right? Let's do something slightly more complicated, like handling mouse clicks. I'd prefer to do this in a REPL window, so let's turn one on in the browser; just place the following script-tag in the page:

Note: you have repl.py locally if you downloaded the demos, or point to the online one directly.

And now when you add ?console to the page's URL a Python repl window will appear:

The console is hooked up to sys.stdout, so your existing text-based Python scripts can come alive in the browser (sans reading from stdin). Also, any print statements you use in the app will show up in the console as well, making it a great println-debugging tool.

Let's play around with the page a bit, adding a DOM element and changing it's HTML content to "Ouch!" when clicked:

How all this works

Wow, Python works in the browser! Let's look behind the curtain for a second to see what is really going on.

dlr.js contains a collection of functions for creating a Silverlight control on the HTML page that is capable of running IronPython code.

By default, just running dlr.js injects a Silverlight <object> tag into the page (immediately after the script-tag) so it can run only DOM-based scripts, and also scans for other script-tags indicating that you want a Silverlight rendering surface, but more on that later.

The injected Silverlight control points to a Silverlight application made specifically to embed the dynamic language runtime, the compiler/runtime/embedding infrastructure IronPython is built on, find all the Python code the HTML page uses, and executes it.

The XAP is tiny, as the DLR and IronPython are in separate packages which are downloaded on-demand; the DLR and IronPython are not installed with Silverlight, so they must be downloaded with the application.

However, if the application depends on the ironpython.net binaries, the user's browser will cache them and they won't be re-downloaded for any other app; almost as good as being part of the installer, while still being able to be open-source.

Now user-code is able to run. Each inline Python script-tag is executed as if it was one Python module, and all other Python files execute as their own modules.

The code is handed off to the DLR Hosting APIs (in the Microsoft.Scripting.Hosting namespace), which (a bit simplified) looks like this in C#:

Executing Python code with the DLR hosting APIs is very straight-forward; essentially Python-eval for .NET-based languages. This hosting API abstract the “embedding” of Python away from the actual engine, so an application that hosts the DLR can use one API and switch between any language compatible with the DLR.

For more information how how this all works, see the paper and the source code. Also, for more information on the DLR, see the DLR docs page.

Batteries included here too

Great, I can write python code in my browser, but how do I test it?

A powerful part of Python is its standard-library; almost all Python applications depend on it, and it has some really useful libraries, like unittest. Here's a very simple test of the “say_ouch” app:

But where did unittest come from? Take a closer look at the first line:

That zip file contains the pieces of the Python standard-library that unittest depends on.

The Python standard library is a little less than 5MB compressed, so it's not unthinkable to include the whole thing for development, but for deployment you should just include the dependencies; unittest's dependencies are 58 KB.

When a zip file's filename is added to the path, it is treated like any other directory; import looks inside it to find modules. You'll also notice that import repl just worked, even though repl.py isn't in the zip file; it was referenced by a script-tag earlier. It works because script-tags actually represent file-system entries; doing open("repl.py"), or open("PythonStdLib/unittest.py") would also work.

For anyone familiar with the older XAP-file/Chiron-based way to build Silverlight apps with IronPython: this combined script-tag/zip-file file-system abstraction is what allows you to never need to put file in the main application's XAP.

Another interesting library to in Silverlight is rst2xaml, which takes any reStructuredText-formatted files and converts them to XAML to be rendered in Silverlight.

Using .NET built-in and external APIs

Now let's transition to what the browser can bring to Python; specifically the APIs that Silverlight exposes. Silverlight has a ton of functionality, and as I was only able to discuss a few Python libraries in Silverlight, I'll only be able to show a few Silverlight libraries being used from Python, but the entirety of Silverlight can be used from Python. See all the features Silverlight provides, as well as how to use .NET APIs in-general from Python.

One interesting API is the WritableBitmap, which gives you per-pixel access to render whatever you want. For example, here its used to render a fractal:

Example derived from A.Boschin.

This is even more interesting because the actual bitmap was generated by code written in C#, but called from Python:

Source code summarized from both mandelbrotbase.cs and mandelbrot.py

As with any computationally-intensive operations, it's a good idea to write them in a static pre-compiled language; for example the scientific-computation libraries for Python are actually written in C, but the library provide an API accessible to Python programmers. Unfortunately, CPython puts that responsibility on the library developer; not every C library can be directly consumed by Python code. However, this example shows that IronPython can call into any C# library, or any library written in a .NET language for that matter. This makes it trivial to just begin writing your application in Python, and then decide to convert the performance-sensitive sections to C#.

Example derived from Tim Heuer’s webcam-mic app

Another interesting use of WritableBitmap is attaching different types of video sources to it, like a webcam! The upcoming version of Silverlight (version 4) supports webcam and microphone capture, and all that can be used from Python:

Webcam usage requires Silverlight 4 Beta; you can download the installer for mac or windows.

Tooling

The IronPython team’s big announcement at PyCon 2010 was the preview-availability of “IronPython Tools”, and add-on for Visual Studio 2010. This release was only distributed to PyCon 2010 attendees on CDs in their swag-bags, with a public release planned for the same time that VS 2010 final is released.

IronPython tools comes with the beginnings of Silverlight support; for starters you can make a new Silverlight project:

IronPython tools uses the DLR hosting APIs for colorizing code:

And using Debug->Attach To Process you can set breakpoints in your python code (even code embedded in the HTML page) and use the Visual Studio debugger to step-through you app:

Conclusion

Now you know …

• What a Python browser app looks like
• What is going on behind the scenes
• How to use real python libs in the browser
• How to use Silverlight APIs from Python
• That there is a prototype of IronPython tooling!

Mark Probst found and squashed one of the hardest bugs in our upcoming garbage collector. Pablo from Codice has been testing the new GC under stress and posted a nice message to the list.

Plenty of great feedback on deprecating old libraries and tools from Mono. We will have a lighter distribution. As things are coming together so fast and we are now well into the features we had planned for 3.0, we might end up just calling the next version 3.0 instead o 2.8.

Andreia got Moonlight running on Chrome.

Download & Installation

Features

At the core of the iPhone UI lies the UITableView, a powerful table rendering widget that is used by pretty much every application on the iPhone. The UITableView is a powerful widget that can render its data in many different ways based on how you configure the widget, these are all variations of the UITableView:

This is one powerful widget.

The contents of the UITableView are rendered by calling into a developer supplied set of routines that provide the data on demand. The protocol includes queries like "How many sections?", "How many rows in section N?", "What is the title for section N?" as well as callbacks to provide the actual contents of a cell. Although the widget is pretty powerful, creating UIs with it is a chore and a pain to maintain. The pain to maintain and the repetitive nature of the process leads to developers either spending too much time customizing each view, bare minimum configuration and lack of polish on certain configurations. As I ported many of the Objective-C samples to C# I found myself repeating the same process over and over.

My fingers developed calluses, and at night I kept thinking that there should be a better way. But at the time, I was just doing a line-by-line port, I was not really ready to build a new API on top of it.

Recently, when my favorite twitter client on the iPhone butchered its UI I figured I would write my own Twitter client. The first step was to create the account configuration for my twitter account. As you can imagine, the configuration is done with a variation of the UITableView. And once again I found myself setting up the model, responding to view events, sprinkling switch and if statements liberally all through my source code and just plainly not having any fun writing the code. This is how MonoTouch.Dialog was born.

I wanted to reflection to allow a class to be mapped to a dialog box, something that would allow me to write a C# class and have it mapped to a UITableView, something like this:

class TwitterConfig {
    [Section ("Account")]
      [Entry] string Username;
      [Password] string Password;

   [Section ("Settings")]
      bool AutoRefresh;
      bool AutoLoad;
      bool UseTwitterRetweet;
}

Instead of starting with the Reflection code to deal with this, I first created an in memory representation of the entire dialog. The idea was that the Reflection code would then be a bridge that could use the engine code.

The engine code is built on the idea that each row could be a specific kind of widget. It could contain text, a switch box, a text editing line, a slider control, a calendar picker or any other kind of user created control. I call these "Elements" and I created a bunch of these:

• BooleanElement: rendered with a UISwitch
• FloatElement: rendered with a slider.
• HtmlElement: when tapped, starts the web browser on a url.
• StringElement: used to render plain strings.
• MultilineElement: A multi-line string element.
• RadioElement: a radio-item, to select one of many choices.
• CheckboxElement: like the BooleanElement, but uses a checkbox instead of a UISwitch.
• ImageElement: Allows the user to pick an image or take a photo.
• EntryElement: text entry element.
• DateTimeElement, DateElement, TimeElement: pickers for dates and times, dates and times.

The MonoTouch.Dialog follows the Apple HIG for the iPhone and implements as much of the UI policy allowing me to focus on the actual application instead of focusing on the administrivia.

Although the UITableView is built on the powerful Model/View/Controller setup that would allow it to scale efficiently to large data sets, most configuration pages and data entry pages do not require this complexity.

Another feature is that it takes care of all the bookkeeping required to do text entry without any work from the programmer: accepting keyboard input, automatically switching to the next entry line on return, aligning all entry lines in a section, dismissing the keyboard with the last input is reached.

Here is a sample of the API in action:

var root = new RootElement ("Settings") {
  new Section (){
    new BooleanElement ("Airplane Mode", false),
  new RootElement ("Notifications", 0, 0) { Notifications }
  new Section (){
    new RootElement ("Sound"), { Sound },
    new RootElement ("Brightness"){ Brightness },
    new RootElement ("Wallpaper"){ Wallpaper }
  },
  new Section () {
    new EntryElement ("Login", "Your login name", "miguel"),
    new EntryElement ("Password", "Your password", "password", true),
    new DateElement ("Select Date", DateTime.Now),
    new TimeElement ("Select Time", DateTime.Now),
  }
}
	

Once the RootElement has been created, this can be passed to a DialogViewController to manage it:

var dv = new DialogViewController (root);
navigation.PushViewController (dv, true);

Reflection API

The reflection API inspects a class and looks for fields that have some special attributes on them.

Here is a sample class and how it is rendered:

class AccountInfo {
    [Section]
    public bool AirplaneMode;

    [Section ("Data Entry", "Your credentials")]

    [Entry ("Enter your login name")]
    public string Login;

    [Caption ("Password"), Password ("Enter your password")]
    public string passwd;

    [Section ("Travel options")]
    public SeatPreference preference;
}
	

As you can see, enumerations (SeatPreference) are automatically turned into a radio selection that uses the UINavigationController to navigate and the captions are computed from the field names, a behavior that you can customize with the [Caption] attribute.

The attributes that are attached to each instance variable control how things are rendered and can be used to specify a variety of attributes like captions, images and overriding the defaults from MonoTouch.Dialog.

Some Samples

Code:

new RootElement ("Settings") {
  new Section (){
    new BooleanElement ("Airplane Mode", false),
    new RootElement ("Notifications", 0, 0) { Notifications }
  new Section (){
    new RootElement ("Sound"), { Sound },
    new RootElement ("Brightness"){ Brightness },
    new RootElement ("Wallpaper"){ Wallpaper }
  },
  new Section () {
    new EntryElement ("Login", "Your login name", "miguel"),
    new EntryElement ("Password", "Your password", "password", true),
    new DateElement ("Select Date", DateTime.Now),
    new TimeElement ("Select Time", DateTime.Now),
  }
}
	

LINQ and MonoTouch.Dialog

Craig has written a great Conference application for the Mix 2010 conference. I helped him reduce the code size of the application by removing all of the repetitive code required to set up UITableViews for various pieces of the application with MonoTouch.Dialog. Since the conference application deals with a database schedule, I extended MonoTouch.Dialog to work better with LINQ.

In the same spirit of the System.Xml.Linq API that allows you to create XML documents with nested LINQ statements, you can use MonoTouch.Dialog to create your entire UIs.

For Craig's application, I wrote a SessionElement that allows sessions to be "starred" and shows both the title of the session as well as the location of the session.

This code constructs the entire UI for the "My Schedule" tab. The data is populated on demand (Apple recommends that all views are loaded lazily)

public class FavoritesViewController : DialogViewController {
  public FavoritesViewController () : base (null) { }

  public override void ViewWillAppear (bool animated)
  {
    var favs = AppDelegate.UserData.GetFavoriteCodes();
    Root = new RootElement ("Favorites") {
      from s in AppDelegate.ConferenceData.Sessions
        where favs.Contains(s.Code)
        group s by s.Start into g
        orderby g.Key
        select new Section (MakeCaption ("", g.Key)) {
          from hs in g
            select (Element) new SessionElement (hs)
        }
    };
  }
}
	

That is it. The entire source code.

So use any of the two models that you enjoy the most: Reflection for quick one-offs and quick data-entry or the Element API for more advanced user interfaces but without having to spend your life writing boilerplate code.

I hope that this helps guys spend more time improving their applications, and less time writing boilerplate code.

MonoTouch.Dialog is not perfect and does not have every possible bell and whistle that you might want to add. Although I do welcome patches for certain features, feel free to fork the code and patch at will to suit your needs.

We just landed the support on MonoDevelop's trunk to support developing applications that target MeeGo powered devices.

MeeGo is a Linux-based operating system designed to run on mobile computers, embedded systems, TVs and phones. Developers would not typically use a MeeGo device as a development platform, but as a deployment platform.

So it made sense for us to leverage the work that we have done in MonoDevelop to support the iPhone to support MeeGo. Unlike MonoTouch, we are not limited to running on a Mac, you can use MonoDevelop on Windows, Linux and OSX to target Meego Devices.

Developers would continue using their Linux Workstation, their Windows PC, or their Mac to develop and test and the resulting cross-platform binary can be deployed and debugged remotely over the wire using Mono's Soft Debugger.

In this video, I interview Michael Hutchinson as he demostrates the developer experience:

The MonoDevelop/Mono that we will be supporting is entirely Gtk# based, both during development as well as during deployment.

Every once in a while I need to debug some Mono program that does not come with a solution. Either a program that was compiled using a Makefile or an executable that I installed with RPM on my system.

Sometimes I would end up cretaing MonoDevelop solution that contained every source file, command line option and resource that I meticulously copied from the Makefile. In other words, I was in for a world of pain just to be able to use MonoDevelop's awesome debugger.

Lluis offered this solution, and I am blogging it hoping that it will help someone else in the future. Follow these steps to debug a Mono executable and set breakpoints on the source code or class libraries source code:

1. Create a Generic Solution

Select File/New Solution and select Generic Solution:

2. Open the Project Properties

Double click on your project, in my case I called the project "compiler":

3. Add an Execute Custom Command

In your project select Custom Commands:

Add a custom Execute command by selecting it from the "Select a Project Operation" option and point to your Mono executable:

4. Load source files

Use File/Open to load the source file where you want to set a breakpoint (the executable source or some class library source) and set your breakpoints:

Then use Run/Debug to start your program in debugging mode (Linux and Windows users can use F5, MacOS X users can use Command-Return).

Every once in a while I would run into someone that will ask me what exactly we are up to in Mono. As Mono becomes larger, and various big projects "land" into the trunk, we can no longer do releases on a monthly basis. Some of the work that we do is inherently very attractive, things like new features, new libraries, new UIs and new frameworks. But probably more important are the efforts to turn our code into programming system products: fixing bugs, testing it, packaging it, supporting it, writing documentation, test suites, improving error handling, scaling the software, making it faster, slimmer and backporting bug fixes.

I wanted to give my readers a little bit of an insight of the various things that we are doing at Novell in my team. This is just focused on the work that we do at Novell, and not on the work of the larger Mono community which is helping us fill in the blanks in many areas of Mono.

MonoDevelop work

We just released MonoDevelop 2.2, a major upgraded to our IDE story, and the backbone that allows developers on Linux to debug various kinds of Mono-based applications. With support for the new Soft debugging engine, it has allowed us to support debugging ASP.NET web sites, ASP.NET web services, Silverlight applications, Gtk# and Console applications with minimal effort. Since the soft debugger leverages Mono's JIT engine, porting the soft debugger to a new architecture is very simple.

MonoDevelop 2.2 major goal was to create a truly cross platform IDE for .NET applications. We are off to a solid start with Linux, Windows and OSX support as well as solid support for C#, VB, Vala and Python.

We are now turning our attention to MonoDevelop 2.4. This new release will incorporate many new UI touch ups which I will blog about separately.

MeeGo/Moblin Support

We have been working closely with the MeeGo (previously Moblin) team at Novell to offer a streamlined developer experience for developers on Windows, Mac and Linux to target MeeGo devices.

Developers will be able to develop, test and deploy from their favorite platform software for MeeGo devices.

Mono Service Pack

A service pack release of Mono's enterprise supported ASP.NET release is ahead of us and we will be upgrading Mono from release 2.4 to release 2.6.

This will bring to our customers support for all of the new features in Mono 2.6 with the added benefit that it has gone through four months of extra testing and polish.

As part of this effort we are also upgrading the MonoTools for Visual Studio to support the new Mono Soft Debugger.

Runtime Infrastructure

Mono's runtime is being upgraded in various ways: we continue to work on integrating LLVM [1], productize our new copying garbage collector that can compact the heap, and make Mono scale better on multi-core systems with the integration of ParallelFX into Mono as well as re-architecting thread management and thread pools in Mono.

A big upgrade for Mono 2.8 will be the support for obfuscated assemblies that insert junk in dead blocks. This is a feature that we never had, but with many Silverlight applications being deployed with these options we started work on this.

We are working to improve our support for F# and together with various groups at Microsoft we are working to improve Mono's compatibility with the CLR to run IronPython, IronRuby and F# flawlessly in Mono. Supporting F# will require some upgrades to the way that Mono works to effectively support tail call optimizations. [1] LLVM: better use LLVM to produce better code, use it in more places where the old JIT was still required and expand its use to be used for AOT code.

Mono for Mobile Devices

We recently shipped Mono for the iPhone and we continue to develop and improve that platform. Our goal is to provide developers with a great experience, so we are doing everything in our power to make sure that every wish and whim of the iPhone developer community is satisfied. We are working to expand our API coverage, write helper libraries to assist developers, tune existing .NET libraries to run on Mobile devices, reduce startup time, and reduce executable sizes.

But we have also just started an effort to ship MonoDroid: Mono for the Android platform. This will include a comprehensive binding to the Java APIs, but accessible through the JIT-compiled, 335-powered runtime engine.

Our vision is to allow developers to reuse their engine and business logic code across all mobile platforms and swapping out the user interface code for a platform-specific API. MonoTouch for iPhone devices and the Monodroid APIs for Android devices.

Head-less Tasks

A big part of Mono's effort is in the development kit: the compiler, the tools and the server side components.

Mono has now a complete C# 4.0 implementation that will be ready to ship with the next version of Mono. Anyone can try it today by building Mono from SVN. We are also porting our C# compiler to work with Microsoft's Reflection.Emit to enable us to run our C# Interactive Shell in Silverlight applications and to allow .NET developers to embed our compiler in their applications to support C# Eval.

Our MSBuild implementation is very robust these days, and it will be fully supported in Mono 2.8 (and we will be backporting it to Mono 2.6 as well).

On the ASP.NET front, we are working with third party vendors to certify that their controls work with Mono's ASP.NET (we will have some tasty announcements soon) and we are also catching up to the new features that are coming with .NET 4.0.

WCF has turned out to be one of the most requested features. We had historically only paid attention to WCF for its Silverlight/Moonlight use cases, but as time goes by, more and more users are moving to WCF. We are working on completing our WCF support.

On the ADO.NET front our major focus has been to complete the support for LINQ to SQL as part of the DbLinq project that we are contributing to. At this point we have no plans to implement Entity Frameworks due to the large scope of that project.

Moonlight 3

I do not need to say much about Moonlight 3. Moonlight 3 is one of our most visible projects right now due to the adoption of Silverlight and Smooth Streaming.

By the first week of Feburary there had been 610,000 downloads of Moonlight 2.0 for Linux. This is only counting the downloads since the official release on December.

Policy Changes

Mono 2.6 was the last release of Mono to support the .NET 1.0 API profile. With Mono 2.8 we are going to drop the class library support for 1.0 and ship both 3.5 and 4.0 assemblies.

With Mono 2.8 we are also switching the default tools and compiler to be 4.0-based as opposed to be based on the 3.5 profile. We will be doing a release of Mono 2.8 a couple of months after .NET 4.0 ships.

Ciao!

The above probably reflects the main focus of the team in the past three months. There are many community driven efforts that are very cool and that deserve their own space and a future blog post. Things like the amazing work that was done on Qyoto and the Synapse IM client come to mind.

We look forward to a great year ahead of us.

Everyone knows that in this day an age a software product is not complete until it offers a Desktop UI, a Web UI, and a front-end on the Appstore.

We access beautiful web sites, we purchase 0.99 apps on our phones and install gorgeous native software on our desktops.

The sysadmin community, once the backbone of Linux adoption, keeps asking "but what about me?". Indeed. What about them?

What are we doing about these heroes? The heroes that ssh in the middle of the night to a remote server to fix a database; The heroes that remove a chubby log file clogging the web server arteries; The very same heroes that restore a backup after we drag and dropped the /bin directory into the trashcan?

They are a rare breed in danger of extinction, unable to transition into a GUI/web world. Trapped in a vt100 where they are forced to by conditions to a small 80x24 window (or 474 by 188 with 6 pixel fonts on a 21 inch flat screen display).

These fragile creatures need our attention.

Today I am doing my part, my 25 cents to help improve their lives.

I am releasing Mono Curses 0.4 a toolkit to create text-based applications using C# or your favorite CLR language.

The combination of C#'s high-level features, Mono's libraries, Mono/.NET third party library ecosystem and the beautifully designed gui.cs, we can bring both hope and change to this community. Hope and change in the form of innovative text-based applications that run comfortably in 80x24 columns.

What is gui.cs

We know that hardcore sysadmins will want full control over what gets placed on the screen, so at the core of mono-curses we expose a C# curses binding.

On top of this, we provide a widget set called "gui.cs". gui.cs was introduced in 2007 enjoying unprecedented public acclaim among a circle of five friends of mine. Eight months after its introduction, it experienced an outstanding 100% growth when a second application was written using it.

Today, gui.cs is the cornerstone of great work-in-progress applications that any decade now will see the light of day. Including a new and riveting version of the Midnight Commander:

With only 3% of features implemented progress is clearly unstoppable!

I believe in dogfooding my own software before I unleash it to the world:

On a typical 21" sysadmin setup: 474x188 with the "Sysadmin Choice" award winning 6 pixel font.

Valentine's Day

So in this Valentine's Day, after you are tired of spending quality time with your grandmother, making out with your significant other or a stranger you just met at the checkout line in Costco, consider donating. Donate some of your time towards building some nice applications for your favorite sysadmin. God knows that he spent the whole day monitoring the dmesg output, looking for a SATA controller failure and keeping an eye on /var/log/secure, waiting for your ex to deface your wordpress installation.

And you have a choice, you can use Boo, IronRuby, IronPython, F# for building your app. VB.NET is also available if you want to teach your sysadmin a lesson in humility.

Get inspired today with some of the old screenshots.

Jcao219: this is actually the conclusion

The amazing Moonlight Team lead by Chris Toshok just released Preview 2 of Moonlight 3 just in time for the Winter Olympics' broadcast:

The player has some nice features like live streaming, Tivo-like "jump-back", accelerated playback and slow motion and it does this using Smooth Streaming which adjusts the quality of your video feed based on your bandwidth availability.

Thanks to Tom Taylor, Brian Goldfarb and the rest of the team at Microsoft for assisting us with test suites and early access to some of the technologies in use at NBC Olympics. With their help we were able to make sure that Moonlight 3 would work on time for the event (with full 24 hours and 14 minutes still to burn!).

As usual, the team did a great job, considering that we had to implement in record time plenty of Silverlight 3 features for Moonlight.

	MOONLIGHT_OVERRIDES=effects=no firefox
	

Lrhazi: Created page with 'This is a port of the code described in this page: [http://blogs.interknowlogy.com/johnbowen/archive/2007/06/20/20458.aspx Transparent Windows in WPF] <pre> import clr clr.AddRe…'

Jcao219: add a sentence, clarify

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

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!

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.

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 …

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:

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.

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.

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.

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)

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>

Jcao219:

• SLog: Silverlight Logging

• A WPF Picture Viewer
• NotifyIcon to use from IronPython

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

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

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

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.

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.

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

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

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

• Embedded IronRuby and IronPython in Silverlight with Multiple Source Files

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

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

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

• IronPython on deviantART

• 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
  

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:

• 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".

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

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

• 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

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.

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

• 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

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.

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.

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!

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

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

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

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

• 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

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.

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.

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!

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

• 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

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

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

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.