<postmodern>
there, fixed the file names in the ruby-versions checksums database, so ruby-install will correctly verify the downloaded jruby release files again. https://github.com/postmodern/ruby-versions/issues/53
postmodern has quit [Read error: Connection reset by peer]
venuex has quit [Quit: was tired]
mattil has joined #jruby
mattil has quit [Quit: Leaving]
venue has joined #jruby
venue has quit [Client Quit]
enebo[m] has quit [Quit: Bridge terminating on SIGTERM]
JulesIvanicGitte has quit [Quit: Bridge terminating on SIGTERM]
TimGitter[m] has quit [Quit: Bridge terminating on SIGTERM]
MattPattersonGit has quit [Quit: Bridge terminating on SIGTERM]
kares[m] has quit [Quit: Bridge terminating on SIGTERM]
byteit101[m] has quit [Quit: Bridge terminating on SIGTERM]
kalenp[m] has quit [Quit: Bridge terminating on SIGTERM]
basshelal[m] has quit [Quit: Bridge terminating on SIGTERM]
ChrisSeatonGitte has quit [Quit: Bridge terminating on SIGTERM]
RobertNicholas[m has quit [Quit: Bridge terminating on SIGTERM]
MarcinMielyskiGi has quit [Quit: Bridge terminating on SIGTERM]
JesseChavezGitte has quit [Quit: Bridge terminating on SIGTERM]
ahorek[m] has quit [Quit: Bridge terminating on SIGTERM]
CharlesOliverNut has quit [Quit: Bridge terminating on SIGTERM]
GGibson[m] has quit [Quit: Bridge terminating on SIGTERM]
headius has quit [Quit: Bridge terminating on SIGTERM]
FlorianDoubletGi has quit [Quit: Bridge terminating on SIGTERM]
rebelwarrior[m] has quit [Quit: Bridge terminating on SIGTERM]
fzakaria[m] has quit [Quit: Bridge terminating on SIGTERM]
TimGitter[m]1 has quit [Quit: Bridge terminating on SIGTERM]
OlleJonssonGitte has quit [Quit: Bridge terminating on SIGTERM]
UweKuboschGitter has quit [Quit: Bridge terminating on SIGTERM]
RomainManni-Buca has quit [Quit: Bridge terminating on SIGTERM]
danieljrubyquest has quit [Quit: Bridge terminating on SIGTERM]
BlaneDabneyGitte has quit [Quit: Bridge terminating on SIGTERM]
lopex[m] has quit [Quit: Bridge terminating on SIGTERM]
liamwhiteGitter[ has quit [Quit: Bridge terminating on SIGTERM]
KarolBucekGitter has quit [Quit: Bridge terminating on SIGTERM]
JasonvanZyl[m] has quit [Quit: Bridge terminating on SIGTERM]
XavierNoriaGitte has quit [Quit: Bridge terminating on SIGTERM]
MatrixTravelerbo has quit [Quit: Bridge terminating on SIGTERM]
kai[m]1 has quit [Quit: Bridge terminating on SIGTERM]
demon36[m] has quit [Quit: Bridge terminating on SIGTERM]
ahorek[m] has joined #jruby
enebo[m] has joined #jruby
kai[m]1 has joined #jruby
lopex[m] has joined #jruby
MatrixTravelerbo has joined #jruby
byteit101[m] has joined #jruby
XavierNoriaGitte has joined #jruby
basshelal[m] has joined #jruby
MattPattersonGit has joined #jruby
ChrisSeatonGitte has joined #jruby
FlorianDoubletGi has joined #jruby
fzakaria[m] has joined #jruby
UweKuboschGitter has joined #jruby
demon36[m] has joined #jruby
CharlesOliverNut has joined #jruby
JulesIvanicGitte has joined #jruby
TimGitter[m] has joined #jruby
kalenp[m] has joined #jruby
OlleJonssonGitte has joined #jruby
BlaneDabneyGitte has joined #jruby
rebelwarrior[m] has joined #jruby
JesseChavezGitte has joined #jruby
liamwhiteGitter[ has joined #jruby
JasonvanZyl[m] has joined #jruby
KarolBucekGitter has joined #jruby
kares[m] has joined #jruby
RobertNicholas[m has joined #jruby
GGibson[m] has joined #jruby
danieljrubyquest has joined #jruby
RomainManni-Buca has joined #jruby
MarcinMielyskiGi has joined #jruby
headius has joined #jruby
TimGitter[m]1 has joined #jruby
venue has joined #jruby
mattil has joined #jruby
<headius>
g'day
<headius>
enebo: woot just saw 6777
<enebo[m]>
well not totally woot
<enebo[m]>
it should be now though
<headius>
so the method table change seems to be working out
<enebo[m]>
When I woke up I forgot I pushed that fix before stopping so I did not see it had a single regression
<enebo[m]>
yeah if you look at my PR you will see quite a few changes but most of those were me getting rid of the use of getNonIncludedClass to getOrigin
<headius>
yeah we should have done that a long time ago just to match terminology
<enebo[m]>
sharing the method was a couple of lines to IncludedModuleWrapper with a bunch of removed methods since we do not need to delegate any more
<enebo[m]>
I fixed two other prepend bugs not actually solved by this but they are tiny commits which can be evaluated pretty easily
<enebo[m]>
There is one more I am looking at for constant resolution of a included module which has been prepended
<headius>
ah yeah
<enebo[m]>
I can see if I do ancestors I see the right list but if I walk up superclasses it skips them
<headius>
I wonder if we could just rename PrependedModule
<headius>
it is not something I would ever expect third-party code to care about
<enebo[m]>
we have a lot of checks like 'attribute == other.attribute' to mean things like 'skip this it is prepended' which has made understanding this more difficult
<enebo[m]>
Yeah I thought about that too
<enebo[m]>
I would guess no one should be using it in an instanceof or constructing it directly
<headius>
yeah they do this.methodTable == that.methodTable checks in MRI too which are confusing
<headius>
getOrigin change looks so much better
<enebo[m]>
It also is shorter :)
<enebo[m]>
Another thing I was thinking about was making an isSame then I realized there was one so I made isSameOrigin
<headius>
yeah I see that
<headius>
yeah this doesn't look bad
<enebo[m]>
I thought about using it for things where we don't even neccesarily need to call getOrigin on one member just to make it more obvious
<enebo[m]>
For 3.0 logic we will also need to keep track of all includes/prepends on original module so when we change it via include/prepend all consumers of it will change
<headius>
so they do basically delegate like we always wanted to
<enebo[m]>
well it sure looks that way
<headius>
🙄
<headius>
should have been that way years ago
<enebo[m]>
yeah although the accounting sort of explains why they were resistant
<headius>
I see you have a PR for 9.2 as well, you feel pretty safe about it>
<headius>
?
<headius>
so frustrating that we can't mark more than one milestone for these prepend issues
<enebo[m]>
I landed one directly as it was just a mistake of not adding methodLocation.searchXXX if was only searchXXXX
<headius>
ok
<headius>
there's a mix of prepend issues marked for 9.2.20 or 9.3 right now, just reviewing updates
<enebo[m]>
This other one which is a PR atm is just removing using definedClass in AliasMethod for call(s) klazz
<enebo[m]>
which I would argue was the wrong behavior anyways if we were in the presence of a method containing a super
<enebo[m]>
I did not verify that but it looked wrong to me
<headius>
alias super behavior has changed subtly over the years too
<headius>
I think we still do it a bit differently than CRuby
<enebo[m]>
it was masking off findImplementer logic
<enebo[m]>
It might have been correct for some other setDefinedClass consumer maybe knowing it is the proper location to search if super is present but in the case of prepend I don't think that is right
<enebo[m]>
LOL ok...so definedClass is only used for prepend
<headius>
there's not much left on 9.3... reviewing to see what can be deferred
<headius>
I punted a couple obscure load issues to 9.3.1
<enebo[m]>
headius: and just to follow up...I recently changed milestones on those prepend issues to reflect where I planned on landing them
<enebo[m]>
2 of them are isolated enough to just go on 9.2 the super one donv opened is fixed (among other things) by sharing the method map
<enebo[m]>
that one I was less gung ho on considering backporting
mattil has quit [Ping timeout: 252 seconds]
<enebo[m]>
It feels bigger/riskier in a way I cannot really qualify
mattil has joined #jruby
<headius>
yeah cool I saw that bunch get retargeted and it will be great to have them gone
<enebo[m]>
The 2 I did back port are either completely broken (alias) or super obviously just doing it wrong
<headius>
I am looking at this thread kill race issue for a bit
<headius>
there's not much else that needs to go into 9.3 of the non-prepend stuff
<enebo[m]>
but with that said 'doing it wrong' makes me wonder how many more sites should be updated in our code base to do methodLocation.XXX
<enebo[m]>
I am hoping to fix the constant one and then the only open prepend issue is enumerable in JI which I do not think is likely really prepends issue
<headius>
nice this may be fixed by my handle_interrupt changes
<headius>
it is not hanging on master
<enebo[m]>
A spicy bonus would be if I could fix the two other prepend alias owner issues in ruby/spec that are tagged out
<enebo[m]>
Although owner of alias methods I doubt are all that important in real code
<enebo[m]>
Especially since they report weird anonymous classes
<headius>
yeah
<enebo[m]>
prepend on include which is then included is a weird beast codewise :)
<enebo[m]>
m = Module.new { def meth; :m end }
<enebo[m]>
c = Class.new { prepend(m); alias_method :alias, :meth }
<headius>
oh ruby
<enebo[m]>
owner of meth here should be c but it is likely some wrapper :)
<enebo[m]>
so I likely will only fix this if it is obvious (e.g. 30-45 minutes of puttering)
<enebo[m]>
I am really only boiling the ocean on these issues because 3.0 is a significant change and I want us to be pretty working on old behavior before changing it
<headius>
yeah for sure
<headius>
great leap forward
<headius>
yeah this seems fixed
<headius>
👍
<enebo[m]>
congrats
<enebo[m]>
ok the 9.2 thing says red but it ran out of meatspace in a jit job
<headius>
enebo: oh not sure if you saw but FFI changes backported to 9.2 look good now too
<headius>
that covers upgrading as well as the bundle issue where we activate FFI too early
<enebo[m]>
great
<headius>
zeitwerk test suite is nearly 100%, only three failures, so I closed the original issue and punted those failures to 9.3.1
<headius>
down to 9 open (milestone shows 10 but there's only 9 in the list) with 7 of those prepend related
<enebo[m]>
ok and only 1 of those 7 is not fixed
<headius>
I punted the open-ended fiber leak issue and will examine that in 9.3.1 along with the parallel fiber shutdown thing that eregon filed
<enebo[m]>
the optmized escapeCGI is part of prepend too if you were including that PR
<headius>
they may or may not be related but given the fact that fiber shutdown runs in parallel there is a potential for it to interfere with fiber termination
<headius>
shutdown runs in the GC and because it can trigger ensures and runs in parallel it may end up racing and messing up the locking structures involved
<headius>
enebo: last issue with bundler was also fixed by other updates
<headius>
so I'm thinking a round of gem and dependency updates
<enebo[m]>
sure thing
<enebo[m]>
may as well be current when we leave the gate
<headius>
yeah and there have been some good jnr updates recently