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!
7 comments:
Haha, my screenshots have Powerpoint's red squiggles in them ... my bad!
How come there you never see ironruby and rails in the same sentence (apart from this comment obviously).
I see this as great potential for ironruby but all I ever read about is ironruby being used for silverlight asp.net mvc or embedding the language.
I am really let down by this. Rails is such a productive environment but it seems it is not a focus for the ironruby team.
Those of us who want rails will just have to jump to a non windows platform.
@Paul Maybe you're just not looking hard enough:
http://ironruby.net/documentation/rails
http://weblog.rubyonrails.org/2009/8/11/community-highlights-ironruby
http://weblog.rubyonrails.org/2009/8/11/community-highlights-ironruby
IronRuby is in a interesting position as it brings together two groups of people; .NET developers that are interested in Ruby, and Ruby developers that want better Windows integration. Being that IronRuby is funded by Microsoft, we do tend to sell ourselves to the .NET crowd more, buts it's definitely not exclusively.
Keep in mind that the IronRuby team consists of three core members. As of late our focuses have been on performance and releasing 1.0. Running Rails well is useless if you're going to do it poorly. Actually, I'm a little disappointed no one in the Ruby community has stepped up and taken ownership of IronRuby running in Rails ... especially if it's so important.
The reality of it is that I don't see anyone taking a real good look at using IronRuby until we release the 1.0. Also, it's been only as of late that IronRuby running Rails can be something realistically deployed on Windows, rather than just a demo.
In short, either give it time, or donate your time to make it happen faster.
That 3rd link should be this:
http://blog.jimmy.schementi.com/2009/05/ironruby-at-railsconf-2009.html
Hy Jimmy,
Im trying to make the download of dlls to happens just one time for all the sites that uses ironruby. There are a lot of Mb to download, and i cant convince my people that is a good choice. Are you already try something like this? Im trying to use iframes or hidden textboks ... Do you have some tip?? Its very sad to the ruby community ironruby not to be included in siverlight plugin.
But thankyou very much for your work man, im your great fan from brazil.
Tcha-Tcho
This is great stuff, Jimmy. Congrats! Despite what may seem a lack of community support, I think that will begin to change. As I'm sure you know, most MS devs have come to expect MS tools to require several releases before they are ready. I think you will find a lot of surprise and more support once people actually start using IR. Keep up the great work!
@testesmeufoco: Yes, you can download the IronRuby binaries apart from the actual application, which are then cached by the browser, and are not downloaded again unless they are updated on the server.
The easiest way to do this is to depend on the new dlr.js which will set up a Silverlight control all for you, and only download the binaries as needed; here's the latest documentation, and some simple samples.
If you want to keep your current setup, you can just tweak the "externalUrlPrefix" setting in Chiron.exe.config to be an absolute URI pointing to where IronRuby's slvx files are hosted ... a slvx file is simply a ZIP file with DLL's inside it. We don't include these files in IronRuby releases as they are hosted online (per the documentation I linked to above). However, the docs describe what SLVX files are needed and what their contents should be.
Another way, which might be a tad simpler for you, is to just use the same XAP file for the entire site, with different start scripts for each "app" (html tags omitted because Blogger is paranoid about them):
!-- foo.html --
param name="source" value="app.xap"
param name="initParam" value="start=app1.rb"
!-- bar.html --
param name="source" value="app.xap"
param name="initParam" value="start=app2.rb"
Let me know if you have any more questions
Post a Comment