jimmy.thinking

Sparklines in WPF and Silverlight

noreply@blogger.com (Jimmy Schementi) — Mon, 09 May 2011 04:15:00 +0000

One seemingly-trivial-yet-recurring problem in financial software is the need for a live-updating line-chart. However, from multiple conversations with Lab49 folks, as well as from experience during my first project, I’ve learned that most WPF/Silverlight charting packages suck in various ways, especially if you’re updating their data frequently. Seems like everyone just rolls their own line chart and tailors it to each project, but doesn’t share it for some reason. I’d like to break that trend by sharing and early version of my own sparkline control for WPF and Silverlight.

http://github.com/jschementi/sparkline

Sample Usage:

It’s implementation is very basic; Sparkline.AddTimeValue constructs a point at the next time interval and adds it to a Polyline. You can control the sparkline’s visuals, including adding visible points along the line and showing horizontal lines for the latest/highest/lowest values. The source builds assemblies for both .NET 4.0 and Silverlight 4.

There are obvious features missing like rendered axis or variable x-axis (time) values, but hopefully this provides a simple starting place for anyone else needing a very simple updating line graph.

By the way, Andre de Cavaignac, a colleague of mine at Lab49, and Daniel Simon shared their own a while back: Live Updating Line Graph in WPF. Let me know if there are any others out there.

Anyways, Happy Mother’s Day!

NYC CodeCamp 2011

noreply@blogger.com (Jimmy Schementi) — Fri, 25 Feb 2011 07:50:00 +0000

This past weekend I spoke at NYC CodeCamp 2011 about the Iron Languages project and dynamic languages on .NET; here are the slides:

Most of the demos were from previous talks, so look through my previous posts on IronRuby and IronPython for relevant demos.

Leadership of IronRuby and IronPython

noreply@blogger.com (Jimmy Schementi) — Thu, 21 Oct 2010 23:14:00 +0000

Now that I’ve moved from Seattle to New York, started my new career at Lab49, got married, and just got back from the honeymoon, my public techie life can resume. And I’m happy to resume it on a positive note.

Today signifies a big step in Microsoft’s commitment to open-source: Jason Zander announced new leadership for IronRuby and IronPython, namely Miguel de Icaza, Michael Foord, Jeff Hardy, and myself. Since Microsoft has officially put the project in our hands, both languages will be open to contributions from the community, not just the core team members. Also, any previously unreleased work as been released, include the IronRuby tools for Visual Studio and groundwork towards IronPython 2.7 and 1.9. You can find the appropriate releases on both IronRuby and IronPython’s CodePlex sites.

Though Microsoft is no longer directly resourcing these projects, there are definitely companies providing support. Lab49 has been tremendously supportive of my participation in the project, and is interested in supporting the project in substantial ways going forward. Those details will become clearer in the future, but it’s great to see my company taking a proactive role in the projects I’m part of. Also, Miguel is a big-shot at Novell, but I’ll let him comment on how his company is supporting the projects. =)

The reality of open-source software is that corporate sponsorship and funding comes and goes. I'm grateful to Microsoft for starting IronPython and IronRuby, funding it up until this point, and passing the torch to individuals who will continue to progress the languages forward. I’d specifically like to thank Bill Chiles, Dino Viehland, and Tomáš Matoušek, who did the hard work to make this transition happen.

If you’re interested in the future of these projects, please subscribe to their mailing lists (IronRuby, IronPython) and help us to continue making a great dynamic language experience on .NET.

“Start spreading the news”: the future of Jimmy and IronRuby

noreply@blogger.com (Jimmy Schementi) — Fri, 06 Aug 2010 21:40:00 +0000

Though Frank Sinatra says it best, “I’m leaving today” isn’t exactly accurate; my last day as a Microsoft employee was July 23rd, 2010. This post is almost two weeks delayed as Felicia and I have been on the road since the 26th, driving cross-country to the east coast; we also decided to leave Seattle in favor of New York, our home state.

Both decisions were extremely difficult to make, as I will miss all the brilliant people I worked with. Just being in their presence made me feel smarter, and we accomplished some amazing things together. Many were also my friends, making this a very heart-wrenching decision too. However, I joined Microsoft to bring Ruby and other open-source programming languages to the .NET framework, as well as to promote open-source practices in general, and I promised myself to ensure the truth of that statement throughout my Microsoft career. So, when my manager asked me, “what else would you want to work on other than Ruby,” I started looking for a new job outside Microsoft.

While Microsoft’s commitment to dynamic languages on .NET has been questioned many times, my tiny team has been excellent at suppressing those fears with quality implementations of Ruby and Python for .NET, compiler services and language embedding API called the Dynamic Language Runtime, and integration with .NET application frameworks like Silverlight and ASP.NET. And most recently the beginnings of IDE support for dynamic languages in Visual Studio. And all this released under an well-known open-source license, the Apache License (Version 2). This was only possible because my team had the freedom to do what we needed to do to counter those fears and run an effective open-source project

However, a year ago the team shrunk by half and our agility was severely limited. I’m omitting the internal reasons for this, as they are the typical big-company middle-management issues every software developer has. In short, the team is now very limited to do anything new, which is why the Visual Studio support for IronPython took so long. IronRuby’s IDE support in Visual Studio hasn’t been released yet for the same reasons. While this is just one example, many other roadblocks have cropped up that made my job not enjoyable anymore.

Overall, I see a serious lack of commitment to IronRuby, and dynamic language on .NET in general. At the time of my leaving Tomas and myself were the only Microsoft employees working on IronRuby. If this direction for dynamic languages on .NET is a path you do not want Microsoft to take, I strongly suggest you provide feedback to the team’s management directly. Also, Jason Zander runs the Visual Studio team, which IronRuby, IronPython, and the DLR happen to be a part of, and is a big proponent of these dynamic languages efforts, so provide him with your thoughts as well.

That being said, I am still interested in implementing dynamic languages on .NET, so I will remain a IronRuby core-team member, ironically making me the first non-Microsoft core contributor. The bad-news is I will no longer be working on IronRuby full-time, but in the near future I’m definitely staying active. Also, Tomas will definitely continue working on IronRuby when he can; we weren’t the last two people left for no reason. :-)

Given that Tomas and I will only be working part-time on IronRuby now, I invite the Ruby and .NET communities to come help us figure out how to continue the IronRuby project, assuming that Microsoft will eventually stop funding it. I’ll start a thread on the IronRuby Mailing List shortly, so keep an eye on that if you’d like to help. [Update: here’s the thread about the next steps for IronRuby. Join the list and discuss.]

While moving to New York is mainly a personal decision, as both my fiancée and I grew up there and our immediate families are still there, it was also for professional reasons; I’ve accepted a new position at Lab49, a financial technology consulting firm in New York City. I chose the financial industry not just because its dominance in New York, but because I see a lot of similarities between financial software and developer tools. Financial software serves a very technical user, much like programmers, but unlike programmers I know nothing these users, making it a challenging new space. It will be familiar as well, as Lab49 has done work with the new Technical Computing team, which many people who once worked on dynamic languages moved to. Lab49 was also very interested in my IronRuby and IronPython background, so it’s a great next step for me.

I’m grateful to have worked on compilers full-time, outside of academia, while still contributing to open-source, especially at a company that hardly showed up on the open-source radar just 4 years ago. And at least one dynamic language at Microsoft is getting love; IE9’s JavaScript engine, and Microsoft has awesome intentions with it. I’m totally a supporter of most things Microsoft is doing, and I look forward to working closely with them on financial problems. I’m just extremely disappointed with their decisions around dynamic languages on .NET. As one former-teammate’s email signature read, “If your ideas are any good, you'll have to ram them down people's throats.”

I’m looking forward to this new chapter in both my life and my career. Not only am I living in the city that never sleeps, but I hope to build upon my dynamic language work and use it in an area completely new to me. While I expect to still be Ruby and .NET oriented, my posts will be about solving new problems, and should make for some good reading. Stay tuned, and thanks for all the support thus far.

ASP.NET dynamic language support is open source

noreply@blogger.com (Jimmy Schementi) — Mon, 26 Jul 2010 07:07:00 +0000

I'm happy to finally announce that the ASP.NET dynamic language support is now open source:

Download IronPython and ASP.NET integration

For a full IronPython release with the Python standard library, download IronPython 2.7 Alpha 1.

