Planet IronPython

OSCON is a happy place for me. It’s my third OSCON, and I created good memories at each one. At my first OSCON, I was showing off RubyCLR to the world, and I met some folks from Microsoft who convinced me that it was the right time in my life to go ship something big. At my second OSCON, I was working for The Man, and we announced that were accepting contributions into IronRuby – a big change at the time.

Today, we’re raising the bar even higher in IronRuby. There are three changes happening today:

1. We’re shipping our first binary release. In this package, we’re taking a “batteries included” approach and shipping the Ruby standard libraries in it. This takes us a big step closer towards “IronRuby runs real Ruby programs”.

2. We’re announcing a new project: ironruby-contrib. It’s hosted at GitHub, an awesome place to do collaborative development. The goal of ironruby-contrib is to provide a place where folks from the community can participate in projects that enhance IronRuby or its underlying platforms. The first project in ironruby-contrib is the Rails plugin that we demonstrated at RailsConf this year. It makes it easier for Rails developers to add Silverlight to their Rails applications, and contains some of our ideas about migrating controller code to the client. Jimmy Schementi is the brains behind the project; see his introductory blog post for more details.

3. We’re announcing that we’ve submitted our first set of changes to the awesome RubySpec project. We’ve been talking about contributing to RubySpec for a long time now, but various things kept us from doing so. We’ve fixed those things now, which takes us a big step closer towards being an active participant in all things Open Source, and not just the things that we create.

John Lam is announcing a bunch of good IronRuby stuff at OSCON today, mainly around the project's commitment to open source. Part of this commitment is being able to collaborate with the Ruby community on projects that are related to IronRuby. This is where I fit in. :)

At RailsConf John Lam and I gave a talk about IronRuby, Rails, and Silverlight. We showed IronRuby running Rails, as well as the beginnings of an integration between Silverlight and Rails. I've hinted in the past about this very thing, but RailsConf was the first time I got to show it to working to actual Rails developers. Pretty awesome. Today, I get to share it with the world:

silverline is a Ruby on Rails plug-in which gives the ability to run Ruby in the browser to manipulate HTML, vector graphics, or just do some computation. Bottom line: it let's you write Rails code that can run on the client.

Check out the website: http://schementi.com/silverline.

And, most importantly, you can download the plug-in from github: http://github.com/jschementi/silverline.

This is all possible because of Silverlight, the 4 megabyte download of the .NET Framework, and IronRuby, the implementation of Ruby on .NET and the Dynamic Language Runtime. silverline lets you do anything you can do in Silverlight with IronRuby, but it's a first-class part of your Rails application, and makes things a whole lot easier.

To see silverline in action, take a look at the demo site: http://silverline.schementi.com. The source is located at http://github.com/jschementi/silverline-demos. I will be posting walk-throughs of silverline's features shortly. Enjoy!

Note: "silverline" might not be the name of this thing in a couple days, so if you see something else on my blog that seems the same but has a different name, then it's the same thing.

A while back I posted about building a cheap robot for a high school summer camp.  Well the camp is over and I think it was pretty successful.  I was able to build 9 robots for under $30 a piece.  Each robot used an Atmel Butterfly and cheap remote control car.  I will have more ongoing information about how these cars work and how to make your own, but for now enjoy the circle of bots :)

linking everywhere -- PoC for HTML5 style href="<url>" attributes on everything.

Python for Executives. 

FsTest : A Unit Testing DSL for F#. 

Object Oriented JavaScript.  

A gentle introduction to (Iron)Ruby from C#.

At Tech Ed last week, I showed a prototype of integration between IronRuby and ASP.NET MVC. I was really happy about how straightforward this turned out to be; it’s a strong testament to the robustness of our hosting API that Levi on the ASP.NET MVC team was able to add IronRuby integration with only a simple example and the existing docs.

Let’s walk through a simple example. Keep in mind that this is a prototype, and that many things will likely change before we’re done with it (particularly some of things we do today with globals and instance variables).

First, let’s look at how you can define some default routes via routes.rb:

Next, let’s look at the Controller code for the HomeController:

The index action renders a view using a trivial Model which lives in models\HomeModel.rb:

This model is used by the index action View, which lives in views\home\index.rhtml:

Next, let's look at a slightly more sophisticated example using a Products Controller that renders a list of categories that looks like:

It also renders a list products for a category when you click on it:

This is what the controller looks like:

There are two actions in this controller: index and list. The index action returns a list of the categories, and the list action returns a list of products for that category.

Note that we're using instance variables on the controller to communicate with the view - this is likely going to change in the future, but it was something we hacked in to see what it would look like.

If we look at ProductsModel, you'll see that it contains a simple adapter around a Visual Studio generated wrapper for the Northwind database:

We had to write our own adapter to work around a few bugs that we have in our .NET interop story as of right now, as well as adding a few model-esque methods. Here's what the NorthwindDatabase adapter looks like:

