<enebo>
actually I might be wrong...that is test:mri
<enebo>
I thought it was higher
<enebo>
well if it did cause regression I will deal with it
<kares>
it seems confusing - I smt get lost in the output
<kares>
maybe I was too eager to restart - seemed like it should go away (did not find anything useful)
<enebo>
kares: It has not made it to TestRational
<enebo>
so it may end up being a regression :)
<enebo>
man test:mri is maddeningly long on travis now
<enebo>
I half feel like breaking it into core and stdlib or something
<enebo>
but who wants to maintain that
<enebo>
kares: yeah I missed it all Numeric stuff does seem to have finished. ok I am happier now :)
<byteit101>
I managed to create this rspec test that fails on JRuby yet works on MRI (linux only (mac might work too)): https://gist.github.com/byteit101/241c5bb712c0d28930163ff0d88dc878 I'm not sure if this is a bug with jruby or my code, so wanted to see if anyone can find any easy flaws in my code before I filed an issue against jruby
<enebo>
byteit101: how much of that passes?
<byteit101>
MRI 3/3. JRuby 1/3
<enebo>
boo :)
<enebo>
byteit101: yeah readline is always weird for us
<enebo>
byteit101: I guess open an issue with this but do you plan on adding this to ruby/spec?
<enebo>
I guess this is rspec but it looks like a candidate
<byteit101>
I've noticed! I was trying to make an embedded irb instance and couldn't use the arrow keys, hence why I eventually got peeved enough to make a reduced test case
<enebo>
byteit101: is that fcntl bug filed already?
<byteit101>
Wasn't planning on it, but could. It's very timing dependant (hence the sleeps with comments about jruby speed :-)) and platform specific, but if it is an actual bug and not an obscure call that I missed, then sure
<byteit101>
No
<enebo>
byteit101: the sleeps do make me wonder what is up there. Probably you should be checking results of select
<enebo>
I know that is not the issue
<byteit101>
Also I couldn't figure out how to run it with the rspec executable (get concurrent modification exception) so I added the autorun call
<enebo>
hmm
<enebo>
possibly stdio mucking
<byteit101>
Well, so the select returns when the puts returns, then the value "=> nil" then jruby threads mean I have to wait for the prompt to appear. the last part is the slowest
<byteit101>
it was so fun making the after:each pass through the rspec output :-(
<enebo>
byteit101: it could be maybe the test could loop and read until select says nothing is left?
<enebo>
byteit101: or is the prompt not readable itself?
<byteit101>
well, the prompt varies between mri and jruby :-) They both have > characters though...
<enebo>
byteit101: I just mean if you call select n times at some point it will report there is nothing more to read
<byteit101>
no it will hang until something happens. not what we want
<byteit101>
(unless you add the timeout param)
<enebo>
oh heh my memory is not what it once was
<enebo>
I was thinking of a nonblocking select but I don't actually know anymore how that resolves to IO.select in ruby
<byteit101>
The prompt is easy to seach for relative to the rspec sleep on 114. That I have no idea what the output is (it is either colorded "." or "F" or test name information)
<byteit101>
enebo: a timeout of 0 would be nonblocking (http://ruby-doc.org/core-2.0.0/IO.html#method-c-select) , but that isn't particularly helpful in this case as I wait for threads to synchronize and want to wait
<enebo>
ah yeah that makes sense. Yeah I guess I was looking at select as an arbiter of whether you should be done reading
<enebo>
but I guess perhaps if we are super slow it may return n bytes then 0 bytes then m bytes
<enebo>
so it would still have same weirdness without adding basically a sleep time
<enebo>
(which I guess would then move it to select timeout)
<enebo>
it is not really material to demonstrating a different problem
<enebo>
so it is just a nose wrinkler :)
<byteit101>
yup, hence why I just added a sleep to get this spec "working" as I was a bit lazy and wanting to get it reduced yesterday
<enebo>
since if we added this test it would likely occassionally fail on travis these days
<enebo>
yeah anyways I guess file this as an issue and the fcntl as a separate one
<byteit101>
as is, yes. I can try and clean it up if you want
<byteit101>
ok!
<enebo>
headius loves bugs involving stdin, readline, and irb
<enebo>
:P
<enebo>
byteit101: so another wonderment is whether IRB is really intended to be leveraged as a library but I guess there are other gems which definitely use it
<enebo>
byteit101: not that we would not try and understand what isn't working
<enebo>
ignore my double negative
<byteit101>
enebo: Yea, here is what I created and found it behaving oddly (not sure if there is something better to use than IRB.start): https://gist.github.com/byteit101/1ac745e429a885e7e05e49cfee6f38e2 (we have a java program at work that has an.. interesting environment that i wanted to be able to inspect at runtime, but couldn't fork() in, hence this)