This release contains the source code to Microsoft.Scripting.AspNet.dll, located in the src directory, licensed under the Apache License (Version 2). It will be available in the source repository for IronPython in the very near future, but don't hesitate to start sending in patches. This release is compatible with IronPython 2.7 Alpha 1.

Background

This download enables IronPython as an ASP.NET programming language. To create a new IronPython ASP.NET WebForms project, simply copy examples\web.config and examples\bin, and use examples\hello-webforms.aspx as a reference. A redistributed copy of the IronPython 2.7 Alpha 1 binaries can be found in the examples\bin directory; all files except Microsoft.Scripting.AspNet.dll, the IronPython ASP.NET integration, are from the IronPython 2.7 Alpha 1 release.

For more detail on getting started, here’s a simple walk-through of making the “hello-webforms” app.

Package

Here's what's in the zip file:

/License.html - The Apache License, Version 2.
/dlr-aspnet.sln - VS2010 solution for examples
/examples - Examples of using IronPython in ASP.NET.
/examples/Web*.config - configures ASP.NET to use IronPython
/examples/bin - Microsoft.Scripting.AspNet.dll, the ASP.NET integration, and a redistribution of IronPython 2.7A1.
/src - C# source code that builds Microsoft.Scripting.AspNet.dll

Upgrading

This release renames the main DLL from Microsoft.Web.Scripting.dll to Microsoft.Scripting.AspNet.dll. If upgrading, you'll have to replace all occurrences of Microsoft.Web.Scripting with Microsoft.Scripting.AspNet. This will primarily be at the top of all aspx pages, as well as in your application's web.config. Also note the version number is now 1.1.0.1, which matches all the other Microsoft.Scripting assemblies.

Feedback

As always, please report issues on the IronPython issue tracker. You can also try to fix any issues yourself and submit a patch. Lastly, you can actually talk to humans on the IronPython mailing list.

Enjoy!

Summer of “Iron”: LINQ, Visual Studio tooling, and the Apache License

noreply@blogger.com (Jimmy Schementi) — Tue, 20 Jul 2010 03:05:00 +0000

New releases and announcements from the “Iron” projects have come out over the last couple days, so I wanted to give you an overview of what’s happening, point out the really cool parts, and reiterate some of the motivations.

From a release perspective, both IronRuby and IronPython released new versions of the DLR-based .NET programming language implementations: IronPython 2.7 Alpha and IronRuby 1.1. Click on the respective release name for the full release notes and downloads, but I’ll summarize a bit here:

IronPython 2.7 Alpha

Install IronPython 2.7 Alpha (includes Visual Studio tooling)

This Alpha release is the first IronPython release working towards Python 2.7 compatibility, and contains a number of bug fixes and performance improvements. It also now requires .NET 4.0 or Silverlight 4; you will need to build from source for down-level frameworks. The installer now includes Visual Studio support for IronPython, rather than being a separate installer, and the source-code for the tools has been open-sourced! Keep reading for licensing information …

IronRuby 1.1

Install IronRuby 1.1

Aside from a bunch of bug-fixes, the latest release of IronRuby adds support for .NET extension methods, meaning that .NET programming patterns that are dependent on extension methods, like LINQ, the Reactive framework, Parallel.NET, etc, are now all usable from Ruby code. For example, here’s a simple LINQ example:

For more information see the 101 LINQ samples ported to IronRuby.

Also, since I never announced the IronRuby 1.0 release on my blog … consider this the announcement.

Apache License, Version 2

IronRuby, IronPython, and the DLR are now licensed under the Apache License, Version 2. To address all concerns around “why” this is changing, it is solely in reaction to feedback about the licensing terms from users and the .NET/Python/Ruby/dynamic-language communities at-large. The Apache License is a more familiar and popular license to those communities than the Microsoft Public License; using it should lower any license-related barriers people encountered in the past when considering these programming-language implementations.

Enjoy!

MIX10, Part 3 - Using dynamic languages in existing web-applications

noreply@blogger.com (Jimmy Schementi) — Tue, 27 Apr 2010 10:19:00 +0000

This post is part of the “MIX10 – Pumping Iron on the web” series:

Part 1 - Introduction
Part 2.1 – Server-side web development with dynamic languages
Part 2.2 – Client-side web development with dynamic languages
Part 3 - Using scripting in static applications
Coming soon: Part 4 - Web-app extensibility with scripts

The original post was mistakenly removed, so it’s been reposted with the original post date, 4/27/2010. Sorry if this confuses your blog readers or causes any other inconvenience.

Up until now I've discussed how to use dynamic languages to power both the server-side as well as the client-side of your web-application, but what if you want to apply these methods to solve certain problems in an existing application?

Testing

A low-risk, high-benefit use of dynamic languages in your existing applications is for testing. This helps make the act of writing tests simpler, and quite possibly more fun, encouraging your team to actually maintain the test suite.

Before looking at how to test web-apps, let's take a brief look at what a test written with RSpec, a popular Ruby testing framework, looks like:

Note: there are Ruby testing frameworks that look a bit more like what you might be used to. The following is an equivalent test written with test/unit, and this will give you a better idea of the structure of the above example:

The RSpec snippet almost reads like english, making it very clear what the intended behavior of Stack is. Also, it shows the power of Ruby for creating internal DSLs; a "language" built out of the constructs of an existing language. describe and it look like language keywords, but in-fact they are really just methods, because Ruby has optional parameters (as we discovered earlier with Sinatra). Using actual strings as the test name, rather than a method name, allows you to describe the test accurately. Each object has a should method which makes any subsequent calls part of an assertion, making it very obvious which value is the "expected" value and which is the "actual".

The crazy thing is how little code is required to make that work; 24 lines of Ruby. The key points are that yield executes the do-end block passed to a method, and the should method is added to every object, turning any subsequent methods calls into an assertion:

However, please don't use this example as your real testing framework, and then get mad at me when it doesn't have a feature you want; RSpec, Bacon, or test/spec are much more mature testing frameworks that support this same syntax.

See my previous post about using IronRuby to test C# Silverlight applications; it’s still relevant though it’s a fairly old post.

Hosting

IronRuby and IronPython are built on-top of the Dynamic Language Runtime, which is comprised of many parts, one of which being a .NET Hosting API, allowing you to embed a scripting language in any .NET app.

Now we come to the "ah-ha!" moment of the talk; everything you've seen in the MIX10 posts is made possible by this API. Keep in mind these languages are built on .NET, so their implementations are accessible from any .NET language. C# and VB today are not built on .NET; they just compile programs to run on .NET, which is why you can't easily host those languages today.

Here's the catch; since these language engines are built on .NET, they need to run in a .NET application. So, all Ruby or Python code runs by hosting the languages inside a .NET application. We do things to make this seamless in specific environments: for example, ir.exe and ipy.exe are both .NET programs which host the language and run the code in a command-line, mimicking the behavior of ruby.exe and python.exe. Here are some other popular hosts:

ipyw.exe: runs scripts in a console-less program for Windows applications
Microsoft.Scripting.Silverlight.dll: entry-point for Silverlight applications which run HTML script tags and scripts inside the XAP
IronRuby.Rack.dll: run rack-based applications on IIS
Microsoft.Web.Scripting.dll: run Python in ASP.NET
System.Web.Mvc.IronRuby: run Ruby in ASP.NET MVC

However, we can't provide "runners" for every environment that will spring up, so we allow you to use the same APIs that these runners use in your own apps. These APIs have been kept very simple, as we want any .NET developer to be able to use a DLR scripting language in their applications.

But why embed a scripting language into your application? The main scenario is to scripts as an extensibility mechanism, either internally or as functionality you provide for your end-users. Here are a few concrete examples of what scripts could be used for:

An advanced search/filter (letting users use LINQ safely)
High-level business logic to computing prices of items, applying discounts, etc; any type of rules engine
A system which changes behavior based on external data
Customizing a single codebase for different clients
Add-ons for end-users to make your application better (eg. Facebook)
Making application logic simpler to read than the core of your system (polyglot)

Let's show you how to do the basics, and hopefully that will spark your imagine to think up other cool use-cases:

Create a new web application project in Visual Studio 2010, and open the Default.aspx.cs page.
Place a label on the page and call it “Message”.
Add references to the necessary DLLs to host IronPython (IronPython.dll and Microsoft.Scripting.dll)
Write the 5 lines of code to update the label’s text from Python:

There are basically three types you need to know; ScriptRuntime, ScriptEngine, and ScriptScope.

