subbu has quit [Quit: Leaving]
<headius> enebo: added
<enebo[m]> headius: thanks. I am just knocking off individual issues to make all our other test pass
<enebo[m]> yesterday I got the overall set to look much more green
<headius> nice
<enebo[m]> 1) Java::JavaNet::URL can used with 'open-uri' and passed to #open and yield an IO
<enebo[m]> That is the last failure of spec:ji
<enebo[m]> After this the only red is sequel/concurrent-ruby/spec-ruby/test:mri
<headius> I can look into that before I get back to kwargs
<enebo[m]> Look at sequel
<headius> I want to see that JI error
<enebo[m]> no implicit conversion of Java::JavaNet::URL into String
<headius> heh
<headius> odd thing to break
<enebo[m]> yeah and the only thing to break
<headius> something changed in open-uri I would guess
<enebo[m]> a) it somehow had to_path and lost it b) convertToString stopped working
<headius> or it is not patching Kernel#open right
<enebo[m]> oh does it patch kernel#open. Ok that makes sense since it is dying in kernel#open
<enebo[m]> it is likely not patching it at all
<headius> well I'm checking that now
<headius> they may have stopped patching it
<enebo[m]> elsif name.respond_to?(:to_str) &&
<enebo[m]> (uri = URI.parse(name)).respond_to?(:open)
<enebo[m]>*rest, &block)
<enebo[m]> %r{\A[A-Za-z][A-Za-z0-9+\-\.]*://} =~ name &&
<enebo[m]> There is logic here
<headius> commit 53862fa35887a34a8060aebf2241874240c2986a (tag: v0.1.0)... (full message at
<headius> so they did remove the override in 3ish
<headius> deprecated in 2.7
<enebo[m]> heh
<headius> so this just needs to switch to calling
<enebo[m]> yeah. I will change it
<headius> ok
<headius> there's a 0.2.0 open-uri, I will check if they have shifted 3.0 to that yet
<headius> and the answer is no
<headius> it was just released in oct
<enebo[m]> The literal/maybekwarg change I think caused these extra params. I think this is all that is broken on concurrent-ruby
<headius> yeah that could be
<headius> what is on master is kinda half switched to that new flag
<headius> I have glanced at sequel before and at least a few of these are due to kwargs breakage
<enebo[m]> ruby-concurrent and sequel might both be fallout from the start of this. It is less clear on sequel since it appears to be using ruby2_keywords directly
<enebo[m]> I am going to switch over to pruning down errors on one of the two large suites today
<enebo[m]> I should work on prepend but I am not feeling that quite yet :)
<headius> ok
<headius> I will look into why test:mri:core is hanging
<headius> looks like stdlib hanging too
<headius> so much of this:
<headius> test/mri/ruby/test_literal.rb:581: warning: ... at EOL, should be parenthesized?
<enebo[m]> hanging?
<headius> they are hanging on CI
<enebo[m]> I am seeing results at the bottom
<enebo[m]> am I looking at the wrong runs?
<enebo[m]> I cancelled the run
<headius> oh
<enebo[m]> Look at last one run
<headius> yeah I didn't want to look there because it was still running several
<enebo[m]> Our queue is small enough where if I push something else I am just killing the last running one
<headius> ok they are completing
<headius> you shouldn't need to kill some of these but I'm not sure the rule... it will not run stale jobs that have not started
<headius> I'm not sure what granularity that is on though
<enebo[m]> I although thought both these were about 200-250 F/E for each and they are over 400 so maybe the literal changes?
<headius> could be
<enebo[m]> TypeError: wrong argument type Integer (expected Symbol)
<headius> I see a lot of Integer coercion errors in the test framework
<headius> looking into that
<enebo[m]> This is weird message
<headius> yeah they are all in core_assertions
<enebo[m]> I see those but through multiple seemingly unrelated methods
<headius> this looks like another kwargs problem
<headius> it is trying to munge some **opts and getting integer keys that are unrelated
<enebo[m]> ah ok
<headius> hmm
<headius> or this has not been updated for ruby 3 kwargs
<headius> res_p, res_c = IO.pipe
<headius> opt[res_c.fileno] = res_c.fileno
<headius> and then it does **opt later
<headius> that
<headius> that would seem wrong for 3.0 kwargs
<headius> I will gank the test/lib stuff from CRuby 3 branch again and see if this changes
<headius> our copy scripts don't copy that so it is a bit manual
<headius> hmm it seems to match
<headius> oh test/tool
<headius> ok we are just wrong here I guess
<enebo[m]> yeah makes sense that they ratcheted down actual kwargs to require proper symbol keys
<headius> you are not reading that right
<enebo[m]> does that also fail if key is a string?
<headius> they allow this through
<enebo[m]> oh they allow it
<headius> bottom is us
<enebo[m]> that does not make sense but nothing surprises me
<headius> I think the rule is bare **opts without other keywords will still allow weird keys through?
<headius> unsure
<enebo[m]> hahah
<enebo[m]> These things make me wonder if it is intentional or not
<headius> Ruby 2.6.5 also errors so this changed in 2.7
<headius> I can remove our check for symbols but then it splits the opts into a separate hash and passes that as an argument
<headius> so that is not a sufficient change to fix this
<headius> it seems clear to me that we have too many failures due to broken kwargs to really iterate properly
<headius> I'm going to go back to my branch and see if I can start to bifurcate the two kwarg-processing paths
<headius> I've merged master to my kwargs branch and will push that to see how test runs look
<headius> it may be better but still needs ruby2_keywords logic restored along some path
<enebo[m]> and ruby2_keywords was not really too hooked up to begin with
<enebo[m]> it was mostly implemented enough for a hash to just know it was one or not
<headius> [] ~/projects/jruby $ rvm ruby-3.0 do ruby -e 'def foo(**opts); opts[1] = 2; bar(**opts); end; def bar(**opts); p opts; end; foo(a: 1)'... (full message at
<headius> oops
<headius> heh ok
<headius> it can't bundle so it won't get far
<headius> I will try a local run since I'm already bundled here but this needs a lot more work
<headius> seems a bit too broken though
<headius> Yeah I'm going to have to back this change off even though it was a good experiment
<headius> Restart the work by taking current logic and setting it aside for Ruby two keywords
<headius> uff-da this code
<headius> I'm restarting by getting ruby2keywords and keyword arguments flags in the right places and propagating them
<headius> rather than having a separate concrete subtype for KeywordsHash it will be less cumbersome to just use a flag on RubyHash
<headius> also added a ruby2keywords flag to IRScope and trying to honor that in frobnicate and other places
<headius> hmm well conservative start doesn't break bundler so that's progress
<headius> this only splits frobnicate and processBlockArgs and doesn't add much logic in either but let me know if the flags and propagation seem right
<enebo[m]> headius: looks reasonable as a start. We keep old logic through that variable
<enebo[m]> we obviously need the state around to know what to do too
sagax has joined #jruby