What are you going to use RubyCLR for? - John Lam on Software

About me

What are you going to use RubyCLR for?
- 6 Apr 2006
- 8 Responses
- views
- Edit
- Delete
- Tags
- Autopost
Wow. I just had to reproduce this comment from Fatih Orhan here:

Looking really nice. So with ability to inline C# (and JScript.NET), i can design forms in VS.NET IDE, inline some Designer generated code in my beloved Ruby and bind some events to it. oooh i can’t wait :) when can we get it? And thank you for this, you filling a very needed gap with your bridge (eheh), i appreciate that. sorry if parts of this message didn’t make sense, english is not my native language.

So this may be a surprise to Fatih, but I didn’t consider this scenario when I implemented this feature. Really. I just wanted to impress my friends who read my blog, and it was a pretty simple and straightforward thing to implement. But thanks to Fatih, I now realize that this is absolutely the killer feature in RubyCLR. On the train ride home, I figured out some other cool ways of extending the inlining functionality to make this an even better experience.

For everyone else: please don’t be afraid to leave comments or send email to jlam at this domain about how you intend to use RubyCLR. A lot of times I’m so buried in implementation details that I can’t see the forest for the trees anymore.

As for scheduling: I’m teaching this week so that means that work on the bridge is pretty much at a standstill. The major features that I’m planning for the next drop are: .NET language inlining and interface implementation. I’m planning on shipping that drop the week of April 24 (or earlier if I can finish implementing those features).

Thanks to everyone for all the continued support and encouragement; it’s very much appreciated!
- 8 responses
- Like
- Comment
almost 6 years ago Michael Trier responded:

Timing is funny these days. I was actually drafting you an email about this very subject. I didn't know if there was any kind of hit with doing it this way, as opposed to doing it all on the Ruby side. Mainly I'm just lazy. My first thought was that it would be easy to create a generator that would take the .NET stuff and transcode it, but then I thought of this. Does functionality remain the same?

almost 6 years ago John Lam responded:

The functionality should remain the same. This lets me bootstrap windows forms programming (and eventually XAML / WPF programming) much faster than creating a CodeDom serializer for Ruby.

almost 6 years ago Pete McKinney responded:

I've been using RubyCLR to provide forms for simple ruby programs. I use the forms designer in Visual Studio to create a form with no functionality behind it. Then I go in and make all the components public. Then I have a simple assembly that I can require in my ruby program and attach events to.

almost 6 years ago John Lam responded:

Pete - will the ability to just ship the C# source code files be an advantage over compiling your own forms into an assembly and shipping the compiled assembly?

almost 6 years ago Matt responded:

So when are you going to become a Micrsoft employee :) The Ruby work you are doing has to be one of the coolest project blogged about currently in the CLR world. I'm sure Jim Hugunin (http://blogs.msdn.com/hugunin/) must be knocking at your door

almost 6 years ago John Lam responded:

Thanks for the encouragement, Matt! Now that I've welcomed the newest addition to my family (MacBook Pro) I can get back to the more serious business of shipping drop 4.
As for MSFT, I'm perfectly happy where I am now. But if they make me an offer I can't refuse ... :)

almost 6 years ago Sam responded:

I used RubyCLR to write a process that hands off data to a SqlBulkCopy for quick inserts into the database. It's fast. It's simple. Since most of it's in Ruby, I can actually wrap my head around the overall design.
Thanks!
The only major pain I had was this:
dt = System::Data::DataTable.new
@column_names.each { |column_name| dt.Columns.Add(System::Data::DataColumn.new(column_name.to_s)) }
@data.each do |elements|
row = dt.new_row
@column_names.each_index do |i|
value = elements[i]
unless value.nil?
row[i] = value.to_s
end
end
dt.rows.add(row)
end
Since I couldn't figure out how to pass NULL (and nil didn't seem to work), it eventually occurred to me (after about an hour :o ) to just avoid setting those fields.
Knowing how to pass a NULL would've made it easier, but I'm more happy with the final result, so win-win I guess. Thanks again for the work!

almost 6 years ago John Lam responded:

Sam, thanks for this bugrep. I beefed up the marshaling code to correctly account for NULL values. The current builds now work correctly with nil values. I don't account for CLR V2 nullable types yet, but that's on the list :)

Archive
- 2011 (4)
  - February (1)
  - January (3)
- 2010 (13)
  - December (12)
  - November (1)
- 2009 (5)
  - December (1)
  - November (1)
  - May (1)
  - January (2)
- 2008 (30)
  - October (1)
  - September (2)
  - July (1)
  - June (2)
  - May (1)
  - April (2)
  - March (9)
  - February (8)
  - January (4)
- 2007 (59)
  - July (4)
  - June (16)
  - May (23)
  - April (2)
  - March (6)
  - February (4)
  - January (4)
- 2006 (214)
  - December (2)
  - November (2)
  - October (8)
  - September (12)
  - August (34)
  - July (29)
  - June (23)
  - May (34)
  - April (15)
  - March (23)
  - February (23)
  - January (9)
- 2005 (46)
  - December (22)
  - November (17)
  - October (7)
Get Updates

Subscribe via RSS

Twitter