ANN: Third Drop of RubyCLR


#1

This is the biggest release so far of the RubyCLR bridge:

http://www.iunknown.com/articles/2006/03/16/third-drop-of-rubyclr

Here’s a brief summary of the current feature set of the bridge:

  • Reference .NET assemblies by assembly name or by filename
  • Create and manipulate .NET reference and value types
  • Automatically marshal .NET reference and value types to / from Ruby
  • Dynamic generation of interop code using CIL instructions
  • Create and manipulate generic .NET reference types
  • Discover and consume .NET interfaces on a .NET object
  • Implement .NET event handlers using Ruby blocks
  • Map .NET member names to Ruby names (e.g. WordCount becomes
    word_count)
  • Mix in Ruby Enumerable support for .NET IEnumerable types
  • Dynamically access .NET XML documentation from irb (requires
    text/format â?? to make it work uncomment require in rubyclr.rb)

There is now a pretty cool Avalon (Windows Presentation Foundation)
sample
in this release. It renders math equations from a quick and dirty Ruby
DSL
that I hacked up yesterday. I think it really shows off some of the cool
things you can do when you have a powerful client-side rendering engine.
You
can see a screenshot here:
http://www.iunknown.com/articles/2006/03/15/rubyclr-and-avalon

I did a lot of perf tuning in this release, so dynamic compilation time
of
the interop shims should be much faster. Runtime performance is pretty
good

  • I can parse a 7.5MB XML doc using XmlTextReader (a pull-mode XML
    parser)
    which results in over a million calls across the interop boundary in
    about
    2s.

Comments / flames / suggestions / contributions are always welcome.

Cheers,
-John
http://www.iunknown.com


#2

Sound like this is really coming along. I wonder does the project have
a web page of its own?

An aside… but I was wondering if you could tell me exactly what a
…NET assembly is.

Thanks,
T.


#3

The project will migrate over to rubyforge between now and the next
release.
It will also get its own page then so that folks can more easily find
stuff
than having to read my blog or look at my RSS feed.

In Windows, we deploy code usually as .EXE or .DLL files (which are both
encoded in the Win32 Portable Executable file format). A .NET assembly
is
how we deploy .NET code. Usually an assembly is packaged as a .EXE or a
.DLL
file, but it can be much more than that (multi-file assemblies are
sometimes
found in the wild).

Cheers,
-John
http://www.iunknown.com


#4

John L. wrote:

This is the biggest release so far of the RubyCLR bridge:

http://www.iunknown.com/articles/2006/03/16/third-drop-of-rubyclr

Sounds great, John. I can’t wait to start playing with it this weekend.

Jeff
www.softiesonrails.com


#5

Hi Trans

An aside… but I was wondering if you could tell me exactly what a
.NET assembly is.

a .NET assembly is what you get when you compile a .NET (C#, VB.Net…)
language into binary form.

cheers

Thibaut


#6

Thanks Thibaut. So they are like DLLs.

double cheers

T-


#7

On 3/17/06, Jeff C. removed_email_address@domain.invalid wrote:

John L. wrote:

This is the biggest release so far of the RubyCLR bridge:

http://www.iunknown.com/articles/2006/03/16/third-drop-of-rubyclr

John, does this address my earlier comments about being able to create
your own assemblies with the RubyCLR “embedded cil assembler”?

Regards,

Robert


#8

John, does this address my earlier comments about being able to create
your own assemblies with the RubyCLR “embedded cil assembler”?

Unfortunately, no. There should be enough features to support creating a
new
type using Reflection (although I haven’t tried yet), but I don’t have a
way
to use my CIL assembler (aka RbDynamicMethod) code to generate a
non-DynamicMethod-yet. Now that said, you could hack that in by adding
some
code to core.h; it shouldn’t be too difficult to do.

The next drop of RubyCLR will likely have what you need. In that release
I’m
planning to let you implement arbitrary CLR interfaces on your Ruby
objects.
So I’ll need to generate a .NET shadow class for the Ruby class, so I’ll
need to add support into the core to support that.

Cheers,
-John
http://www.iunknown.com


#9

Ok, I will take a look. Any you are using Komodo for all this dev?
Only Windows yet though or could this work also on the Mono/Linux
side?

I use Komodo for all the Ruby parts of the code. I use VS 2005 for the
C++
stuff.

Mono doesn’t have a C++/CLI implementation so it won’t work there. But I
believe they have enough runtime support for all of the DynamicMethod
stuff.
So it becomes a matter of writing a Ruby extension that interops with C#
on
Mono. It’s not too hard, it’s just a lot of tedious work since the IJW
features of C++/CLI make managed / unmanaged code interop dirt simple.

Sounds great. But at least a month away?

That’s likely - I have to teach for the next 3 weeks, so that leaves
precious little time for hacking :frowning:

-John
http://www.iunknown.com


#10

On 3/17/06, John L. removed_email_address@domain.invalid wrote:

John, does this address my earlier comments about being able to create
your own assemblies with the RubyCLR “embedded cil assembler”?

Unfortunately, no. There should be enough features to support creating a new
type using Reflection (although I haven’t tried yet), but I don’t have a way
to use my CIL assembler (aka RbDynamicMethod) code to generate a
non-DynamicMethod-yet. Now that said, you could hack that in by adding some
code to core.h; it shouldn’t be too difficult to do.

Ok, I will take a look. Any you are using Komodo for all this dev?
Only Windows yet though or could this work also on the Mono/Linux
side?

The next drop of RubyCLR will likely have what you need. In that release I’m
planning to let you implement arbitrary CLR interfaces on your Ruby objects.
So I’ll need to generate a .NET shadow class for the Ruby class, so I’ll
need to add support into the core to support that.

Sounds great. But at least a month away?

Thanks,

Robert


#11

I really haven’t looked at what features the compact framework stuff
supports. DynamicMethod support would be an absolute minimum. Does Ruby
run
on any compact framework systems?

-John
http://www.iunknown.com


#12

John L. schrieb:

Comments / flames / suggestions / contributions are always welcome.

As .NET should be portable (I never tried it), are there any chances to
use your cool assembly to write Ruby P.s on Pocket PC based systems
(which should run a NET framework on)?


#13

John L. wrote:

This is the biggest release so far of the RubyCLR bridge:

[snip]

Very interesting. Thanks for your hard work.

John, did you get the email I sent you a couple of
days ago?

Hal


#14

John L. schrieb:

I really haven’t looked at what features the compact framework stuff
supports. DynamicMethod support would be an absolute minimum. Does Ruby run
on any compact framework systems?

I don’t have any experience but I’ll try tomorrow (uuh, the big trial
day for ruby on pocket pc g)

g,


#15

Daniel Völkerts schrieb:

I don’t have any experience but I’ll try tomorrow (uuh, the big trial
day for ruby on pocket pc g)

g Oooh yes, I’ve no experience. The package is cool and works as
expected under Win XP, but as there are no ruby interpreter which access
CLR I can’t get it working under WinCE 5.0

Nice weekend,


#16

This is very, very cool! Thanks!


#17

Thanks, Hal - I just replied last night to your earlier email.

Cheers,
-John
http://www.iunknown.com