<byteit101[m]> headius: I mucked around with flags and think I generated the right file this time. Grab all-gems from https://github.com/byteit101/subspawn/actions/runs/4003226272 and pull out the arm64-darwin one. if it works for you i'll push a new version to rubygems
<headius> Ok I'll give it a shot
<headius> byteit101: seems like I'm still getting the same arch error
<headius> I grabbed the built gem as you described, installed it, and it's still erroring
<headius> $ file lib/ruby/gems/shared/gems/ffi-binary-libfixposix-0.5.1.0-arm64-darwin/lib/libfixposix/binary/libfixposix.dylib
<headius> lib/ruby/gems/shared/gems/ffi-binary-libfixposix-0.5.1.0-arm64-darwin/lib/libfixposix/binary/libfixposix.dylib: Mach-O 64-bit dynamically linked shared library arm64
<headius> seems right
<headius> $ jruby -e 'require "libfixposix/binary"'... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/7c5c4aad83f14f700c8c070c20b3ada3072a62e8>)
<headius> fix for that SecureRandom.random_number thing being zero
<headius> I did not notice the default Random constructor does not initialize the state array with any seed data, so it just returned zero forever
<headius> waiting on more feedback for this ClassCastException that seems to date back quite a while
<enebo[m]> interesting. I wonder if there is any recommendation on this
<enebo[m]> I remember in ye olden days making a random seed (which I suspect is wrong today) was current time or'd with process id.
<enebo[m]> But the general gist is making it complicated for someone to determine the seed value
<headius> yeah this logic was only ever used by actual RubyRandom instances, which seeded the Random instance. Not sure why there's even a no-arg constructor since it's not really usable unless you seed it.
<headius> in CRuby they just go into some other PRNG algorithm when there's no random number instance in hand
<headius> this is also not really in the spirit of SecureRandom gem since it should be calling back out to get more random bytes
<headius> but I think we fix it this way and then look at improving it after 9.4.1
<enebo[m]> ok
<lopex[m]> hmm I was looking for local CI for gitlab
<lopex[m]> but there's also this https://github.com/nektos/act
<byteit101[m]> headius: That error is in ffi-binary-libfixposix-0.5.1.0-java, try updating that from the all-gems zip too
<enebo[m]> err
<enebo[m]> If I clone this repo and run tests I still see that the refinment is not getting installed
<enebo[m]> I just checked because I saw you landed a refinement fix
genpaku has quit [Read error: Connection reset by peer]
genpaku has joined #jruby
<headius> Did you try my branch?
<headius> I will look into it later
<enebo[m]> I thought it had landed
<headius> Ah yeah I did
<headius> So you got latest changes
<byteit101[m]> headius: did you try updating the -java gem too?
<headius> No
<lopex[m]> does jvm bytecode have compact array representation now ?
<lopex[m]> or is it still a bunch of loads and stores ?
<lopex[m]> I mean array literals
<lopex[m]> like I guess ldc for arrays
<lopex[m]> afair it was push value, push index, store, etc
<headius> You might be able to do something with constant dynamic
<headius> But otherwise nothing I know of
<lopex[m]> so String is still special ?
<lopex[m]> I mean the only special wrt arrays
<headius> Yeah which is why we compile Ruby byte-based strings as a packed invalid character array inside a string
<lopex[m]> ah yeah
<headius> We do something similar for Big num
<lopex[m]> yeah, I saw the bignum issue you comemnted once somewhere
<lopex[m]> I wonder if specialised impl based on two longs would be long enough stick
<lopex[m]> it would be still bit manipulation
<headius> It would be a little more compact, but once we have constructed the big num we don't return to that packed version again