<headius> good evening
<headius> byteit101: testing that patch locally now and then I will push
<headius> ahorek: I am seeing frozen string errors too
<headius> I don't see any recent commits that would cause this
<headius> ah this branch is behind
<headius> damn... byteit101 it seems to be your PR, I have no explanation
<headius> ugh no checks were running on your PR for whatever reason
<headius> I don't see what would cause it
drbobbeaty has quit [Ping timeout: 250 seconds]
drbobbeaty has joined #jruby
<headius> object_id
<headius> I think I have a lead
<headius> object_id is normally treated specially since it is lazily calculated
<headius> but I think the changes here turned it into a normal ivar
<headius> and we reject deduplicating strings that have ivars
<headius> maybe
<headius> those should all be the same object
<headius> the way these tests are written it will get the literal, deduplicate it, call object_id, which makes that object have vars... next one tries to get same object, deduplicate, but now it has vars so we make a new object
<headius> I'm going to revert for now to continue progress on 9.3.4... we can push a new PR with testing and figure out how to handle the object_id case along with the ivars
<headius> I still do not see the exact problem
<headius> byteit101: this is not your fault... I should have noticed CI was not running on that PR. I don't see an obvious reason why this breaks but I'm pretty sure object_id variable handling is the root issue
<headius> revert PR appears to be going mostly green (need to investigate recent changes to concurrent-ruby but the regressions are gone): https://github.com/jruby/jruby/pull/7146
<headius> ahorek: you can rebase your test PR or I can just recreate it locally along with a stdlib update
<headius> I will push a stdlib update momentarily
<headius> looks like only one change from 2.6.8 to 2.6.9 in the versioned stdlib files
<headius> enebo: range fix and circular cause fix are green and merging now
<headius> I have not slept so I will not be working during the day today
<enebo[m]> great
<enebo[m]> ok
<enebo[m]> I should get a fix in for kwrest
<headius> the ivar thing is something with object_id and the way byteit101 reworked stuff... it is reverted but I think we have time to fix that and gain some confidence
<headius> or we just punt to 9.3.5
<enebo[m]> I think the answer will be to mark the hash as kwrest splat and check it on way in during check_arity and then unmark it
<headius> yeah I read your analysis
<headius> looking forward to hitting kwargs hard after 9.4 so we can pipeline them through
<enebo[m]> yeah
<enebo[m]> They will increasingly become important so having them not create the hashes will be big
<headius> I have it planned out in my head
<headius> hmm github is not letting me close https://github.com/jruby/jruby/issues/7035
<headius> some error... "you can't comment at this time"
<enebo[m]> I closed it
<enebo[m]> not sure what is up
<headius> weird
<headius> logger release with that fix is out too, updating us
<headius> wow, github has some problems today
<headius> To github.com:jruby/jruby.git
<headius> ! [remote rejected] jruby-9.3 -> jruby-9.3 (Internal Server Error)
<headius> worked a second time
<headius> punted remaining 2.6 work to
<headius> enebo: only remaining marked issue is your kwargs thing
<enebo[m]> cool!
<enebo[m]> That also will give us a little more time for this all to settle
<headius> and whatever we decide to do with byteit101 ivar stuff
<enebo[m]> yeah I just saw the fallout without looking at any why
<enebo[m]> id is not atomic was all I really got out
<headius> it broke frozen strings by making object_id look like an ivar
<headius> we don't dedup strings with ivars
<enebo[m]> yeah
<headius> so if you call object_id on one then future attempts to dedup it will create a new one
<headius> I have not sorted out exactly why it is broken in the patch
drbobbeaty has quit [Ping timeout: 240 seconds]
drbobbeaty has joined #jruby
drbobbeaty has quit [Ping timeout: 240 seconds]
drbobbeaty has joined #jruby
<byteit101[m]> That's very strange. I assume the refactoring of the variable table manager is what caused this. Which test bucket was the failure in so I can look at this after work today?
<headius> byteit101: The code snippet above is a simple reproduction but running the specs in spec/ruby/language/string_spec.rb should report as well
<byteit101[m]> headius: thanks. I think I see the problem. will open new PR after dinner
<byteit101[m]> headius: new PR created https://github.com/jruby/jruby/pull/7150 Turns out I left in an extra increment that was now a duplicate (see last commit in that PR for the change)
<byteit101[m]> Tests kicked off...
<byteit101[m]> how concerned with the 8 failures should I be?
<headius> Ugh logger update regressed some stuff
<headius> byteit101: probably not your issue
<headius> This is not too surprising since I didn't update logger tests along with the gem
<byteit101[m]> cool. I rebased the commits on top so it should be a fast forward if you think the new PR is fine
<headius> Yeah I will take a close look this time and fix up my logger regressions before we go ahead
<headius> Thank you, I'm glad and not too surprised that it was just an increment out of place