Forum: Ruby Brite - A ruby compiler for the .NET platform

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Pascal H. (Guest)
on 2006-05-20 14:14
(Received via mailing list)
Hi folks!

I discovered ruby some month ago and I liked it in a bunch of minutes.
Then I was involved in a project using ASP.NET. At this point I had a
dream ;-) Ruby that works on .NET (knowing ruby, neither VB nor C#
fits!) .
I found some material, but nothing useable or 100% .NET, so I took
some time and decided to create a ruby compiler.

Here it is... well, at least the first version which is early alpha.

Get it, try it, read it, and tell me what you think. Is this project
worth
continuing?

You can read some info about it and also download it here:
    http://mortimer.devcave.net/projects/brite

Cheers,

Pascal H.
Florian GroÃ? (Guest)
on 2006-05-20 14:57
(Received via mailing list)
Pascal H. wrote:

> I discovered ruby some month ago and I liked it in a bunch of
> minutes. Then I was involved in a project using ASP.NET. At this
> point I had a dream ;-) Ruby that works on .NET (knowing ruby,
> neither VB nor C# fits!) . I found some material, but nothing useable
> or 100% .NET, so I took some time and decided to create a ruby
> compiler. [...] Get it, try it, read it, and tell me what you think.
> Is this project worth continuing?

This looks very promising and I hope it will continue to be developed.
I'd really like to see something like this working very well. Perhaps
even in a boot-strapped, self-hosting way which would be possible with
.NET. And I think your approach is going to be self-hosted. This is the
way I have dreamed of doing it in the past.

Regarding implementation of the standard library. I've done part of it
in JavaScript [1] already and another very small part in Ruby [2].

I've tried to make the implementation as self-based and simple as
possible.

I hope it is of some use to you.

I'm not sure in what state your parser is currently in, but you might be
able to heavily cheat with this by either only accepting YARV byte code
as input or by letting Ripper or ruby -y do the hard work for you. This
would mean needing to call an external binary for things like eval() at
first, but for an initial version that would be good enough, I think.

Continuations are very hard to do, but it might be possible to do them
for the Ruby side with a heavy transformation of method calling code.
I've thought about this in the past [3], but I think
continuations could still be added very, very late when other things
already work.

Regarding .NET interoperability: Using Ruby objects from .NET is the
hardest to do. Think about things like method_missing() and you will
realize that rubyObj.method() will not be good enough. You probably
would need to do rubyObj.send("method") in all .NET code.

The other way around is more important at first because it would allow
you to implement the standard library in Ruby while using .NET
infrastructure. (Very handy for things like Regular Expressions, Date
stuff, IO and probably yet more.)

It would be very wonderful if the run time could automatically translate
Ruby's blocks to .NET's delegates and so on. But this is a convenience
feature as well. Not strictly necessary at first.

> A method definition can also use "pass remaining param as an array".
> What should we do with this? Is there vararg in CLS ?

  From what I understand C# and so on implement varargs by accepting an
array as the last argument. You can forward arguments that way as well.
So it's pretty much syntax. The same could be done for Ruby. You could
annotate the methods as having varargs to make the distinction clearer.

Regarding blocks: Mono's JScript.NET solves that kind of thing (how to
pass information for closures and so on) by passing in a single engine
argument. It can be used to find out information for context and so on.
I imagine this would also work well for Ruby. A delegate would mostly
work, but you can't handle this case:

    a = "foo"
    foo() do
      eval("a")
    end

Because you don't see the access of the variable a in the block at
compile time. So you need some kind of mechanism to access parent scopes
at run time. This is what the engine would do.

I'd ignore the whole String thing for now. Ruby's strings are going to
change quite a bit very soon. For now I think it would be enough to do
the simplest thing: Unicode strings.

Hope all of this is of some help to you. Good luck!

[1] http://flgr.dyndns.org/ruby.js/
[2] http://flgr.dyndns.org/code/method-dict.rb
[3] http://flgr.dyndns.org/callcc-cil.rb
Kris (Guest)
on 2006-05-21 19:13
Would this allow Ruby to be compiled to CIL?
Florian GroÃ? (Guest)
on 2006-05-21 23:06
(Received via mailing list)
Kris wrote:

> Would this allow Ruby to be compiled to CIL?

It would be the ultimate goal of the project as far as I understand. Of
course you would still need a run time as well.

Oh, and don't expect 100% feature completeness too soon. There's a lot
of edge cases that are hard to get right.

