<byteit101[m]> headius: possible ffi answer for solaris https://www.phoronix.com/scan.php?page=news_item&px=Oracle-Solaris-11.4-CBE
subbu has joined #jruby
subbu has quit [Ping timeout: 246 seconds]
subbu has joined #jruby
adam12 has quit [*.net *.split]
adam12 has joined #jruby
nilsding has quit [*.net *.split]
subbu[m] has quit [*.net *.split]
subbu[m] has joined #jruby
subbu has quit [Ping timeout: 256 seconds]
nilsding has joined #jruby
subbu has joined #jruby
subbu has quit [Ping timeout: 256 seconds]
wybpip[m] has joined #jruby
wybpip[m] has left #jruby [#jruby]
ccmywish[m] has joined #jruby
<JasonLunn[m]> What's the current state of support for beginless ranges? From https://github.com/jruby/jruby/issues/6464 it looks like the task is done, which seems consistent with the change history of RubyRange. But when I fire up jirb and try it out, I get a syntax error. Is there a flag I need to set?
<enebo[m]> Jason Lunn: It is on master which will be in 2.4 which is Ruby 3.1. So we are jumping from 2.6 to 3.1
<enebo[m]> It is already implemented and I don't think we have any outstanding broken tests for it
<JasonLunn[m]> So I'd need to build from source in order to kick the tires at the moment?
<JasonLunn[m]> 👍️
<enebo[m]> I got here from this link so you should be able to find your way back.
<headius> good morning!
<headius> stringio pre gem is released and hooked up in https://github.com/jruby/jruby/pull/7178
subbu has joined #jruby
<headius> oops, missed a reference
<headius> byteit101: oh nice
subbu has quit [Quit: Leaving]
<headius> aha, and removed something stringio needs... I'll also fix that in the gem
<headius> there now CI is looking a bit better
enebo has joined #jruby
enebo has left #jruby [#jruby]
<headius> enebo: what's your status on that delegation stuff?
<headius> I want to get the test suites green but I know a couple were blocked on that... if you have a branch I could work from there
<enebo[m]> headius: I am working on redoing kwargs as we speak
<enebo[m]> Some things work and some don't but it is not yet as good as it is on master
<enebo[m]> and of course this is only suspected to be part of the issue with root delegation from rails but it seems likely to be the issue
<headius> I can review the red suites and see if I can find some that are easy to fix
<enebo[m]> There are definitely still quite a few specs/tests to be knocked down
<headius> yeah I want to try to get the non-compat suites green though so we have a better idea of regression there
<enebo[m]> I think biggest missing feature might be the fiber/io scheduler but I am unsure how important that is to running
<headius> JI, etc
<headius> I doubt Rails does anything with fiber/io/scheduler right now
<enebo[m]> interestingly a couple of months ago they all were passing (JI/compiler)
<enebo[m]> all our internals except I think we had some failures in regressions (and each time I hit one of those it was that Ruby changed so the test was not needed)
<headius> yeah I will have a look
<headius> I saw some gem and yaml-related failures in test:jruby that are likely just bad tests now
<headius> yaml safe load stuff
<enebo[m]> heh something is epicly broken in spec:compiler
<headius> yeah core dump
<headius> shouldn't be possible
<enebo[m]> wow I even forgot about this
<enebo[m]> I asked you to look at the code I was trying to set keyword2 things at the top of the emitted scope
<enebo[m]> It was not crashing the JVM but it was for sure not working properly
<enebo[m]> With that said the new keyword stuff may possibly change things...nonetheless fixing that on HEAD would maybe make a lot of F's go away and possibly fix the suite
<headius> I'll see if I can figure anything out or file an issue with openjdk
<enebo[m]> This has actually been maybe 3 months or so since I even was looking at that
<enebo[m]> but the crash itself was not happening in the past so I don't get that
<headius> hmm running locally they all fail with verification errors
<enebo[m]> yeah it is the thing I was mentioning
<headius> the crash may be something different about the zulu jvms
<headius> we have juggled these suites around the past few months
<enebo[m]> so the scope.recievesKeywordArgs() section to call frobnicateKwargsArgument is broken
<enebo[m]> if you remove it then the verification error will go away but it should be doing that in a ruby2keywords method
<enebo[m]> It is also possible the new keyword_arg instr can perform this so this could probably go away but I am still wondering what I did wrong
<headius> $ jruby -Xdebug.parser -Xjit.logging -X+C -e 'def foo2(a); a + yield.to_s; end; foo2("baz") { 4 }'
<headius> 2022-04-18T14:35:35.984-05:00 [main] ERROR Ruby : failed to compile target script: -e - Bad type on operand stack
<headius> simple enough to repro in any case
<enebo[m]> yeah super simple
<enebo[m]> 100% of all JIT
<enebo[m]> I think the args push is the broken part
<headius> the jit logic looks ok
<enebo[m]> I spent like an hour on it and could not see what I was doing wrong
<enebo[m]> I assume I somehow have an extra item left on the stack that maybe the next thing is seeing and going nope
<headius> ALOAD -1
<headius> it is not getting an index for args from signature
<enebo[m]> ah
<headius> because there's no args
<headius> this is failing for zero-arity methods because it blindly tries to load args and mark them
<headius> I will fix
<enebo[m]> aha
<headius> this failure is your fixme section
<enebo[m]> I knew you would figure this out quickly. It was why I didn't spend time
<headius> should that be in the receivesKeywordArgs?
<enebo[m]> yeah I think it will be
<enebo[m]> but it can't hurt to make sure the JIT is working as well as the interp with current design
<headius> I can try moving it up there and assume that it is always IRubyObject[] signatures then
<headius> my old code was doing some arg juggling but only in this block
<headius> yeah is this all going to change though?
<headius> I can try to match current interp but is it useful?
<enebo[m]> well the main change is a new instr and that new instr can also do the ruby2keyword logic
<enebo[m]> I am not doing it yet because I am still trying to get this basic ruby3 stuff working
<enebo[m]> the main changes besides that instr in the JIT will be to pass a live UNDEFINED/RubyHash for keyword arg to all recv_* and check_arity instrs
<headius> ok
<headius> yeah makes sense
<enebo[m]> that new instr does make this seem simpler but I am getting a nagging feeling about order of execution coming into play
<headius> after this change, spec:compiler down to 8 failures
<enebo[m]> but no issues with that...just having "feelings"
<enebo[m]> ok cool
<enebo[m]> I probably made those 8 failures too :)
<headius> these look like valid compat changes
<enebo[m]> oh ok great
<headius> yeah it's two failures times four modes
<headius> same two failures that look like compat
<enebo[m]> hahah yeah and I just added that error checking last week
<headius> so that is probably an invalid spec now
<enebo[m]> well the top-level error the circular came with parser updates
<enebo[m]> they all are only as much as they need to be nested into something
<enebo[m]> circular ones I don't know though
<enebo[m]> oh yeah those are all invalid
<headius> could be new restriction due to masgn order of operations
<enebo[m]> they are no longer allowed
<headius> yes
<headius> so that one I will just delete
<headius> the other one might be ok with a global or something
<headius> oh I see
<headius> it is testing several variable types
<headius> but they appear to be at top level for these tests so we can't test @@a this way
<enebo[m]> yeah global probably fixes the other one
<enebo[m]> so that is the same test just run in a loop for modes?
<enebo[m]> err same two tests run in 4 modes
<headius> I can just remove the class var lines here
<enebo[m]> ah
<enebo[m]> instance vars will have same issue
<enebo[m]> I just did not fix it because I realized this should error like this in an eval as well as top-script but I don't really understand why that is
<enebo[m]> in mspec there will be it "fsdklfjklsdfjkl" { eval "@@should_error" }
<enebo[m]> but how can that be top-level scope?
<enebo[m]> It potentially is a series of nested closure scopes which happen to be in a top-level script scope
<headius> I am wrapping these in methods to avoid the scoping issue
<enebo[m]> ah yeah that makes sense
<headius> ok, I pushed this change and spec:compiler is green
<headius> this may clear up some other things so I will let it chew for a bit
<headius> Oh I fixed the M1 runner to run as a service and restart properly, it seems like every time GitHub updated it it would refuse to come back up so hopefully this will be better
<headius> So we had a bunch of builds that never ran because it didn't come back up
<headius> weird, I am not getting these other compiler failiures locally
<enebo[m]> I am done for today but I will share how far I have gotten
<headius> rspec './spec/compiler/general_spec.rb[3:85]' # JRuby's jit passes kwargs through zsuper correctly
<headius> rspec './spec/compiler/general_spec.rb[3:97]' # JRuby's jit combines optional args and zsuper properly
<headius> rspec './spec/compiler/general_spec.rb[3:87]' # JRuby's jit passes keyrest arguments through zsuper correctly
<headius> those are only failing on CI
<headius> and this is in the commit where I changed that kwargs line
<headius> so I think I'm not going to messs with it further
<enebo[m]> Things are a little dirty so I am not yet read to commit but gem list runs/ rake runs/mspec runs but only in interpreted mode as I am not touching JIT until this is ironed out
<headius> very nice
<enebo[m]> I think there may be some old code I am hitting but I want to completely pass all kwargs and cleanup
<enebo[m]> I am guessing tomorrow interpreter will be ok unless I find some unexpected fatal flaw
<enebo[m]> The funny IR story of the day was I added keyword as an operand to several instructions
<enebo[m]> I extended an existing class which extended NoOperandInstr
<enebo[m]> This meant when doing analysis it did not see I was using the keyword variable anywhere and DCE would remove the get_keyword instr
<enebo[m]> This in turn would set the temp for the variable to null
<enebo[m]> but we null guard temps so it ended up becomding a nil
<enebo[m]> It was not nearly as obvious and I described but I was "how the hell can this thing be a ruby nil?"
<enebo[m]> The bigger issue is virtually nothing runs at this stage so I cannot just run some scripts
<enebo[m]> but once I figured out the instr had disappeared it was obvious
<headius> hah that is rather involved
<enebo[m]> 3490 files, 28325 examples, 109059 expectations, 16 failures, 24 errors, 1620 tagged
<enebo[m]> So that should be 3F for me locally so I still have some debugging
<enebo[m]> but it is pretty close
<headius> eliminating null guarding is left as an exercise for the reader
<enebo[m]> yeah I think this was a tradeoff of not puting nil copy assigmnets to all temp vars on all paths
<enebo[m]> no explicit init will just end up being null so we pay a little hit
<headius> ok these are only failing in indy
<enebo[m]> I do think I went into indy for some of this and I thought it was working but maybe I didn't change everything
<headius> non-indy run on 8 is green so that's progress
<enebo[m]> passing values to whatever gets bootstrapped I remember was a little jarring
<headius> need to see what would be different
<enebo[m]> dinner...but I should have someone on a branch tomorrow
<headius> ok cool
<headius> I will get this green tonight
<enebo[m]> I may not have JIT but I am hoping to have interp with no kwargs issues
<headius> and then see how we are on the other peripheral suites
<enebo[m]> dinner prep
<headius> these are all zsuper
<headius> ttfn
<enebo[m]> heh...that sounds familar :)
<headius> I thnk I found it
<headius> the meaning of the boolean passed into literal hash construction flipped from meaning kwargs to meaning literal but only the non-indy path inverted it
<headius> they should be green now