lucf117 has quit [Remote host closed the connection]
sagax has quit [Excess Flood]
<headius>
Good morning
<headius>
enebo: thoughts on that FFI backport?
<headius>
if we want to commit to fully backporting, to align 9.2 with current FFI and allow the ruby sources to be gem-upgraded, we need to have larskanis push a release
<enebo[m]>
headius: you landed it already right?
<headius>
no
<enebo[m]>
headius: I think it is ok I guess. We will be on a multi-release train and ffi has gotten quite ab it of attention this year
<headius>
I can't land it because it doesn't run tests right until the FFI gem loads right
<headius>
I asked larskanis to do a prerelease that supports 9.2.20 so we can try it out... we can decide if it goes in that release or 9.2.21 once it is green
<enebo[m]>
oh ok
<enebo[m]>
sorry I missed the "hit a snag" comment above
<enebo[m]>
headius: I somehow thought you were asking about something which landed but I think I misread the PR. Seems like if the 9.2 loading is fixed we can land and evlauate if we find problems? ffi is a strange library in that it is probably used in many more ways than we have tests for
<enebo[m]>
with that said I am not as worried about that as much as massive changes to shelllauncher
<enebo[m]>
but we need to fix problems too
<enebo[m]>
some risk is unavoidable
<headius>
9.2 loading is not fixed because the fix is in FFI ruby sources
<headius>
so we either hand-patch those sources again or bite the bullet and get the build using the gem
<enebo[m]>
MONKEY PATCH
<enebo[m]>
I am kidding
<headius>
ShellLauncher gutting will be post 9.3
<headius>
what's another round of hacks among friends
<enebo[m]>
as you said we can manually patch but then we lose the upgrade path unless next ffi release fixes it
<headius>
we have been upgrading manually up until 9.3, and then I finally aligned our ext with the gem and started using the stock rb files
<headius>
but it has gotten harder because the changes get a little bigger each time
<headius>
and we can't really say we ship FFI version X compatible logic
<enebo[m]>
yeah. so two more reasons to get ffi 9.2 capable
<headius>
if we get that prerelease gem I will finish the PR and we can see how drastic it is
<headius>
most of the changes were not big but in a few cases Java classes were deleted in favor of newer pure-Ruby versions... so that is a larger risk
<enebo[m]>
I guess if we can "if" then we try and see if we can break something after that
<headius>
but it is working on master for many months
<enebo[m]>
yeah I guess I never know what that means since it has no official release but we know it works enough for the stuff we test (and some people are definitely playing with master)
<headius>
and if future fixes come into gem's ruby sources 9.2.x users will be able to get them
<headius>
the main issue was not unwrapping singletons, so a top-level autoload would go in the wrong place
<headius>
however I had to add a second version of `getRealClass` called `getRealModule` because `rb_class_real` works on both modules and classes and they use that here
<headius>
I tried to life realClass logic from RubyClass into RubyModule but it gets messy with all the constructors. We will want to revisit caching the real module so it doesn't do this walk every time, and try to unify the two impls, but it is fine for this case