ScriptRuntime is a level of encapsulation for your scripts; it represents the DLR scripting runtime, and all script operations go through it.
ScriptEngine is the type that is returned from ScriptRuntime.GetEngine; it represents a DLR-language. In this case, we asked for the language by name, as that's the easiest way to keep it easily configurable, but the downside is you need language configuration info in your App.config. However, if you only want to depend on IronPython, you can use IronPython.Hosting.Python.CreateEngine(), which does all the setup for Python for you.

The ScriptEngine enabled you to execute code in that language, in a variety of ways, from the basic engine.Execute method (essentally eval), or being more fine-grained engine.CreateScriptSourceFromString(code).Compile().Execute(), which parses the file, compiles it, and then executes it. Code can be executed against a ScriptScope to set initial state and share state between executions.
ScriptScope defines the state for your script; like what variables/methods are present. It is a dynamic object, so you can do things like scope.page = this, and that will set the page variable for scripts that execute against the scope. In downlevel .NET frameworks, you'd have to use scope.SetVariable(page, this).

Slight aside: since these APIs are .NET based, the dynamic languages themselves can consume them to run other dynamic languages! For example, here's Ruby executing Python code through the DLR Hosting APIs:

What's also interesting is the dynamic languages can communicate between each-other just as easily; here's Ruby calling Python code:

Anyway, hopefully this sparks some creativity! For more web-related information, also posted about this in relation to Silverlight applications: Scripting C# apps with IronPython.

The next post will show some cool applications of this … (coming soon).

MIX10, Part 2.2 – Client-side web-development with dynamic languages

noreply@blogger.com (Jimmy Schementi) — Mon, 26 Apr 2010 10:18:00 +0000

This post is part of the “MIX10 – Pumping Iron on the web” series:

Part 1 - Introduction
Part 2.1 – Server-side web development with dynamic languages
Part 2.2 – Client-side web development with dynamic languages
Part 3 - Using scripting in static applications
Coming soon: Part 4 - Web-app extensibility with scripts

The original post was mistakenly removed, so it’s been reposted with the original post date, 4/26/2010. Sorry if this confuses your blog readers or causes any other inconvenience.

IronRuby and IronPython are fully-supported in the browser, thanks to Silverlight. In-fact, they are hands-down the simplest way to develop a Silverlight application. This is not only because of how expressive the programming languages are; the integration with Silverlight doesn't fight how the web works.

For example, here's an entire Silverlight app which just writes a message into the HTML page, written in Python:

DLR-based Silverlight applications let you write HTML script-tags in other languages than JavaScript, but in a way that works cross-browser and cross-platform; the languages work in Moonlight on Linux as well.

Both inline and script-src tags are supported, so your scripts can be separated from the HTML file:

This integration makes writing Silverlight applications just as easy as they were in Silverlight 1, but with the power of .NET and Ruby or Python. DLR-based applications also support a XAP model for anyone familiar with how static Silverlight applications work, so you get to choose which way you prefer to write your applications.

All the specific examples used in this section of the talk were taken from these posts:

Python in the browser: my blog post from PyCon 2010 about IronPython in Silverlight
Ruby in the browser: my article in RubyInside about IronRuby in Silverlight
Silverlight.net / d ynamic languages: tons of info on getting started with Python, Ruby, and the DLR in Silverlight.

Next up, using dynamic languages in your existing web-applications.

MIX10, Part 2.1 – Server-side web development with dynamic languages

noreply@blogger.com (Jimmy Schementi) — Mon, 26 Apr 2010 06:35:00 +0000

This post is part of the “MIX10 – Pumping Iron on the web” series:

Part 1 - Introduction
Part 2.1 – Server-side web development with dynamic languages
Part 2.2 – Client-side web development with dynamic languages
Part 3 - Using scripting in static applications
Coming soon: Part 4 - Web-app extensibility with scripts

The original post was mistakenly removed, so it’s been reposted with the original post date, 4/25/2010. Sorry if this confuses your blog readers or causes any other inconvenience.

One reason for embracing dynamic languages is to make your entire web-development experience simpler, be it on ASP.NET enabled web-servers, or on the client through Silverlight. Let's first look at the server.

Both IronPython and IronRuby can run on the same infrastructure as your ASP.NET applications, though in their own ways. Due to historic reasons, IronPython is supported as an ASP.NET language through the ASP.NET Dynamic Language integration, and IronRuby is supported through IronRuby.Rack, which enables Rack-based Ruby web-applications to run on ASP.NET. However, both are open-source, so each one could be ported to the other language.

Since these DLR-based languages run on ASP.NET, deploying them is no different than any other ASP.NET application; they can be run on any ASP.NET enabled web-server like IIS. Keeping that in mind, let’s first look at how simple Ruby web apps can be.

Minimal Ruby web-applications

Ruby itself has very expressive syntax, and the Ruby community has built many web-frameworks to make web-development really simple. For example, Sinatra is a web-framework made to minimize the amount of code required to respond to web requests:

The above code does exactly what it says; when a get request happens for '/', show "Hello, World" on the page. This highlights Ruby's domain-specific language abilities; get looks like a keyword, though it's really just a method call with '/' as the first argument (Ruby lets you omit parenthesis from method calls too ... any VB script fans out there?). The do-end block is syntactic sugar for passing a lambda as the last-argument to the get method; all Ruby methods take an arbitrary "block" of code between do-end or {}. Inside that block is what happens on each request, and whatever is returned is written to the response ("Hello, World"); the last statement of any expression (blocks, methods, if-statements, etc) is implicitly the return value of the statement.

For all those C# fans, you can use curly-braces too:

Though these features sound arbitrary by themselves, if I were to write this with only the more-familiar language features found in Ruby, it would lose its character:

This defines a Ruby method verbose, which explicitly returns the string "Hello, World", and then calls the get method directly with the first argument being the URL and the second argument being an explicit pointer to the verbose method. Why does this look so much uglier? While this might be closer to how the programming language actually runs the initial examples, it's not how the programmer thinks.

Not to leave Python out of this love-fest, Python can make this look very pretty as well, but in her own special way. Imagining that a Sinatra-like library exists for Python:

Here the index method is created, which explicitly accepts both the request and the response as arguments; Python's all about being explicit, while Ruby is very implicit. Then the method would be "decorated" with the sinatra.get decorator, which would tell the web-framework that index represents a get-request for "/".

What's a decorator?

A Python decorator is basically a function that accepts a function and returns a function, so this imaginary Sinatra-like framework would define get something like this:

Another way of looking at it is without the decorator syntax:

It’s a bit more readable than Ruby, and almost equivalent to the decorator way, except for the order of get in the code. You'll also see that getting a method pointer is much cleaner than Ruby (index vs. method(:index)); in Ruby index would call the method, since Ruby allows method calls with or without parenthesis, where Python uses parenthesis to indicate a method call.

Point being is that both Ruby and Python are very expressive in their own ways, and makes it really easy to make simple websites on Windows. The IronRuby team takes of advantage of this to power http://ironruby.info, a Ruby-compatibility reporting website. This is the code from the main page:

This renders the index.haml template with the data returned from Stats.get_latest, which is pretty much what the code says. The HTML is generated from the haml templating engine, which makes generating HTML and calling Ruby code extremely easy:

To play around with using HAML, you can use aspnet-haml to support .haml files though ASP.NET.

Ruby on Rails - Databases with Ruby

One of the most popular (or most buzzed) web-frameworks is Ruby on Rails, which is just a collection of Ruby libraries for structuring your web-application. Rails uses the Model-View-Controller pattern, so any ASP.NET MVC people will find it a very-familiar framework. However, Rails really shines when it comes to interacting with the database through it's ActiveRecord library (the “Model” layer). ActiveRecord maps Ruby classes to database tables, and provides an Ruby abstraction for interacting with the database:

This is all the code that is required to map your Ruby classes to the database, as well as create the structure of the database. ActiveRecord dynamically provides getters/setters for the table, as well as sets up foreign-keys and relationships based on conventions (belongs_to :posts assumes that the table has a 'post_id' field).

Interacting with the database is just as easy as calling methods; Post.all translates to the SELECT * from posts SQL query, since the Post object is mapped to the posts database table. Post.find(<id>) does a SELECT * from posts where id=<id>, etc.

