Compiling Ruby code

[Sean Russell]

I do not know if I can look at the source to make a
specification, then start working on a compiler that
is under a BSD license. Most of the code is copyright
by Matz and the companies that hired him. I do not
want any legal complications. --David

Hey David,

I just wanted to let you know that I'm all for you exploring this
(Ruby-to-native compiler). I'm a little distressed that the first
responses that you got to your posting were "it can't be done," "it
will be harder than you think," "you won't get the performance gain
you expect," etc., etc.. I think a native Ruby compiler *is*
possible, although some aspects will be difficult, and I'd *love* to
see a good one.

You might talk to Robert Feldt, or take a look at RockIt. I suspect
that Robert has a formal grammar for Ruby floating around somewhere
and has a pretty good specification in his head if not on paper. It
would be a pretty good place to start.

There are a number of unit tests for Ruby and Ruby code in the Ruby
CVS repository. You should be able to *use* those without violating
any white-room requirements you have.

Finally, you might just email Matz, and ask him to give you a
specific, written exemption from whatever IP or copyright restrictions
you're concerned about for this specific project.

--- SER

 

[Curt Hibbs]

Hey David,

I just wanted to let you know that I'm all for you exploring this
(Ruby-to-native compiler). I'm a little distressed that the first
responses that you got to your posting were "it can't be done," "it
will be harder than you think," "you won't get the performance gain
you expect," etc., etc.. I think a native Ruby compiler *is*
possible, although some aspects will be difficult, and I'd *love* to
see a good one.

I'd love to see one two!

What might be even better would a Ruby compiler for the .NET CLR -- now that
Mono has reached 1.0 that would immediately make it viable on Windows and
Linux.

Curt

 

[gabriele renzi]

I'd love to see one two!

What might be even better would a Ruby compiler for the .NET CLR -- now that
Mono has reached 1.0 that would immediately make it viable on Windows and
Linux.

IIRC Robert Feldt's student should end his 'ruby on the clr' project
in this days

 

[Bill Kelly]

Hi,

SR> it possible to distribute the application without distributing the
SR> source code to it. That isn't so important for us, but it may be for
SR> others.

Use ExErb, in version 3.2 it stores the node trees.

I read this with much interest (!) ... However I just
tried out exerb-3.2.0 and searched through the binary
and was able to see my source code there. I was hoping
that if it stores the node trees, my source code would
no longer be in ASCII form. Did I misunderstand?


Thanks,

Regards,

Bill

 

[Lothar Scholz]

Hello Bill,

BK> Hi,


BK> I read this with much interest (!) ... However I just
BK> tried out exerb-3.2.0 and searched through the binary
BK> and was able to see my source code there. I was hoping
BK> that if it stores the node trees, my source code would
BK> no longer be in ASCII form. Did I misunderstand?

I must say i didn't look at it exactly but in the source code of
exerb-3.2.0 there is a subdirectory "bruby-0.0.7" which contains the
code to read/write the binary node tree.

So i thought that there is some way to use it. But a short grep shows
that no file includes anything from "bruby". So i can't say if this is
a coming or a going feature.

 

[Lennon Day-Reynolds]

This chunk (from 'src/mod_bruby/mod_bruby.cpp' in the exerb-3.2.0
distribution) would seem suggestive:

static VALUE
mod_bruby_load_code(const char *code, const DWORD size, const char *filename)
{
::rb_raise(rb_eLoadError, "not implemented");
return Qnil;
}

So I think that the bruby hooks may indeed be unfinished.

In general, while I've used Exerb on a number of projects and found it
to be very convenient for simple distributions of Ruby apps, it lacks
a number of features that an ideal packaging tool would have for my
uses.

What *I* really want is just a quick way to statically link a set of
extensions into a custom Ruby interpreter. Ideally, it would also
include an arbitrary chunk of Ruby code (either as a node tree, or
just a constant C string) to be evaluated at startup. I don't need
obfuscation, just convenient packaging.

If I had the time to work on it right now, I'd probably be hacking
something up to do just that; as it is, though, all I can do is
complain and hope someone else will do it first.

Lennon

 

[Joel VanderWerf]

What *I* really want is just a quick way to statically link a set of
extensions into a custom Ruby interpreter. Ideally, it would also
include an arbitrary chunk of Ruby code (either as a node tree, or
just a constant C string) to be evaluated at startup. I don't need
obfuscation, just convenient packaging.

Don't know whether this qualifies as quick, but why not just put your
extension in ext/ and build it statically? You have to edit ext/Setup to
refer to your extension, so that the build process knows you want to
build it statically. For details, grep for Setup in README.EXT.

For QNX, I've ended up doing this for all extensions I use, both stdlib
and otherwise, because ruby on QNX seems to have trouble loading
dynamically.

But in any case, it has the effect of creating a custom ruby interpreter
with your libraries (well, the .so part anyway) built in. You still have
to load lib/ stuff separately, of course, so this may not help you.

I guess you could write a C extension that contains a huge string, which
has all your ruby code, and just evals that string at startup.

 

[Lennon Day-Reynolds]

Joel,

That's precisely what I was looking into; however, it would be nice to
have a somewhat more automatic way of doing all that housekeeping.
Basically, I want to just define the modules I'm using, and have a
driver script handle the source tree setup, building, and linking.

Lennon