- Posted by Shay Friedman on May 21, 2009
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: http://blog.jimmy.schementi.com/2009/05/ironruby-05-released.html
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,
Shay.
- Posted by Shay Friedman on May 9, 2009
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:
After the tool is done, it generates a folder with the needed files to start with:
- D:\IronRuby\WeatherWidget
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:
Looking at the command line, you can see what chiron has fetched:
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!):
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,
Shay.
Share: DotNetKicks | DotNetShoutout | DZone