Notice how we can use LINQ to SQL to write our queries to the database, and the funky C# 3.0 anonymous delegate syntax that we use for GetCategory().

The interesting code in the view looks like:

Today we're using the MVC template engine, but there isn't any reason why we couldn't enable erb / haml etc. in the future.

How can I get it?

You can download a ZIP of the entire project from here if you want to take a closer look. Note that you can't run these bits yet, since I demo'd it using a private build of ASP.NET MVC from mid-way through their current milestone. That said, when Preview 4 of ASP.NET MVC ships you'll be able to run IronRuby on top of it (their current release is Preview 3).

Look for a blog post here, and from the folks like Phil over in MVC-land when we're ready to ship you some bits to build MVC apps using IronRuby.

When building a Rails plugin, you're given a skeleton for building tests from "ruby script/generate plugin MyPlugin", but it's set up to use Test::Unit. What about RSpec?

If you're building the plugin along with a existing app (which you should be), you can sit at the root of your app and do "rake spec:plugins", which will run all the specs for your plugins, [presumably] including yours.

But how can I run just the plugin tests?

ruby script/spec vendor/plugins/MyPlugin/spec/*

That'll work fine, but you need to also pass it the spec.opts file for colorization and other settings. But if you used Test::Unit you could just sit in the plugin's directory and say "rake test", how can we do "rake spec" and get the same result?

Take a look at rspec-rails/tasks/rspec.rake; there's some tasks you can grab from there and put in your own plugin's Rakefile. You'll have to change a bunch of stuff, but in the end this should be your plugin's Rakefile:

require 'rake'
require 'rake/rdoctask'

# In rails 1.2, plugins aren't available in the path until they're loaded.
# Check to see if the rspec plugin is installed first and require
# it if it is.  If not, use the gem version.
rspec_base = File.expand_path(File.dirname(__FILE__) + '/../rspec/lib')
$LOAD_PATH.unshift(rspec_base) if File.exist?(rspec_base)
require 'spec/rake/spectask'

task :noop do
end

task :default => :spec
task :stats => "spec:statsetup"

desc "Run all specs in spec directory"
Spec::Rake::SpecTask.new(:spec => :noop) do |t|
  t.spec_opts = ['--options', "\"spec/spec.opts\""]
  t.spec_files = FileList['spec/**/*_spec.rb']
end

namespace :spec do
  desc "Run all specs in spec directory with RCov"
  Spec::Rake::SpecTask.new(:rcov) do |t|
    t.spec_opts = ['--options', "\"spec/spec.opts\""]
    t.spec_files = FileList['spec/**/*_spec.rb']
    t.rcov = true
    t.rcov_opts = lambda do
      IO.readlines("spec/rcov.opts").map {|l| l.chomp.split " "}.flatten
    end
  end
  
  desc "Print Specdoc for all specs"
  Spec::Rake::SpecTask.new(:doc) do |t|
    t.spec_opts = ["--format", "specdoc", "--dry-run"]
    t.spec_files = FileList['spec/**/*_spec.rb']
  end

  [:silverline, :client].each do |sub|
    desc "Run the specs under spec/#{sub}"
    Spec::Rake::SpecTask.new(sub => :noop) do |t|
      t.spec_opts = ['--options', "\"spec/spec.opts\""]
      t.spec_files = FileList["spec/#{sub}/**/*_spec.rb"]
    end
  end

  # Setup specs for stats
  task :statsetup do
    require 'code_statistics'
    ::STATS_DIRECTORIES << %w(Model\ specs spec/models) if File.exist?('spec/models')
    ::STATS_DIRECTORIES << %w(View\ specs spec/views) if File.exist?('spec/views')
    ::STATS_DIRECTORIES << %w(Controller\ specs spec/controllers) if File.exist?('spec/controllers')
    ::STATS_DIRECTORIES << %w(Helper\ specs spec/helpers) if File.exist?('spec/helpers')
    ::STATS_DIRECTORIES << %w(Library\ specs spec/lib) if File.exist?('spec/lib')
    ::CodeStatistics::TEST_TYPES << "Model specs" if File.exist?('spec/models')
    ::CodeStatistics::TEST_TYPES << "View specs" if File.exist?('spec/views')
    ::CodeStatistics::TEST_TYPES << "Controller specs" if File.exist?('spec/controllers')
    ::CodeStatistics::TEST_TYPES << "Helper specs" if File.exist?('spec/helpers')
    ::CodeStatistics::TEST_TYPES << "Library specs" if File.exist?('spec/lib')
    ::STATS_DIRECTORIES.delete_if {|a| a[0] =~ /test/}
  end
end

desc 'Generate documentation for the silverline plugin.'
Rake::RDocTask.new(:rdoc) do |rdoc|
  rdoc.rdoc_dir = 'rdoc'
  rdoc.title    = 'Silverline'
  rdoc.options << '--line-numbers' << '--inline-source'
  rdoc.rdoc_files.include('README')
  rdoc.rdoc_files.include('lib/**/*.rb')