Because Rails uses the Rack web-server interface, it will also run on IIS using IronRuby.Rack. See the IronRuby Rails documentation for more info about using Rails on IronRuby, and the Ruby on Rails documentation for general Rails usage.

ASP.NET MVC and IronRuby

Those were all Ruby-based web-frameworks, but what about using ASP.NET directly? The IronRuby community has developed an integration with ASP.NET MVC, so you can write your controllers and views in Ruby. Special thanks to Ivan Porto Carrero for single-handedly maintaining it.

ASP.NET and IronPython

Again, to give Python some love, IronPython directly integrates with ASP.NET, letting you write your ASPX code-behind files in Python.

Because of ASP.NET's events-based API (rather than a response-based API like Sinatra/Rails), Python methods can automatically hook events by using the <object>_<event-name> convention, and all server-side controls with "ID"s ends up being a variable available to the Python module. And application-level event hooks can go in global.py. But it's really nice to write Language="IronPython" at the top. =)

Python code can can also interact with the controls:

The <%# %> syntax lets run Python code in the context of the ASP.NET control's data source. The repeater's data-source was set to a list of IMAGETAGS (a python class), which has all those fields on it.

In conclusion, on the server you have many options for using IronRuby and IronPython to simplify your solutions.

Next up, using dynamic languages on the client through Silverlight.

MIX10, Part 1 – IronRuby, IronPython, and the web

noreply@blogger.com (Jimmy Schementi) — Sat, 24 Apr 2010 07:10:00 +0000

This post is part of the “MIX10 – Pumping Iron on the web” series:

Part 1 - Introduction
Part 2.1 – Server-side web development with dynamic languages
Part 2.2 – Client-side web development with dynamic languages
Part 3 - Using scripting in static applications
Coming soon: Part 4 - Web-app extensibility with scripts

The original post was mistakenly removed, so it’s been reposted with the original post date, 4/24/2010. Sorry if this confuses your blog readers or causes any other inconvenience.

This past week I had the pleasure of attending and speaking at MIX10 in Las Vegas about using IronRuby and IronPython on the web. If you’re a TV-person instead of a reading-person, here’s a video of the talk:

As I usually do, this series of posts will be a write-up of my talk … but first …

iron? - Jim Hugunin and John Lam have both been quoted as saying "Iron" stands for different acronyms; "Implementation running on .NET" and "It runs on .NET", respectively. I’m going to put my foot down and officially side with Jim, though really they are bacronyms; neither is actually the original meaning. A StackOverflow post explains more, and I hope that puts the wondering to rest.

This talk is all about the why and how of embrace dynamic languages on Microsoft's web platform - be it on the web-server (IIS) or in the web-browser (Silverlight), and even in existing applications. To start out with, here’s my rational for why we as a developer community should care:

It’s no secret that developers like things to be simple, and the web is pretty simple as far as application models go. While the web’s feature-set is pretty attractive itself (server-client oriented, instant client deployment, and cross-platform clients to name a few), the equally attractive development experience (simple UI mark-up system and a scripting language) still make it easy for people to build amazing websites.

Though the application model is simple, developers continue to evolve it; server and client frameworks are vital tools that make the web-development experience even more productive – it’s very rare that a website has no server side or client side dependencies.

These frameworks provide such innovative features because they stand on the shoulders of powerful and expressive dynamic/scripting languages, giving the frameworks the unique ability to model the "web" as they see fit.

While each web-framework is powerful in its own right, the power really comes from the choice to use whatever tools help get things done. Developers and designers for .NET have the same need to get things done, and if getting things done is essentially the result of programming language choice, what choices are there? Really only C# and VB, which are static programming languages, requiring a compile step before execution and relying on debugging to see code in action. Take a look at the other languages mainly used on the web again -- they're all dynamic languages, running from source code, and providing interactive environments for running code. Why is .NET static while the rest of the web is dynamic? Why can't they exist together? If .NET provided some language choice for developers, all the languages be used together, and the .NET community could benefit from the amazing work being done by dynamic language community, and visa versa.

We in-fact live in this world, and embracing dynamic languages is possible on .NET, but why would you want to do it? I'll discuss this in the following posts (links to posts coming soon):

Server-side web development with dynamic languages
Client-side web development with dynamic languages
Using dynamic languages in your existing web-applications
Coming soon: Opening up your applications to extensibility with scripts

PyCon 2010: Python in the browser

noreply@blogger.com (Jimmy Schementi) — Fri, 05 Mar 2010 22:30:00 +0000

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

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.

To allow Python to be indented inside a script tag, the margin of the first line which does not only contain whitespace is removed. Line numbers in the HTML are preserved, so error messages show up correctly:

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!

What can you get with 10KB of Ruby or Python code?

noreply@blogger.com (Jimmy Schementi) — Thu, 21 Jan 2010 00:54:00 +0000

$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 …

Enter your app right now »

IronRuby @ RubyConf 2009 – Part 4: Project status

noreply@blogger.com (Jimmy Schementi) — Tue, 15 Dec 2009 23:41:00 +0000

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

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

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

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

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

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

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

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

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

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

IronRuby @ RubyConf 2009 – Part 3.5: Embedding IronRuby

noreply@blogger.com (Jimmy Schementi) — Tue, 15 Dec 2009 06:29:00 +0000

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:

2D rendering surface with simple primitive shapes
Simple animation support – callbacks for each frame and each object on the canvas
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.

IronRuby @ RubyConf - Part 3: Sneaking Ruby to the top

noreply@blogger.com (Jimmy Schementi) — Mon, 14 Dec 2009 09:28:00 +0000

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.

IronRuby @ RubyConf 2009 – Part 2: What sets IronRuby apart?

noreply@blogger.com (Jimmy Schementi) — Wed, 09 Dec 2009 07:20:00 +0000

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.

IronRuby @ RubyConf 2009 – Part 1: Summary

noreply@blogger.com (Jimmy Schementi) — Wed, 09 Dec 2009 06:39:00 +0000

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

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

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

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

IronPython gets a long overdue website!

noreply@blogger.com (Jimmy Schementi) — Mon, 07 Dec 2009 21:29:00 +0000

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!

Embedding IronPython in Silverlight - Importing

noreply@blogger.com (Jimmy Schementi) — Wed, 11 Nov 2009 09:05:00 +0000

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

Slight detour – Embedding in Silverlight 101

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

In case you need to customize your ScriptRuntime, the DynamicEngine.CreateRuntimeSetup method is there to create a ScriptRuntimeSetup object configured for Silverlight, which then you can tweak things as necessary and create your own ScriptRuntime.

Note: The IronPython sources currently are broken for embedding, but in the next few days the sources should reflect what this post shows.

Testing that "import" works

Ok, great, the boilerplate hosting code doesn’t need to look hideous, but let’s get back on track.

Embedding IronPython in Silverlight – importing test (sources)

Here’s a quick test of IronPython’s ability to import various modules in Silverlight, testing this exact code works while being embedded:

None of these worked when I first wrote the tests, since there was an exception being thrown in the XAP-virtual-filesystem, reported yesterday on the IronPython mailing list. But with that fixed, the import bar.baz case still failed:

[FAIL]
Traceback (most recent call last):
  at test_import in foo.py, line 5
ImportError: No module named bar.baz

Here's the layout of the Python files in the XAP

foo.py
bar/
bar/__init__.py
bar/baz.py

Application.GetResourceStream("bar/__init__.py") was returning null, though bar/__init__.py was definitely inside the XAP. However, bar/__init__.py was empty, and it turns out that Application.GetResourceStream returns null if the file is empty as well as if it doesn’t exist! Putting a single space in bar/__init__.py (or anything that will make the file not empty … I suggest a comment) causes it to be found, and then bar/baz.py can be imported properly.

So, moral of the story:
“an empty file in the XAP is a non-existent file!”

Anyway, I hope that clears up some of the issues most people initially face with embedding IronPython in Silverlight. Let me know if there are any more issues.

Note: As I said before, the current IronPython sources are broken for embedding, but in the next few days the sources should reflect what this post shows. If you’re impatient, grab these binaries.

IronRuby and IronPython for .NET 4.0 Beta 2

noreply@blogger.com (Jimmy Schementi) — Thu, 22 Oct 2009 09:20:00 +0000

Quick download links: IronRuby | IronPython | .NET 4.0 Beta 2

