<kares>
lopex: hey! there actually is ... 1.7 hasn't upgraded jossl (if you're using that)
<kares>
ooh on reloading - in that case feel free to ignore me :)
sam2000 has joined #jruby
prasunanand has joined #jruby
sam2000 has quit [Ping timeout: 246 seconds]
alxs has joined #jruby
alxs has quit [Ping timeout: 258 seconds]
olle has joined #jruby
olle has quit [Client Quit]
<kares>
headius: hey! you should check-out some smaller but "officially" linux supported vendors for a laptop
<kares>
personally do not have experience with these but would love to (except shipping to EU is price-y and in case of issues covered by warranty I need to sent it overseas) :
<cprice404>
if there's anyone around today who knows anything about what happens when you write Java code that iterates over a RubyArray object, you would be my friend :)
<enebo>
cprice404: well I can answer that
<enebo>
:)
<cprice404>
yay
<enebo>
cprice404: when Ruby Array makes it into Java it implements java.util.List
<enebo>
cprice404: so we do not convert the entire array when it crosses the boundary BUT when you access ala next() it will perform coercion
<enebo>
cprice404: our iterator() is return new RubyArrayConversionIterator();
<cprice404>
i'm trying to debug this jruby-openssl thing, and what I'm seeing is that I have two objects which, in Ruby, show up as type "OpenSSL::X509::Certificate". when they cross into the java code, one of them is passed in as a normal ruby object, and one is wrapped in a RubyArray.
<cprice404>
on the java side when i print the java class of the one that was passed in as a normal RubyObject, the java class shows up as "org.jruby.ext.openssl.X509Cert",
<cprice404>
but then if I iterate over the RubyArray,
<cprice404>
and print the java class of the "OpenSSL::X509::Certificate" object that is in the array,
<cprice404>
I get a different class back - something from the bouncycastle package.
<cprice404>
so it feels like something that is happening in the coercion is different for the one inside of the RubyArray
<cprice404>
does that sound plausible?
<enebo>
cprice404: sure although it should be the same
<cprice404>
i'm not sure if I'm barking up the right tree or not, but it seems odd that for two objects with the same Ruby class, they would show up on the Java side with different java classes
<enebo>
cprice404: I can see we call toJava(Object.class) in the iterator
<enebo>
cprice404: I am not so involved in JI changes of last year or more but kares might more readily know the differences
<enebo>
cprice404: in theory when you move to Java and ask for Java-usable version it should be doing the same thing if they really are the same thing
<enebo>
so you basically next() it to a Java reference and ask it to print out it’s java class right?
<cprice404>
if I do 'puts x.class', 'puts y.class' on the ruby side, and get the same value back, does that satisfy the definition of "they really are the same thing"? Or is there something beyond that that I shhould be keeping an eye out for
<cprice404>
I'm doing a 'for (Object o : myRubyArray)' iteration in java and then printing "o.getClass()"
<enebo>
cprice404: a nicer repro would be to take x and pass it both ways to eliminate that question
<enebo>
cprice404: through things like become_java! and Java procy objects I think it is possible those two puts could print out the same name but not be the same
<cprice404>
if you look at lines 17/18 they are showing that the objects have the same ruby class, then line 21 calls into java
<cprice404>
on the java side I immediately print out the java type of ee1_cert, and then loop over the array to print out the java type of ca2_cert, and they give different values
<cprice404>
but i can probably try passing in one of the two certs for both args
<enebo>
cprice404: at a glance it looks reasonable to expect this to work
<enebo>
cprice404: here is something to try for fun: [ca2_cert].to_java(java.util.List)
<cprice404>
another really weird symptom is that this seems to have been introduced solely by upgrading bouncycastle; as best as I can tell, with older versions of bouncycastle, the java types come out the same, and then when the upgrade to a newer bouncycastle happened, the types stopped matching - seemingly without *any* changes to the jruby-openssl code
donV has quit [Ping timeout: 245 seconds]
<cprice404>
k, i will try that
<enebo>
cprice404: ah intersting
<enebo>
cprice404: without knowing what issue_cert is doing the snippet would impl all the certs are made the same way
<cprice404>
yes, as best as i can tell that is true
<enebo>
cprice404: but maybe ca_2 is made weirdly and not backing it iwith the Java type expected
<enebo>
cprice404: you can also try printing out ancestors or spelunking in the structure of each cert
<cprice404>
they all appear to go through the same "ObjectAllocator", which is fairly simple
<enebo>
ok
<cprice404>
switching back to the problematic branch so i can try what you suggested above with the to_java
<enebo>
cprice404: Also try my original idea of using same object in list and non-list args
<cprice404>
ah, yeah
<enebo>
cprice404: it will not work but your print on Java side should be interesting
<enebo>
cprice404: if you see the right type from array then you know it is openssl code and not our JI
<cprice404>
the 'to_java' calls on the ruby side all seem to return the bouncycastle java class,
<cprice404>
i added a snippet of what I'm printing on the java side,
<cprice404>
and the output from that is still showing two different java classes
<cprice404>
it could definitely still be a bug on the jruby-openssl side but I just don't have a good sense of what to look for in terms of how the objects are coerced
<cprice404>
FWIW the objectAllocator, to the extend that I understand it, is just doing 'return new class org.jruby.ext.openssl.X509Cert()' in all cases, so I'd sort of expect that to be the java class that shows up in all cases
claudiuinberlin has joined #jruby
<cprice404>
hmmm, so it appears that the 'toJava' method inside of this class gets called when we are accessing objects inside of a RubyArray, but it does *not* get called when we are just interacting with the RubyObject directly... does that make sense?
<cprice404>
the 'toJava' method is definitely returning a different thing than what the original RubyObject is
maclover7 has joined #jruby
maclover7 has quit [Client Quit]
subbu|lunch is now known as subbu
<GitHub91>
[jruby] headius pushed 2 new commits to ruby-2.4: https://git.io/v1vnU
<GitHub91>
jruby/ruby-2.4 fcfb94a Charles Oliver Nutter: TRUE / FALSE / NIL These constants are now obsoleted....
<GitHub91>
jruby/ruby-2.4 e52c4a8 Charles Oliver Nutter: Merge remote-tracking branch 'origin/master' into ruby-2.4
<GitHub59>
[jruby] eregon pushed 5 new commits to truffle-head: https://git.io/v1vlf
<GitHub59>
jruby/truffle-head f63d3b1 Benoit Daloze: [Truffle] Check if we already rewrote to a call node....
<GitHub59>
jruby/truffle-head 9d2cb83 Benoit Daloze: [Truffle] We need to pass the updated receiver and arguments when rewriting to a RubyCallNode....
<GitHub59>
jruby/truffle-head a4b3300 Benoit Daloze: [Truffle] Update comment in InlinedCoreMethodNode.
<enebo>
cprice404: file an issue on JRuby and ping kares to me this feels like a JI issue
claudiuinberlin has quit [Remote host closed the connection]
claudiuinberlin has joined #jruby
claudiuinberlin has quit [Remote host closed the connection]
claudiuinberlin has joined #jruby
<cprice404>
enebo: I've already got a few issues opened and I think kares has seen them. thanks for your help.
<enebo>
cprice404: yeah you passed in the same object in two ways and it is being coerced differently
<enebo>
cprice404: so whatever we are doing in our current method mapping logic for coercing is different from that iterator
<cprice404>
well, the iterator appears to call '.toJava' implicitly, and I think the implementation of '.toJava' for that class might be bad
<enebo>
cprice404: and that could make sense since we examine type signatures on method calls
<cprice404>
but they might *both* be issues ;)
<enebo>
cprice404: yeah I agree…it is tough to know
<enebo>
cprice404: actually I did not read the Java part closely enough
<enebo>
final Object nestedCert = mychain.get(0); —> final Object nestedCert = mychain.eltOk(0);
<enebo>
cprice404: if you do this then it should be the same but this code appears to be native ext code only…if you pass that array to a Java library then that coercion will happen
<enebo>
cprice404: but as written I am not surprosed soemthing it different
<enebo>
cprice404: only because you are passing this into a @JrubyMethod
olle has joined #jruby
<cprice404>
interesting. what is 'eltOk'?
<GitHub146>
[jruby] nirvdrum pushed 1 new commit to truffle-head: https://git.io/v1v0b
<GitHub146>
jruby/truffle-head c2d4c15 Kevin Menard: [Truffle] Bump from JVMCI-enabled JDK 8 version 8u92-jvmci-0.22 to 8u111-jvmci-0.23.
FINbit has quit [Ping timeout: 240 seconds]
olle has quit [Quit: olle]
<GitHub55>
[jruby] headius pushed 3 new commits to ruby-2.4: https://git.io/v1vEX
<GitHub55>
jruby/ruby-2.4 f77b626 Charles Oliver Nutter: Cleanup.
<GitHub55>
jruby/ruby-2.4 80e046d Charles Oliver Nutter: Enumerable#uniq...
<GitHub55>
jruby/ruby-2.4 49be498 Charles Oliver Nutter: Comparable#clamp....
<GitHub154>
[jruby] chrisseaton pushed 1 new commit to truffle-head: https://git.io/v1vuc
<GitHub154>
jruby/truffle-head 14f3823 Chris Seaton: [Truffle] Make a separate copy of MRI stdlib again, so we're isolated from JRuby's update to 2.4
<GitHub191>
[jruby-openssl] cprice404 opened pull request #114: Fix ClassCastException in X509Store.verify (master...bug/0.9.18/bc_classcast_in_x509store_verify) https://git.io/v1vuE
<cprice404>
enebo: that ^^ PR fixes the specific test failures I was seeing, but I have no idea if that's a sane way to fix it. I pinged kares on the PR. Thanks again for your help!
sam2000 has joined #jruby
<enebo>
cprice404: was at store…but that is how we access array ellements when it is still a ruby object
<nirvdrum>
enebo: On these OpenFlag issues on Windows, do you know if native is disabled?