end

 

• Python for Executives

• Recruiting - It turns out that smart and innovative people are attracted by Python .Innovative smart people can also learn Python very quickly.
• Risk - in one year we had only five cases where a Python specific bug occurred. We had many more ASP. NET, JavaScript, HTML and even Java specific problems.
• Maturity - not only is Python very solid, so is IronPython. The code is stable, the smart features work, the community is responsive and the libraries are rich. The only downside is the IDE and Visual studio integration, but this is progressing as well.
• Performance - Python flexibility allowed extremely fast optimizations at the system and algorithmic levels, without requiring premature optimization. The system and algorithm changes are the ones critical in a real world environment. Some issues are showing up, but it seems they can be solved with a reasonable cost.

• Announcing IronEditor - An Editor for IronRuby, IronPython and other DLR languages
• IronEditor Homepage and Download on Codeplex

I am a strong proponent of making everything in my life digital.  I own a tablet PC and spend most of my time working on engineering projects on the computer.  One thing that always drives me nuts is printing out stuff just to go into a engineering notebook.  First I'm waisting paper, second its not the write medium for an entire source code system.  Where are digital engineering notebooks? 

I propose that someone starts a company that is basically a limited access subversion repository ran by lawyers and IT specialist.  Client can use Tortoise SVN or the like to synch their directory changes to the server.  Someone can even have rules in place that require digital signatures before commits can happen.  If a patent dispute ever happens the company can show the directory in its state as of a certain disputed date.

What this gives you:

• A way to backup your files
• A clean medium for digital files like source code
• Worry free notebook maintenance

The company could make a good deal of money charging for space and charging a lot of money for engineering audits. 

Well just a thought!

I image my machine once a semester to clear off all the garbage I installed over the term. (I use partimage in case anyone cares).  Anyway I always have unsused shortcuts left in my startmenu since that lives on my d:\ drive which is where my data and profile are.  I wrote the code below to nuke bad shortcuts and empty shortcut directories.  It doesn't get all the uninstall files and readme links but its good enough!

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
using IWshRuntimeLibrary;

namespace ConsoleApplication12
{
    class Program
    {
        static void Main(string[] args)
        {
            string path = @"D:\Michael\Start Menu\";

            WshShell shell = new WshShell();
            string[] files = Directory.GetFiles(path, "*.lnk", SearchOption.AllDirectories);
            Directory.CreateDirectory(@"C:\oldshortcuts");
            List<string> directories = new List<string>();
            foreach (string file in files)
            {
                IWshShortcut link = shell.CreateShortcut(file) as IWshShortcut;
                if (!System.IO.File.Exists(link.TargetPath))
                {
                    Console.Write("Broken Shortcut");
                    Console.WriteLine(file);
                    directories.Add(Path.GetDirectoryName(file));
                    try
                    {
                        System.IO.File.Copy(file, Path.Combine("C:\\oldshortcuts", Path.GetFileName(file)), true);
                        System.IO.File.Delete(file);
                    }
                    catch { Console.WriteLine("Error copying file and deleting file. Press any key to continue"); Console.ReadLine(); }
                }
            }
            //now delete the old shortcuts
            foreach (string dir in directories)
            {
                if (!Directory.Exists(dir)) { continue; }//we already deleted this!
                DirectoryInfo info = new DirectoryInfo(dir);
                if (info.GetFiles("*", SearchOption.AllDirectories).Length == 0)
                {
                    try
                    {
                        info.Delete(true);
                        Console.Write("Deleting directory");
                        Console.WriteLine(info.FullName);
                    }
                    catch { Console.WriteLine("Error Removing Directory. Press any key to continue"); Console.ReadLine(); }
                }
            }


        }
    }
}

Summary:

Summary:

The recipe for how to expose internal members of your assembly to Rhino Mocks is given in the toolkit wiki -- to recap, add

[assembly: InternalsVisibleTo(Rhino.Mocks.RhinoMocks.StrongName)]

at the cost of a reference to the Rhino Mocks assembly or

[assembly: InternalsVisibleTo("DynamicProxyGenAssembly2, " +
  "PublicKey=00240000048000009400000006020000002400005253413" +
  "10004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606" +
  "cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc" +
  "297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8" +
  "e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf6" +
  "9b9291ed0a340e113be11e6a7d3113e92484cf7045cc7")]

to your assembly (key valid for version 3.4, subject to possible change without notice).

But this means that any assembly so strong-named (with a publicly available key) can get at the internals of your assembly -- which you may not want to have happen.

You could extract all the interfaces into a types assembly of their own, and expose it to your implementation via InternalsVisibleTo as well as to Rhino Mocks -- but that means having to make a possibly artificial split (and complicate your build process).

