<headius>
enebo: in the shuffle I never got back to that random number thing so I'm checking to see if it can be done safely
<enebo[m]>
ok
<headius>
the main issue is that up until we switched to the gem, SecureRandom was its own random number generation entirely using JVM's SecureRandom. The Random class was never set up with the appropriate callbacks to "rand" and "bytes" that allow for SecureRandom to just plug into it
<headius>
so this is kinda full circle... I bashed my head against this rand_ulong_limited function from CRuby while trying to fix the SecureRandom issue because of the ulong behavior that was hard to emulate
<headius>
this time I decided to just modify the bignum version for long and it should be good enough
<enebo[m]>
something looks counterintuitive looking at the reported problem
<headius>
this completes the SecureRandom fix... before this is it was only "fixed" by always falling back on the Random PRNG
<enebo[m]>
the extra logic added seems to be for random == null which is the opposite of what I expected
<enebo[m]>
Is this so objRandomBytes can get called which does a dyn dispatch to the generator?
<headius>
Yeah it does a dynamic call back to the random object to get some random bytes
<headius>
The test that was failing just returns
<headius>
Oops, it returns a string of null bytes preventing the random numbers from being anything other than zero and we failed it because we continued to actually generate random numbers
<headius>
This completes the secure random fix because now for all cases it will actually call back to the secure random implementation of bytes
<headius>
The random null check basically indicates that we are not in a Random instance and should use the callbacks to generate random numbers
<enebo[m]>
ok. I figured it must be something like that
<headius>
Oops. There must be a zero check I missed because bunch of stuff is failing
<headius>
I'll fix it momentarily
<headius>
testing fix
<headius>
there's a zero check in the MRI version I missed
<headius>
ok it is in but when I ran specs locally I got some other failure
<headius>
1)
<headius>
SecureRandom.random_number generates a random positive number smaller then the positive integer argument FAILED
<headius>
Expected 0.7592402634967462 (Float) to be kind of Integer
<headius>
I don't see how my change would have caused this to start returning a Float for a random Integer
<headius>
if it fails again in CI I think we should push until Monday
<headius>
conference that day is just workshops so I will be working
<headius>
yeah this should have failed before
<enebo[m]>
ok we should do that anyways at this point
<enebo[m]>
and spend a little time talking about the other issues still marked
<enebo[m]>
none of them I think we need to get in but there 2-3 we should talk through
<enebo[m]>
This obviously needs to be fixed in stringio so another for .2 but you mention we should try and leverage io infra to make this simpler so that will be jruby-proper possible code + stringIO fix
<enebo[m]>
This one is unknown but may just be updating a gem once fixed
<enebo[m]>
Also .2 I think is safe
<headius>
The StringIO bug could be patched to ignore the encoding as a stop gap but I'd rather do a proper fix
<headius>
Monday would be good then. If we can figure out what else we want to get in I can work on it during my travel
<enebo[m]>
You also have some PR which I don't remember but whatever that issue was it definitely is not right for .1 but should immediately land for .2 if it is ready
<enebo[m]>
like why combine two thoughts into one line of code
<enebo[m]>
It is really odd. I guess it is just C-golfing
<enebo[m]>
but the split impl is pretty interesting in how much they don't do that they could
<enebo[m]>
I am especially confused by the AWK split since it is a hot-pathed single byte split
<enebo[m]>
I guess I should have examined it more. It is because it is not a single byte but isSpace so that is several matches
<headius>
ahh right
<enebo[m]>
Will closure using lambda forms in Java optimize as well as not using the lambda?
<headius>
generally should perform like inner classes
<enebo[m]>
A lot of this code could be simple loops with a test lambda
<headius>
same inlining problem but nothing new there
<enebo[m]>
ok so in this case I would be better off not doing that vs n different impls
<headius>
if (!max) return Qnil;
<headius>
is it a typical C-ism to always test for zero this way?
<headius>
I find if (max == 0) so much clearer
<enebo[m]>
how do you insert a tab in element.io?
<enebo[m]>
yeah Cism for sure
<headius>
I do not know the answer to that
<enebo[m]>
It is why 70% of the time my code snippets are not in code blocks
<enebo[m]>
30% I happen to snag a leading whitespace
<headius>
you can use triple backquote but usually need to shift+enter to keep it from sending early
<enebo[m]>
yeah I just want to past into the nice indented box thing
<enebo[m]>
Off to twitter I Go!
<headius>
hah
<headius>
I'm stepping through the CRuby random logic to figure out what I missed
<headius>
oy vey, mixing TRUE and 1 for a true boolean in the same function
<enebo[m]>
nice
<enebo[m]>
Hopefully you find some bitmath back into a boolean
<enebo[m]>
I do not mean to be hard on what I think is nobu as he seems to do an amazing amount of support but the code golf stuff drives me crazy
<enebo[m]>
seeing that pattern in Java is also always jarring because no one writes those weird C things in Java normally
<headius>
I blame lack of IDE features
<headius>
Ola had the same kind of code
<enebo[m]>
yeah that is a great point
<headius>
the single letter vars all over CRuby code drive me nuts
<enebo[m]>
IDE has been a huge lacking feature of C
<enebo[m]>
that could also be english as a barrier a bit
<headius>
there was an encoding method I looked at the other day that had s, e, sn, p, pn, and pe I think
<enebo[m]>
but a lot of c does like small var names
<headius>
like wtf
<headius>
I had no idea what any of them meant
<headius>
no doco, no comments of course
<enebo[m]>
yeah when start, end, ??, pointer (p is fine here) and ?? :)
<enebo[m]>
string n and pattern n
<enebo[m]>
I did not become a math major for a reason -- single letters
<enebo[m]>
I can say for a lot of stringy stuff at least those single letters are consistently used
<headius>
I missed having to do anything in FORTRAN, by the time I was there it was not in any of the U courses
<enebo[m]>
The other obvious point is the 80 column thing
<headius>
well not anything except advanced numerical stuff
<enebo[m]>
I took fortran class for fun
<headius>
heh yeah
<headius>
well and mixing tabs and spaces, which I'm not sure I ever have seen elsewhere
<enebo[m]>
It was not required when I started and that was 1986
<headius>
If 0 is given or an argument is not given, SecureRandom.random_number returns a float: 0.0 <= SecureRandom.random_number() < 1.0.
<enebo[m]>
I learned F77 for that. Crazy language
<headius>
so my 1 is becoming a 0 somewhere here
<enebo[m]>
Fortran still runs a lot of the world too
<headius>
F77 was still single-letter vars only right?
<enebo[m]>
no I don't think so but the first letter would give an implicit type
<enebo[m]>
I-N were integers
<enebo[m]>
Index yay I dno't have to say it is an integer
<enebo[m]>
7 bit ascii source too
<enebo[m]>
no recursion
subbu has joined #jruby
<enebo[m]>
Imagine taking scheme classes at the same time as one on fortran. Pretty mind expanding :)
<headius>
ugh my fix was wrong
<headius>
return 0 not nil
<enebo[m]>
return !!r;
<headius>
should be green now
<headius>
did you see that thread about !! the other day?
<enebo[m]>
no
<headius>
Nate Berkowhatever
<headius>
dont' want to spell it from memory
<headius>
it was arguing against something like find_user(criteria).present? versus !!find_user(criteria)
<headius>
he preferred !!
<enebo[m]>
BerkoThunderCougarFalconBird
<headius>
!! is baffling for the uninitiated
<headius>
I strongly disagree but I did not want to get into it
<headius>
at least there's no value to that in C
<enebo[m]>
I have seen this argument before and it is weird to me
<enebo[m]>
It requires you to see the same syntax applied twice to realize it will guarantee boolean value
<headius>
oh ffs alina clinics still blocks port 22
<headius>
baffling
<enebo[m]>
It seems like it is trying to pretend this convention is syntax or something
<enebo[m]>
but my complaint is it tries to avoid exploiting the idea of truthiness
<enebo[m]>
making a method which is nil/!nil means you do not need to care about something being boolean
<headius>
it just reads so bad
<headius>
if not not find user
<headius>
wat
<headius>
if BANG BANG find user?
<headius>
sounds like a lyric
<enebo[m]>
so the really really weird part is if this is an arel expression the first ! forces execution of the query
<enebo[m]>
That is really not obvious
<headius>
ah interesting
<enebo[m]>
find_foo does trigger execution but a scope in arel?
<headius>
unsure
<enebo[m]>
otherwise it would just not execute until you did .first or whatever
<enebo[m]>
the ! forces it to trip otheriwse it could not check the value
<headius>
tethering to the rescue
<headius>
ok that random thing should be ship shape
<enebo[m]>
If you are a Rails dev I suppose you just know this but as someone who does not do this stuff regularly it looks like a side-effect (and honestly !! gives the same vibe)
<headius>
I was actually patching my patch in the car in Southdale parking lot before a haircut
<headius>
so cut me some slack bro
<headius>
and some hair
<headius>
work-related: this random bytes method should accept an optional buffer into which to put random bytes
<headius>
the way it works now we have to allocate String + ByteList + byte[] for every random number coming from SecureRandom
<zzak[m]>
feel like i just jumped into your guys DMs :)