<headius[m]>
starting to suspect this is a false error
<headius[m]>
give that command line a try and I will look into glibc code
<enebo[m]>
This works for me
<enebo[m]>
Although I am using master
<headius[m]>
can you try 9.2.14
<headius[m]>
working theory at this point is that some waitpid logic, either in libc or in our binding, is not being sanitary about errno
<enebo[m]>
yeah almost built
<headius[m]>
so the waitpid call returns the pid as though it was successful, but errno is EAGAIN for some unrelated reason
<enebo[m]>
still works
<headius[m]>
fascinating
<headius[m]>
what is your glibc version?
<headius[m]>
actually you could check 9.2.13
<enebo[m]>
2.2.5 I think (I used nm)
<headius[m]>
I have not actually confirmed this on anything but 9.2.13 on fzakaria image
<headius[m]>
mrnoname says it happens on musl too
<enebo[m]>
still works
<headius[m]>
that would start to point back at jnr-ffi not being tidy
<headius[m]>
ugh but if it works for you that is so confusing
<headius[m]>
bottom line at this point is that we should be checking for -1 retval in any case, which would fix it, but I want to know why errno is not 0 after a successful waitpid
<enebo[m]>
yeah
<headius[m]>
waitpid code falls into kernel very quickly and I can't find my way through that
<enebo[m]>
afk a little bit
<headius[m]>
let me know what kernel version when you are back
<enebo[m]>
headius: 5.8.13-200.fc32.x86_64
<headius[m]>
ok
<headius[m]>
I pinged Andrew Haley about this because he pinged me a couple months ago about some weird rogue EAGAIN during JVM process logic
<headius[m]>
he thought it was our fault but in the end he found some kernel module was causing it
<enebo[m]>
yeah if I remove **kwargs from MRI run no to_hash is called
<headius[m]>
ok so I am getting a picture
<headius[m]>
9.2 looks the same
<enebo[m]>
So we pass in a HashMap and because it has to_hash and **kwargs exists it does it...pretty weird but I believe this is how it works
<headius[m]>
so this may actually be correct logic but HashMap should perhaps not to_hash
<enebo[m]>
your Class.new helps a lot in proving that
<headius[m]>
which would be in keeping with other coercion methods... to_str, to_ary etc are supposed to only work for a natural string or array I think
<headius[m]>
people don't follow that but maybe JI should
<enebo[m]>
So this references rspec...did something break?
<headius[m]>
yeah something in rspec expectations introduced a **kwargs format and it caused the incoming value to get converted
<headius[m]>
it was a recent change to better support kwargs in expectations
<enebo[m]>
but this will happen to any code which happens to pass a single element which has to_hash on it
<headius[m]>
so it caused our specs to fail because the HashMap started getting converted
<headius[m]>
it was "fun" to diagnose
<headius[m]>
yeah so this isn't a bug
<headius[m]>
but I am leaning toward JI HashMap not doing to_hash
<enebo[m]>
so either a) we should remove to_hash if it is so common but then I think we will get other reports b) tell them this will likely cause confusion for them as well
<headius[m]>
that is the new debate I guess
<headius[m]>
yeah like you say I dunno if this has a fix
<headius[m]>
this is the behavior
<enebo[m]>
Another thought would be to do to_hash and return self
<headius[m]>
so if they are going to have **kwargs in this call path they will risk converting expected values that define to_hash
<enebo[m]>
Ultimately that would probably duck type properly but would not reflect properly
<headius[m]>
that seems like a bigger risk... if anything to_hash should return a natural hash
<enebo[m]>
well I would argue anyone who depends on to_hash would be surprised to see it go away too
<headius[m]>
HashMap can still have a to_h
<headius[m]>
yeah but is that a thing?
<enebo[m]>
but I don't know the use case of this
<headius[m]>
most people call to_h
<headius[m]>
internals may call to_hash though
<enebo[m]>
yeah I really cannot comprehend the scope of this
<enebo[m]>
it is so implicit
<headius[m]>
or this could be argued as an rspec bug and they should not be causing coercible objects to follow a path where they will coerce
<headius[m]>
right
<enebo[m]>
I also wonder how much people even know to_hash is happening too
<headius[m]>
you and me
<headius[m]>
and the folks wrestling with 2.7/3.0 kwargs behavior
<enebo[m]>
yeah I can say from a pure-Ruby perspective it could happen but will anyone notice
<headius[m]>
maybe I should file an rspec issue and tag some folks that are kwargs adjacent
<enebo[m]>
some object which is not Hash but will make one but once made will stop working in the spec
<enebo[m]>
In cases like that it would be someone inappropriately defining something which is not really a hash but then by that logic is anything a hash which is something more than a hash?
<headius[m]>
this implicit trailing arg logic goes away in 3.0 it seems
<headius[m]>
deprecated in 2.7
<headius[m]>
(which I agree now we should just skip and make 9.4 be 3.0)
<headius[m]>
or JRuby 10k
<enebo[m]>
yeah 2.7 having transitional behavior which is neither 3 not 2.6 seems not worth it
<headius[m]>
I will file an rspec issue... at least get more input on this
<headius[m]>
and my vote is for removing HashMap.to_hash in 9.3
<enebo[m]>
well it will be interesting to see if anything even stops working in our test suite
<headius[m]>
true
<headius[m]>
will do it as a PR
<headius[m]>
would not change in 9.2.x in any case
<enebo[m]>
At some level the need to make something a real Ruby Hash should be muted by duck-typing on the Ruby side
<enebo[m]>
OTOH if you make HashMap -> Hash on Ruby and then pass it back to Java then it will stay a Ruby Hash but act like a HashMap with per element coercion
<enebo[m]>
by not doing that it will stay unconverted on Java side but on Ruby side it will do per element coercion all the time
<enebo[m]>
So logically I think we are fine but from a performance notion people may notice hash in Ruby slow down in a case
<enebo[m]>
The workaround is not difficult but it is an observable change maybe for someone...or maybe not :)
<enebo[m]>
What actually calls to_hash though :)
<headius[m]>
yeah not much
subbu is now known as subbu|away
<enebo[m]>
9.3 is significant and I guess we can see
<enebo[m]>
I don't know if the rspec usage is enough to convince me we are doing anything wrong but to_hash is pretty toxic in kwargs now