3 ms·

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

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.

kronos29296 9y ago
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.
- bjpbakker 9y ago
  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.
rubyfan 9y ago
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.
pmq20 9y ago
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 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.
- chrisseaton 9y ago
  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.
  - bjpbakker 9y ago
    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
- bjpbakker 9y ago
  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 :)

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.

kronos29296 9y ago

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.

bjpbakker 9y ago
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.

rubyfan 9y ago

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.

pmq20 9y ago

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 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.

chrisseaton 9y ago
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.
- bjpbakker 9y ago
  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
bjpbakker 9y ago
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 :)