11:09 <GitHub63> [jruby] kares pushed 3 new commits to master: https://git.io/vQ2r1

11:09 <GitHub63> jruby/master 48876be kares: implement Kernel#singleton_method(name)

11:09 <GitHub63> jruby/master 24db4f0 kares: deprecate not-used push_m method on RubyArray

11:09 <GitHub63> jruby/master 107054e kares: deprecate method(s)19-suffixed impls; hide/refactor internal helpers

17:00 <codefinger> enebo: do you think this change should be prerequisite on said "mechanism for adding our own definitions to the stdlib"? Or should i try to improve it as mentioned in mine and kares comments? https://github.com/jruby/jruby/pull/4698

17:18 <enebo> codefinger: yeah I don't know. I guess we should not hold you up unless we have a more concrete idea

17:19 <enebo> codefinger: we can always migrate later. I just was realizing how nice it would be to have a standard mechanism for this

17:21 <codefinger> enebo: it's not holding me up. this is an ergonomic change. i'd rather get it right than introduce something that might be troublesome

17:22 <codefinger> enebo: would a simple mechanism be a set of files that are copied onto the stdlib (i.e. never change existing files)?

17:23 <codefinger> s/onto/into/

17:23 <enebo> codefinger: we actually maintain our stdlib as a separate repo and it fetches from MRI then we overlay onto our repo (and look for changes which are not in our repo)

17:24 <enebo> codefinger: but maintaining the delta itself is something we would like to get smaller which is why I made mention in the PR. Since these are new non-overlapping methods it seems like it could be in another file if we had some smarts in loading

17:25 <enebo> err method

17:26 <codefinger> i'm significantly more confused now than when this convo started

17:26 <enebo> haha

17:26 <codefinger> it sounds like my changes should not go in lib/ruby/stdlib/?

17:27 <enebo> codefinger: so you are patching in a new method and putting it into an existing stdlib file means we need to maintain a delta of that file now since we source them from MRI

17:27 <codefinger> actually, i put the method in a new file. but i do need to edit uri.rb to require it

17:28 <enebo> codefinger: my pondering on the PR was that if we could seamlessly load a second file with our additions (but without editing the original) then we could never have any deltas to maintain

17:28 <codefinger> ok i get that

17:28 <enebo> codefinger: how to do that is what I have no handle on

17:29 <codefinger> can that mechanism be one file in lib/ruby/stdlib/ that contains only `require` calls?

17:29 <enebo> codefinger: I mentioned having a file further up the load path and that would require_relative the real stdlib but that feels icky to me so it was just an illustration

17:29 <enebo> codefinger: it could be but we would then need to rename files in MRI stdlib when we pulled them over

17:29 <enebo> codefinger: which, to me, does not really improve the maintenance situation a lot

17:31 <enebo> codefinger: I think what would be nice would be some feature like 'after_require "stdlib/uri", "jruby_uri"'

17:32 <enebo> codefinger: this would be put into our kernel ruby files or something and it would be a post hook which would require jruby_uri if it loads/requires stdlib/uri

17:32 <codefinger> i see

17:32 <enebo> codefinger: it is a bit opaque at one level which some people may dislike but it would make maintenance really simple

17:33 <enebo> codefinger: it also solves any monkey patching as well so we could get rid of a few things we have now

17:33 <codefinger> i could also put `java.net.URI.new` in a helper method in my app :)

17:33 <enebo> codefinger: it is just an idea though

17:33 <enebo> codefinger: well I don't have an issue with to_java getting added to uri now

17:34 <enebo> codefinger: my musing as I said was not to derail but more to see if it got any reaction

17:34 <codefinger> seems like a lot of work if it's only needed for this one thing though. but i imagine there are other potential use cases for tweaking stdlib

17:34 <enebo> codefinger: yeah we add our own methods to some types and we replace the definitions sometimes as well

17:35 <enebo> codefinger: ultimately it would be nice if all our changes were just upstream in MRI's copy but realistically it is weird for them to have a to_java

17:35 <enebo> codefinger: and Ruby Java Bridge may not dig that too

17:36 <enebo> hook for pre/post require seems like it would solve this nicely but I bet people would think we were the antichrist because it gives a nice generic way of adding monkeypatches

17:37 <enebo> and it is a bunch of hidden implicit behavior triggering

17:37 <enebo> (e.g. if you do not know the hook is registered you will throw your keyboard against the wall when you realize a hook replaced a definition on you)

17:38 <enebo> so in my mind I am not sure it is a good or bad solution to this in the long run

17:38 <enebo> the simplest solution is to just maintain the deltas

19:21 <GitHub196> [jruby] headius pushed 1 new commit to ruby-2.4: https://git.io/vQa1S

19:21 <GitHub196> jruby/ruby-2.4 ddec5e2 Charles Oliver Nutter: Check for negative fileno....