Yes, this is very interesting.
I've just started a 12-week undergraduate project on the topic of integrating
Ruby and .NET.
The following three projects bridge Ruby and .NET by using "proxy objects"
(both the Ruby and .NET runtimes are used in the same application, and they
are integrated "on the borders").
http://rubydotnetproxy.rubyforge.org/
http://rubydotnet.sf.net/
(I wrote rubydotnetproxy before starting my undergrad project.)
Jan-AAke Hedstro:m (a student of Robert Feldt's) has developed RubySharp,
while compiles a subset of Ruby into CIL. (CIL = .NET's "Common Intermediate
Language".) See http://www.pronovomundo.com/htu/theses2004/
There is a mailing list for discussing Ruby/.NET integration:
http://sourceforge.net/mailarchive/forum.php?forum_id=34312
In my project, I am intending to do the following:
- Aim is to allow people to use .NET and Ruby code in the same application,
use .NET libraries in Ruby and vice versa.
My aim is not to make Ruby work faster than it does currently.
- Prototype, test, compare ideas and approaches. The main output will be a
paper rather than code.
- I suspect that my approach will use the existing Ruby interpreter and
bridge with the .NET system (as in the first three projects I listed) -
but doing some runtime compilation for performance.
(All existing Ruby programs will work since we can fall back on the Ruby
interpreter.)
Thomas Sondergaard (author of http://rubydotnet.sf.net/\) points out two
drawbacks to this method:
(http://sourceforge.net/mailarchive/message.php?msg_id=8843283\)
" - bridging anything to the current ruby runtime will remain mostly a
hack, because I don't think you will be able to satisfactorily solve at
least the following fundamental problems
1) The dual-gc problem,
2) The ruby pseudo-threading versus .net native threading problem
"
Hopefully I can mitigate these. #2 looks to be the harder.
- Since people have already done work in this area, a (big?) part of my
project will be to compare approaches. e.g. compare performance. The
three "bridging" projects were (I believe) all concerned about first
getting something that worked. Not much attention has been paid to
performance.
Any suggestions people have would be very welcome.
[If you think I'm going down the wrong path then now is a good time to tell
me, before I do any work 
]
路路路
In article <1091061436.6219.12.camel@linux.site>, Daniel Cremer wrote:
This might interest some of you
A (fast) python implementation targeting .net and Mono has been released
as open source today. Apparently this was announced at OSCON today. If
anyone attended the talk I would be interested in hearing about it. I've
been waiting for this for a while, not because I program in python but
because it's supposed to have some good solutions for implementing
dynamic languages on the CLR.
Interestingly the author, Jim Hugunin, is going to join the CLR team at
Microsoft and he (quote from website:) "will also reach out to other
languages to help overcome any hurdles that are preventing them from
targeting the CLR effectively."
I haven't had the chance to play with this yet but it looks pretty cool.
http://www.ironpython.com
--
Tim Sutherland <timsuth@ihug.co.nz>
2004 SDKACM President
Software Developers' Klub - the University of Auckland ACM Student Chapter
http://www.sdkacm.com/
