eval functions with panic safe implementation #79
  Add this suggestion to a batch that can be applied as a single commit.
  This suggestion is invalid because no changes were made to the code.
  Suggestions cannot be applied while the pull request is closed.
  Suggestions cannot be applied while viewing a subset of changes.
  Only one suggestion per line can be applied in a batch.
  Add this suggestion to a batch that can be applied as a single commit.
  Applying suggestions on deleted lines is not supported.
  You must change the existing code in this line in order to create a valid suggestion.
  Outdated suggestions cannot be applied.
  This suggestion has been applied or marked resolved.
  Suggestions cannot be applied from pending reviews.
  Suggestions cannot be applied on multi-line comments.
  Suggestions cannot be applied while the pull request is queued to merge.
  Suggestion cannot be applied right now. Please check back later.
  
    
  
    
This requires a version bump in
ruby-sysfor the new eval methods and then theCargo.tomlhere can be set to that version.The code works as is now but I have a few questions. Before those questions I'll explain that I've chosen to use
rb_eval_string_protectforVM::evalsince it allows us to get a standardResult<AnyObject, c_int>back and we won't need to worry about it crashing our program. Therb_eval_stringI added as an unsafeVM::eval_strbecause any exceptions raised crash the program. So until we have exceptions implemented I figured this would be the safer Rust way to do it.My questions are whether we should have
VM::eval_strat all since I've marked it as unsafe. Should theVM::evalbe enough and I remove the other method since we don't have exception handling? If so I would suppose the binding for that should go for now, or maybe#[allow(dead_code)]?Of course once we have exceptions implemented then I would expect the
VM::evalmethod to switch from therb_eval_string_protecttorb_eval_string.Thinking out loud: But thinking about the way Rust works I believe that any time an exception is, or can be, raised then methods should return a
Result<AnyObject, Error>and it would be nice forResultto implement thetry_convert_todirectly on it. Errors can still be of typeAnyObjectbut return types in general would make more sense as aResultand just re-implement casting to theResulttypesOkandErr. Those are my thoughts on that.TODO
ruby-sysupdate and updateCargo.toml