Ironing code, geek t-shirts and even presentations!


Do You Want IronRuby/IronPython Support in Visual Studio 2010?

I know I do. If you want too, please rate and vote up the suggestions on the Microsoft Connect site:

IronRuby VS Integration:

IronPython VS Integration:

Yes we can!

WinForms in IronRuby

IronRuby holds so much potential. I can say from my perspective, that since I’ve been playing around with it, I became more and more enthusiastic about it and sure that it’s going to succeed big time.

However, IronRuby still has a few drawbacks. They focus mainly on the the lack of Visual Studio support and its side-effects. WinForms is one of the technologies that suffer from this shortcoming. Do you expect me to develop WinForms without the precious designer? I know everyone has their love-hate relationship with the VS designer, but taking it away entirely is just too much to handle.

Well, that’s what I’m here for - to hand you a solution!

I’ve written an IronRuby script (actually, it will run on MRI as well) that will convert a winform designer code (C# only currently) to IronRuby code. By using the script, you can use the VS designer and create the form you want. After you’re finished, run the script and voila – you have all the designer code in IronRuby code!

I won’t explain the code here (maybe I’ll write another post about it, not sure) but in short, it uses regular expressions to find several C# things and replaces them to ruby things…

The file

The ruby source file can be downloaded from here.

(if someone is willing to help me uploading it to GitHub, please do :) ).

How to use it?

First, you need to load the ruby library. The file is named “win_forms_converter.rb” so just start by requiring it:

require “win_forms_converter.rb” # Assuming it appears within the current directory

The library contains one single method accessible from WinFormsConverter.convert_winform. The method receives three parameters:

  • designer_file – the path to the form designer file. For example, C:\Dev\WinForm\Form1.designer.cs.
  • target_file – the path of the new IronRuby file. For example, C:\Dev\IronRubyWinForm\Form1.rb.
  • target_main_file – optional parameter. The path of the form runner file. If this parameter exists, a file will be created on the given path that executes the created form. For example, C:\Dev\IronRubyWinForm\main.rb.

REPL Example

This is a sample command prompt session for converting a WinForm to IronRuby and run it:



D:\>cd demo

IronRuby on .NET 2.0.50727.4016
Copyright (c) Microsoft Corporation. All rights reserved.

>>> require  "win_forms_converter.rb"
=> true
>>> WinFormsConverter.convert_winform('Form1.designer.cs','D:\Demo\IR\form1.rb','D:\Demo\IR\main.rb')
Converting designer file from Form1.designer.cs
Creating IronRuby file at D:\Demo\IR\form1.rb
Creating main file at D:\Demo\IR\main.rb
Conversion is finished.
=> nil
>>> exit

D:\Demo>cd IR

D:\Demo\IR>ir main.rb



This is the very very first version of this convertor. I haven’t tested it deeply and I’m kind of freeing it to the wild so you people can take it and make it much better.

If you need any explanation about the source  code, you have comments, you’ve found bugs or whatever, you’re welcome to contact me via the contact page or via twitter @ironshay.

Hope it helps,
All the best,

New IronRuby and IronPython Versions

Good news! IronRuby and IronPython have just been released with new and shiny versions!

IronRuby 0.5

  • Download IronRuby 0.5
  • Adaptive compilation – performance boost!
  • Removes ClrString. CLR strings are referred to as System::String
  • Removes IronRuby library. "require 'IronRuby'" is no longer needed; IronRuby module is now a built-in module.
  • Integer/Float operations for all CLR primitive numeric types
  • System::Char and System::String methods so that they behave like an immutable UTF-8 encoded string
  • Improves handling of BOM in 1.8 mode
  • Debugger visualizer for RubyObject so that VS will display the result of to_s in the Watch window.
  • Adds support for .NET operators (op_* special methods)
  • Implements bitwise operators on flag enums
  • Precompilation of simple Ruby method invocations
  • Improves performance for file IO#read method. Previously we were 10x slower than MRI, now we are approx. 1.5-times faster.
  • Tons of fixes to File, String, Array, and other built-in types to drive up RubySpec and Ruby application test-suite pass-rates. One bug fix is mine!
  • For a detailed description, read Jimmy’s blog post:

