07:03 <headius> good evening

07:03 <headius> byteit101: testing that patch locally now and then I will push

07:46 <headius> ahorek: I am seeing frozen string errors too

07:47 <headius> I don't see any recent commits that would cause this

07:50 <headius> ah this branch is behind

07:56 <headius> damn... byteit101 it seems to be your PR, I have no explanation

07:58 <headius> ugh no checks were running on your PR for whatever reason

08:00 <headius> I don't see what would cause it

09:00 <headius> object_id

09:10 <headius> I think I have a lead

09:10 <headius> object_id is normally treated specially since it is lazily calculated

09:10 <headius> but I think the changes here turned it into a normal ivar

09:10 <headius> and we reject deduplicating strings that have ivars

09:11 <headius> maybe

09:11 <headius> those should all be the same object

09:15 <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

12:27 <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

12:27 <headius> I still do not see the exact problem

12:29 <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

12:54 <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

13:00 <headius> ahorek: you can rebase your test PR or I can just recreate it locally along with a stdlib update

13:00 <headius> I will push a stdlib update momentarily

13:07 <headius> looks like only one change from 2.6.8 to 2.6.9 in the versioned stdlib files

14:44 <headius> enebo: range fix and circular cause fix are green and merging now

14:44 <headius> I have not slept so I will not be working during the day today

14:44 <enebo[m]> great

14:44 <enebo[m]> ok

14:44 <enebo[m]> I should get a fix in for kwrest

14:45 <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

14:45 <headius> or we just punt to 9.3.5

14:45 <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

14:45 <headius> yeah I read your analysis

14:45 <headius> looking forward to hitting kwargs hard after 9.4 so we can pipeline them through

14:45 <enebo[m]> yeah

14:46 <enebo[m]> They will increasingly become important so having them not create the hashes will be big

14:47 <headius> I have it planned out in my head

14:47 <headius> hmm github is not letting me close https://github.com/jruby/jruby/issues/7035

14:48 <headius> some error... "you can't comment at this time"

14:48 <enebo[m]> I closed it

14:48 <enebo[m]> not sure what is up

14:48 <headius> weird

14:51 <headius> logger release with that fix is out too, updating us

14:53 <headius> wow, github has some problems today

14:53 <headius> To github.com:jruby/jruby.git

14:53 <headius> ! [remote rejected] jruby-9.3 -> jruby-9.3 (Internal Server Error)

14:53 <headius> worked a second time

14:55 <headius> punted remaining 2.6 work to 9.3.5.0

14:55 <headius> enebo: only remaining marked issue is your kwargs thing

14:55 <enebo[m]> cool!

14:55 <enebo[m]> That also will give us a little more time for this all to settle

14:55 <headius> and whatever we decide to do with byteit101 ivar stuff

14:56 <enebo[m]> yeah I just saw the fallout without looking at any why

14:56 <enebo[m]> id is not atomic was all I really got out

14:56 <headius> it broke frozen strings by making object_id look like an ivar

14:56 <headius> we don't dedup strings with ivars

14:57 <enebo[m]> yeah

14:57 <headius> so if you call object_id on one then future attempts to dedup it will create a new one

14:57 <headius> I have not sorted out exactly why it is broken in the patch

16:38 <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?

20:41 <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

21:59 <byteit101[m]> headius: thanks. I think I see the problem. will open new PR after dinner

22:38 <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)

22:38 <byteit101[m]> Tests kicked off...

22:59 <byteit101[m]> how concerned with the 8 failures should I be?

23:14 <headius> Ugh logger update regressed some stuff

23:14 <headius> byteit101: probably not your issue

23:15 <headius> This is not too surprising since I didn't update logger tests along with the gem

23:16 <byteit101[m]> cool. I rebased the commits on top so it should be a fast forward if you think the new PR is fine

23:19 <headius> Yeah I will take a close look this time and fix up my logger regressions before we go ahead

23:19 <headius> Thank you, I'm glad and not too surprised that it was just an increment out of place