peko[m] has joined #jruby
<reydi[m]> <headius> "reydi: could you file a bug at..." <- yes i did! https://github.com/byteit101/subspawn/issues/2
<reydi[m]> thanks for responding headius
<reydi[m]> <byteit101[m]> "headius: all gems from https://..." <- right, i saw this commit. then as i described on the issue i reported, i tried to `$ rake binary` from the master branch, the libfixposix.dylib now exist, but i'm still stuck with the... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/233b0c9dccfee00201dfc86d17591819b010b8c6>)
<reydi[m]> * from the latest master branch,
<reydi[m]> * i did! cc byteit101 https://github.com/byteit101/subspawn/issues/2
<byteit101[m]> reydi: try the "all-gems" download from the linked run. I'll look into the build failure later today hopefullly
<headius> gonna take a step back this morning to get master green
<headius> stupid indy failures that I thought I'd fixed
<headius> ah at least I found the aborted work I did to fix this method_missing thing: https://github.com/jruby/jruby/commit/bfb070d51b274064fb9824b9099988d1647fba01
<headius> this never landed because it dug too deep and caused other problems... I guess I forgot I reverted this part of the fix
<headius> ok simple fix for the method_missing problem is to just revert direct indy binding of user-created method_missing
<headius> we'll revisit it later but this logic needs some refactoring
<headius> splitting is probably applicable here too so that will force us to do more
<headius> I see this filling up logs in at least the indy mri:core job
<headius> /home/runner/work/jruby/jruby/test/mri/ruby/test_thread_queue.rb:553: warning: deprecated Object#=~ is called on FalseClass; it always returns nil
<headius> guess I shoul dlook into that too
<headius> it doesn't fail but warns thousands of times
<headius> hmm or maybe it does fail something
<headius> TestThreadQueue#test_queue_close_multi_multi [/home/runner/work/jruby/jruby/test/mri/ruby/test_thread_queue.rb:555]
<headius> some method redefinition concurrency thing maybe
<enebo[m]> hmm
<byteit101[m]> reydi or headius: Grab & install ffi-binary-libfixposix-java gem from https://github.com/byteit101/subspawn/actions/runs/5016320107 and let me know if that works on m1 macs
<byteit101[m]> If it does, I'll try to tag a release
<headius> byteit101: I'm still getting that SO_VERSION error
<headius> I installed the binary for amd64-darwin and the bindings
<headius> from all-gems on that build
<byteit101[m]> No, java
<headius> oh
<byteit101[m]> This is where we failed last time iirc :-)
<headius> loads ok with that installed
<byteit101[m]> (I mean you can test MRI if you wnt)
<headius> ahh right the java one has all the binaries
<byteit101[m]> Yup
<byteit101[m]> Ok, so the -java binary works for you on arm apple?
<headius> yeah seems to work here on M1
<headius> yes
<byteit101[m]> Yay!
<byteit101[m]> Only took... 4 months to confirm xD
<headius> so tag off and then we can upgrade what we install for JRuby build
<byteit101[m]> Awkwardly I did this fix in the middle of win32 work
<headius> I will send you auth info for the MacStadium M1 instance; there's a couple GH runners on there now but they're idly 99% of the time
<byteit101[m]> oh great!
<headius> so we just need to set up another runner for your stuff
<headius> two existing = one for JRuby and one for JNR
<headius> runners are at org level I believe
<byteit101[m]> I'm not sure if I can get to this before the weekend, still lots of post-vacation stuff I need to do, but at least we have a confirmed fix.
<byteit101[m]> I'll update the ticket now
<byteit101[m]> then I'll backport the fix soonish
<byteit101[m]> Hopefully release tomorrow or over the weekend
<byteit101[m]> And we can maybe discuss the win32 issues after that?
<headius> ok no problem
<headius> yeah I am back home for a while now
<headius> I also have win32/arm64 running in parallels so we can try to cover that too
<byteit101[m]> I'll need to split the ci-run target as right now it assumes it's running on intel GHA
<headius> byteit101: seems like your dm is not getting e2e encryption
<byteit101[m]> Ah, this is an old build, let me try something
drbobbeaty has quit [Quit: Textual IRC Client: www.textualapp.com]
<headius> ok
drbobbeaty has joined #jruby
peko[m] has quit [Excess Flood]
<headius> ugh I can't get this encoding thing to fail in isolation
<headius> enebo: you around today?
<enebo[m]> headius: yeah
<headius> if you could try this on linux maybe it will fail for you
<headius> jruby -Xcompile.invokedynamic -Xjit.threshold=0 test/mri/runner.rb --excludes=test/mri/excludes:test/mri/excludes_wip test/mri/ruby/test_m17n_comb.rb -n test_str_squeeze
<headius> my linux machine is not accessible at the moment
<enebo[m]> ok
<headius> I'm trying a full run locally to see if it's some multi-faceted issue
<headius> it's tough because these nonblock tests still hang on macOS (and always did I think)
<enebo[m]> 1 tests, 3779 assertions, 0 failures, 0 errors, 0 skips
<headius> phooey
<headius> I don't even have a theory why this would fail with indy in CI
<headius> it's basically "".force_encoding("ASCII-8BIT").squeeze("\x80".force_encoding("EUC-JP"))
<enebo[m]> Its a block?
<enebo[m]> is it 50 in?
<headius> jit mode testing so it should be threshold=0
<headius> I can try without threshold 0 and 50 iters though
<headius> yeah still seems to fail every time
<headius> locally
<headius> 2023-05-18T15:58:25.4508382Z 1) Failure:
<headius> 2023-05-18T15:58:25.4508898Z TestM17NComb#test_str_squeeze [/home/runner/work/jruby/jruby/test/mri/ruby/test_m17n_comb.rb:1200]:
<headius> 2023-05-18T15:58:25.4510324Z [ArgumentError, Encoding::CompatibilityError] expected but nothing was raised.
<headius> 2023-05-18T15:58:25.4509767Z "".force_encoding("ASCII-8BIT").squeeze("\x80".force_encoding("EUC-JP")).
<enebo[m]> hmm
<enebo[m]> race is all I can think of but what?
<enebo[m]> dedup somehow
<headius> frozen-strings is false
<headius> I'll have to dig deeper into how this test is set up
<headius> could be something with how the strings are being compiled
<headius> argh
<enebo[m]> my fun arg is spending 35 minutes trying to decode optparse to realize while is not working right then realize yarp is returning keyword_while_modifier for a keyword_while and compiling it as an until