I’m pleased to announce the release of the IronRuby and IronPython CTPs for .NET 4.0 Beta 2. This is the third preview of IronRuby and IronPython running under the Dynamic Language Runtime that is built directly into .NET 4.0. As before, this release allows you to use IronRuby objects and types as .NET 4.0 dynamic objects from within C# and Visual Basic code. These binaries are roughly equivalent to the functionality found in IronRuby 0.9 and IronPython 2.6 RC. Take a look at Harry Pierson’s blogpost about this release as well, especially if you’re more into snakes than gemstones.

Here's a small example showing just how powerful the new dynamic feature is for taking advantage of dynamic language functionality in statically typed languages:

Here is the IronPython version as well. It basically loads up the desired scripting engine (in this case, Ruby), loads a script, instantiates the “Mock” class defined in the script, and calls a method on an instance of “Mock” which the C# compiler cannot possibly know of; the Mock class dynamically responds to any method call with a random result. The “dynamic” keyword indicates that the C# compiler should use the DLR to dispatch method calls at runtime, rather than trying to validate the method calls at compile time. This enables a very clean integration between dynamic languages and static languages, and even gives you the ability to define your own dynamic objects. Chris Burrows has a great blog series on how C# “dynamic” works.

Try it out

To try out this release:

Install NET 4.0 Beta 2 or Visual Studio 2010 Beta 2
Download either IronRuby or IronPython
Follow any of the many dynamic walkthroughs online. This would be a good start.

Build from source

To build IronPython or IronRuby for .NET 4.0 Beta 2 from source, get the sources from:

IronPython: CodePlex
IronRuby: GitHub (direct download)

Note: use the "v4" build configurations.

Caveats

Being a “preview” release, these releases haven’t gone through the usual testing that the normal binary releases go through. However, both IronRuby and IronPython will be supported on .NET 4.0 when it ships for real. Also note that the these releases will run only under .NET 4.0 Beta 2.

There is no project-system integration between IronRuby and IronPython in Visual Studio 2010 Beta 2, so don’t expect to find File->New Project->IronPython or something like that; this release is just about the integration between .NET 4.0 and DLR-based languages. If you’d like that to not be the case, please continue to let Microsoft know that on the open http://connect.microsoft.com issues for IronRuby and IronPython Visual Studio 2010 integration.

If you find any issues, please report them on the language’s respective CodePlex sites (IronPython | IronRuby).

IronRuby 0.9 Released!

noreply@blogger.com (Jimmy Schementi) — Sun, 02 Aug 2009 00:54:00 +0000

I'm pleased to announce a new release of IronRuby: 0.9!

Download IronRuby 0.9

You can also get the source code for this release

It’s been a long ride since IronRuby was announced at MIX ‘07, but now all eyes are focused on getting it to 1.0. The past couple of versions have made vast compatibility and performance improvements, and 0.9 marks the last set of major features that will be added to IronRuby. From now on, all IronRuby languages will be primarily focused on bug fixing and anything else the community deems necessary to call IronRuby a 1.0 release. These improvements be delivered as point-point releases (0.9.1, 0.9.2, etc) until you decide it is ready to call 1.0.

Though IronRuby is breaking away from it’s conference-driven development schedule, this release comes only a week after OSCON 2009 where I talked about using IronRuby with Mono and Moonlight, and scripting open source apps.

What's in the Release?

Library performance was a big focus for this release; basically going though the Ruby Benchmark suite and making sure any obvious slowness was fixed. As I said in my previous post about OSCON, IronRuby is approximately 2x faster than MRI when running the benchmark suite, but in the near future a complete evaluation of IronRuby’s performance will be done and published on the website.

Antonio Cangiano has already published benchmark results between IronRuby 0.9 and Ruby 1.8.6, and things look really good for IronRuby.

On the compatibility front, the Win32OLE Ruby library is now available in IronRuby. This builds on top of IronRuby’s existing COM interop from version 0.5, letting you script any Windows component/application that exposes a COM interface. Though it hasn’t been fully tested yet, this will make things like Watir work on IronRuby.

Lastly, there have been interop improvements with .NET, most notably making Generic types more friendly to all the crazy things Ruby can do to them, and also with other DLR languages, making it really easy to call IronPython from IronRuby.

For more detailed information, please see the CHANGELOG (which includes all commit messages for the release ... not just "syncing to head of tfs")

Want to find out more about the release? Read on:

Calling Python code from Ruby
Win32OLE support
Rubyizing Generics
Some more notable changes
Bugs closed

Calling Python code from Ruby

In an effort to allow Ruby to call Python code easily, IronRuby provides a way to importing files of other DLR languages, giving you access to the DLR scope. Here's a basic usage:

IronRuby#require(path), load(path) allow you to include script files, just like Kernel#require, #load except that they execute the given script against a new Scope and return it, instead of just returning true/false/nil. If the target is an assembly they return the loaded assembly. Keep in mind you can still use Kernel#require, #load to use other language's script files, but if the language requires you obtain an object representing that file (in Python it's called a module) you'll have to get it elsewhere (see below).

There are other methods to help you use other languages from Ruby:

IronRuby#loaded_scripts has also been added to returns a dictionary that holds on loaded scripts and their Scopes, in-case you used Kernel#require to load a script, and need its Scope at a later time.
IronRuby#loaded_assemblies returns an array of assemblies already loaded in the current runtime; though this isn’t needed for DLR language interop it makes sense to include along with IronRuby#loaded_scripts.
IronRuby#globals returns the current ScriptRuntime.Globals scope; this allows you to easily use Python files and work with the modules they define.

Keep in mind these concepts don’t only apply to Python; they can be used with any language that uses first-class scopes.

Win32OLE support

Since IronRuby 0.1 was released we’ve said Win32OLE was not going to be supported, due to the lack of general COM support in the DLR. However, when the DLR implemented a COM binder for the new dynamic feature in C# 4.0, this allowed IronRuby and IronPython to easily implement COM support. IronRuby 0.5 had this support, but in this release we provided win32ole.rb to implement Ruby’s Win32OLE API. Here’s a simple automation example which opens Excel, adds some data, generates a chart, and rotates the chart. taken from the Ruby Pragmatic Programmer’s Guide (aka. the pickaxe book), which now works in IronRuby:

Rubyizing Generics

Note: this feature didn’t make it into 0.9, but it is in the sources and will be part of 0.9.1

