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