Re: [Rubydotnet-developer] Undergrad project

[Richard K. <ri...@in...>]

You may want to contact Robert Feldt: <fe...@ce...> (I Cc'd him on
this message).

He has students working on a Ruby to CIL compiler (from his ruby-talk post)=
:

=3D=3D original message =3D=3D

Hi,

I created a web page for the theses of the student projects I have
talked about on the list during the last couple of months. Not all pdf
are up yet but hopefully I'll have the time to add them before going on
a 3-week vacation (with no/little Internet connection!) tomorrow.

Feedback and comments appreciated.

http://www.pronovomundo.com/htu/theses2004/

Jan-=C5ke Hedstr=F6m, "RubySharp =AD A Ruby to CIL Compiler"
This paper describes the development of RubySharp, a proof-of-concept
compiler. It is able to compile a subset of features from the dynamic
programming language Ruby into CIL (Common Intermediate Language), which
is a static assembler intermediate language in the .NET platform. The
language constructs of Ruby and CIL are examined to see what
similarities and differences that exist. To be able to support the
correct Ruby behaviour in all compiled programs, a class hierarchy is
developed for RubySharp. Additionally, basic goal programs are defined
in Ruby and in CIL, forming a specification for the RubySharp compiler
on how to compile the goal programs. Furthermore, other Ruby language
constructs, besides these introduced by the goal programs, are also
examined to see if and how they can be implemented on the .NET platform.

=3D=3D clip MorphR stuff =3D=3D

-Rich

On 6/30/04 3:50 AM, "Thomas Sondergaard" <th...@th...>
wrote:

> Hi Tim,
>=20
> 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
>=20
> 1) The dual-gc problem,
> 2) The ruby pseudo-threading versus .net native threading problem
>=20
> 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.
>=20
> 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?
>=20
> Thomas
>=20
> 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).
>>=20
>> 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!
>>=20
>> 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".
>>=20
>> I'd like to do a project about integrating Ruby and .NET. A semester
>> lasts 12 weeks. (19 Jul 2004 to 23rd October 2004.)
>>=20
>> 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).
>>=20
>>=20
>> So my questions to you guys:
>>=20
>> What is currently missing or undeveloped in the current Ruby-.NET
>> bridging libraries? In my opinion:
>>=20
>> 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.
>>=20
>> 2) Threading support. Dealing with the differences between threads in
>> .NET and in Ruby is hard.
>>=20
>> 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.
>>=20
>> 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).
>>=20
>>=20
>> 4) ???
>>=20
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> The result of my project will be
>>   1) Some code.
>>   2) A written report on what I have learned.
>>=20
>> (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.
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Rubydotnet-developer mailing list
> Rub...@li...
> https://lists.sourceforge.net/lists/listinfo/rubydotnet-developer
>=20