IronRuby has great .NET framework integration, so code written with a CLI-based language (C#, VB, F#) can be called from IronRuby, without it feeling like interop. As we work towards a stable 1.0 release and this integration continues to be polished; in this release we most notably made working with generics a bit friendlier to Ruby.

The first improvement has to do with re-opening a generic class. In the past you couldn’t just re-open a generic class and assume anything you added to it would be found on other versions of that generic class (eg. adding methods to List[] wouldn’t have them show up on List[String] and List[Fixnum]). Now the Ruby class corresponding to the CLR generic type definition is a super-class of all instantiations of that type, making this possible:

There's a much more usability improvements to generics and .NET interop in general in this release, so either take a look at the CHANGELOG or keep an eye on the .NET documentation.

Some more notable changes:

Fix to Module#autoload so it doesn’t squash an existing constant
Fix parsing of YAML time strings
Replace DLR closures by a Ruby-specific implementation for performance
Implement StringIO#ungetc – used in ActiveSuppor
Re-implements “tr”, “tr!”, “tr_s”, “tr_s!”. The new implementation is almost 12x faster.
Reimplements “join” to achieve better perf.
Change ComBinder class to internal.
Improves the ExpressionVisitor API
Improves implementation of RubyArray. A loop doing Array#shift is not shifting the entire array content left every iteration.
Add hosting of IronPython to hosting tutorial
Implements interpretation of coalescing expression
Implements Kernel#rand, Kernel#srand.
Improves scope allocation perf.
ironruby tutorial in Silverlight
More fixes to win32ole to get the ADO DBI driver working
String, Array, and Bignum fixes (thanks Daniele Allessandri!)
Explicit x64 support with ir64.exe, and force ir.exe to run in a 32bit process on a 64bit OS.
Implements basic debug views for classes that implement IRubyObject

For more details, see the CHANGELOG.

Bugs closed

Here are all 26 bugs closed since the last release (2009-07-02). You can see more information about each one on CodePlex.

1841 	Rubygems Test Failures in 'hash'
1506 	-X:PrivateBinding does not enable referring to classes that have internal visibility
1533 	Unverifiable code generated by mspec :lang
1678 	ArgumentError when calling System.String..ctor(Char[], int, int)
1211 	Adding a random object to Time which responds to to_f
910 	YAML does not properly deserialize Time values.
1626 	Rubygems failures
964 	overriding unsafe methods
1537 	rand doesn't work collectly
468 	Better error message for running ir.exe on pre-.Net 2.0 SP1
1787 	All-caps .NET method names are mangled strangely
1521 	Access is allowed to internal fields
1502 	alias_method fails for :do
821 	File.expand_path does not support a line number after filename
1509 	Proc.to_s should include line number where the block was declared
1501 	WinForms broken
1400 	$? is not always Process::Status
1345 	load_assembly() should work
1344 	System.Action.new does not work
1306 	Cannot call CLR constructor of builtin type
1184 	public(:foo) does not work correctly for mixed-in methods
1060 	visibility of send :define_method
917 	Passing a Ruby array to a .NET method that expects an IEnumerable derivative fails with GetEnumerator call
783 	Assert in SetMethodBasesNoLock when calling #== on Ruby class inheriting from CLR class which overrides Equals
761 	Wrong behavior when calling redefined methods on object instances
1470 	Can't call the BigIntegerOverload of a method with a DefaultProtocol Attribute on the BigInteger attribute

Enjoy!

Please test out IronRuby 0.9 and let us know if you have any issues. We hope you enjoy this release! Please submit issues to CodePlex and help prioritize features for 1.0.

Technorati Tags: IronRuby,Release,OSCON

IronRuby at OSCON 2009: Mono, Moonlight, and scripting open source apps

noreply@blogger.com (Jimmy Schementi) — Fri, 24 Jul 2009 01:08:00 +0000

Today I’ll be giving a talk at OSCON 2009 titled “IronRuby 0.9”. For any new readers, IronRuby is an Open Source implementation of the Ruby programming language for the Microsoft .NET Framework; it brings the expressiveness of Ruby to .NET, and the capabilities of .NET to Ruby. I’ll walk you through the talk in this post:

Road to IronRuby 1.0
Running the same application on the desktop and in the browser, on most major platforms (Windows, Mac OS, Linux) and most major browsers (Firefox, Safari, Internet Explorer)
Detour – Gestalt: Running Ruby and Python in the browser, again.
Using code written in any C# and Python from Ruby without it feeling foreign.
How IronRuby has improved in the past 6 months, and how you can help IronRuby become a 1.0 quality implementation.

Road to IronRuby 1.0

It’s been a long ride since IronRuby was announced alongside Silverlight at MIX ‘07, but in a few days the 0.9 version will be available, and all eyes will be focused on getting it to 1.0. The past couple of versions have made vast compatibility and performance improvements, and 0.9 marks the last set of major features that will be added to IronRuby. From now on, all IronRuby languages will be primarily focused on bug fixing and anything else the community deems necessary to call IronRuby a 1.0 release. These improvements be delivered as point-point releases (0.9.1, 0.9.2, etc) until you decide it is ready to call 1.0.

But we’ll dive into the numbers and metrics at the end; let’s talk about why IronRuby is useful in your toolkit.

Cross-platform, cross-browser Ruby implementation

Whenever people hear .NET [they first think about a top-level domain, but when in the context of “Microsoft”] they immediately think “Windows”. But Miguel and the Mono team have shown that isn’t reality. They’ve built a open-source implementation of .NET which runs on Linux, Mac OS, and also Windows. They are also building a open-source Silverlight 2 implementation, called Moonlight, allowing Silverlight applications to run on Linux browsers supporting Mozilla’s plug-in architecture; Silverlight 2 runs on Intel Macs and Windows. Since IronRuby runs on .NET and Silverlight, it also runs on Mono and Moonlight. Let’s explore that a bit:

With Microsoft.NET and Mono, IronRuby can run on Windows and Linux (anywhere Mono runs, including Mac OS).

You’ll notice that real Ruby code runs, it’s running on a Unix environment on Mono, and .NET types can be accessed in a Ruby-esk way, even generic types.

Because IronRuby integrates directly with .NET, you can use any existing .NET code from IronRuby. This means that any frameworks, be them Windows Forms, Windows Presentation Foundation (WPF), or GTK(#), can be used from IronRuby because .NET and Mono [respectively] have CLI bindings for these frameworks. Mono even has a Windows Forms implementation that translates to GTK, so the same application can run unmodified on both implementations. Mono only supports the “Silverlight” subset of WPF, which I’ll elaborate on in a bit.

There’s also a tiny subset of .NET which is part of a browser plug-in called Silverlight; Microsoft’s implementation runs on Windows and Mac, in Firefox, Safari, and Internet Explorer (though any browser which supports ActiveX, Mozilla’s, or Safari’s plug-in architecture should work fine, like Opera or Chrome).

The IronRuby tutorial application runs as a WPF desktop application (on the left), as well as Silverlight application (on the right).

Also, Silverlight 3 supports running applications out of the browser, very simply on Windows and Mac OS by right-clicking on the Silverlight application and selecting “Install”.

Through Moonlight the IronRuby tutorial app also runs on Linux:

Mono also supports running Moonlight applications through GTK on the desktop, just as a WPF application would work. While direct support isn’t in current daily builds of Moonlight, Miguel shows how easy it is to make the same code target the browser with Moonlight and the Linux desktop with Mono, just using C# code:

Note: the latest Moonlight stable release will not work for IronRuby, you must install the latest Moonlight build from their build bot: http://sublimeintervention.com:8123/GetFile.aspx?id=11487919

Detour: Gestalt –- Ruby and Python in the browser

My last blog-post talks about a new prototype from the MIX Online Lab called Gestalt, which lets you write Ruby and Python in place of JavaScript – literally in <script> tags. Here’s a very simple example:

It uses Silverlight to do this, so this will work in Moonlight as well.

Dynamic and Static language interop

IronRuby has great integration with the .NET framework APIs, so C#/VB code can be called from IronRuby without it feeling like “interop”. C# can also call IronRuby through the Dynamic Language Runtime (DLR) Hosting APIs. However, in .NET 4.0 dynamic method dispatch is part of C#, so calling IronRuby from C# is just as easy as a C# method call. Being that IronRuby is built on the DLR, it can interoperate with other DLR languages just as easily, so Python and Ruby play along nicely today, and future DLR languages as well.

A simple way to show that capability is by writing a unit test for a class in .NET; let’s pick “Stack”:

As you can see, creating .NET types, calling methods on .NET classes, and all the other language features Ruby has work against .NET types (even re-opening .NET classes).

To show the reverse, lets look at a very simple REPL implementation:

In less than 100 lines of code, you have a program that runs arbitrary Python and Ruby code. The DLR hosting API lets you run dynamic language code from a static language just from strings.

Expanding on these ideas, let us give the experience a upgrade to the 21st century. John Lam has shown this before at TechEd 2009: an editor that can double as a REPL.

Downlaod it here

This seems like a great idea, and it is even better once you start using it. It works like a normal editor, but selecting a block of code and pressing ctrl-e will run the code, showing the output directly below selected code as a comment, and ctrl-enter runs the current line. The code that gets run gets syntax highlighted. There is no need to have up-down-cursor history, as it’s all right there in the editor. If you need to modify something you’ve already run just, just modify it in the editor and re-run it! This integrates the editor-repl experience, making it a very valuable tool.

Note: this is not a new idea by any means, as TextMate does something similar, but no one seems to explain this as an upgrade to your traditional REPL.

Using this editor, it can be integrated into any .NET project as a lightweight way to experiment with adding scripting support. Using the hosting ideas I presented before, an application written in C# could use IronRuby to allow users to write applications against their object model, or extend it at runtime. Here’s a small example of hosting this editor in Witty, an open-source Twitter client running on .NET:

You can get this version of Witty from GitHub.

While it is great that you can so easily add scripting into a .NET application, it ends up exposing the design deficiencies in the application being scripted. In Witty’s case, the Twitter class (T) is very good, but the Window class (U) isn’t in good shape, as there are a ton of methods on the type, and it’s unclear how they should be used to drive the UI. Jon Galloway wants to merge this into Witty, so hopefully some of these refactorings can be made to enable scripting better.

I extend this offer to all open-source .NET/Mono projects – if you want to improve your architecture and add scripting support, please let me know and I’ll help out.

It's worth noting that .NET 4.0, the next version of the .NET framework, C# supports a "dynamic" keyword which will let you call Ruby or Python (or any DLR language) just by using method calls.

Project status

Compatibility is really good at this point. We run the RubySpec test suite, passing at (85%) and the test suites from popular Ruby frameworks, including Rails, Rake, RSpec, and RubyGems, on every check-in, and can run pretty substantial Rails applications. Increasing compatibility bugs will definitely be the focus of the point releases approaching 1.0; mainly based on what you tell us needs fixing.

This upcoming version will boast support for the Win32OLE library, making existing Ruby applications with interact with COM work as they do in MRI, like Watir.

Performance is also in a very good place. This past version has pushed on the Ruby benchmark suite, and now we are >= 2x better than MRI on almost all benchmarks. Those numbers will be published on http://ironruby.info around the same time IronRuby 0.9 comes out. The above image shows that IronRuby (in blue) is normally significantly faster than MRI (in red), except for a handful of cases. The is not the end-all-be-all metric to measuring performance, but it’s nice to see IronRuby continuing to improve here.

In prior releases, Rails startup has gotten dramatically better, going from 80+ seconds in March to ~20 seconds now. Read more about Rails performance is the IronRuby 0.6 release.

Interesting IronRuby usages

Now that IronRuby is approaching 1.0, we're seeing very interesting usages of Ruby with .NET:

AutoCAD scripting -- Kean Walmsley
magic DSL for Windows UI frameworks -- Thibaut Barrère
Automated conversion of an app written in an in-house language (lang runs on FORTRAN77) and MOTIF UI “to” IronRuby and WPF -- Robert Brotherus
Point of Sale application based on WPF, IronRuby and FoxPro -- Nick Rickets

If you know of more interesting usages, please send them my way!

Thanks!

Thanks for reading this far! Keep an eye out on this blog and the ironruby website for the upcoming 0.9 release.

Technorati Tags: IronRuby,OSCON,Mono,Moonlight,Silverlight

Gestalt: Ruby and Python in the browser, again

noreply@blogger.com (Jimmy Schementi) — Wed, 22 Jul 2009 03:06:00 +0000

Today Mix Online Lab released a prototype implementation of Ruby and Python in the browser, named Gestalt. Feeling a bit of de ja vu? If not, you can ignore this post and just see what it’s all about. Regardless, I suggest you read on.

A simple Ruby-based web page using Gestalt would look like this:

Gestalt adds “ruby” and “python” to the languages supported by the <script> tag. You can also include other files rather than writing the code in the HTML page:

My first reactions when hearing about this project was “Holy crap, wow, they got Ruby and Python running in the browser, that’s freakin’ awesome!” But I work on the Silverlight integration with IronRuby and IronPython, already letting you write Ruby and Python in the browser instead of JavaScript. Hmm. Not to my surprise, Gestalt uses IronRuby and IronPython in Silverlight to accomplish this. But damn, wouldn’t it be awesome if this is how the world worked?

For any new readers, IronRuby and IronPython are implementations of Ruby and Python for the .NET Framework, utilizing the Dynamic Language Runtime (DLR).

Gestalt is a effort to show what it would be like if there were other standard languages in the browser, other than just JavaScript. The Mix Online Lab focuses on using Microsoft technology in ways that make non-Microsoft developers interested, so this project is right up their alley. They wanted to showcase the DLR languages in Silverlight as a way of showing how our efforts can make the web a better place.

So what are the difference between IronRuby and IronPython’s Silverlight integration and what Gestalt provides?

Again, you can already make IronRuby and IronPython based applications in Silverlight; Gestalt just puts a new spin on how to do that. IronRuby and IronPython use the XAP file for the application packaging, including script files, and provides a development-tool called Chiron to auto-package the app, providing the edit-refresh experience that is familiar for a web browser app. Chiron is also used to write the package to disk so it can be deployed to any web-server. This model works great for getting new and existing Ruby and Python programs running in Silverlight, as the packaging is transparent to a developer. And it doesn’t fight Silverlight’s packaging conventions, so using Silverlight-specific features will be straight-forward from a DLR language.

Gestalt takes a much different approach using <script> tags, making the integration much more familiar to current JavaScript developers. They also handle all the Silverlight <object> tag stuff in gestalt.js, taking away the need to host Silverlight yourself.

Why Gestalt is interesting to me

The thing that I really like about Gestalt is that Chiron is not needed for development. Just edit the file and refresh the browser. No need to run something in the background generating a XAP file. Gestalt.js detects which languages the page’s <script> tags use, and picks a pre-packaged Gestalt-*.xap file, one for Ruby, one for Python, one for both, and one for none. This means your application could look something like this:

index.html (can contain Python and/or Ruby code)
gestalt/
- gestalt.js
- gestalt-rb.xap
- gestalt-py.xap
- gestalt.xap
- gestalt-x.xap

Very clean. The gestalt directory is just dropped onto your web-server (to be shared among all your applications), and gestalt.js is referenced from your HTML file, and your good to go. No running Chiron.exe, or installing Mono on the Mac to run Chiron.exe. I’m jealous.

So what’s the catch?

While Gestalt is a much simpler to get started writing Ruby and Python applications in the browser, it does not support a major feature of Ruby and Python – accessing something like a file-system. For example, including other files at runtime uses the language’s underlying File access to read the file in and run it’s contents. Ruby uses “require” or “load”, and python uses “import” to do this.

IronRuby and IronPython in Silverlight normally support this, as all file reads are redirected to the XAP file. Since Gestalt’s XAP files are opaque to the the developer, they do not support File access. This is only an issue when you want to use existing Ruby or Python code in the browser. For example, existing code usually has more dependencies, especially into portion of the language’s standard library which is written the language itself. Usually you’d just put these files in the folder that Chiron is auto-xapping for you, and that’s it. However, Gestalt has no way of doing this today.

Making it better

A possible solution is to just cache the contents of <script src> tags, and use the languages path resolution mechanism to test if those files have already been downloaded. If it finds a match, serve the file’s contents. If not, it could either fail fast and say that your missing a <script src> reference, or it COULD download the file synchronously (and still cache it) and display a warning that you are missing a <script src> reference.

Unfortunately, this only works for script files; what if you just want to download a txt file? Having <script src=”foo.txt”> is not going to fly. Maybe using <link> tags could work?

Why can’t we just download them synchronously? No! Though the current bits do have a synchronous downloading mode, it’s only experimental and should not be used in production. Synchronous downloads are significantly slower since only one download can occur at a time. Downloads need to be synchronous since “opening a file” is expected to block until it is complete. Also, IronRuby/IronPython do not support continuations (for good reasons), so the code cannot be “paused” while a file is downloaded, and then be “resumed” when done. And even if they did support continuations (as there is a way to get it working for the very specific case of file access), the downloads would still all occur one at a time, making the loading much slower. So downloading “on-demand” for file reads is not a good solution, and that’s precisely why the browser doesn’t do that today … so let’s not fight it.

Is Gestalt going to always be separate from IronRuby and IronPython?

No! :) While Gestalt’s first release was best to be separate, I’m very interested in merging the ideas Gestalt has back into Microsoft.Scripting.Silverlight … in-fact discussions have already begun on the IronPython Mailing List.

In short, Ruby and Python Silverlight applications are a bit too complex, and Gestalt shows us that it doesn’t need to be that way. Work has already begun to merge Gestalt and Microsoft.Scripting.Silverlight, so play with Gestalt and let me know what you think!

Technorati Tags: IronRuby,IronPython,DLR,Silverlight,Browser,Ruby,Python,dynamic languages

IronRuby 0.6 Released!

noreply@blogger.com (Jimmy Schementi) — Thu, 02 Jul 2009 19:08:00 +0000

The IronRuby team is pleased to announce a new release of IronRuby: IronRuby 0.6!

Download IronRuby 0.6

You can also get the source code for this release

Staying true to our "Conference-driven development schedule," this release is in conjunction with ... wait, there is no conference this time! Just a good ol' monthly release of IronRuby, chock full of awesomeness. And just so happens to be the 4th of July weekend, so hopefully you have some downtime this weekend and can give the new release a spin.

What's in the Release?

Performance has been a major focus to this release, getting startup time quicker and optimizing built-in types. There has been more progress with Ruby compatibility (Cucumber works!) and .NET interop. Silverlight binaries are back in the release, and there are a couple of samples to help you learn IronRuby.

Most of these descriptions are from Tomas's very detailed code review emails, so thanks Tomas! For more detailed information, please see the CHANGELOG (which includes all commit messages for the release ... not just "syncing to head of tfs")

Lazy method compilation
CLR member enumeration
Generic-Method Parameter-Inference
Testing C# with Cucumber
Silverlight building and updated binaries
Samples

Lazy method compilation

Last release adaptive compilation was enabled for IronRuby, which uses a fast-to-start-up interpreter to start up the program, while code which gets run a lot is compiling on a background thread. This gave IronRuby significant performance improvements for large apps like Rails, which has improved startup by 2.5 times.

This release we've added "lazy method transformation" to the bag of startup performance tricks. In IronRuby 0.5, a method was transformed to the DLR AST as soon as it was defined. IronRuby 0.6 postpones the transformation until the first time the method is called. This significantly improves startup time. For example (not NGEN'd):