IronPython 2.6 Beta 1

.Net 4.0 CTPs

With the release of VS2010, new IronLanguages CTPs came along. These CTPs make calling dynamic languages from C# 4.0 a very easy task. Give it a try:

IronPython 2.6 CTP for .Net 4.0 Beta 1

IronRuby CTP for .NET 4.0 Beta 1


We’re living in exciting times guys!

All the best,

kick it on  Shout it

IronRuby Journey Update #1 – Establishing The Silverlight Environment for IronRuby

OK, so I’ve started up my project to port a Silverlight application from C# to IronRuby. The special thing about this app is that it also makes some webservice calls, something that isn’t as obvious as it is in C# - you don’t have the wsdl tool to create the proxy class for you.

Well, Ruby is a fun language to code in so I’m sure that the lack of a few things here and there will not be much of a problem (I’m sure some of you nod your heads with a “yea right” look on your faces :) ).

Step #1

The first thing I needed to do was to be able to use IronRuby with Silverlight. This is done by the agDLR project which is a pack of tools to help you integrate Silverlight and the DLR. agDLR version is currently 0.5 which means it’s still a beta version and hopefully will improve until V1. It currently supports Silverlight 2 and Silverlight 3 beta.

I downloaded it – first task is done!

Step #2

Next I needed to create an IronRuby-driven Silverlight application. Among the agDLR files, there is a tool named SL. This is a command line tool that generates a simple Silverlight application with code files written in the selected dynamic language (Ruby and Python are supported). You will find it under the scripts folder where you extracted the agDLR files. The command line parameters are simple:

sl [ruby|python] <ApplicationPath>

Running it looks like that:

Running agDLR SL tool

After the tool is done, it generates a folder with the needed files to start with:

  • D:\IronRuby\WeatherWidget
    • \app
      • app.rb
      • app.xaml
    • \css
      • screen.css
    • \js
      • error.js
    • index.html

I have the project files ready – step #2 is complete!

Step #3

Trying to browse to the index.html file that sl has generated for us will not take us to where we want. We  will simply hit an error telling us that the silverlight file could not be downloaded. This is because the index.html file looks for app.xap, which wasn’t generated by the sl tool.

This is when the Chiron tool comes to our aid.

In the Greek mythology, Chiron was a very wise and kind centaur (a man-horse combination) and the teacher of many heroes like Asclepius the God of medicine, Theseus the legendary king of Athens and the greatest warrior Achilles.

In 2009, Chiron is a local web server which runs directly from the command line. It dynamically generates the silverlight xap file from your dynamic language code. You can run it by using the server.bat file that is located under the scripts folder. Chiron has various different startup options which you can view if you execute it with the /? switch: server /?.

In order to run the Silverlight project, you need to run server /b from the project directory (which means you need it on your PATH list) or by passing the directory using the /d switch. I went on and created a batch file to start the server automatically from the project directory, the batch file has a single line inside:

d:\IronRuby\agdlr-0.5.0\script\server /b /d:d:\IronRuby\WeatherWidget

So now all I need to do is run my batch file! Running it starts the web server on port 2060 and opens the browser with the directory listing:

Browser after running Chiron


Looking at the command line, you can see what chiron has fetched:

Chiron running

Clicking on the index.html file will show you the default Silverlight application that sl has generated for us. It has a built in console where you can write IronRuby code and see the changes live (awesome!):

Default agDLR silverlight application

OK – the environment is ready! step 3 is done.

Update #1 Conclusion

