From: timsuth@... (Tim Sutherland) Date: 2004-07-29T18:46:46+09:00 Subject: Re: ironpython (.net python) and dynamic langs on CLR 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 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://www.saltypickle.com/rubydotnet/ 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 :-) ] -- Tim Sutherland 2004 SDKACM President Software Developers' Klub - the University of Auckland ACM Student Chapter http://www.sdkacm.com/