Announcing Beta Release of GP Ruby.NET Compiler

We are pleased to announce the preliminary Beta release of the Gardens
Point
Ruby.NET compiler. Note: this is not just a Ruby/.NET bridge, nor a Ruby
Interpreter implemented on .NET, but a true .NET compiler. The compiler
can
be used to statically compile a Ruby source file into a verifiable .NET
v2.0
assembly or it can be used to directly execute a Ruby source file
(compile,
load and execute). Our implementation is not yet fully complete, but it
is
the only Ruby compiler that we know of for either the .NET or JVM
platforms
that is able to pass all 871 tests in the samples/test.rb installation
test
suite of Ruby 1.8.2.

Complete source code of our system can be downloaded from:
http://plas.fit.qut.edu.au/Ruby.NET

Please note, that we have so far made no attempt to optimize the
performance
of our system or to provide any support for interoperability with .NET
programs written in other languages. We have chosen instead to initially
focus on the challenging task of achieving complete semantic
compatibility
with the standard Ruby interpreter. Once this is achieved we will move
on to
those other challenges.

To achieve full semantic compatibility, many sections of our runtime
library
implementation mirrors the structure of the Ruby 1.8.2 interpreter code.
We
thank Matz and his colleagues for making their source code available
under
such a liberal license that enables works such as ours. We similarly,
make
our system freely available under a similarly liberal open-source
license.

We are seeking keen Ruby and .NET programmers to assist with further
testing
and development (see our web site for further details).

We look forward to your feedback …

Cheers, Wayne.
(For the GP Ruby.NET development team).

Wayne K. wrote:

We are pleased to announce the preliminary Beta release of the Gardens
Point
Ruby.NET compiler. Note: this is not just a Ruby/.NET bridge, nor a Ruby
Interpreter implemented on .NET, but a true .NET compiler.

Complete source code of our system can be downloaded from:
http://plas.fit.qut.edu.au/Ruby.NET

WOW!!

This is great news!

It also looks like you have some Microsoft sponsorship.

The corporate world is going to love this! :slight_smile:

