swills has quit [Remote host closed the connection]
swills has joined #jruby
swills has joined #jruby
<GitHub178> [jruby] headius pushed 2 new commits to ruby-2.4: https://git.io/v7qQt
<GitHub178> jruby/ruby-2.4 637ca8a Charles Oliver Nutter: Fix scaling and clean up Rational#round.
<GitHub178> jruby/ruby-2.4 4b13469 Charles Oliver Nutter: Kill some deprecated and incorrect uses of op_idiv.
_whitelogger_ has joined #jruby
<GitHub135> [jruby-openssl] kares pushed 1 new commit to secure-random-opts: https://git.io/v7q5o
<GitHub135> jruby-openssl/secure-random-opts df0b4e3 kares: we (still) should not break older JRubies we test against on CI (in 0.9.x)
<travis-ci> jruby/jruby-openssl (secure-random-opts:df0b4e3 by kares): The build is still failing. (https://travis-ci.org/jruby/jruby-openssl/builds/257160721)
<travis-ci> jruby/jruby-openssl (secure-random-opts:df0b4e3 by kares): The build was fixed. (https://travis-ci.org/jruby/jruby-openssl/builds/257160721)
ericu-sp1cworks has quit [Ping timeout: 240 seconds]
ericu-spicworks has joined #jruby
<GitHub69> jruby/ruby-2.4 d331d07 Charles Oliver Nutter: Fix Float#rationalize for Integer unification.
<GitHub69> jruby/ruby-2.4 a133cb3 Charles Oliver Nutter: Emulate rounding up without damaging precision.
<GitHub69> jruby/ruby-2.4 c8f8c10 Charles Oliver Nutter: Make sure double to Bignum goes through normalization.
<GitHub69> [jruby] headius pushed 6 new commits to ruby-2.4: https://git.io/v7qNa
prasunanand has joined #jruby
<GitHub42> [jruby] headius pushed 1 new commit to ruby-2.4: https://git.io/v7qpB
<GitHub42> jruby/ruby-2.4 5f4caec Charles Oliver Nutter: Ensure Kernel#integer goes through the same Inf/NaN checks.
<GitHub181> [jruby-openssl] kares pushed 1 new commit to secure-random-opts: https://git.io/v7qhk
<GitHub181> jruby-openssl/secure-random-opts 9c2a464 kares: try tuning JRuby's SecureRandom preferred instance logic a bit...
<travis-ci> jruby/jruby-openssl (secure-random-opts:9c2a464 by kares): The build was broken. (https://travis-ci.org/jruby/jruby-openssl/builds/257187606)
vtunka has joined #jruby
vtunka has quit [Quit: Leaving]
kitallis has quit [Ping timeout: 240 seconds]
brixen has quit [Ping timeout: 240 seconds]
vtunka has joined #jruby
kitallis has joined #jruby
brixen has joined #jruby
drbobbeaty has joined #jruby
Cooter has joined #jruby
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
Cooter has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
prasunanand has quit [Quit: Leaving]
prasun has joined #jruby
drbobbeaty has joined #jruby
bbrowning_away is now known as bbrowning
vtunka has quit [Quit: Leaving]
vtunka has joined #jruby
vtunka has quit [Quit: Leaving]
vtunka has joined #jruby
lanceball has quit [Excess Flood]
lanceball has joined #jruby
vtunka has quit [Quit: Leaving]
chrisarcand has quit [Ping timeout: 260 seconds]
chrisarcand has joined #jruby
jeremyevans has quit [Ping timeout: 260 seconds]
subbu is now known as subbu|lunch
<headius> kares: I'm so tired of entropy issues :-(
<headius> just when I think we've got it someone in our toolchain changes again
<headius> kares: you too if you have time
<headius> it feels icky but I'm not sure of a better fix
<headius> probably some way to chew on the raw float bits and figure this out without Big*
<headius> MRI does not have this problem because their fixnum boundary is short of 64 bits
<headius> so they can exceed fixnum precision in a long and then decide what to do
subbu|lunch is now known as subbu
jeremyevans has joined #jruby
<enebo> I don't really grok two == checks here
<enebo> I mean a java double mapped into a long can be a larger value than MIN or MAX by a bit over MRI so I feel I am missing something
subbu is now known as subbu|away
nirvdrum has quit [Ping timeout: 260 seconds]
<headius> enebo: it's an attempt to detect that the truncation of the double produced a value outside of long
<headius> the case I ran into is in some specs, specifically this: 9223372036854775808.1.floor
<headius> that should produce a Bignum of 9223372036854775808 but double to long casting truncates to ...807
<headius> which is fixnum max
subbu|away is now known as subbu
<enebo> headius: but can it be > than that value? or is the double coming in limited to Fixnum.Max in some way?
<enebo> or maybe that changes sign to negative
<lopex> numbers!
<lopex> enebo: I guess it's a question what is the resolution of mantissas at those scales
<enebo> lopex: ok so just glancing at that check I don't know if that is all we need to check or not. Actually just glancing at it I don't really know why the check is there at all
<enebo> I mean I can guess
<lopex> headius: does strictfp change anything here ?
<lopex> is strictfp stil la thing ?
<lopex> enebo: oh you mean why would they equal ?
<lopex> or what it would save ?
<headius> lopex: I could try it but I've never seen strictfp do anything at all
<headius> enebo: I check == because it can't be bigger (it's a long) and the troublesome case was at the boundary
<headius> so if it resolves to long max I assume it could be bigger than fixnum and use the alternative logic that doesn't use double > long
<enebo> headius: I think I am only confused because Long.MAX and Fixnum.MAX are not the same value
<headius> it's the double > long that resolves weird because that double truncates to long max
<lopex> says nearest
<headius> enebo: you sure?
<lopex> oh arent they ?
<headius> I'm pretty sure they're the same even though we calculate Fixnum.MAX
<enebo> public static final long MAX = (1L<<(BIT_SIZE - 1)) - 1;
<headius> yes
<headius> which would be 64-bit long max
<enebo> if so then why do we not just do Long.MAX then?
<headius> because we used to calculate it as bit size - 2 or whatever
<headius> now I guess there's no reason
<headius> we changed to make fixnum just be long many years ago
<enebo> I am too old to remember what two's complement is anymore so I cannot just tell by looking at that
<enebo> so my question only got muddled because I did not realize that was Long.MAX
<headius> ok
<headius> for MRI this value is already well beyond fixnum so they don't have it
<enebo> but we may want to change this logic in RubyFixnum since we are not likely to subtract a bit any more
<headius> it's odd that there are tests for this boundary in specs because it isn't MRI's boundary, it's 64-bit long boundary
<headius> sure, I'll change it
<lopex> yeah MRI has one bit less
<lopex> still ?
<enebo> yeah they are 62 bit right?
<enebo> 1 for tag and one for sign
<lopex> 63 ?
<enebo> oh well 63 including sign bit
<headius> $ jruby -e "p java.lang.Long::MAX_VALUE, org.jruby.RubyFixnum::MAX"
<headius> 9223372036854775807
<headius> 9223372036854775807
<lopex> yeah
<headius> just confirming
<headius> lopex: yes
<lopex> enebo: but in second completion bit is a value
<lopex> sign bit is a value bit
<headius> they definitely still use tagged pointers for fixnums and added flonums a couple releases ago
<lopex> yep
<enebo> in any case they lost a bit
<enebo> so why do they test beyond that boundary
<headius> so the problem I had was that case above turning into long max because it is right near the boundary
<enebo> maybe for us
<lopex> the tagging goes deeper for symbols etc
<lopex> but for fixnum it's only one bit
<headius> my logic basically just backs off and does a more accurate BigDecimal/BigInteger conversion when the result was at the boundary
<headius> all other double > MAX cases should result in bignum
prasun has quit [Remote host closed the connection]
<lopex> if it matches mri rounding then sure
<lopex> I see that float_invariant_round being an opt I assume ?
<headius> lopex: yeah I believe so
<headius> hah
<lopex> headius: wrt your latest jcodings changes, "fixed width encoding" name no longer holds
<headius> yeah
<headius> I guess that class could be AbstractUTF32Encoding or something
<lopex> oh, is 1.7 eol now ?
<lopex> headius: I wanted to remove some jcodings classes
<headius> pretty much yeah
<lopex> those BaseWhatever
<headius> what classes?
<headius> ah
<lopex> those which delt with the bifurcation
<headius> right, we're never going back
<lopex> in 1.8 these werent validating the inputs
<headius> ahh sure
<lopex> headius: but I still think having mri modes in same code base was a good idea
<lopex> imagine the cross merging madness
<headius> I agree
<lopex> I just recall the day that decision was made
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<headius> oh heck
<headius> I just realized Math.round returns a long, but round(2) returns a double
<headius> that explains some of my issues
hays has quit [Quit: No Ping reply in 180 seconds.]
hays has joined #jruby
Specialist has joined #jruby
<headius> enebo: I'm not sure what to do here
<headius> our Float.round can't handle doubles > long max at all because of this
<headius> might have been the actual bug
<headius> I'll have to duplicate what libc round does
<enebo> a double
<enebo> hmm seems weird
<enebo> but sure enough
<lopex> maybe libc does something simple
<headius> Math.floor and ceil return double but round doesn't :-\
<enebo> so I am confused can a java double return a value > than a long if round happens to return long?
<enebo> or is this for like half rounds or somethign as the issue
<enebo> heh ignore that
<headius> Math.rint returns double
<headius> how messed up is that naming
<enebo> looks sensible since they took the POSIX name already :)
<headius> these look like they were both in 1.0
<headius> posix has round and roundi
<headius> ok, so using rint still passes round specs but I can't remove my Big* logic
<headius> heh
<headius> passes specs but fails MRI suite
<headius> once again specs are gappy
<headius> ugh, rint is round half to even
bbrowning is now known as bbrowning_away
<lopex> like it should be viewed at 3x
<lopex> wow, but it shows deopt frames quite in depth
knu has quit [Ping timeout: 240 seconds]
knu has joined #jruby
deep-book-gk_ has joined #jruby
deep-book-gk_ has left #jruby [#jruby]