<headius>
enebo: I am going to push a separate PR for 9.3 since we aren't currently running any tests on 9.2... assuming that looks fine with updated JNR I will spin releases today
<enebo[m]>
sweet
<headius>
ssaschaa: thanks for the confirm on that 9.2 PR
<headius>
looking pretty good on 9.3 PR
<headius>
enebo: at some point we will want to consider walking away from 9.2 branch and only merging back targeted fixes
<headius>
9.3 seems to be going pretty well and the two branches are highly divergent now
<enebo[m]>
headius: yeah I think we are mostly there now
<headius>
any nontrivial change on 9.2 is a pain to merge
<enebo[m]>
we are only merging back reported issues with low risk
<headius>
right
<enebo[m]>
so I think we are fairly restrictive but we do need to make sure anyone on 9.2 has no 9.3 issues. I feel 2.5.x is so old people really want to at least be on 2.6
<headius>
yeah there's that too
<headius>
enebo: no reason I need to keep my kwargs PR open anymore right?
<enebo[m]>
headius: no. you can close it
<enebo[m]>
headius: we do still have some to_hash errors with kwargs but that obviously is new work
<headius>
did you do a PR I can reference?
<enebo[m]>
I don't think I did nope
<headius>
JNR updates look good
<headius>
I'm going to start spinning
<headius>
😵💫
<enebo[m]>
I have one exception from pattern match I introduced and it is NPE'ing but I don't see where
<enebo[m]>
until I type a sentence like this
<headius>
hah
<headius>
just do what I do and yell about your bugs while you work
<enebo[m]>
funny how that works. We line up pushes exactly and so that cannot be the issue but I realize this is nested and it pops which restores
<enebo[m]>
I am likely popping a null and not a object back
<headius>
M1 support will be a big one for 9.3.3 so we should prioritize it
<headius>
I'm trying to remember if there's anything else needed for 9.2 to support this
<enebo[m]>
pops are also lined up but they pass the value as temps in the yaccish grammar which makes it all a bit weirder
<enebo[m]>
yeah M1 is just more and more the thing which people will use
<enebo[m]>
Ruby is still mac heavy :)
<headius>
and then I can start using my M1 mini as a desktop for work when I hate my new Linux lappy
<headius>
THIS ISN'T FOR YOU IT'S FOR ME
<enebo[m]>
yeah it has already been foretold
subbu has joined #jruby
<enebo[m]>
although it may be the year of the linux desktop for you
<headius>
this MBP has gotten so slow (or feels slow) that anything will be step up
<headius>
I'm going to release this as minor jnr updates across the board since it doesn't add much other than Variadic annotation and just fixes broken logic on M1
subbu has quit [Ping timeout: 256 seconds]
subbu has joined #jruby
<headius>
enebo: so back to what I said above... should I merge the 9.2 PR and merge 9.2 forward or merge these separately and today is the day we stop merging from 9.2
<headius>
ssaschaa: I did not fix the 17 issues because they are present on current versions as well... will get back to that soon
<headius>
JNR releases are out!
<headius>
ah nevermind about merging.. it was easy anyway
<headius>
oh ok it was just due to no kwargs on receiver
<enebo[m]>
yeah I keep getting confused because I remember all the variations of this proposal
<enebo[m]>
I expected it to error or show nothing but this was a change to make older libraries not all require rewriting
<enebo[m]>
mri31 -e 'C = "constant"; def m()="method"; a = {C:, m:}; p a'
<enebo[m]>
{:C=>"constant", :m=>"method"}
<enebo[m]>
ok the constant bit is broken but yikes on this feature
<enebo[m]>
method does work but this makes sense. So on compiling this they do a constant check.
<headius>
wow wat
<headius>
so it works like defined?
<headius>
I hope people don't use that
<enebo[m]>
it is just using what they are defined as
<enebo[m]>
C = 1 would use 1
<headius>
does it?
<enebo[m]>
mri31 -e 'C = 1; def m()="method"; a = {C:, m:}; p a'
<enebo[m]>
{:C=>1, :m=>"method"}
<enebo[m]>
The question I have is why?
<headius>
yeah that is really an odd feature
<enebo[m]>
Are people having a strong desire to have capitalized keys?
<enebo[m]>
The insane part of that I just realized
<enebo[m]>
m: is doing a vcall of m
<headius>
at least we can still determine statically where the values come from
<headius>
or how to get them I mean
<headius>
m: there will always be populated by funcall
<enebo[m]>
The parser fills these in so it is static in that sense
<enebo[m]>
if ends up being {C: C, m: m}
<enebo[m]>
where m is not a valid variable but resolves to a vcall
<enebo[m]>
C is probably being made into a vcall and failing when it needs a little help in parser support to make it go "oh this is a constant" but I need to see how MRI does this
<headius>
just tried spec:ruby:fast and spec:ffi... the former failed because ant isn't installed on the MacStadium instance we have and the latter failed with some problem building the test library
subbu has quit [Ping timeout: 240 seconds]
subbu has joined #jruby
subbu has quit [Ping timeout: 240 seconds]
<headius>
segv in FFI specs trying to pass a Ruby function to C as a callback
<headius>
this might have something to do with limitations on data/exec memory on M1
<headius>
security stuff
<headius>
hah I thought I'd check if the C ext fixes this but they have gobs of M1 bugs that don't appear to be going anywhere
<headius>
Funny you should mention that... We just merged a bunch of fixes for M1 today
<headius>
They are not in a release yet but you could download a snapshot
<jamesgecko[m]>
Oh, whoops, I guess I should have scrolled up. Is M1 support still WIP? I guess I assumed Java was automatically portable.
<jamesgecko[m]>
It works! Kinda. Seems like Sorbet is just borked on this codebase, native binary or not, haha. Thanks!
<headius>
Great news! I would say support is still in progress but I just fixed the last major issue I knew of. Now we run through test suites and fix any straggling issues