<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?
<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>
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>
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>
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
<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