This has made Rails startup time 30% faster, coming in approximately 20 seconds on my dual-core laptop running Windows 7.

CLR member enumeration

Now methods like Module#instance_methods, etc, include CLR member names. Though it's a lot cooler than that. The array of methods returns contains strings for Ruby methods, and objects of type IronRuby::Clr::Name to represent CLR methods that can be called by either the actual CLR name or a mangled (Ruby-esk) name. ClrName has methods to_s, to_sym, to_str, <=>, inspect, and dump so that it can be used wherever a string can be used. The display string for the name uses single quotes so that you can easily distinguish CLR (dual) names from regular names (plain mutable strings). CLR strings display themselves as single quoted strings, so this fits nicely.

Even cooler, this works well for meta-programming:

A new set of define_method overloads, strongly typed to ClrName, have been added to enable this. They define the real method using the ruby_name and alias it using the clr_name. So both CompareTo and compare_to calls are intercepted.

Generic-Method Parameters-Inference

Thanks to some work by the IronPython team, IronRuby now has parameter inference for generic methods.

This needs some more TLC before it works perfectly, but this lets you use simple LINQ methods from IronRuby.

Testing C# with Cucumber

This release of IronRuby runs the Cucumber testing framework rather well. Try out Cucumber against some C# code.

Given a feature file (this being the addition.feature)