But there is a cunning plan you can use -- your unit test assembly will need friend access to the implementation anyway (but you strong name that using a key you don't publish), so in the unit test assembly, derive types from the implementation. Then you expose the unit test assembly to Rhino Mocks and mock or stub on the unit test types when you need to fake internal types to feed into classes under test.

On Tuesday of last week we branched Mono for the 2.0 release; Packages are being QAed for our first release candidate and will be available next week. Bug fixing for the final release will happen on this branch.

Meanwhile, the excitement continues on trunk. Zoltan today merged the Linear IL branch.

The Linear IL code has been under development for two years and eight months and it was an effort that we started to address some of the main limitations in our current JIT design. Some of these limitations in the old design made it very hard to bring some code generation optimizations into the JIT, or made the optimizations not as effective as they could have been.

The new JIT engine will debut in Mono 2.1, later this year. Now that Linear IL is the default, the entire JIT team will focus on tuning the engine and extracting more performance out of it. But even without tuning, the new engine is already performing very well as you can see in the results comparing the engines.

Additionally, a number of creative ideas that we have to improve Mono all depended on doing this switch. We have a few surprises for developers in the next coming months.

Congratulations to Zoltan for getting this work merged.

using + lambda/delegate = problem.

Egoless programming, intent programming.

Erlang is gaining momentum for massively concurrent applications.

JRuby 1.1.3 -- with enough enhancements I'd've called it 1.2!

jQuery resources and widgets - toast, progress-bar,

• Ben Hall announcesIronEditor, a simple dev tool for IronPython and IronRuby. Pretty nice, though fairly simplistic (as Ben readily admits). For example, it doesn't have an interactive mode, only the ability to execute scripts and direct the output to IronEditor's output window. However, it is a good start and I'm sure it'll just get better. One thing he's apparently considering is a Silverlight version. (via Michael Foord)
• Speaking of "Iron" tools, Sapphire Steel have had an IronRuby version (in alpha) of their Ruby in Steel product for several months now. I wonder if John's had a chance to play with it.
• Speaking of John, the ASP.NET MVC / IronRuby prototype he talked about @ TechEd is now available on ASP.NET MVC Preview 4 via Phil Haack.
• Ted Neward has an article exploring the IronPython VS Integration sample that ships in the VS SDK. As I mentioned the other day, we're starting working on a production quality implementation of VS Integration for IPy.
• Ophir Kra-Oz (aka Evil Fish) blogs Python for Executives. I like his "Risk, Recruiting, Performance and Maturity" model - four boxes, perfect for keeping an executive's attention! :) Plus Ophir has some nice things to say about IronPython. (via Michael Foord)
• Ronnie Maor blogs an extension method for PythonEngine to make Eval simpler. I especially like how he uses string format syntax so you can dynamically generate the code to eval. I wonder what this would look like in IPy 2.0 with DLR Hosting API. (via IronPython URLs)
• Speaking of DLR Hosting, Seshadri has another great DLR hosting post, this time hosting IPy inside of VS08 so you can script VS08 events (document saved, window created, etc) with Python.
• Justin Etheredge has a bunch of IronRuby posts - Getting IronRuby Up and Running, Running Applications in IronRuby, Learning Ruby via IronRuby and C# Part 1. (via Sam Gentile)
• Don Syme links to several F# related posts by Ray Vernagus, though he's apparently also experimenting with IronRuby. I'm really interested in his Purely Functional Data Structures port to F#.
• Speaking of F#, Brian has a teaser screenshot of F# upcoming CTP. However, he chooses the New Item dialog to tease, which looks pretty much like the current new item dialog (the new one does have fewer F# templates). However, if you look in the Solution Explorer, you'll notice a real "References" node. No more #I/#R! Yeah!
• The interactive graphic in Kevin Kelly's One Machine article is fascinating. It really highlights that the vast vast vast majority of power, storage, CPU cycles and RAM come from personal computers on the edge. Even in bandwidth, where PC's still have the highest share but it looks to be around 1/3rd, the aggregate of all edge devices (PCs, mobile phones, PDAs, etc.) still dominates the data centers.

• Review of IronPython in Action

• Embedded IronPython 1 - The Simple Way

• Dynamic Language Console: Create Python Host
  

• IronPython Tutorial

• IronPython and Silverlight

• How to wire up a timer-triggered WPF event handler in IronPython

From a recent interview on the design team for C# 4.0 Anders said about the room they meet to discuss the C# design:

We have been meeting in this room for nine years, three times a week.

This seems to be one of the reasons C# has evolved so nicely.

Sadly there are no actual details on the interview about what is coming up on C# 4.0. We have to wait until the PDC to get an idea of what will be coming.

Luckily, Mono's C# compiler is already 3.0 compliant, and we are ready to start adding 4.0 features the moment they become public.

My friend Mirco Bauer has been maintaining and coordinating the Mono packaging for Debian for many years.

Today he released smuxi. His own IRC client that he built on top of Gtk#:

• Easier Python Evaluation from C#
  

• DLR Hosting Sample : QikScript - Handle Visual Studio 2008 extensibility events in IronPython

Summary:

• C# 4.0: Meet the Design Team
  

• IronPython Post 2.0 Roadmap

• Pushing out a new 1.1.2 release in the coming weeks, the last planned released of the 1.X (pre-Dynamic Language Runtime) branch of IronPython
• Getting IronPython 2 (currently still in beta) completed by the end of the year. IronPython 2 targets compatibility with CPython 2.5.
• Python 2.6 support (both language and library compatibility) will come sometime in the IronPython 2.1 lifecycle. Along with this will be Visual Studio integration.
• An IronPython 3 that will target Python 3.

• IronPython uses the underlying .NET basic types. Strings are therefore Unicode by default, as they will be in Python 3.
• IronPython compiles Python code to .NET assemblies, and uses neither Python stack frames nor bytecode.
• CPython extensions written in C, using the CPython C API, don't work with IronPython (at least not until Ironclad is completed).

• Differences between IronPython 1.0.x and Python 2.4.3
• Differences between IronPython 1.1.x and Python 2.4.3
• Differences between IronPython 2.0.x and Python 2.5.2

• Visual Studio IronPython Integration Deep Dive
  

• MSBuild integration with the Visual Studio environment
• A custom tool window to display the IronPython console
• Code snippets
• Project template support

To resolve the problems in the previous post, I've done the following changes to the XHTML page with the embedded object.

1. Removed the classid from the object and giving it an id, thus

   
   <object id="blogroll" data="blogroll.htm" 
   style="width:50%;float: right;height:60em; z-index=10" type="text/html">
       …fallback text…
   </object>

2. Added some script to put it back, and also to tidy away the annoying scrollbar that IE insists on putting in the right hand side

   
   <!--[if IE]>
     <script  type="text/javascript">
   // apply the attribute I'd removed
   $(document).ready(function(){
     $("#blogroll").attr("classid", "clsid:25336920-03F9-11CF-8FD0-00AA00686F13");
        });
   
   // fixup the scrollbar when it has been put in place
   $(window).bind('load', function() {
       document.getElementById('blogroll').body.scroll = "auto";
   });
   
   </script>
   <![endif]-->

Next to test it with FF3 -- IE7 and FF2 work like a dream. But if it weren't for the fact that the content I'm embedding is itself script, I'd be unhappy at using script to make it appear cross-platform.

LATER

Yes, that works.

I could replace the document.getElementById('blogroll').body.scroll = "auto"; with $('#blogroll').get(0).body.scroll = "auto";, but I'm not sure that being jQuery-purist gains much in this case.

I guess I ought at least to test Opera… :)

