<byteit101[m]> Why did I name my class FFI so I have to use ::FFI for the real ffi?!
<byteit101[m]> Wow, CRuby segfault handler on windows/wine is so much slower
<byteit101[m]> Is there someone with a real windows machine that can test subspawn? I'm not sure if this is a wine bug or my code bug
<byteit101[m]> Subspawn win32 status: platform agnostic (done) tests (wip) pty impl (wip)
<headius> nice
drbobbeaty has joined #jruby
drbobbeaty_ has quit [Ping timeout: 246 seconds]
<olleolleolle[m]> I took a peek at the jbundler repo, and its using Travis, which... stopped. Should we attempt to get a GitHub Actions thing going for the repo?
<olleolleolle[m]> I am asking on behalf of the warbler repo, which is sorta behind on releasing.
<olleolleolle[m]> Relevant warbler link; https://github.com/jruby/warbler/issues/498
<enebo[m]> olleolleolle: yeah GHA is the new black
<headius> enebo: dunno if you saw this but SecureRandom.random_number is returning 0 all the time in 9.4
<headius> something wrong in the series of methods I tried to convert over from CRuby... complicated bit math in there and something is not working right
<enebo[m]> headius: is that why that regexp issue is fast?
<headius> I haven't looked at that
<enebo[m]> headius: I was trying to see what could have changed with regexp to see and you made thread-local change for match data but that would not make something go from 40s to 0.1s
<headius> which bug is this
<enebo[m]> it is unrelated
<enebo[m]> well it might be related I guess is rand_str is nothing
<headius> this securerandom thing seems to be in code dating back to 2011, contributed by nahi
<headius> it got hooked up in 9.4 because we moved to the gem and I had to massage things around so we'd call the same callbacks as in CRuby
<headius> so either this piece never worked or I didn't massage it right
<enebo[m]> HAHAHA rand_str in example on 9.4 is all "AAAAAAA...."
<headius> it bottoms out in here and results in zero for at least this limit of 10
<enebo[m]> ok so our regexp issue filed is still slow
<headius> so this is going to take some time to untangle and still have it do the callback to bytes on self like SecureRandom expects it to do
<enebo[m]> it is securerandom making a uniform string which is quickly processed by joni
<headius> aha
<headius> so this is the same issue
<enebo[m]> well the fast result is the same issue unfortunately for the person who opened it
<headius> SecureRandom#bytes seems fine but other methods that build on it are not using it right
<enebo[m]> but it exposed it in a "you dashed my hopes" sort of way
<headius> I am stepping out for lunch shortly... since your issue is related to mine maybe you can poke around this random code too
<headius> I'm just trying to understand some of this old code and what it and the C code are supposed to do
<headius> this code in CRuby is heinous
<enebo[m]> something must have changed?
<enebo[m]> It was working
<headius> well that is confusing... why aren't we failing any tests
<enebo[m]> no one tests randomness
<headius> could be
<headius> could try bisecting
<enebo[m]> all "A" or all 0 just makes those tests pass quicker
<headius> if it doesn't boil down to some big "rework random" commit maybe it will be a small bug
<enebo[m]> yeah I bet this will bisect to something very narrow
<enebo[m]> but narrow could be one massive commit but it wasn't me
<headius> it has not been refiled against JRuby as of yet
<enebo[m]> I suspect if you don't remember doing that we probably unhooked something
<headius> I remember doing a bunch of work to get SecureRandom gem working, which required hooking up similar callback pipeline as in CRuby
<headius> but once it was working I would be surprised if I missed the fact that it was always zero or AAAAAA
<headius> basically all of these should bottom out in the SecureRandom.bytes method and use that to generate other random data types
<enebo[m]> I will bisect it
<enebo[m]> b6ebb172d6e184b087dcdae47c7cea24bac9f781
<enebo[m]> headius: it was switching to switching to the gem which I guess you probably figured
<byteit101[m]> enebo: you are on windows, no?
<headius> Heh yeah
<enebo[m]> byteit101: I have a windows machine but I am not using it as my dev env
<byteit101[m]> Ah fair enough. I am trying to use wine to do subspawn-win32 but am not sure if I'm running into wine bugs or my bugs
<enebo[m]> byteit101: I can try running something if it is easy enough
<byteit101[m]> Sure, one sec. Clone master of byteit101/subspawn, and I'll get the command
<headius> Okay I will keep looking at this random thing
<enebo[m]> so where is random_number the method actually defined
<enebo[m]> It is returning 0 but I do not see where it is defined or how it connects back to gen_random
<headius> RubyRandomBase
<headius> In CRuby it is in random.c
<byteit101[m]> enebo: ruby -I "subspawn-win32/lib" -I "subspawn/lib" -r 'subspawn' -r 'subspawn/replace-pty' -e 'm,s =PTY.open; p [m,s]; pid,j = SubSpawn.spawn(["cmd"], pty: s); sleep 5; m << "echo yes\n\r\nexit\r\n"; m.flush; p pid, j; p m.read(5); p Process.wait(pid); puts "done"'
<byteit101[m]> ^JRuby or CRuby, doesn't matter
<byteit101[m]> I have no idea how the quoting should work, that's for wine via bash
<byteit101[m]> the key question is does it segfault or does it give another error (or does it magically work)
<byteit101[m]> only dep is ffi
<enebo[m]> headius: I am still not seeing random_number as a method defined
<enebo[m]> not in Java or Ruby
<enebo[m]> byteit101: I will pop over...be back in a sec
<byteit101[m]> enebo: Thanks!
<headius> oh well sorry not that for ruby_random
<headius> random_number
<headius> that is in RubyRandom
<enebo[m]> byteit101 I am getting undefined errno for SubSpawn::Win32::FFI
<enebo[m]> haha
<byteit101[m]> ooh, wait, which line?
<enebo[m]> I am not logged into github or I could give you more exact string
<enebo[m]> win32/pty.rb:202
<enebo[m]> I had to make a script since CMD was very confused about seeing << in the -e (in addition to changing all quoting)
<enebo[m]> but I made a script out of that
<byteit101[m]> oh dear, IO.pipe may not be native pipes
<byteit101[m]> JRuby or CRUby?
<enebo[m]> JRuby
<enebo[m]> I don't have C ruby installed there atm
<byteit101[m]> Ok. Drat, I may have to upgrade JRuby's pipes
<byteit101[m]> Alright thank you!
<byteit101[m]> I think I have some work ahead of me
<enebo[m]> byteit101: yeah np
<enebo[m]> headius: so single argument random_number is almost always a zero return
<enebo[m]> jruby -e 'p Random.random_number(3)'
<enebo[m]> I did get a 2 once :)
<enebo[m]> no argument version seems to give pretty random looking values between 0-1
<byteit101[m]> headius: JRuby uses java Pipe.open, do you know if there is a way to get a windows handle from them? enebo's error above is because there was no associated handle & fileno with the (Ruby)IO
<headius> We dig it out using reflection, probably do not have the right code in place for the Windows impl
<headius> FilenoUtil
<headius> ok so I have something working but it reuses the BigInteger path because of unsigned longs
<headius> the CRuby code is very fancy with the bit math so that they can avoid passing through Bignum for large longs, but it makes the logic very hard to port
<headius> ulong is hard to emulate