<headius>
ok these failures are from the non-fiber test_backtrace.rb and probably never passed
<headius>
I am confused why they just showed up now
<headius>
duh
<headius>
I didn't use target thread's context for the backtraces when I refactored for fiber
<headius>
should be fixed now on master
razetime has joined #jruby
<headius>
well I managed to reproduce and fix the io-wait dependency issue on M1
<headius>
but env is still really wacky
<headius>
rake spec:ffi runs for me on that machine (segv partway through but it runs), but when running in CI it can't even load the dylib for testing
<headius>
the mvn -Ptest has some syntax error in the maven-ci shell script even though the shebang line points at bash
<headius>
byteit101: so I looked at those two snippits of code for adding opens at runtime and they both would require we open java.lang for reflective access... so it's not really a solution
<headius>
not sure I ever circled back to this but wanted to mention what I noticed
<headius>
enebo: I'm probably going to take the FFI m1 job out of circulation until I can spend some time figuring out why it's not building the test library right
<headius>
The other job running our core tests is working properly now that I upgraded bash on that machine
<headius>
Oh and I fix that back trace thing last night, it was just a dumb refactoring mistake on my part
<headius>
Other than continuing to fix work in progress stuff, is there anything specific you want me to do?
<enebo[m]>
headius: I think we should continue trying to run Rails unit tests looking for issues
<headius>
ok
<enebo[m]>
headius: I want to figure out whatever kwargs thing is wrong and I am wondering about looking into running tests in a variety of gems
<enebo[m]>
probably cloning and running tests locally
<enebo[m]>
we do have some issue with mocking Time::now which is problematic but a bit part of it is it is doing it in parallel
<enebo[m]>
I just do not remember how I was able to sequentialize that
<enebo[m]>
so activesupport unit test even running their one file at a time thing is still showing that messing shit up
<enebo[m]>
That one annoys me because I do not think it is us and it is not supporting concurrent changing of global constants while testing
<enebo[m]>
I think this week we need to close out what we will not be fixing and hopefully fix the rest of CI issues while also looking for active problems in Rails and other gems
<enebo[m]>
I have to stress ripper because I have high confidence small wrong type casts will happen like we saw last week.
<enebo[m]>
but kwargs is the other one. In looking at that selenium one I realized it jitted quite a few methods and it ocurred to me that fix arity has different kwargs setup logic. So just talking outloud but mixing up test with -X+C may also be a good idea
<headius>
ok
razetime has quit [Ping timeout: 260 seconds]
<byteit101[m]>
headius: ah ok, that's unfortunate. have you gotten a chance to look at the (short) second PR (PTY.spawn) yet?
<headius>
I'll review this afternoon
drbobbeaty has quit [Read error: Connection reset by peer]
drbobbeaty has joined #jruby
<headius>
enebo: what's the status of your launcher btw
<headius>
I am doing issue cleanup for now and just running into a couple launcher issues we have never resolved
<enebo[m]>
it hasn't advanced in a long time but it was a line for line port of nblauncher code which I now think we don't want
<enebo[m]>
we need a significant portion of what I wrote for parsing the command-line options but we should match the sh script
<enebo[m]>
and I have to convert from String to OsString since we can handle non-valid encoded strings
<enebo[m]>
(I may have done that last one)
<headius>
ok
<enebo[m]>
I am fixing zillions of ripper issues
<headius>
should I punt these to some other version then? 9.5?
<headius>
nice
<headius>
I just closed a half dozen IRB and readline issues that are good under new IRB and reline
<enebo[m]>
the good news is I found them before release and the bad news is MRI and spec coverage of ripper I think is not covering a lot
<headius>
heh surprise surprise
<enebo[m]>
The other value of doing Rails unit tests is showing how compat we are
<enebo[m]>
Kevin Newton's syntax_tree gem is very good at using ripper features
<headius>
maybe we should throw it into CI
<headius>
we could use more third-party libs in CI, especially if they exercise things that are weak in specs
<headius>
this is a good feeling, closing these old bugs
<headius>
just closed one about 9k having poor stack depth because we have great stack depth now
<enebo[m]>
Last I recall I asked kristian a question and didn't hear back but his example I don't think works at all
<enebo[m]>
Of course it would be great to fix that but I don't feel we have time to do much more than just address Ruby compat features and stability
<enebo[m]>
Perhaps we stab a few older outstanding things like this once we have 9.4.0.0 out
<enebo[m]>
Hardly feels like a reward for releasing but it is easy to punt on stuff like this
<headius>
I am punting larger structural changes to 9.4 but incremental improvements like this could go to 9.4.1
<headius>
s/4/5/
<enebo[m]>
yeah this is non-release sort of thing
<headius>
mostly I'm closing things that are fixed enough for 9.4 though!
<enebo[m]>
I mean it is specifically for a release but it is just something under the covers
<enebo[m]>
yeah that's cool. I am sure we have fixed lots of things
<enebo[m]>
I know I have fixed things that were not even 2.7 compat new so I am sure a few older reported issues ended up getting fixed
<headius>
yeah
<headius>
for once, waiting paid off... reline/new IRB has fixed a ton of problems we had with jline
<enebo[m]>
neat mri:test:extras I think had a number of E/F
<enebo[m]>
unless it was stdlib
<enebo[m]>
one of those two anyways
<enebo[m]>
headius: one release prep thing to also do is tag out all those openssl tests in MRI. I have not done it because I am unsure if we should not just disable it period or not.
<enebo[m]>
Probably has some value being run but we fail so many things I half wonder if we ever ran this in the past
<headius>
tests that are not tagged in wip?
<enebo[m]>
yeah.
<headius>
so they have never been running in our suites
<enebo[m]>
I don't know
<enebo[m]>
it is just like 150 F/E
<enebo[m]>
Which makes me think that is a lot
<enebo[m]>
which makes me ponder
<enebo[m]>
It could just all be new ciphers we do not have or some new method we did not add. I guess that is part of this activity