As part of a university project we tried to explore different options to support PyCall running on TruffleRuby (GraalVM). The choices we made are:
Using wrappers on top of Graal's Polyglot API (necessary to support API/behavioral differences compared to PyCall)
Disable native extension build for TruffleRuby (currently not compatible)
Rewrite/duplicate some files for TruffleRuby and load them conditionally if RUBY_ENGINE=='truffleruby'
In the current form it's working fine and passes almost all Unit Tests (except some that depend on native extensions and half of spec/conversion_spec.rb), but judging by code-review by @eregon the current structure of having duplicated code for the TruffleRuby variant might make it unmaintainable. Our thought was that merging the code and adding a lot of if RUBY_ENGINE=='truffleruby' might also be suboptimal.
We would like to ask you for your feedback: What do you think? What should be improved? How do you feel about enabling PyCall to run on TruffleRuby (GraalVM)?
As part of a university project we tried to explore different options to support PyCall running on TruffleRuby (GraalVM). The choices we made are:
RUBY_ENGINE=='truffleruby'In the current form it's working fine and passes almost all Unit Tests (except some that depend on native extensions and half of spec/conversion_spec.rb), but judging by code-review by @eregon the current structure of having duplicated code for the TruffleRuby variant might make it unmaintainable. Our thought was that merging the code and adding a lot of
if RUBY_ENGINE=='truffleruby'might also be suboptimal.We would like to ask you for your feedback: What do you think? What should be improved? How do you feel about enabling PyCall to run on TruffleRuby (GraalVM)?
(/cc @stefreschke @eregon @fniephaus)