-
-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Supporting TruffleRuby through using RubyNext #168
Comments
Yeah for sure. I'd welcome it if you could restrict the platform to just truffleruby. (I don't want to inflict a dependency on folks that aren't on it.) Long-term yeah syntax tree is going to drop its dependency on ripper and just used the shared library. |
The workflow seems to be to generate some extra files just before packaging/releasing a gem: https://github.com/ruby-next/ruby-next#integrating-into-a-gem-development |
I think we could probably check |
@eregon truffleruby should now be working except for the language server (I still need to remove the pattern matching there). Could you give it a shot? |
Yes, I tried to run |
Let's close this since the gem loads on TruffleRuby now. |
Playing a bit more with RubyNext and desugaring some test files I'm down to Many of them are Also some of these, which I'm not sure why it happens:
|
Running the tests on latest |
Adding TruffleRuby in CI in #183 |
From phlex-ruby/phlex#157
https://github.com/ruby-next/ruby-next could be a nice way to support TruffleRuby in
syntax_tree
until TruffleRuby has full pattern matching support (which will likely require the new parser, the existing one seems too buggy to support hash patterns and other cases).@kddnewton Would you be open to a PR using https://github.com/ruby-next/ruby-next to make syntax_tree on TruffleRuby and potentially other Rubies? I might give it a try.
It's not ideal because Ripper is rather slow on TruffleRuby (it's a lot of C ext code to warmup), but it should work.
P.S.: I guess longer-term the new parser would probably also be used for syntax_tree or instead of it? Although I guess if Ripper uses the new parser there might not need to do anything and it'd still use the new parser under the hood, it'd just be an extra indirection in between.
The text was updated successfully, but these errors were encountered: