TimGitter[m]1 has quit [Ping timeout: 244 seconds]
<enebo[m]1>
headius: I have been changing those over time...intellij gives a warning in every file that it is a danngling javadoc
JulesIvanicGitte has quit [Ping timeout: 240 seconds]
TimGitter[m]1 has joined #jruby
<enebo[m]1>
I will look to see if Arity has any extra imports anywhere. In many cases Arity is still in the same files because of deprecated methods but I may have missed some
<headius[m]>
Ok maybe we should just do a single pass and fix them all
<headius[m]>
It looked like random formatting change in the pr
JulesIvanicGitte has joined #jruby
<enebo[m]1>
To be fair it is only a minor annoyance to see the yellow tick at the top of the file but I do see some value in the warning if we increase how much javadocs we have since it will catch when we format poorly (like add annotation above or something)
<headius[m]>
Yeah fine with me
<enebo[m]1>
So although I am done for tonight I always see some questionable suggestions
<enebo[m]1>
ALLOCATORS will get the suggestion to use lambdas instead
<headius[m]>
Yeah they all could switch over
<headius[m]>
Fewer classes to ship
nirvdrum has quit [Ping timeout: 264 seconds]
TimGitter[m]1 has quit [*.net *.split]
kalenp[m] has quit [*.net *.split]
boc_tothefuture[ has quit [*.net *.split]
kalenp[m] has joined #jruby
TimGitter[m]1 has joined #jruby
boc_tothefuture[ has joined #jruby
_whitelogger has joined #jruby
lopex has quit [Quit: Connection closed for inactivity]
<headius[m]>
enebo: I made a 9.2.17.0 milestone to punt the Psych upgrade... I am still trying to get Psych's test suite greener on JRuby and I'm waiting on input from tenderlove and asomov (from SnakeYAML)
<headius[m]>
users can install and use newer psych any time so it is really just about getting it upgraded in JRuby without excluding more tests
<headius[m]>
hmm in fact I will see if I can push the psych stuff forward today
<enebo[m]1>
ok
<enebo[m]1>
so today meaning you are punting but may have a gem install they can do which is the finished product?
<headius[m]>
the released gem fixes the one issue we had reported, but installing it in our build causes more tests to fail than before... so users can use the gem and it should be fine, but until I am satisfied we pass as much as we can I won't upgrade the version we ship
<headius[m]>
it only failed on JDK14 and I saw it only fail on 11 the other day
<headius[m]>
I don't know what is up... it should not be flaky
<enebo[m]1>
interesting so maybe something sometimes returning nil or something
<enebo[m]1>
The error looks like it wants an integer so nil would be my guess
<enebo[m]1>
I like that rails 6.1 in dev mode puts response time graphic in upper left corner
<headius[m]>
perhaps but it just gets a socket option using native getsockopt for this case
<headius[m]>
using the real fileno... so sometimes it can't get the real fileno? It doesn't make sense that it would be flaky unless something is wrong with the test
<headius[m]>
actually if it could not get real fileno here it would raise
<headius[m]>
yeah I don't see any problem with that part
<headius[m]>
just this len.get without a flip
<headius[m]>
and technically it should use buf.position() instead of assuming 0 but we know it is zero
<enebo[m]1>
yeah so the other part would be that we are somehow monkey patching over something in Ruby and not doing what we think we are
<headius[m]>
hmm
<enebo[m]1>
intialize also will set data to whatever is the fourth arg
<headius[m]>
now I am wondering if the flip is actually necessary
<headius[m]>
if they were native buffers, then the underlying memory would be passed to getsockopt and there would be no way to know how many bytes were written to them
<headius[m]>
so flip would be incorrect since the ByteBuffer fields would still say position = 0
<headius[m]>
but these are heap buffers so they get copied into after the call
<headius[m]>
or by an explicit write in the JNI logic maybe
<headius[m]>
oh I can't test this on macos
<headius[m]>
there is no SOL_TCP
<headius[m]>
enebo: can you step into this and see if the buffer actually needs to be flipped?
<enebo[m]1>
are you sure this is not too late
<headius[m]>
if either buffer is not at position=0 after the call they need to be flipped
<enebo[m]1>
validateDataSize happens before unpackInt
<headius[m]>
yeah I don't think there's any problem in Option
<enebo[m]1>
but the raise happens before the bytebuffer part
<enebo[m]1>
data is just checked to see if realSize == 4 and it is 0
<headius[m]>
where do you see that validateDataSize
<enebo[m]1>
in int()
<enebo[m]1>
asInt in Option
<headius[m]>
Ruby method int calls rb_int
<headius[m]>
not asInt
<headius[m]>
oh wait
<enebo[m]1>
why? it is a no arg version of int right?
<headius[m]>
wtf who named these
<headius[m]>
but yeah that is still the same bug
<headius[m]>
the bytelist gets len = 0 sometimes and so its length is 0
<headius[m]>
my fix would still be appropriate if these do indeed need to be flippped
<headius[m]>
flipppppped
<enebo[m]1>
I just don't see how it could based on how Option is created
<enebo[m]1>
data if it comes from rubybasicsocket will be realzise of 4 or 8
<enebo[m]1>
going to windows back in 2-3 minutes
<headius[m]>
if you're lucky
<headius[m]>
I will push fix to branch to make sure it doesn't break worse
<headius[m]>
but I would like to know for sure that the flip is necessary
<enebo[m]1>
I am still confused why flip is the issue
<headius[m]>
because if the len IntBuffer received a value it would no longer be at position = 0 and int.get would get nothing but 0s
<headius[m]>
it needs to be flipped so int.get reads from position 0
<headius[m]>
I don't know if it is the issue but it is an issue
<headius[m]>
it just confuses me that it doesn't always fail
<enebo[m]1>
but the error comes from validateDataSize which is not getting the unpack treatment yet
<headius[m]>
yes, because the ByteList created with int.get as its length ends up zero length
<headius[m]>
which then doesn't validate
<headius[m]>
nothing to do with the unpack
<headius[m]>
the bug is in getsockopt, not in Option
<enebo[m]1>
so you are saying packInt called from getSockOpt is the problem
<headius[m]>
no
<headius[m]>
I am saying missing flip in RubyBasicSocket.getsockopt is the problem
<headius[m]>
I guess you are not looking at the right method
<headius[m]>
I linked the code above
<enebo[m]1>
so getSocketOption impl?
<headius[m]>
no
<headius[m]>
RubyBasicSocket.getsockopt
<enebo[m]1>
I have been staring at that for minutes
<enebo[m]1>
it gets some int value back and then presumably does a packInt
<headius[m]>
I have no idea what you are looking at
<headius[m]>
you know, if we had reworked JRuby so that you could bind `initialize` to object constructors, we could mark way more object state as final
subbu|away is now known as subbu
tychobrailleur has joined #jruby
tychobrailleur has left #jruby [#jruby]
subbu is now known as subbu|afk
<enebo[m]1>
headius: jeremyevans Freaky I just sent an email to release. Curious if you all see it.
<jeremyevans>
enebo[m]1: I got an email that I had to allow access to send to the email address, which I did
<headius[m]>
perhaps this should be another mailman list on ruby-lang.org
<enebo[m]1>
jeremyevans: yeah that appears to be a new feature of forwarding but now it looks like forwarding to multiple addresses is done via a filter
<enebo[m]1>
Let me mess around a few more minutes...I already made this account
<headius[m]>
ok
<enebo[m]1>
I am not sure if we can make a new address there or we would have to ask so this may be simpler
<headius[m]>
we would have to ask
<headius[m]>
someone presumably has mailman admin privileges but it is not us
<enebo[m]1>
ok I have this almost figured out. I can see the list of names once I set a filter but I need to fill in some criteria
<enebo[m]1>
I think I will narrow this to [ANN] which I always add to annoucements and then just add this into jruby@ and ruby-talk@
<enebo[m]1>
This will also prevent us from getting arbtrary spam somewhat
<enebo[m]1>
Although I still stand by the above statement
<headius[m]>
huh that is a weird one to fail on
<enebo[m]1>
I think the full release value always will fail with deploy
<headius[m]>
non-snapshot builds don't run deploy
<enebo[m]1>
ok well I think I have never seen a green run with release version
<headius[m]>
org.torquebox.mojo.rubygems.layout.SimpleStorage$StreamLocation is in unnamed module of loader org.codehaus.plexus.classworlds.realm.ClassRealm @151f1734)
<headius[m]>
Failed to execute goal on project jruby-stdlib: Could not resolve dependencies for project org.jruby:jruby-stdlib:jar:9.2.16.0: Could not transfer artifact rubygems:ipaddr:gem:1.2.0 from/to mavengems (mavengem:https://rubygems.org): class javax.net.ssl.SSLException cannot be cast to class org.torquebox.mojo.rubygems.layout.SimpleStorage$StreamLocation (javax.net.ssl.SSLException is in module java.base of loader 'bootstrap';
<headius[m]>
wat
<headius[m]>
random module failure how
<headius[m]>
omg this recruiter keeps calling me
<headius[m]>
for a python job
<ahorek[m]>
hey headius I've found a solution for Error: test_tcp_socket_get_keep_intvl(SocketTest): TypeError: size differ. expected as sizeof(int)=4 but 0
<headius[m]>
oh this should be interesting
<ahorek[m]>
it looks like IntBuffer doesn't hold the reference for the native memory, it's just being GCed
<headius[m]>
you mean whatever buffer JFFI makes to pass to native?
<headius[m]>
the call from JRuby just passes a HeapIntBuffer which jffi/jnr-ffi then has to populate
<headius[m]>
I was wondering about a GC effect but these are both heap and hard-referenced... so it would have to be something deeper getting lost
<ahorek[m]>
https://github.com/jruby/jruby/pull/6593 it passes my stress test and travis also looks happy. I don't fully understand why IntBuffer doesn't work, IMO it should.
<headius[m]>
Yeah that is pretty weird
<headius[m]>
Seems like it would have to be something internal to jffi that is not handling the native buffer properly when copying values back out into the heap buffer
<headius[m]>
So potentially a larger problem we may want to dig into
<ahorek[m]>
indeed
<headius[m]>
👍 thanks for this though, at least we have a workaround