A step_definition file (calculator_steps.rb)

And a DLL:

Cucumber will test the addition feature:

3 scenarios (3 passed)
12 steps (12 passed)
0m0.753s

Silverlight building and updated binaries

This release re-adds Silverlight binaries to IronRuby, contained in the "silverlight" directory of the release. These bits have been integrated from the AgDLR project, and will be maintained in the IronRuby and IronPython source code repositories from now on. The AgDLR GitHub project will redirect to one of those for binaries for both languages in Silverlight. In addition, the SDLSDK CodePlex site will be redirecting to the IronRuby and IronPython CodePlex sites, for downloads, discussion, and issue tracking. AgDLR was a little side project to add new features to DLR Silverlight applications, and play around with Git. I'm very happy to see it merged back in with the languages.

Note: IronPython Silverlight assemblies are included directly in the release. They may be moved out to the separate package that contains IronPython desktop DLLs in the future.

See the integration commit for more information

Another notable change is that you can now build Silverlight binaries out of IronRuby's GitHub repository very easily. Given that you have Silverlight installed at C:\Program Files\Microsoft Silverlight\2.0.40115.0, this will build IronRuby for Silverlight:

msbuild Merlin/Main/Languages/Ruby/Ruby.sln
  /p:Configuration="Silverlight Release
  /p:SilverlightPath="C:\Program Files\Microsoft Silverlight\2.0.40115.0

You can also build IronPython for Silverlight in a similar manner. Aliases for this will be added soon, but if you need a custom build of the DLR languages for Silverlight, this is the way to do it.

Samples

Six samples are included in this release. The first three are desktop samples in the “/samples” directory. The last three are Silverlight samples in the “/silverlight/samples” directory:

Tutorial - An interactive IronRuby tutorial

DiskUse - A small WPF application which visualizes the disk usage for a particular directory

IRPowerShell - a small library and sample applications showing how to interact with PowerShell from IronRuby

Clock – a simple Silverlight sample

Photoviewer – do AJAX programming with IronRuby (ARAX =P)

REPL – Interactive console in the browser.

Some more interesting changes:

Improved DLR Interop: adds support for GetMember/SetMember with method_missing, Binary/Unary operators, and indexers.
Handling of CLR protected and private methods and properties
Reimplemented File.expand_path such that it does not use System.IO.Path.
This allows us to get better compatibility with MRI. The motivating reason was
that RSpec does File.expand_path("filename:linenumber")
Improves the implementation of singleton method dispatch.
These changes improve running time of specs significantly (2x)
Renames Method, UnboundMethod#overloads (plural) to
Method, UnboundMethod#overload (singular).
The old name is still available for now and throws an exception.
Implements adaptively compiled rules
Improves performance of Array#- from quadratic algorithm to linear.
Improves implementation of RubyArray

Bugs closed

Here are all 37 bugs closed since the last release (2009-05-19). You can see more information about each one on CodePlex.

1521  Access is allowed to internal fields
1502  alias_method fails for :do
821   File.expand_path does not support a line number after filename
1509  Proc.to_s should include line number where the block was declared
1501  WinForms broken
1400  $? is not always Process::Status	
1345  load_assembly() should work
1344  System.Action.new does not work
1306  Cannot call CLR constructor of builtin type
1184  public(:foo) does not work correctly for mixed-in methods
1085  Cannot call new on subtypes of builtin classes whose "new" method has optional arguments
1060  visibility of send :define_method
917   Passing a Ruby array to a .NET method that expects an IEnumerable derivative fails with GetEnumerator call
783   Assert in SetMethodBasesNoLock when calling #== on Ruby class inheriting from CLR class which overrides Equals
761   Wrong behavior when calling redefined methods on object instances
1470  Can't call the BigIntegerOverload of a method with a DefaultProtocol Attribute on the BigInteger attribute
1426  The located assembly's manifest definition does not match the assembly reference. (ctp dev10 beta1)
1441  Error with cyrillyc text in Sharepoint	
1352  Test Defects	
814   Allocator underfined for  (TypeError)
572   Error when running Cucumber examples with IronRuby
718   IronRuby ignores RUBYLIB environment variable
727   to_proc not working
1351  redist-libs should have rubygems-1.3.1	
466   ''.split(//, -1) returns [""] instead of []	
940   Can't inherit from abstract classes	
1028  Missing conversion from Duration to Fixnum (ActiveSupport)?
374   irails Foo: undefined method for OpenSLL::Random.random_bytes
459   throw FileNotFoundException => rescue Errno.NoEntryError
499   Pathname#cleanpath messes up the pathname
467   "igem install rails" fails
375   "ir script\server" causes a YAML parser error
461   Generic type conversion from Fixnum to Integer
674   autoload does not use File::SEPARATOR
1021  Time class instance
578   yield fails in eval'd code
605   Array#hash should properly handle recursive arrays

Enjoy!

Please test out IronRuby 0.6 and let us know if you have any issues. We hope you enjoy this release!

-- The IronRuby team

Technorati Tags: IronRuby,Performance,Cucumber,Testing,Silverlight,Release,Ruby

Simple Python testing in Silverlight with unittest

noreply@blogger.com (Jimmy Schementi) — Mon, 29 Jun 2009 07:55:00 +0000

Since doing a post about Ruby testing of Silverlight applications, I’ve felt a bit guilty about leaving Python fans in the dark. However, like Ruby, it takes very little work to run Python unit test frameworks in Silverlight, since IronPython is a very compatible implementation of Python. Though my results aren’t as exhaustive as the IronRuby examples, here’s one simple example:

http://github.com/jschementi/europycon2009

zip download

The original example is from the Python website’s unittest documentation. Very little bootstrapping is required to get this running in Silverlight; this is u1.py code that is the start-script for the Silverlight app, which runs the tests:

I did have to make a modification to unittest.py; removing a call to sys.exit since Silverlight doesn’t support that, and just returning the exit code.

There’s also a GUI test runner (http://pyunit.sourceforge.net/pyunit.html#GUI), so it might be interesting to port that to Silverlight to get a nicer test run graphic along with the console, but it’s great that the REPL enables this to just work =) It also helped me find some bugs with the REPL, which will make their way to the IronPython source code shortly.

Let me know how it works for you. The next step is to tackle testing Silverlight C#/VB apps with Python.

Technorati Tags: IronPython,Testing