But it might happen and I hope it eventually will happen.
Daniel A. (Guest)
on 2006-05-22 07:47
(Received via mailing list)
Most people are already aware of this, but just for the newcomers,
this group is also working towards similar goals:

http://plas.fit.qut.edu.au/rubynet/

Although I, personally, am cheering for Florian, since the result of
his efforts will be truly open source, as opposed to the QUT effort
that will be  (to quote their home page):

'under a relatively liberal open source license that largely allows it
to be freely used by anyone in any way and for any purpose.'

I'm a little wary of the 'relatively', 'largely' and 'used by' phrases
(as opposed to 'modified by'). We'll have to see.

Dan
Daniel A. (Guest)
on 2006-05-22 07:53
(Received via mailing list)
Just to head off any confusion...

I don't mean to imply that the QUT license shouldn't have any
restrictions, since most OS licenses do (for good reason). My only
concern is that when the license is announced, it may turn out not to
be very open at all.

So I'm basically just hoping that they're wise about which license
they use, since so far they haven't committed to anything specific
yet.

Dan
Kris (Guest)
on 2006-05-22 11:56
I guess a Rails app would be more difficult to compile...
Is CIL reverseable back to code like Java bytecode is? And is it suited
to holding a decryption key from preying eyes, like you would with a
native binary?

Florian GroÃ? wrote:
> Kris wrote:
>
>> Would this allow Ruby to be compiled to CIL?
>
> It would be the ultimate goal of the project as far as I understand. Of
> course you would still need a run time as well.
>
> Oh, and don't expect 100% feature completeness too soon. There's a lot
> of edge cases that are hard to get right.
>
> But it might happen and I hope it eventually will happen.
Kris (Guest)
on 2006-05-22 12:01
I guess a Rails app would be more difficult to compile...
Is CIL reverseable back to code like Java bytecode is? And is it suited
to holding a decryption key from preying eyes, like you would with a
native binary?

Florian GroÃ? wrote:
> Kris wrote:
>
>> Would this allow Ruby to be compiled to CIL?
>
> It would be the ultimate goal of the project as far as I understand. Of
> course you would still need a run time as well.
>
> Oh, and don't expect 100% feature completeness too soon. There's a lot
> of edge cases that are hard to get right.
>
> But it might happen and I hope it eventually will happen.
Dido S. (Guest)
on 2006-05-22 15:42
(Received via mailing list)
On 5/21/06, Kris <removed_email_address@domain.invalid> wrote:
> Would this allow Ruby to be compiled to CIL?

I think a better tack might be to make a JIT compiler into CIL. This
would allow things like Ruby's eval to continue to function.
Simen (Guest)
on 2006-05-22 15:42
Kris wrote:
> I guess a Rails app would be more difficult to compile...
> Is CIL reverseable back to code like Java bytecode is? And is it suited
> to holding a decryption key from preying eyes, like you would with a
> native binary?
>

A Rails app wouldn't be any more difficult than any other Ruby app. If
you've ported all non-ruby libraries Rails uses (database bindings etc.)
to .net it would be just as easy as any other app. It's just Ruby code.

I believe there exists a .net disassembler, so you could inspect the
assemblies.
Florian GroÃ? (Guest)
on 2006-05-22 17:42
(Received via mailing list)
Kris wrote:

> I guess a Rails app would be more difficult to compile...

Once you have support for most of the language it ought to be possible.

> Is CIL reverseable back to code like Java bytecode is?

Yes, as is any other byte code format.

> And is it suited
> to holding a decryption key from preying eyes, like you would with a
> native binary?

I don't understand how a decryption key would be hold from preying eyes
by a native binary. Wouldn't you still be able to extract it?
Kris L. (Guest)
on 2006-05-22 17:53
I found a one page html page detailing how to decrypt a CIL back to
source like you can with Java bytecode... Its just too easy to do!
Getting a key out of binary can be made to be difficult, not impossible.
With bytecode its just all to easy.
REally we need encrypted ruby code, but there seems to be resistance to
the idea in the ruby community...