Michael Foord (aka voidspace) twittered that "None of the IronPython team can get it together to blog regularly, except @jschementi of course." While I'm not sure Jimmy is all that prolific either, Michael's certainly right about me. I started this job at the beginning of April, and I've only blogged twenty one times in the three and a half months since. Worse, I've only blogged six times in the past month and a half - and half of those have been since Michael called out my lack o' posting. My wife has blogged like twenty five times in that same time period. I can only plead pressures of a new job plus a two week vacation. I have been twittering a lot.

Michael was twittering in response to Todd Ogasawara's post wondering about our Python 3.0 plans. Since we haven't been particularly transparent (my fault) I thought I'd lay out our near and middle term plans.

First off, we're on the verge of releasing 1.1.2 (the release candidate is available now), a service release in our 1.x branch which contains a bunch of bug fixes we've back ported from our 2.0 work. This is our last planned release in the 1.x branch. For those who don't know, our 1.x branch tracks CPython's 2.4 branch.

Most of our team's focus has been on 2.0 which we're on track to shipping later this year. Our 2.0 corresponds to CPython's 2.5 branch. It's a major release for us because of the addition of the Dynamic Language Runtime. Currently, you can get 2.0 Beta 3, with Beta 4 scheduled for early August (we go about 6 weeks between beta releases). If you want even fresher code than our latest release, you can pull and build the source yourself. We went about two months without pushing source due to some broken scripts, but they're fixed now so we're going to try and push out code much more often than we have in the past.

For the non-Python geeks in the audience, Python is undergoing a major change. Python 3.0 is going to break backwards compatibility with Python 2.x in number of ways. Breaking backwards compatibility always has to be handled carefully, so the Python community is investing quite a bit of effort to make the transition as smooth as possible.The Python Software Foundation is currently working on both 2.6 and 3.0 simultaneously. The idea is to have as much feature parity between the two releases (except for the stuff being removed from 3.0) and to provide an automatic tool to translating to the new version.

