rubydotnet-developer

[Rubydotnet-developer] Undergrad project

[Tim S. <ti...@ih...>]

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.

-- 
Tim Sutherland <ti...@ih...>
2004 President of SDKACM, the Software Developers' Klub Incorporated.
This is the University of Auckland ACM Student Chapter and is AUSA affiliated.
See http://www.sdkacm.com/ for information and resources.

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.

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

Re: [Rubydotnet-developer] Undergrad project

[Tim S. <ti...@ih...>]

On Wed, Jun 30, 2004 at 09:56:51AM -0400, Richard Kilmer wrote:
> 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):
> 
[...]
> http://www.pronovomundo.com/htu/theses2004/
> 
> Jan-?ke Hedstr?m, "RubySharp ? 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),
[...]

> On 6/30/04 3:50 AM, "Thomas Sondergaard" <th...@th...>
> wrote:
> 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
[...]

Thanks to both of you for your comments.

The concern I have with dropping the current Ruby runtime entirely is
that then you're no longer dealing with Ruby, but instead have 'the
subset of Ruby that is currently supported by this .NET
compiler/interpreter'.

It would be interesting to combine a CIL compiler with the Ruby runtime
so we gain performance and integration when dealing with .NET stuff but can
also use normal Ruby code. I will certainly read the RubySharp paper.

A large part of my project will be considering what other people have
already done in this area, both by the people on this list and by projects
for other languages and systems. (e.g. Ruby and Python on Java projects.)

-- 
Tim Sutherland <ti...@ih...>
2004 President of SDKACM, the Software Developers' Klub Incorporated.
This is the University of Auckland ACM Student Chapter and is AUSA affiliated.
See http://www.sdkacm.com/ for information and resources.

Re: [Rubydotnet-developer] Undergrad project

[Ron J. <ron...@ac...>]

On Wednesday, June 30, 2004, at 11:48:18 PM, Tim Sutherland wrote:

> On Wed, Jun 30, 2004 at 09:56:51AM -0400, Richard Kilmer wrote:
>> 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):
>> 
> [...]
>> http://www.pronovomundo.com/htu/theses2004/
>> 
>> Jan-?ke Hedstr?m, "RubySharp ? 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),
> [...]

>> On 6/30/04 3:50 AM, "Thomas Sondergaard" <th...@th...>
>> wrote:
>> 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
> [...]

> Thanks to both of you for your comments.

> The concern I have with dropping the current Ruby runtime entirely is
> that then you're no longer dealing with Ruby, but instead have 'the
> subset of Ruby that is currently supported by this .NET
> compiler/interpreter'.

> It would be interesting to combine a CIL compiler with the Ruby runtime
> so we gain performance and integration when dealing with .NET stuff but can
> also use normal Ruby code. I will certainly read the RubySharp paper.

> A large part of my project will be considering what other people have
> already done in this area, both by the people on this list and by projects
> for other languages and systems. (e.g. Ruby and Python on Java projects.)

I don't have an answer to the question I'm about to ask, but the question
is this:

  What does a person using Ruby with .NET really want and need?

Let me riff on that a bit.

One might just need Ruby. If I just want to script some .NET programs with
Ruby, it probably works fine as it is. Start programs, read and write
files, no big deal. Probably not a project lurking there.

Or, one might want to program in Ruby, mixing and matching with .NET
programs and libraries in the "same way" one can mix C# and VB programs.
(At least with managed programs, let's say.)

Now here it gets interesting. There are in fact probably things that are in
real Ruby that are "inappropriate" if one's doing a Ruby.NET. Very likely,
almost everything should work the way it works in .NET, not the way it
works in Ruby. Files and directories should use the .NET facilities. (This
could be very important with upcoming changes to the file system in future
versions of Windows.) Strings should use and work on .NET strings.

This would come down to Ruby syntax, compiling to IL, running against the
real .NET libraries, and -- I suppose -- producing libraries that can be
used from other .NET languages.

Thinking this way, I imagine that I might want to have .rb source files
open in Visual Studio, the same way I have .cs or .vb files open. Build the
app, they compile and build just like anything else.

A real live compatible Ruby. A hard project but from some viewpoints, the
only one.

I don't mean that to be the answer to my question of what we want and need,
but it might be ONE answer.

Regards,

Ron Jeffries
www.XProgramming.com
Learn from yesterday, live for today, hope for tomorrow.
The important thing is to not stop questioning. --Albert Einstein

Re: [Rubydotnet-developer] Undergrad project

[Rodrigo B. de O. <rb...@ac...>]

----- Original Message ----- 
From: "Ron Jeffries" <ron...@ac...>
> ...
> ...
>   What does a person using Ruby with .NET really want and need?
>

Pretty much what you've already said, Ron, I'm just throwing one more
vote: being able to consume and produce cli components with ruby like syntax
and semantics.

The syntactic part is somewhat easy but implementing the full ruby semantics
in a way that still allows one to write .net consumable classes seems a bit
hard.

The approach I have used in boo (http://boo.codehaus.org/) was to drop the
hard-to-mix-with-cli semantics in favor of a more tight integration with
the type system. The type inference mechanism (still maturing) gives one
the scripting feeling of a lighter syntax although most of the dynamic
semantics are lost:

    import System.IO

    for line in File.OpenText("albatros.txt"):
        print(line) if line =~ /^Man/


While I'm pretty much happy with that I don't think most rubysts and
pythonists
for that matter are willing to give up the truly dynamic nature of their
programming languages.

Regards,
Rodrigo