Florian GroÃ? wrote:
> Kris wrote:
>
>> I guess a Rails app would be more difficult to compile...
>
> Once you have support for most of the language it ought to be possible.
>
>> Is CIL reverseable back to code like Java bytecode is?
>
> Yes, as is any other byte code format.
>
>> And is it suited
>> to holding a decryption key from preying eyes, like you would with a
>> native binary?
>
> I don't understand how a decryption key would be hold from preying eyes
> by a native binary. Wouldn't you still be able to extract it?
Ryan L. (Guest)
on 2006-05-22 19:18
(Received via mailing list)
On 5/22/06, Kris L. <removed_email_address@domain.invalid> wrote:
> I found a one page html page detailing how to decrypt a CIL back to
> source like you can with Java bytecode... Its just too easy to do!
> Getting a key out of binary can be made to be difficult, not impossible.
> With bytecode its just all to easy.
> REally we need encrypted ruby code, but there seems to be resistance to
> the idea in the ruby community...

In some sense I suppose encrypting code is against the spirit of Ruby,
but from my perspective the problem is more of practicality. The basic
issue is that if the computer can decrypt the code to run it, then
someone else can as well. You will have to embed the key somewhere in
the binary, and it would be trivial to run the interpreter in a
debugger to see where the key was hidden.

This is the same problem big media is running against with their
incessant and obsessive fight against supposed "copyright
infringement" with DRM technologies. At some point the data has to be
unencrypted for humans to see, read or hear it. Unless of course we
all have special chips embedded in our brains that allow us to only
see or hear content specifically licensed to us. That is the next
logical step. Be prepared for the introduction to Congress of the
Omnibus Verifying Entertainment Revenue with Licensing Or Restriction
of Data Act (aka the OVERLORD Act) sometime in 2008. Your chip awaits.
</end_copyright_tirade>

Ryan
Regg M. (Guest)
on 2006-05-22 20:01
Pascal H. wrote:
> Hi folks!
>
> I discovered ruby some month ago and I liked it in a bunch of minutes.
> Then I was involved in a project using ASP.NET. At this point I had a
> dream ;-) Ruby that works on .NET (knowing ruby, neither VB nor C#
> fits!) .
> I found some material, but nothing useable or 100% .NET, so I took
> some time and decided to create a ruby compiler.
>
> Here it is... well, at least the first version which is early alpha.
>
> Get it, try it, read it, and tell me what you think. Is this project
> worth
> continuing?
>
> You can read some info about it and also download it here:
>     http://mortimer.devcave.net/projects/brite
>
> Cheers,
>
> Pascal H.


Have you seen IronPython yet?

It's Python with .NET and it's being sponsored by Microsoft.


http://www.ironpython.com/


Here is a video of it.
http://msdn.microsoft.com/msdntv/episode.aspx?xml=...


Pretty nice!!
Kris L. (Guest)
on 2006-05-22 20:38
If its against the spirit of ruby then it makes it less commercially
useable since code can't be distributed in a closed way. I do hear a lot
of resistance to encrypted ruby cos people are just self hosting app's
which is fine, but...

Encryption would offer quite a bit of protection, you could hide a key
well, not impossible to find but enough to make it easier to write the
app from scratch than go to the trouble of steeling source code.
:)
Ryan L. wrote:
> On 5/22/06, Kris L. <removed_email_address@domain.invalid> wrote:
>> I found a one page html page detailing how to decrypt a CIL back to
>> source like you can with Java bytecode... Its just too easy to do!
>> Getting a key out of binary can be made to be difficult, not impossible.
>> With bytecode its just all to easy.
>> REally we need encrypted ruby code, but there seems to be resistance to
>> the idea in the ruby community...
>
> In some sense I suppose encrypting code is against the spirit of Ruby,
> but from my perspective the problem is more of practicality. The basic
> issue is that if the computer can decrypt the code to run it, then
> someone else can as well. You will have to embed the key somewhere in
> the binary, and it would be trivial to run the interpreter in a
> debugger to see where the key was hidden.
>
> This is the same problem big media is running against with their
> incessant and obsessive fight against supposed "copyright
> infringement" with DRM technologies. At some point the data has to be
> unencrypted for humans to see, read or hear it. Unless of course we
> all have special chips embedded in our brains that allow us to only
> see or hear content specifically licensed to us. That is the next
> logical step. Be prepared for the introduction to Congress of the
> Omnibus Verifying Entertainment Revenue with Licensing Or Restriction
> of Data Act (aka the OVERLORD Act) sometime in 2008. Your chip awaits.
> </end_copyright_tirade>
>
> Ryan
Ryan L. (Guest)
on 2006-05-22 22:05
(Received via mailing list)
On 5/22/06, Kris L. <removed_email_address@domain.invalid> wrote:
>
> Encryption would offer quite a bit of protection, you could hide a key
> well, not impossible to find but enough to make it easier to write the
> app from scratch than go to the trouble of steeling source code.
> :)

