An unholy amalgam of therubyracer's V8 engine and emscripted-ruby to allow a truly sandboxed Ruby-on-Ruby environment.
MIT License
An unholy amalgam of therubyracer's V8 engine and emscripted-ruby to allow a truly sandboxed Ruby-on-Ruby environment. This is a terrible idea.
Add this line to your application's Gemfile:
gem 'ruby_on_ruby'
Or install it yourself as:
$ gem install ruby_on_ruby
As with any usage of therubyracer, you'll need to install v8 with your package manager or use the libv8
gem (currently ~> 3.11.8
). See therubyracer's installation instructions for more information.
require 'ruby_on_ruby'
context = RubyOnRuby::Context.new
context.eval "(1..10).inject(1) { |fact, n| fact * n }" # => "3628800"
Ruby MRI 1.8.7
Only through assignment and return values, at the moment. If emscripted-ruby provides a more complete API, so can I. For now, it's probably best to communicate over simple structures and do things like this:
context.eval "a = #{my_ruby_data.inspect}"
context.eval "result = process a"
result = eval(context.eval("result"))
# Horrible, right? Right!
Nope. Available RAM ought be enough for anybody. (According to emscripted-ruby, "The Ruby garbage collector is currently incompatible with Emscripten, so we disable it completely. This causes memory leaks, but prevents crashes.")
Sometimes.
That depends. For your problem, is three orders of magnitude slower acceptable? Remember: Ruby scales! Just run it on three orders of magnitude more servers.
(Also, the same code may be up to an order of magnitude FASTER than native, non-sandboxed Ruby if you write it in JavaScript and run it with therubyracer, or with RubyOnRuby::Context#js_eval
.)
No comment.
This code is released under the MIT License. You can use it however you like. I recommend that you not, and will not be held accountable if you do.
git checkout -b my-new-feature
)git commit -am 'Added some feature'
)git push origin my-new-feature
)