<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
fidothe has quit [*.net *.split]
fidothe has joined #jruby
mattil has quit [Quit: Leaving]