When the abstractions need to be bailed out

April 27, 2006 17:30:29.299

Less is better is having adventures pusing Ruby onto the CLR:

I should have known better, but I failed to account for blittable vs. non-blittable value types in RubyCLR. I explicitly avoid boxing value types in RubyCLR by blitting the value type into memory that I explicilty allocate for the Ruby object. All of my value type marshaling tests were done on sequential layout types such as Point whose layout in managed memory is the same as they would be in unmanaged memory.

Do you get the idea that putting a dynamic language onto the CLR is kind of like trying to dress up a pig? The pig is still ugly after you're done, but it's annoyed.

Comments

It's hard work, but someone has to do it :)

[John Lam] April 27, 2006 20:32:32.153

It certainly is hard trying to get interop working. But I'm not actually running Ruby code in the CLR - it still executes in the Ruby interpreter. Instead I marshal types back and forth across the interop boundary (all in-process) and do conversions where appropriate (e.g. there is no data loss). So this way Ruby is still Ruby, and the CLR is still the CLR. I just enable you to get access to the platform libraries that are hosted on the CLR.

But RubyCLR is a very high-fidelity interop layer. I respect ruby_naming_conventions and ClrNamingConventions as a simple example. I also let you interop very nicely by letting you implement CLR interfaces in Ruby, and handling the dirty work of setting up all of the interop shims that are required to support that scenario.

Salty Pcikle

[ anonymous] April 27, 2006 22:21:41.732

Comment by anonymous

How does this compare to how the Salty Pickle Ruby.Net Bridge works?

I haven't used the Ruby one but the Squeak version maked .Net almost pleasurable to use.

RubyCLR vs. SaltyPickle

[John Lam] April 28, 2006 7:58:26.277

It's similar in spirit to the SaltyPickle Ruby and Squeak bridges. But how it does things is very different. The SaltyPickle bridge uses Reflection to invoke / marshal across the interop boundary whereas I dynamically create IL shims using CLR V2's DynamicMethod facility. This gives RubyCLR roughly a 1000X perf boost vs. their bridge. Also, I spend a lot of time making the CLR *feel* like Ruby, which is important. There's attention to detail such as making IEnumerable types in the CLR mixin the Enumerable module in Ruby so that Ruby idioms such as obj.collect() just work.

I don't know Smalltalk, so I have no idea how to make it work. But hey, RubyCLR is open source under the MIT license and you have the source for the SaltyPickle bridge - presumably it wouldn't be all that hard to do a port (but of course the devil's in the details :).

Re: When the abstractions need to be bailed out

[ Michael Lucas-Smith] April 28, 2006 11:33:48.325

Comment by Michael Lucas-Smith

I always thought Miss Piggy was kind of cute