This is going to be a nice competition between you and Sapphire in Steel
(http://www.sapphiresteel.com) for marketshare.

Competition is good…

Nice work. I wish you all the best.

Michael

On Tue, 2006-06-20 at 14:08 +0900, Wayne K. wrote:

Complete source code of our system can be downloaded from:
http://plas.fit.qut.edu.au/Ruby.NET

The download page gives an ASP error message.

Please note, that we have so far made no attempt to optimize the performance
of our system or to provide any support for interoperability with .NET
programs written in other languages. We have chosen instead to initially
focus on the challenging task of achieving complete semantic compatibility
with the standard Ruby interpreter. Once this is achieved we will move on to
those other challenges.

Even though you have said that, I am salivating a little. Okay, really,
a lot. If I understand your project page description of your approach
correctly, in theory, your approach would out-perform YARV by quite a
bit in most test cases because it’s compiled. Can you tell us how much
overhead is added by having to send all method calls through your custom
call dispatcher? If it’s not much then the benchmarks should come out a
little slower than C# execution speeds … which would just be amazing.
drool

Obviously, the load-compile-run is going to be slower than in Ruby 1.8,
but, assuming some pre-compiling could be done similar to what Python
does with caching .pyc files, that could be overcome.

I know you haven’t focused on performance yet but if you could just
comment on what you believe the performance “ceiling” is …

To achieve full semantic compatibility, many sections of our runtime library
implementation mirrors the structure of the Ruby 1.8.2 interpreter code. We
thank Matz and his colleagues for making their source code available under
such a liberal license that enables works such as ours. We similarly, make
our system freely available under a similarly liberal open-source license.

We are seeking keen Ruby and .NET programmers to assist with further testing
and development (see our web site for further details).

I noticed, also, that you are funded by Microsoft and, as such, I’m sure
you’re not very keen on Mono, but, I am curious, have you tried
compiling this on Mono’s GMCS (their DotNet 2.0 compiler)? If so, what
work is needed to make it work there?

We look forward to your feedback …

Great news!

Very exciting! I hope to see this progress quickly - I’m especially
interested in using it to drive Windows Forms applications.

I know you aren’t requesting bug reports but I have a couple anyways:

ruby --version
ruby 1.8.4 (2005-12-24) [i386-mswin32]

rubycompiler --version
ruby 0.5.0 (2006-06-30) [Ruby.Net]

rubycompiler -e “puts ‘Hello, world!’”

No output

test.rb:

require ‘net/http’
puts ‘Hello, world!’

rubycompiler test.rb
Error: Ruby.RubyException: No such file to load – net/http
at Ruby.Methods.rb_f_load.Call1(Object recv, Frame caller, Proc
block,
Object fname)
at Ruby.Methods.rb_f_require.Call1(Object recv, Frame caller, Proc
block,
Object fname)
at Ruby.Eval.CallPrivate1(Object recv, Frame caller, String methodId,
Proc block, Object arg1)
at hello.Init(Object recv, Frame caller)
at hello.Main(String[] args)

Set RUBYLIB:

set RUBYLIB=c:\program files\ruby\lib\ruby\1.8;c:\program
files\ruby\lib\ruby\1.8\i386-mswin32
rubycompiler test.rb

Different error - socket not found

Error: Ruby.RubyException: No such file to load – socket
at Ruby.Compiler.AST.PROGRAM.ExecuteInit(Assembly Assembly, Frame
caller)
at Ruby.Compiler.AST.PROGRAM.ExecuteInit(PEFile Assembly, Frame
caller)
at Ruby.Methods.rb_f_load.Call1(Object recv, Frame caller, Proc
block,
Object fname)
at Ruby.Methods.rb_f_require.Call1(Object recv, Frame caller, Proc
block,
Object fname)
at Ruby.Eval.CallPrivate1(Object recv, Frame caller, String methodId,
Proc block, Object arg1)
at hello.Init(Object recv, Frame caller)
at hello.Main(String[] args)

On Wed, 21 Jun 2006 01:04:22 +0900, you wrote:

ruby --version
ruby 1.8.4 (2005-12-24) [i386-mswin32]

rubycompiler --version
ruby 0.5.0 (2006-06-30) [Ruby.Net]

i don’t see a problem with that…maybe ruby 0.5.0 could be changed to
rubycompiler 0.5.0

rubycompiler -e “puts ‘Hello, world!’”

No output

[r:\ruby.net\bin]rubycompiler -e ‘puts “hello, world”’
hello, world

http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org

On 6/20/06, tony summerfelt [email protected] wrote:

rubycompiler 0.5.0
Sorry, that’s not part of the bug report - I was just showing the
version of
the code I was running.

On 6/21/06, tony summerfelt [email protected] wrote:

[r:\ruby.net\bin]rubycompiler -e ‘puts “hello, world”’
hello, world

It seems to be a sort of quoting args problem on windows CLI.
Single quoting works as above. (e.g. -e ‘puts “hello, world”’).
Double quoting doesn’t work. (e.g. -e "puts ‘hello, world’‘)
I have no idea, except Windows’ CLI really sucks.

Gyoung-Yoon N. wrote:

It seems to be a sort of quoting args problem on windows CLI.
Single quoting works as above. (e.g. -e ‘puts “hello, world”’).
Double quoting doesn’t work. (e.g. -e "puts ‘hello, world’‘)
I have no idea, except Windows’ CLI really sucks.

Depends. With regular ruby, no quoting issue:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

d:\development>ruby -e “puts ‘Hello!’”
Hello!

d:\development>ruby -e ‘puts “Hello!”’
Hello!


James B.

http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://yourelevatorpitch.com - Finding Business Focus

At 06:04 PM 20/06/2006, you wrote:
Wayne K. wrote:
> We are pleased to announce the preliminary Beta release of the Gardens
> Point
> Ruby.NET compiler. Note: this is not just a Ruby/.NET bridge, nor a Ruby
> Interpreter implemented on .NET, but a true .NET compiler.
>
> Complete source code of our system can be downloaded from:
> http://plas.fit.qut.edu.au/Ruby.NET
>

This is going to be a nice competition between you and Sapphire in Steel
( http://www.sapphiresteel.com) for marketshare.

Actually, Sapphire in Steel is a Visual Studio plug-in for Ruby,
it is not a Ruby compiler for .NET. So they are not competitors in
that regard.

However, in a separate Microsoft sponsored project we are working
on a simple managed framework for integrating third party languages
such as Ruby into Visual Studio (based on lex and yacc like specifications).

Cheers, Wayne.

Dr Wayne Kelly                    Senior Lecturer
Email: [email protected]        School of Software Engineering and DC
Phone: +61 7 3864 9336           Faculty of Information Technology
Fax: +61 7 3864 9390             Queensland University of Technology

At 02:37 AM 21/06/2006, you wrote:
On Wed, 21 Jun 2006 01:04:22 +0900, you wrote:

>> rubycompiler -e "puts 'Hello, world!'"
># No output

[r:\ruby.net\bin]rubycompiler -e 'puts "hello, world"'
hello, world

Actually quoted strings on the command line is an interesting issue ...

Single quoted arguments is a UNIX concept and not generally supported on Windows:

[r:\ruby.net\bin]rubycompiler -e 'puts "hello, world"'

On Windows would produce argc = 4 and
argv[0] = "rubycompiler"
argv[1] = "-e"
argv[2] = "'puts"
argv[3] = "hello, world'"

To get around this, the Ruby interpreter on Windows instead calls the
windows library function GetCommandLineA() to retrieve the raw command line
and then parses it manually to reproduce UNIX semantics.

We similarly call System.Environment.CommandLine and perform our own
command line parsing, but that parsing code is so far, far from
complete - as you have illustrated.

Interestingly, even the Ruby 1.8 interpreter on Windows doesn't produce
the same results as on UNIX when the following command is issued from
a command prompt window as everything following the '&' character
is not even accessible to the GetCommandLineA function.

Ruby -i.bak -pe 'sub(/^[0-9]+$/){$&.to_i * 5}' script_tmp


Cheers, Wayne.

Dr Wayne Kelly                    Senior Lecturer
Email: [email protected]        School of Software Engineering and DC
Phone: +61 7 3864 9336           Faculty of Information Technology
Fax: +61 7 3864 9390             Queensland University of Technology

At 01:08 AM 21/06/2006, you wrote:
On Tue, 2006-06-20 at 14:08 +0900, Wayne K. wrote:
> Complete source code of our system can be downloaded from:
> http://plas.fit.qut.edu.au/Ruby.NET

The download page gives an ASP error message.

And what error is that? (I don't get any errors)

> Please note, that we have so far made no attempt to optimize the performance
> of our system or to provide any support for interoperability with .NET
> programs written in other languages. We have chosen instead to initially
> focus on the challenging task of achieving complete semantic compatibility
> with the standard Ruby interpreter. Once this is achieved we will move on to
> those other challenges.

Even though you have said that, I am salivating a little. Okay, really,
a lot. If I understand your project page description of your approach
correctly, in theory, your approach would out-perform YARV by quite a
bit in most test cases because it's compiled. Can you tell us how much
overhead is added by having to send all method calls through your custom
call dispatcher?

It does basically what the Ruby interpreter does ...
It needs to work out the Ruby class of the receiver object and search
for the method (by ID) in the method table of that class. If it can't
find it there it needs to search in sub-classes (and mix-ins).
The Ruby interpreter optimises this slightly by caching the methods
that have been called previously, but it still needs to do at least this
one cache lookup. We haven't yet implemented such a caching mechanism
but we will do so.
On locating the method it needs to check if it can be legally accessed
(public, private or protected).

If it's not much then the benchmarks should come out a
little slower than C# execution speeds ... which would just be amazing.

I wouldn't be so confident.

Obviously, the load-compile-run is going to be slower than in Ruby 1.8,

Not necessarily, once the load-compile step is out of the way,
we are executing native JIT compiled code rather than the interpreting
that Ruby 1.8 is doing.

I know you haven't focused on performance yet but if you could just
comment on what you believe the performance "ceiling" is ...

I suspect some programs will run faster compiled to Managed .NET code
and some will run faster interpreted with the native C interpreter.

I noticed, also, that you are funded by Microsoft and, as such, I'm sure
you're not very keen on Mono, but, I am curious, have you tried
compiling this on Mono's GMCS (their DotNet 2.0 compiler)?

We don't have any issues with Mono. I  haven't had the chance to try
our compiler on Mono but I'd be really interested to know if it works.
And if not, if there's anything we need to change. We're more than
happy to cooperate with any such efforts.

Cheers, Wayne.

Dr Wayne Kelly                    Senior Lecturer
Email: [email protected]                 School of Software Engineering and DC
Phone: +61 7 3864 9336           Faculty of Information Technology
Fax: +61 7 3864 9390             Queensland University of Technology

On 6/21/06, Wayne K. [email protected] wrote:

It does basically what the Ruby interpreter does …
It needs to work out the Ruby class of the receiver object and search
for the method (by ID) in the method table of that class. If it can’t
find it there it needs to search in sub-classes (and mix-ins).

That’s superclasses, not subclasses, right?

Wayne K. wrote:

This is going to be a nice competition between you and Sapphire in Steel
http://www.sapphiresteel.com) for marketshare.



Actually, Sapphire in Steel is a Visual Studio plug-in for Ruby,

it is not a Ruby compiler for .NET. So they are not competitors in

that regard.

That is correct. Though I should clarify that our current development is
the Steel IDE for Ruby or “Ruby In Steel”. Our site is called “Sapphire
In Steel” and we shall, at a later date, provide more details of the
Sapphire project.

The Steel IDE should support development of a Ruby CLR compiler
developed by a third party and we shall be happy to cooperate to ensure
that this is the case.

best wishes
Huw C.
www.sapphireinsteel.com

On Wed, 21 Jun 2006 03:34:46 +0900, you wrote:

I have no idea, except Windows’ CLI really sucks.

4nt makes it a wee bit better.

for most cli stuff i use cygwin (even for windows related operations).

http://home.cogeco.ca/~tsummerfelt1
telnet://ventedspleen.dyndns.org