I feel stolen code is a legal problem, not a technical one. For one
thing, as I have argued, it is a very hard if not impossible problem
to solve with a language like Ruby (and most other languages.) But the
same aspects of Ruby that make your code available to steal also make
it easy to see who has stolen your code. At that point you can put
some legal hurt on the parties that have stolen the code.

Whereas if you build some system for encrypting the code that is
actually easily broken people can steal your code and you may never
suspect it, since you will think your code is safe.

In addition, with our current world being full of open source projects
for just about every conceivable thing, the "value" of source code has
been greatly reduced. In fact if anything there needs to be more "code
stealing" in the form of reuse because everyone always seems to want
to reinvent the wheel (at least in open source software.)

If you really feel your code is valuable then you need to make it so
that the code is never on the client machine, which means some kind of
online service, like a web-site or SOAP API.

Ryan
Kris L. (Guest)
on 2006-05-22 22:23
Its not just having code stolen but the fact that it can be modified so
that it dumps its data to file or screen... If your dealing with
sensitive data thats a problem.

Ryan L. wrote:
> On 5/22/06, Kris L. <removed_email_address@domain.invalid> wrote:
>>
>> Encryption would offer quite a bit of protection, you could hide a key
>> well, not impossible to find but enough to make it easier to write the
>> app from scratch than go to the trouble of steeling source code.
>> :)
>
> I feel stolen code is a legal problem, not a technical one. For one
> thing, as I have argued, it is a very hard if not impossible problem
> to solve with a language like Ruby (and most other languages.) But the
> same aspects of Ruby that make your code available to steal also make
> it easy to see who has stolen your code. At that point you can put
> some legal hurt on the parties that have stolen the code.
>
> Whereas if you build some system for encrypting the code that is
> actually easily broken people can steal your code and you may never
> suspect it, since you will think your code is safe.
>
> In addition, with our current world being full of open source projects
> for just about every conceivable thing, the "value" of source code has
> been greatly reduced. In fact if anything there needs to be more "code
> stealing" in the form of reuse because everyone always seems to want
> to reinvent the wheel (at least in open source software.)
>
> If you really feel your code is valuable then you need to make it so
> that the code is never on the client machine, which means some kind of
> online service, like a web-site or SOAP API.
>
> Ryan
MenTaLguY (Guest)
on 2006-05-23 00:02
(Received via mailing list)
On Tue, 23 May 2006 03:04:23 +0900, "Ryan L."
<removed_email_address@domain.invalid> wrote:
> Whereas if you build some system for encrypting the code that is
> actually easily broken people can steal your code and you may never
> suspect it, since you will think your code is safe.

Not to mention that they could use the same obfuscation techniques to
hide the fact that they misappropriated code in the first place.

-mental
MenTaLguY (Guest)
on 2006-05-23 00:08
(Received via mailing list)
On Tue, 23 May 2006 03:24:03 +0900, Kris L.
<removed_email_address@domain.invalid> wrote:
> Its not just having code stolen but the fact that it can be modified so
> that it dumps its data to file or screen... If your dealing with
> sensitive data thats a problem.

If the data is sensitive, why are you putting it on an unsecured
machine?

Obfuscation might stop the honest user who's just curious, but if you're
dealing with a malicious user (especially if they have a financial
incentive) then sending the data to a machine they control is simply a
free gift.

-mental
Hal F. (Guest)
on 2006-05-23 09:12
(Received via mailing list)
Kris L. wrote:
> I found a one page html page detailing how to decrypt a CIL back to
> source like you can with Java bytecode... Its just too easy to do!
> Getting a key out of binary can be made to be difficult, not impossible.
> With bytecode its just all to easy.
> REally we need encrypted ruby code, but there seems to be resistance to
> the idea in the ruby community...

No, I think you're missing the point.

Bring the issue up on sci.crypt and see what they say.


Hal
Alex Y. (Guest)
on 2006-05-23 10:26
(Received via mailing list)
Kris L. wrote:
> Its not just having code stolen but the fact that it can be modified so
> that it dumps its data to file or screen... If your dealing with
> sensitive data thats a problem.
>
Ok.  What we have here is 3 separate problems:

