[–] pmq20 link

Currently it is just packaging, but when combined with work of @ko1 we could achieve real compiling in order to boost start-up speed and also protect intellectual properties.

I talked to @ko1 last year after his presentation about AOT compiling for Ruby at RailsConf, and it seems like we were missing a piece of the puzzle at that time, which is to preserve the file system structure after compiling, in order to accommodate `__FILE__` and `require` calls. I achieved it now with the help of libsquash(https://github.com/pmq20/libsquash). So now in runtime every path that begins with `/__enclose_io_memfs__/` got redirected to the memory, and so are your project files.

reply

[–] bjpbakker link

Preserving the file structure and deriving information from it at runtime (__FILE__, require, etc) is still totally not AOT compilation..

I can understand that you're just starting on the project and don't want to discourage you in anu way. But it might help if you reflect your projects goals but also the current status in the readme :)

reply

[–] chrisseaton link

Maybe you know something I don't, but I understand that Koichi's AOT is still just translating the Ruby source code to bytecode which is then interpreted. It isn't AOT to native code.

reply

[–] bjpbakker link

You are correct. AOT compilation for ruby would translate the internal AST into machine code.

While serializing Ruby files in byte code might be a good idea (I don't know enought of the internals of MRI so I can't judge that), it's still not AOT compilation

reply

[–] kronos29296 link

So it compiles your code into a bundle with ruby interpreter so that you don't need one during execution? It sounds like what youtube-dl does in Windows by adding the interpreter to the executable. Useful but not in speeding things up but in packaging without dependencies.

They should probably mention that in the README because it is ambiguous and I thought it was a bytecode or binary compiler for Ruby at first.

reply

[–] bjpbakker link

IMO there's not mich ambiguity in AOT compilation; it /compiles/ the code ahead of time. This tool is just not that. It /copies/ the code ahead of time. There's not really an advantage in that (maybe distributing a single file, but that's it).

Maybe the author should consider describing it as packager or something else.

reply

[–] rubyfan link

As I was skimming README, I was thinking "what's the catch?"

And there it is, you're absolutely right this is not an AOT compiler.

reply

[–] bjpbakker link

This is /not/ AOT compilation of ruby code.

It simply compiles a ruby interpreter and adds your code to the executable (as memfs).

The output is an executable that /interprets/ ruby code.

reply

[–] hursortue link

https://duckduckgo.com/?q=%22that+just+works%22

<Product name>. <What it does>, that just works. Made by <name> in <city> with love.

reply

[–] sk0g link

It just works, passing tests and all that fancy stuff is out of the project's scope.

reply

[–] dankmemes420 link

http://i.imgur.com/MVOSH81.png

I can't be the only one

reply

[–] ksec link

A lot of people have complained about the lack / difficulties of Ruby Programs distribution. I remember the Authors of Vagrant said one of the reason why he switched to Go was that.

And this solves that problem.

reply

[–] funkaster link

As suggested by other comments, this is not really AOT, more like a bundler (not that bundler) or packer. It prepacks a Ruby interpreter with your files/libs/deps. Useful and interesting, but not an AOT.

reply

[–] kej link

While still useful, this appears to be more of a bundler than a compiler, per se.

reply

[–] undefined link
[deleted]

reply

[–] bjpbakker link

Fairly easy. It's inside a memfs in data section in the binary.

reply

[–] mkarklins link

How easy would it be to retrieve the ruby source code from the distributed binary?

reply