Let me be very clear (since as Todd discovered, we haven't been to date) that once we get IronPython 2.0 out the door, we will start working towards IronPython 3.0, which will be our version of Python 3.0. We want to take the same stepping-stone approach that CPython is taking. So that means at a minimum we'll do an IPy 2.1 with CPython 2.6's new language and library features, (along with the usual bug fixing and other quality improvements we do every cycle) before then proceeding to work on IPy 3.0.

Until we get IPy 2.0 out the door, I'm not willing to talk about specific timelines. We're an agile project and we're going to be feature and quality driven, full stop. There were about seven months between the release of IPy 1.0 and 1.1, however that didn't include much new Python feature work so it's not a good comparison IMO. My gut tells me the IPy 2.1 release will take longer than a typical minor release while the IPy 3.0 release won't take as long as a typical major release. Note, those are guesses, not commitments.

Besides IPy 2.1 and 3.0, the other major thing we're working on is Visual Studio integration for IronPython. Yes, there is IronPythonStudio, but that's a VS SDK sample not a production-quality VS integration the IPy team maintains or supports. The IntelliSense implementation is pretty flaky, the compile-oriented project system feels pretty un-pythonic and of course we need to upgrade it to support IPy 2.0 and the DLR (it would be nice if IronRuby could leverage our efforts down the road). Like everything else we do in this group, we'll be publishing the VS Integration source code up on CodePlex as early and often as we can.

So to recap our current thinking:

• IPy 1.1.2 in RC now, shipping in several weeks assuming we don't find any major regressions
• IPy 2.0 in beta now, shipping later this year
• IPy 2.1 supporting new CPy 2.6 features at some point after IPy 2.1, probably longer than a typical minor release
• First release of IPy integration with VS in the same timeframe as IPy 2.1 but with alpha drops as soon as we can 
• IPy 3.0 supporting new CPy 3.0 after IPy 2.1, probably shorter than a typical major release

One last thing, as many of you know the IronRuby project supports community contributions to the standard libraries. I wanted the IPy community to know I'm 100% committed for establishing a similar arrangement for IronPython. I've got nothing to announce yet, but rest assured I've been spending a lot of time talking to lawyers.

As always, if you've got opinions to share please feel free to leave me comments below, shoot me an email, or join the IPy mailing list.

If you look at the "my photos" sidebar at the right, you'll see that unlike Firefox 2, it can't handle html via an object tag:-

<object classid="clsid:25336920-03F9-11CF-8FD0-00AA00686F13" data="http://www.windsong.demon.co.uk/flickr.htm" style="width:150px;height:520px" 
 type="text/html">
…fallback…
</object>

Here it is...

Installed on a new Vista machine with only the eb_GB spellchecker extension, you just get the fallback text. To get it to work I have to resort to condtional comments and for non-IE browsers, omit the classid attribute -- which isn't exactly standards friendly. It'll have to be jQuery to the rescue, I would guess.

Almost enough to drive me to Opera…

LATER

In order to fix it for IE, I've been driven to an iframe, which also works in FF3. But with iframe replaced by object in XHTML 1.1, I'm going to have to do something cunning and probably scripty for my table-of-contents page -- where I use object to embed a page served as plain text/html which contains scripts involving Document.write() and other X(HT)ML incompatible behaviours.

Functional C# -- Part 5 and last, the Match operator.

IronPython 1.1.2RC1 and Jython 2.5 first alpha release.

F# -- semi-formal spec

oMeta (and oMeta#) -- Object-Oriented Language for Pattern Matching i.e. a lexer/parser/... kit

Emmanuele Bassi has summarized a discussion that happened on IRC after my Gtk+ 3.0 post.

His blog entry starts by saying that we should not use blogs to discuss and then goes on to discuss. I agree with the sentiment, but IRC is not a good place to do the meeting either as we do not even have IRC logs for whatever channel they were on discussing.

It is about the ISVs

Emmanuele seems to think that this is a marketing problem. It is not.

This is about the effect that the current Gtk+ 3.0 plan has on ISVs.

KDE has almost no ISVs, Qt does.

GNOME has almost no ISVs, Gtk+ does.

Most likely because anything beyond the core toolkit is too unstable in both cases, and because things are too quickly flagged as deprecated with no roadmap in place.

The Qt situation is much better, as it is commercially designed, and they have existing customers that are paying them money to solve problems for them, not introduce new ones.

Qt is also designed to be bundled with your application, and you can make your proprietary application not break if the user upgrades his Qt. This is not the modus operandi for Gtk+.

Having an "abandoned Gtk 2.x" and a "maintained, but API and ABI incompatible 3.x" which will not be available everywhere at the same time is a major turn off for ISVs.

Creating an ISV ecosystem is incredibly hard, and somehow the new generation of Gtk+ developers is now "OK" to throw away years of work of those that had to work with fewer resources than Gnome has today, fewer developers, a smaller community, slower computers, bigger challenges and yet, managed to keep Gtk+ 2.0 API compatible.

Perhaps it is not a matter of being "OK", but the new crop of Gtk+ developers does just not appreciate just how much value ISVs are for Gtk+, Gnome and the Linux desktop in the first place. They did not have to fight to get those guys on board on the first place.

The premises and the conclusions of Imendio's paper would not hold if you were to consider application developers in the mix. But in particular, it seems that the mindset is dangerously close to the rationalization used recently by a KDE spokesperson and lampooned by the Linux Hater Blog.

What bothered me last night

What bothered me last night after I blogged was the realization that most of the Imendio developers have switched to OSX as their main desktop operating system (At least rhult, hallski and kris).

These are great developers, but for their day-to-day activities, they have given up on the Linux/Gnome desktop. Their concern is no longer to attract ISVs, as long as the source compiles with some changes, they will be OK.

There are certainly some developers at Imendio that still use Linux, and I am sure they have a "Linux partition" to test things out. But when it comes to ensuring the viability of the Linux desktop ecosystem, I do not feel comfortable about wiping out the ISV ecosystem that we have.

Discussion

Emmanuele says:

for instance, I would have loved to have Miguel at the gtk+ team meeting of Tuesday at GUADEC: it would have been a great discussion, I’m sure of it, and we might have had a different state of the union talk.

I mentioned this problem in my previous blog entry. Even if I had made it to Istanbul on Tuesday, I am merely one of the voices concerned about API stability. "Tuesday Meeting at Guadec" is hardly inclusive:

There was no Adobe.

There was no VMware.

There was no Medsphere.

There were no Eclipse folks (who have complained previously about the ABI/API issues).

There was no Gnumeric.

And these are the ones I can think of the top of my head.

Senior voices from our own community were missing, like Morten Welinder who has expressed his opinion in a shorter post:

The best thing about tabs that I can think of is that it will keep certain people from doing more harmful things like changing the gtk+ api for no good reason.

I do not know who attended the Gtk+ planning on Tuesday, but it was not inclusive, and I suspect it was heavily tilted towards the Nokia-ecosystem.

From a Nokia standpoint, I understand the desire of dropping older code, get a smaller version of Gtk+ out there, and be able to get a very flashy system at all costs. The iPhone and OSX are strong UIs, and I can understand the desire to compete, but lets not throw the baby with the bathwater.

Decisions about the future of Gtk+ can not be done without all the stakeholders, and specially without those that have worked for years in keeping the API stability under duress and have built applications on top of it.

Features

Emmanuele says:

Yes, 3.0.0 might not have features. is this bad marketing? probably. so we need to fix this. a way1 to do this would be keeping the 3.0.0 in alpha state, call it 2.99.02 and add features to that until we get to a 3.0.0 that developers will want to migrate to, like the new scenegraph API or the new style API. let’s break with 2.x in style

As I said previously, I would endorse such a plan if it is shown that fundamental new features could not be implemented in an API/ABI compatible way. Nobody has yet refuted my assessment of the various areas that would not break compatibility, and that covers most of the new features.

Although I am not the only stake holder, nor the only ISV, nor the only developer.

Communication

Emmanuele says:

communication: there’s a certain lack of communication between the gtk+ team and the users of the library. in my opinion, it’s due to the small number of active developers and to the fact that ISVs don’t really get involved into shaping the platform they are using. they have the source code, and sometimes it’s easier to fix in-house than to communicate and go through the proper process — and this is a structural problem that is caused by the small number of people involved in the said process as well. the gtk+ team needs to open up more, and at the same time the ISVs need to get more involved. sometimes it feels to me that the team is waiting for features, direction and help in the development, while the users of the library are waiting for the team to come up with the perfect plan to fix all the bugs and warts while retaining the whole API and ABI.

I agree with Emmanuele.

We setup the GNOME Foundation for things like this; Lets use the GNOME Foundation organizational powers to reach out to ISVs; to organize a platform and Gtk+ summit as it is now clearly needed; Lets include all the stakeholders, not only the active developers.

Process

Emmanuele says:

process: this is connected to the first point - we have a lot of channels, and it might be daunting to actually follow them all; but we're also open in terms of discussion and revision. this is our strength. so please: if you want to discuss, join the IRC meetings on the #gtk-devel channel on Tuesday at 20:00 UTC or send an email to gtk-devel-list with your points. get involved. help shaping the future. don’t stand idly by, and wait for stuff to break to complain.

Casual discussion on IRC is OK, but that should not be the repository for decision making for such a fundamental component of GNOME and the Linux desktop.

Perhaps the discussion can start on IRC, but minutes, summaries and decisions should be posted to the Gtk+ developers and users mailing list and given enough time for all the stake holders to participate.

Additionally, you can not expect that your blog has now reached all the ISVs, not even the gtk-devel-list (which is presumably a mailing list for the developers of Gtk+ not for its users).

We need to have a mailing list discussion, and then we need to have an outreach program to get to all stakeholders, including the ISVs to formulate a plan.

• Download IronPython 1.1.2 RC1
• IronPython 1.1.2 RC1 Release Notes

It's a little late, but we just pushed out the RC for IronPython 1.1.2. This is a minor release with a bunch of bug fixes we've backported from our 2.0 work.

However, there are two minor breaking changes I wanted to highlight:

1. Work Item #16348 - We've changed the nt.unlink method so that it raises an exception if the file doesn't exist. This brings nt.unlink in line with CPython's behavior, but does change the public behavior of the method.
2. Work Item #16735 - We've changed the return type of IronPython.Runtime.Operations.Ops.Id() from long to object. We return a boxed 32-bit integer for Ops.Id(), unless you've allocated over 2^32 objects in which case we roll over to our arbitrary precision IronMath.BigInteger type. Note, this only would affect statically typed languages compiled against the IronPython assembly. It wouldn't affect python  code in any way.

We think these are fairly minor (hence the reason we green-lit them) and furthermore these changes mirrors the eventual behavior of 2.0. Please let me know if either of the changes is a problem for you or your project.

Nester -- a C# version of the Jester code mutator.“Why just think your tests are good when you can know for sure?”

LinFu -- interesting .Net meta-programming library -- including support for declarative Design by Contract.

(Mis)using PoSh L10N to prompt for a configuration file.

The Gtk+ 3.0 proposal being discussed currently sounds like a disaster for GNOME. The reasoning was first articulated in the histrionic Imendio Gtk+ 3.0 Vision presentation done at the Gtk+ Hackfest in Berlin. This is a meeting where application developers were underrepresented, and somehow we have accepted those proposals as the community consensus.

The proposal goes like this: Gtk+ 3.0 will hide all public fields in objects, provide accessors to these, remove APIs that have been flagged as deprecated and introduce no new features.

All the actual new features that some people want would come up in future versions. Which features will come is yet to be decided, because nobody knows when and what will be implemented.

There are lots of technical problems with the proposal, and from my discussions this week at GUADEC it does not seem that the Gtk+ developers have discussed the implications with the users of Gtk+.

There is a major strategic problem with the plan as well. The most important one is that there is no actual plan for which features will be added, and when these features will be added. There are no prototype implementations, and the idea of first developing the new features in a branch to actually study the code, the implementation and its potential APi breakage is not even on the agenda.

Basically, we are being told that we should trust that first breaking the API and hiding fields will suddenly enable a whole generation of new features to be implemented.

But it gets better. There are no guarantees that 3.x will not break the API if the feature in question turns out to require API breakage. Which means that we might actually end up in a situation where there will be multiple API breakages.

This by all means sounds like a bad plan.

Towards a Better Plan for Gtk+ 3.0

I am not against breaking the API for newer versions of Gtk+ if the benefits outweigh the downsides, and the execution presented is not bad. But "3.0 will help us clean up" is not a good enough reason.

We need:

• A Clear Roadmap: We need a clear roadmap of which features will be implemented and when they will be implemented. This is the first step to making decisions.
  

  A clear roadmap would also allow new developers to join the efforts and big companies like Red Hat and Novell to dedicate some full time resources to make some of these feature happen. As things stand today, we are basically being told to "wait-until-3.0-then-we-will-sort-it-out".

• Working Code: Before a feature for a future version of Gtk+ can be considered a reason to break the API, the technology must exist in the form of a patch/branch.
  This is not new, and should be of no surprise to anyone. This is how the Cairo integration into Gtk+ was done, how the layout changes are being implemented and how every other software product is ran.
• New API-breaking features must be publicly discussed with the community: Since this will affect every application developer (open source and proprietary) we should get the feedbacks of these communities.
  We could all get as excited as we want about a "gboolean bouncing_text" field in a GtkLabel, but that does not mean that we should break the API for the sake of it.
  Application developers were underrepresented at the Berlin hackfest, and even GUADEC is a microcosm of the ISVs that we had to reach. For instance, I did not see anyone from Adobe, VMware or Medsphere at the conference.
• Transitional 2.x Releases: For a long-enough period to get distributions to include the code, Gtk+ 2.x should include getter/setter macros to allow software developers to upgrade their source code to work with and without the public fields. To soft-land the switch to a hiding-field Gtk release (this is covered in the Imendio proposal).

This is by no means a comprehensive plan, it is only the beginning of a plan.

Lets please avoid inflicting in GNOME a KDE 4.0 (yes, I know its not the exact same scenario; and yes, I know those clock applets are cute).

Gtk+ Extensions

From looking at the original Imendio proposal. it seems that plenty of the things they want can be implemented without breaking the API:

• Animation: doable entirely without breaking the API. The animation/storyboard framework is an entirely new codebase, that would not touch anything in Gtk+. Some widgets might require smoother rendering on changes, but all can be done in an API-compatible framework. public API.
• Physics: same, add-on.
• Data-binding: same, add-on.
• Easier language bindings: same, add-on.
• Improved back-ends, more OS integration: Can not think of a major issue, but granted, I could be missing something, and Imendio has done the OSX