<headius>
the open question is whether we will continue to ship and support jruby-readline
<headius>
9.4 should be using reline now, I think, but we may still want to have jruby-readline as a known-working backup. I am not sure how compatible it is with the new IRB, however, but new IRB may explicitly use only reline anyway
<headius>
I have not done any work to make the one fall back on the other, nor much testing of IRB with jruby-readline or other readline things with reline
<enebo[m]>
headius: is this for 9.2/3 largely? You say older irb. I half wonder if we just update to newer irb in 9.2/9.3 and retire the project
<enebo[m]>
Unless those cannot run with the newer reline version
<headius>
9.2/9.3 will continue to use jruby-readline so it may be worth it to do this upgrade
<headius>
They might work with reline if the io-console fixes I made have been backported
<enebo[m]>
I wonder though could we just use a newer irb? I am not worried about compatibility in the case of irb so long as it works
<headius>
Those are in the gem now which master uses but it's the same code
<enebo[m]>
ah so there might be some risk with that idea
<headius>
I think the newer IRB always uses reline so that would have to be evaluated on 9.2 and 9.3
<enebo[m]>
I guess you answered your own question though. Since we will support older irb we potentially need to fix jrbuy-readline if it helps irb work better
<enebo[m]>
If newer can work it would mean retirement of jruby-readline sooner than later but if it involves potentially messing with IO we maybe don't want to
<headius>
I'm not entirely sure new IRB is fully functional on master either, but it should be close and has been continuously improving
<enebo[m]>
ah
<enebo[m]>
That is enough of a ? for me for 9.2 at least
<headius>
jruby-readline is basically equivalent to the CRuby readline-ext gem
<enebo[m]>
Does reline also emulate readline?
<headius>
They attempt to load that when you require readline, falling back on reline if it is not available
<headius>
Yes it is supposed to be compatible I believe but no dependence on a native library
<enebo[m]>
ok yeah cool.
<headius>
It should just require a fully functional io-console which we provide via FFI where possible
<enebo[m]>
reline/readline is UI-ish. I wonder if it has a test suite
<headius>
I think windows may be an issue there
<enebo[m]>
ah
<enebo[m]>
yeah I bet
<headius>
Terminal emulation on windows lol
<enebo[m]>
although io-console for MRI must have the magic...so we could duplicate that or maybe it just works
<enebo[m]>
I assume IO is tricky in Windows :)
<enebo[m]>
This is another issue for 9.4 (although perhaps not 9.4.0)
<headius>
io-console passes all the io-console tests on Linux and MacOS after my fixes but I have not attempted to make it pass on Windows
<headius>
well, all the tests except the ones that require forking a PTY
<headius>
enebo: eregon's latest spec update is still outstanding as well and we should decide how to handle new incoming failures considering our new WIP tag: https://github.com/jruby/jruby/pull/7126
<enebo[m]>
just got back from lunch....looking
<enebo[m]>
headius: 7131 The comment for the check was not obvious to me for a few seconds but your description in the issue is more clear. but my broader question on it is whether we know this is the cause of the originally reported issue. It makes sense that it could be
<enebo[m]>
I guess it does not really matter though. It seems likely it is a race so I am do not think it is a bad fix as much as wondering if it is the real cause of the issue which generated this PR
<headius>
I can't guarantee the cause is the same as the stack trace that commenter provided but it seems likely since the failing spec was related to closing an IO across threads while it is in use
<headius>
It's still an error but now it's a more appropriate error I guess
<headius>
I'm sure there are little races like this all over IO but multi-threaded use of an IO is somewhat undefined even in CRuby
<enebo[m]>
yeah
<headius>
And the code in question probably should be checking for a null FD anyway
<enebo[m]>
So I landed the marshal fix but it is mostly just time logic itself and not specific to marshal
<enebo[m]>
eregons PR I think should just be normal tags because none of them appear to be 3.0 or 3.1 behavior but I guess perhaps we need to triage all incoming tags and mark as WIP only if it is new behavior
<headius>
Yeah
<enebo[m]>
fwiw we probably should be eye-balling all incoming failures to make sure they are not really simple to fix
<headius>
ahorek confirmed my arch fix and has an additional one for the -m bit width flag
<headius>
I asked him to retarget it for 9.3
<enebo[m]>
nice
<headius>
we could probably use a 9.3.4 soon
<enebo[m]>
yeah
<headius>
enebo: I saw this httpx library released with some update for JRuby so I'm running tests, but the first thing that fails is due to JRuby.runtime not being defined anymore
<headius>
NoMethodError: undefined method `runtime' for JRuby:Module
<headius>
<main> at /Users/headius/projects/jruby-9.3/lib/ruby/gems/shared/gems/ruby-ll-2.1.2-java/lib/ll/setup.rb:10
<headius>
I'll look into that in ruby-ll
<headius>
oh great, this is a YorickPeterse project that has been abandoned
<headius>
yeah it is using Oga
<enebo[m]>
you can patch from httpx by requiring before it
<headius>
yeah I threw it in test_helper so I can at least run the tests