ur5us has joined #jruby
ur5us_ has joined #jruby
ur5us has quit [Ping timeout: 264 seconds]
ur5us_ has quit [Ping timeout: 264 seconds]
Antiarc has quit [Ping timeout: 260 seconds]
Antiarc has joined #jruby
_whitelogger has joined #jruby
dentarg[m] has quit [Quit: Idle for 30+ days]
subbu is now known as subbu|afk
subbu|afk is now known as subbu
<headius[m]> good morning!
UweKuboschGitter has quit [Ping timeout: 244 seconds]
kares[m] has quit [Ping timeout: 244 seconds]
OlleJonssonGitte has quit [Ping timeout: 244 seconds]
nhh[m] has quit [Ping timeout: 244 seconds]
TimGitter[m] has quit [Ping timeout: 244 seconds]
KarolBucekGitter has quit [Ping timeout: 244 seconds]
nhh[m] has joined #jruby
kares[m] has joined #jruby
OlleJonssonGitte has joined #jruby
TimGitter[m] has joined #jruby
UweKuboschGitter has joined #jruby
KarolBucekGitter has joined #jruby
<headius[m]> this does not have to get in by any means but it makes Float behave more like CRuby flonum for purposes of identity
<enebo[m]> headius: looking at the PR
<enebo[m]> Do people id2ref fixnums and floats?
<enebo[m]> Or I guess I should say if they do then they are probably doing it generically
<headius[m]> I don't think they do it on purpose
<headius[m]> yeah that
<enebo[m]> Did this fix some specs or tests somewhere. I am not against this at all personally but I am wondering what the win is
<headius[m]> see the link
<headius[m]> it was just a behavioral difference that started with Ruby 2.0 when they added flonums... not specified behavior, but since we emulated fixnum behavior previously this closes a gap
<enebo[m]> ah yeah I missed that
<headius[m]> nobody should rely on this behavior and it should not be specified but this reduces our exposure
<enebo[m]> So we can make equal? work and not get an issue report down the road
<headius[m]> yeah
<headius[m]> and I realized while working on it that equal? and object_id equality have to go hand in hand so I did that half as well
<enebo[m]> yeah you know me. I love any change which will reduce our likelihood of getting a bug report
<headius[m]> and fixed fixnum to limit the equal? range to the range we generate object_id for
<headius[m]> (which only means values near 64 bits will not pretend to be the same object anymore)
subbu is now known as subbu|lunch
<enebo[m]> So our ranges are a little different than MRIs but MRIs is different depending on arch already right?
<headius[m]> our ranges match MRI on 64bit exactly now
<headius[m]> we use a Fixnum object for more values than MRI does but that is not visible since the Integer unification
<enebo[m]> ah cool.
<enebo[m]> we just get better perf a little longer :)
<enebo[m]> So over the weekend I bit the bullet and got all out of proc launching on windows to use SUSPECT plus other odd bits
<headius[m]> yeah basically
<enebo[m]> A small irony is my launching issue still persists but I think I am missing something which establishes the processes and in the same window group
<headius[m]> mostly need it this way for Java integration, so values near 64 bits don't require a Bignum
<enebo[m]> I will figure that out but now I am making dll loading working since I made it over the hump of importing winapis into Rust
<enebo[m]> but I realized this weekend I made like 5x the progress just not being connected to social media at all
<headius[m]> byteit101: I didn't forget about you... mopping up some unfinished work today and then will continue to review your questions
<headius[m]> enebo: yeah I usually just have this and chats open during work
<byteit101[m]> headius: Thanks! No rush though
<headius[m]> byteit101: 9.3 won't ship without this
<headius[m]> hmm anyone got a way to simplify this feel free: https://github.com/jruby/jruby/commit/fa49c58e4b
<headius[m]> specs like this are always gross
<headius[m]> ahorek: @ene
<headius[m]> ugh
<headius[m]> pick a way to @ and stick with it Matrix
<headius[m]> ahorek: enebo and I were chatting last week about backporting socket updates to 9.2 from 9.3
<headius[m]> in truth we could probably copy the entire ext.socket package over and it would work fine but maintaining commit history would be nice
<headius[m]> just not sure how much work that would be... what do you think?
<ahorek[m]> hey headius yes, it'll improve puma & redis features.
<ahorek[m]> redis will work without it, so no rush. tcp_keepalive is optional, the option was ignored before, now it fails. But it's easy to disable it.
<headius[m]> yeah just feeling like enough fixes have stacked up that it would be worth aligning 9.2 socket with 9.3
<headius[m]> and trying to decide the cleanest way to do that
<travis-ci> jruby/jruby (master:fa49c58 by Charles Oliver Nutter): The build was broken. https://travis-ci.com/jruby/jruby/builds/215649606 [210 min 16 sec]
travis-ci has left #jruby [#jruby]
travis-ci has joined #jruby
<headius[m]> ok that's weird
<headius[m]> all the JDK 11 and 14 runs started failing
Iambchop_ has joined #jruby
den_d_ has joined #jruby
OlleJonssonGitte has quit [*.net *.split]
Iambchop has quit [*.net *.split]
den_d has quit [*.net *.split]
souravgoswami[m] has quit [*.net *.split]
hopewise[m] has quit [*.net *.split]
kroth_lookout[m] has quit [*.net *.split]
liamwhiteGitter[ has quit [*.net *.split]
FlorianDoubletGi has quit [*.net *.split]
MarcinMielyskiGi has quit [*.net *.split]
Iambchop_ is now known as Iambchop
den_d_ is now known as den_d
subbu|lunch is now known as subbu
souravgoswami[m] has joined #jruby
FlorianDoubletGi has joined #jruby
liamwhiteGitter[ has joined #jruby
MarcinMielyskiGi has joined #jruby
kroth_lookout[m] has joined #jruby
hopewise[m] has joined #jruby
ur5us_ has joined #jruby
OlleJonssonGitte has joined #jruby
<headius[m]> had to do some additional fixes for #6466 because there are other ways the little Process.detach thread might see exceptions get raised
<headius[m]> so #6466 was only partially fixed in 9.2.14
<headius[m]> I retargeted #6466 to 9.2.15 but we can open a separate issue if you prefer
<headius[m]> retargeted and reopened
<travis-ci> jruby/jruby (master:fa49c58 by Charles Oliver Nutter): The build was broken. https://travis-ci.com/jruby/jruby/builds/215649606 [227 min 57 sec]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<headius[m]> great, some reruns passed and some didn't
<headius[m]> something is squirrely with JDK 11 and JDK 14 on travis now
<headius[m]> enebo: you didn't do anything on master with launcher yet right?
<enebo[m]> nope
<headius[m]> ok
<headius[m]> travis problem then
<enebo[m]> It is named differently as a repo and on my github account so far
ruurd has quit [Quit: bye folks]
<travis-ci> jruby/jruby (master:fa49c58 by Charles Oliver Nutter): The build was broken. https://travis-ci.com/jruby/jruby/builds/215649606 [237 min 34 sec]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<headius[m]> getting warmer
<headius[m]> only one failed that time
<travis-ci> jruby/jruby (master:fa49c58 by Charles Oliver Nutter): The build was broken. https://travis-ci.com/jruby/jruby/builds/215649606 [237 min 30 sec]
travis-ci has left #jruby [#jruby]
travis-ci has joined #jruby
<headius[m]> sonuva
<headius[m]> there's some kind of connectivity problem on travis today
ur5us_ has quit [Ping timeout: 264 seconds]
ur5us_ has joined #jruby
<headius[m]> enebo: tagged pointer stuff was green finally and has been merged
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (master:222eec9 by Charles Oliver Nutter): The build is still failing. https://travis-ci.com/jruby/jruby/builds/215690547 [224 min 23 sec]
<headius[m]> 🙄
ur5us_ has quit [Ping timeout: 264 seconds]