<GitHub145>
[jruby] enebo closed pull request #4927: Raise `TypeError` if `module_function` is not called for modules (master...test_module_function) https://git.io/vbAbc
<cremes>
headius: I’m hoping to start a dialog with Matz & folks about considering this for Ruby 3.0. I don’t have high hopes on that front but you never know…
<headius>
you're using fibers eh?
<cremes>
yeah, found a fiber bug in jruby, truffle ruby, and rubinius.
<headius>
what are you using fibers for here?
<cremes>
I need coroutines / continuations to make async look sync. No other way to really do it.
<cremes>
when you make a potentially blocking IO call, your calling fiber is suspended. The IO is performed on a dedicated IO thread. Upon completion, your fiber is awakened and you are given the result.
<cremes>
makes heavy use of Fiber#transfer
<headius>
select can't make async look sync?
<headius>
perhaps I'm not understanding how your async IO works
<headius>
I mean fibers are fine, except for the thread weight they have on impls other than MRI
<cremes>
select/kqueue/epoll only tell you when read/write events are available
<headius>
what other IO events are you looking for?
<cremes>
evented code is difficult to write and difficult to read. so by using fibers, we can make evented code look sequential. much nicer for the programmer.
<cremes>
read, write, accept(2) will succeed, timers, etc
<headius>
select can do accept/connect and obviously supports timeouts
<headius>
I'm sure there's something you need fibers for I'm not getting...perhaps it's the same reason celluloid uses them?
<cremes>
I’m working on the library this week. I’ll have examples written in a few days. That should make the reasoning more clear.
<cremes>
BTW, the purpose of the library isn’t just async. There is a set of Sync classes too that clean up Ruby’s current IO API. I think it’s a mess, so I’m hoping to design something cleaner.
<cremes>
again, examples later this week will make that easier to discuss.
<headius>
okeedoke
<cremes>
in the meantime, fix that fiber bug :P
<headius>
Fibers are heavy enough that I tend to discourage their use unless there's no alternative...I just want to understand what you can't do without them :-)
<headius>
hmm...I'm not sure, enebo might have something
<headius>
we have not had many
<chrisseaton>
Does security@jruby.org go to both you and Tom? Could I possibly be on it as well?
<chrisseaton>
We still have a lot of code from you.
<headius>
sure, enebo has the keys to that
<headius>
I do too somewhere
vtunka has quit [Quit: vtunka]
<bga57>
chrisseaton: does openjdk 9 contain graal?
<chrisseaton>
bga57: yes
<bga57>
So I should be able to run truffle on freebsd once they get openjdk 9 released?
<chrisseaton>
In Linux only actually
<chrisseaton>
Sorry I don’t know if we have any BSD support
<bga57>
there's not an openjdk9 for freebsd yet.
dave__ has joined #jruby
dave__ has quit [Ping timeout: 252 seconds]
<chrisseaton>
You can literally run Truffle on any JVM - but I know that's probably not what you mean - you mean Graal as well
cremes has quit [Quit: cremes]
Puffball has quit [Ping timeout: 240 seconds]
dave__ has joined #jruby
dave__ has quit [Remote host closed the connection]
nlew has left #jruby ["Leaving..."]
dave__ has joined #jruby
dave__ has quit [Ping timeout: 240 seconds]
bbrowning is now known as bbrowning_away
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
kith has joined #jruby
mistergibson has quit [Quit: Leaving]
<chrisseaton>
headius: I'm looking at using Java's SecureRandom to seed our hashes. Why do you use the time instead? Is having enough entropy an issue? Rubinius uses /dev/urandom
<chrisseaton>
MRI uses current time
<headius>
No particular reason, but entropy has always been an issue with SecureRandom
<chrisseaton>
I'm reading things like 'Believe it or not, there is no advantage in using /dev/random over /dev/urandom. They use the same pool of randomness under the hood. They are equally secure. If you want to safely generate random numbers, you should use /dev/urandom.' but it all seems circular to me.
<chrisseaton>
If they're equally secure, why is one more safe than the other?
<headius>
where do you see that we're using time?
<headius>
I have gone over and over this and all posts indicate urandom is always fine, and on OS X they're the same thing
<headius>
I have not been able to find any reason you should use /dev/random instead, nor any clear indication as to what you lose by using /dev/urandom
<headius>
our launchers try very hard to force JDK to use urandom now
<chrisseaton>
Oh I see it's just a fallback in JRuby
<headius>
yes, we should be using random.nextInt for the seed, I belive
<headius>
as far as we know there have been no exploits for it
<chrisseaton>
So MurmurHash2 is an option?
cremes has joined #jruby
<headius>
string hash is always either perlhash or sip if requested
<headius>
I'm trying to sort out if we use murmur anymore
<headius>
looks like there's a handful of places that use it to supplement some base hashcode impl
<chrisseaton>
Yeah that's what I was wondering
<headius>
I believe all the CVE were about string collisions so after we settled that I think we stopped tracking updates to the other hash functions
<chrisseaton>
We're using MurmurHash2 - maybe that's wrong if you've chosen perlhash
<headius>
at least, I never heard of an exploit that didn't involve directy strings
<headius>
er, dirty strings
<headius>
we never really bought into the CVE to begin with
<headius>
every platform has a simple hash table and many like Java have simple, set-in-stone hash calculation for strings
<GitHub149>
[jruby] yui-knk opened pull request #4933: Add `#test_define_method_with_symbol` to test targets (master...test_define_method_with_symbol) https://git.io/vbhHB
<lopex>
afaik java has to since it uses compile time hashcodes for strings in switches
<headius>
yes, Java set that in stone
<lopex>
headius: mind releasing jcodings again ?
<headius>
lopex: if you open an issue on sonatype oss jira I can get you added for deploys
<headius>
I'll do another deploy now though
<lopex>
ah ok
<chrisseaton>
headius: it looks like you use PerlHash for full byte[] hashes, but MurmurHash2 for things that still want to do their own begin-update-update...-end
<chrisseaton>
That's probably why we've used it then - our ropes mean we don't have a single byte[] for strings
<headius>
chrisseaton: that would make sense...trying to match MRI's pre/post logic for hashes meant we needed an algo with pre/post there
<headius>
perlhash could obviously be adapted to work over a series of byte[] or individual values
<chrisseaton>
Yes I'll do that
<headius>
lopex: done
<lopex>
headius: thx
<lopex>
headius: btw unicode 10 is there
cremes has quit [Quit: cremes]
<headius>
chrisseaton: of course don't trust my memory for perlhash security :-) we used it instead of sip because sip was expensive and perlhash had no issues *at the time*
<headius>
lopex: ah great!
<chrisseaton>
Yeah I'm doing a survey of Ruby CVEs
<chrisseaton>
Do you know what MRI uses now off the top of your head?
<headius>
I believe it's still sip
<lopex>
looks like sip_hash13
<chrisseaton>
Yeah, Rubinius too
<chrisseaton>
Perl is definitely prettier than SIP
<headius>
that's for sure
<headius>
and it's much lighter weight, both in base logic and because we have to cheat to make byte[] look like longs
<headius>
we use unsafe for that if available
<headius>
sip uses a 64-bit stride we can't simulate on byte[] without unsafe or varhandles
<lopex>
like that fast utf-8 walker
<headius>
yeah
<headius>
sip has similar code in it
<headius>
probably should move byte[] viewing to a separate library so we can make it use varhandle on 9
<headius>
in other news, my simple handle compiler does appear to produce native code I'd expect to see
<headius>
so that's fun
<chrisseaton>
So your compiler generates a set of calls to the AST execute methods?
<headius>
no, it turns the AST into handles
<headius>
all method handles all the way down
<chrisseaton>
What kind of method handle does a local variable write become?
<headius>
the scope initializes some heap storage for local variables...I'm not sure there's a good way round that
<headius>
so entering a body of code, first thing this experiment does is allocate an array with space for locals, and then all AST nodes are just functions consuming that array and producing a value