- Data security.  Don't want people who shouldn't being able to get hold
of the data.
- Code security.  Don't want people who shouldn't being able to get hold
of the source (or a usable representation of it).
- Code validity.  Don't want untrusted code running at all.

The first is answered by classical computer security concerns.  The last
requires trusted hardware.  The second is technically impossible but
legally enforceable.  There may be mileage in putting *enough* of a
barrier up to wave the DMCA in peoples' faces if they cross it (in
addition to whatever contractual/copyright/licencing system you put
around your code), but that doesn't deal with the problem of finding out
when they have.

I feel I should also point out that despite how easy it is to reverse
CIL and Java bytecode, there is a thriving commercial market in software
dealing with sensitive data for both those platforms.
Kris L. (Guest)
on 2006-05-23 11:53
What would be secure hardware?
Alex Y. (Guest)
on 2006-05-23 13:21
(Received via mailing list)
Kris L. wrote:
> What would be secure hardware?
>
A smart card, a Trusted Computing(tm) platform, or some equivalent.
Essentially a platform where digital signatures on the code are
implemented in hardware and cannot be circumvented without the whole
thing breaking.

Alternatively, a sealed computer in a locked room with no network
connection (possibly).  It all depends on how paranoid you are.
Kris (Guest)
on 2006-05-23 13:25
Alex Y. wrote:
> Kris L. wrote:
>> What would be secure hardware?
>>
> A smart card, a Trusted Computing(tm) platform, or some equivalent.
> Essentially a platform where digital signatures on the code are
> implemented in hardware and cannot be circumvented without the whole
> thing breaking.

Oh right, Ive never used such a platform...

>
> Alternatively, a sealed computer in a locked room with no network
> connection (possibly).  It all depends on how paranoid you are.

For a web application? :)
Alex Y. (Guest)
on 2006-05-23 13:36
(Received via mailing list)
Kris wrote:
> Alex Y. wrote:
>>Alternatively, a sealed computer in a locked room with no network
>>connection (possibly).  It all depends on how paranoid you are.
> For a web application? :)
I thought you said you had sensitive data?  :-)
Kris (Guest)
on 2006-05-23 14:27
Yes and I'm looking for a way to allow it to be managed across the
web... It may not be possible to secure using this method of access.

Alex Y. wrote:
> Kris wrote:
>> Alex Y. wrote:
>>>Alternatively, a sealed computer in a locked room with no network
>>>connection (possibly).  It all depends on how paranoid you are.
>> For a web application? :)
> I thought you said you had sensitive data?  :-)
Ernest M. (Guest)
on 2006-05-23 15:23
Pascal H. wrote
> Hi folks!
>
> I discovered ruby some month ago and I liked it in a bunch of minutes.
> Then I was involved in a project using ASP.NET. At this point I had a
> dream ;-) Ruby that works on .NET (knowing ruby, neither VB nor C#
> fits!) .
> I found some material, but nothing useable or 100% .NET, so I took
> some time and decided to create a ruby compiler.
>
> Here it is... well, at least the first version which is early alpha.
>
> Get it, try it, read it, and tell me what you think. Is this project
> worth
> continuing?
>
> You can read some info about it and also download it here:
>     http://mortimer.devcave.net/projects/brite
>
> Cheers,
>
> Pascal H.

Have you looked at IronRuby, which includes both an interpreter and
compiler for .NET (2.0)?  See: http://wilcoding.xs4all.nl

^Ernest
Alex Y. (Guest)
on 2006-05-23 15:40
(Received via mailing list)
Kris wrote:
> Yes and I'm looking for a way to allow it to be managed across the
> web... It may not be possible to secure using this method of access.
You can't trust the client machine (unless there's another factor at
work here).  Nor can you necessarily trust any of the routers between
the server and the client not to try a man-in-the-middle attack.  Again,
  it depends how paranoid you want to be.

Of course, it's possible to *manage* data without exposing or
transmitting it, as long as your management can be done purely on the
basis of information digests rather than on the information itself, but
that's a whole other barrel of chipmunks.
Pascal H. (Guest)
on 2006-05-24 11:06
(Received via mailing list)
>
> Have you looked at IronRuby, which includes both an interpreter and
> compiler for .NET (2.0)?  See: http://wilcoding.xs4all.nl
>
> ^Ernest
>

Jeeeez, I didn't get this one! Seems far more mature than my Brite.

Thanx for the link.
This topic is locked and can not be replied to.