Well, I’ve got to say, this wasn’t easy. I think that this process of establishing the Silverlight environment revealed the Achilles heel of the current status of Silverlight and DLR languages. The process is not even nearly as intuitive and fluent as the C# process from Visual Studio (this whole post would have been one line if it was a C# tutorial – choose New->Silverlight Application and click OK).

.Net programmers have gotten used to intuitive, rich and fluent work process which obviously will not be what they’ll get with DLR languages currently.

I guess that these issues will improve with time. Currently, Microsoft spends time on the core things and not on the nice-to-have things. After IronRuby, IronPython and the DLR core development is done, Visual Studio integration will follow.

For me, I’m not planning on giving up. I really believe in these languages and the great things they bring to the programming world.

Stay tuned!

All the best,

Share: DotNetKicks | DotNetShoutout | DZone

IronRuby Journey Update #0

Well, the journey is going very slow… But I wanted to let you know that it’s on!

This is update #0 and not #1 because it’s an update. I’ve decided to help the community with this journey, so instead of writing VS integration, I’ll be writing a Silverlight weather widget that uses web services for fetching data.

I even appear on the IronRuby Wiki as a contributor:

I'm an IronRuby Contributor! Woohoo!


I have already started and I have some insights about doing Silverlight stuff with Iron languages. This is going to be the content of update #1.

Stay tuned,

An Invitation To My IronRuby Journey

I’ve just realized that I’ve been preaching about IronRuby and the DLR - telling you to use it, showing you how, but I’ve never deep dived into it by myself. So I’ve decided to go deeper and examine IronRuby in “real life” situations. I want to run into its rough edges, write workarounds, feel the engine.

How far are we from V1? Is 0.3 really 70% far from being complete? from being ready to use?
I’m planning to find out the answers in the tough way – by getting my hands dirty!

IronRyb Journey You’re probably wondering how I’m gonna do that. Well, it’s simple – I’m going to take ideas and develop them entirely in IronRuby. I will write here about my experience and share my thoughts, critic, successes and failures.

My first idea I’m going to work on is an ironic one – An IronRuby Visual Studio Integration.
The target is to achieve a simple code coloring ability and an auto-completion mechanism for IronRuby inside VS.

If you have more ideas for the rest of the journey, please let me know!

Off we go!


Getting Started with IronRuby

The web is filled with lots of resources about Ruby and .Net. It does lack of resources about the combination – IronRuby. I’m sure this will get better as time goes by and official releases are out the door.

Here I’ll try to gather the most effective resources for you so your entrance to the IronRuby world will be smooth and enjoyable.

IronRuby resources

  • – the official site and a great place to start.
  • IronRuby Mailing List – THE place to ask questions (look here if you prefer to watch it in a forum view).
  • GitHub site – IronRuby code repository on GitHub.
  • GitHub wiki - How to get, build, debug and contribute to the IronRuby source.

IronRuby Related Blogs

For .Net developers – Ruby resources

For Ruby developers - .Net resources

If I have missed something, please comment or contact me and I’ll add it!

Enjoy IronRubying!

Share: DotNetKicks | DotNetShoutOut | DZone

Tip: How To Use Generic .Net Classes in IronRuby

In the latest version of IronRuby (0.3), the ability to use Generic .Net classes was added. I couldn’t find anywhere how to do that so I dug it out of the code and now I’ll share it with you!

Example #1 - List

This is how to define an Int32 list, add two numbers to it and print them:

list = System::Collections::Generic::List[System::Int32].new

list.add 4
list.add 12

list.each { |x| puts x }

Of course we can also use Ruby type like Numeric, String, etc.

Example #2 – Dictionary

This is how to declare a number-string dictionary, add values to it and print them:

dict = System::Collections::Generic::Dictionary[Fixnum, String].new

dict.add 1, "Hey"
dict.add 15, "There"

dict.each { |x| puts "#{x.key} - #{x.value}" }


All the best,

IronRuby 0.3 Has Been Released!

