Re: [Rubydotnet-developer] Undergrad project

[Thomas S. <th...@th...>]

Hi Tim,

I think the most interesting project in this realm is IronPython. Rather
than bridging it is a rewrite of Python targetting IL. I don't think it
is available yet, but you could google for it and get in contact with
the author for details. Fundamentally he (IronPython) has the right idea
- 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

Furthermore, I think embedding a ruby interpreter in a .net application
would be a killer feature, and while it can be done, the ruby
interpreter is not reentrant. 

So I think the best solution would be to ditch the ruby interpreter
alltogether and follow the same path as IronPython. I exchanged a few
emails with the IronPython author and as far as I recall he would like
to target other dynamic languages than Python in the future, if he has
the time. Maybe he would be interested in helping out a student project,
who knows?

Thomas

On Wed, 2004-06-30 at 06:55, Tim Sutherland wrote:
> Hi everyone. For those of you who've forgotten, I wrote the
> "rubydotnetproxy" library which allows Ruby to call .NET methods and
> vice versa. Several other people/groups wrote similar things, some of
> which supported more features than mind (e.g. a Ruby class can
> implement a .NET interface).
> 
> A couple of months ago I said I was going to port my code to Mono, spent
> one weekend working on it and then didn't have time to do any more work
> on it!
> 
> I'm an undergraduate student (University of Auckland), and I'm trying to
> decide what courses to do next semester (which starts in a few weeks).
> One of my options is an "Undergraduate Project in Computer Science".
> 
> I'd like to do a project about integrating Ruby and .NET. A semester
> lasts 12 weeks. (19 Jul 2004 to 23rd October 2004.)
> 
> In trying to be a good scientist, I would spend a lot of time looking at
> what other people have done (in Ruby, as well as other dynamic
> languages) and adapt/use their code/ideas. For example, I could use
> someone elses code and add features or improve the implementation. (e.g.
> considering different ways of implementing certain features).
> 
> 
> So my questions to you guys:
> 
> What is currently missing or undeveloped in the current Ruby-.NET
> bridging libraries? In my opinion:
> 
> 1) Mono support. This is important to me, since at home I only use
> Linux. I wouldn't want to just abandon my work at the end of the
> semester, so it would have to be runnable on Linux so that I remain
> motivated.
> 
> 2) Threading support. Dealing with the differences between threads in
> .NET and in Ruby is hard.
> 
> 3) Speed. There are some simple things (at least with my library) that
> can be done to improve speed. e.g. my library used Type#InvokeMember
> each time a .NET method was called from Ruby. Instead of that, the first
> time we call a .NET method we could use Type#GetMember (or whatever it's
> called) and subsequently used the cached result.
> 
> Potentially there are a bunch of low-level things that can be done as
> well. I'd have to become more familiar with the way .NET works (CLR
> stuff).
> 
> 
> 4) ???
> 
> 
> As far as licensing goes, any code I write would be released under a
> license that's compatible with Ruby's. This whole scheme could come
> unstuck if my University won't agree to that, but hopefully I can
> negotiate with them.
> 
> With reusing code, I believe that while there are several different
> projects approaching this problem, the amount of code in each is not
> large. On the other hand, the code is very "dense", i.e. the code uses
> fairly complicated ideas and there are plenty of fairly subtle issues.
> 
> I suspect that it is less important whether or not I re-use actual code
> (though I will attempt to do this where possible) than that I re-use
> (steal) ideas from the implementations.
> 
> I think the best approach would be to take an existing implementation
> and then extend it, since then both the original authors and myself
> would be "supporting/promoting" the code.
> 
> The result of my project will be
>   1) Some code.
>   2) A written report on what I have learned.
> 
> (2) is going to be more important than (1), since everyone will be able
> to use the ideas for their own implementations, and it will be useful to
> people developing bridges in dynamic languages other than Ruby too.