Great news! As Jimmy Schementi describes it – the “conference-driven development schedule” of IronRuby brings us some news for the MIX09 conference. It’s the 0.3 version of IronRuby!

IronRuby 0.3 is out!

So what’s new in 0.3?

  1. IronRuby now passes 10% more of the RubySpec than v0.2 has. Make sure to check in order to get up-to-date statistics.
  2. Better .Net interoperability – you can now call generic methods and implement interfaces!
  3. More! you can read about all changes in the CHANGELOG.txt file that you’ll find in the zip.

Grab it:


Make Your Application Extendable Using the DLR

It’s very common for applications to have a way to extend them. Extensibility comes in various ways and have multiple names too – plug-ins, add-ins, addons, etc. It seems, though, that one kind of extensibility was left to the very few – application macros.
The concept is very simple – You don’t need to create a special Dll, implement a specific interface and register it somehow, you don’t even have to install an IDE. All you have to do is to open the relevant window, write some code and voila – you’ve extended the application.

What is this post about?

I’ll start with the result.
I built a simple application – it has a textbox, a “Send” button and a larger textbox for the application output. The flow is very simple – the user writes text in the textbox, hits “Send” and a “Hello” message appears in the larger textbox:

Extending Applications using the DLR - Sample #1

The power lies in the button on the bottom of the form - “Extensions”. Clicking there will open the extensions dialog, where you can write a macro which will be run after the user clicks “Send”. The users can choose the language for their macro, which will be one of the DLR’s languages – IronRuby or IronPython. After the user writes the code and hits “Save”, the application is extended!

Extending Applications using the DLR - Sample #2


Now when the user clicks send, look what happens:

Extending Applications using the DLR - Sample #3

This sample is very simple but it took me about 20 minutes to get it done. It’s just magic!

How was it done?

Well, all the credit goes to the DLR. This amazing little thing, makes it soooo easy to integrate dynamic languages into the .Net environment, that it’s a shame not to do so.

The heart of this application is the ExtensionRunner class and its Run method:

public static bool Run(Form1 frm, string code, bool rubyCode)

The method receives 3 parameters – the form object to pass to the executed code, the code that the user has written and a boolean value indicating whether it’s ruby or python code.

Firstly, I declare a ScriptScope and a ScriptEngine variables and fill them with the chosen language implementation. Because all DLR languages implement the same interfaces and classes, this is the only language-related code here. After that, the code will fit every DLR language. This means that adding IronScheme and Nua here, for instance, will be a matter of seconds:

scope = null; ScriptEngine engine = null; if (rubyCode) { engine = Ruby.CreateEngine(); scope = Ruby.CreateRuntime().CreateScope(); } else { engine = Python.CreateEngine(); scope = Python.CreateRuntime().CreateScope(); }

Now we declare variables that the macro code will be able to use. We declare 2 variables:

  • frm – which is the form object. you wouldn’t want to do that in your application, the right way will be to pass a class with targeted functionality for the extensions.
  • return_value – the extension will put a value here. It’s a boolean value which indicates whether we should continue with the regular flow of the application after the extension has been executed or stop.

"frm",frm); scope.SetVariable("return_value", false);

The rest of the code is pretty straight forward – I create a ScriptSource object from the given code and execute it. Then I get the return_value value and return it to my main application.

// Run the code!
ScriptSource source = engine.CreateScriptSourceFromString(code, SourceCodeKind.Statements); source.Execute(scope); // Get the return value bool retVal = scope.GetVariable<bool>("return_value"); return retVal;

This is it. The other code of the application is just a regular WinForms code so I won’t deep dive into it.


In conclusion, the DLR makes it very simple to run dynamic languages from your .Net code. I showed you here only one of the possibilities that are made available with this kind of integration.

Go ahead and try!

Download the source code

All the best,

Like it? Share it: Loves soccer? Kick it  | Angry? Shout it  | In DA ZONE? DZone it