ur5us_ has joined #jruby
nirvdrum has joined #jruby
nirvdrum has quit [Ping timeout: 245 seconds]
subbu has quit [Ping timeout: 260 seconds]
subbu has joined #jruby
havenwood has quit [Quit: ZNC - https://znc.in]
havenwood has joined #jruby
havenwood has quit [Changing host]
havenwood has joined #jruby
ur5us_ has quit [Ping timeout: 240 seconds]
nirvdrum has joined #jruby
nirvdrum has quit [Ping timeout: 245 seconds]
nirvdrum has joined #jruby
michael_mbp has quit [Ping timeout: 260 seconds]
michael_mbp has joined #jruby
<fidothe> Think I managed to wake https://github.com/jruby/jruby/issues/6160 from its slumber
<fidothe> I'm doing some stuff with a FunctionInterface and I'm not sure I understand how to make the magic add-a-method-any-method java aspect work without block passing, which may account for some of that
<headius[m]> Hmm
<headius[m]> You are seeing those errors when trying to implement an interface?
<headius[m]> fidothe
<fidothe> Yup
<fidothe> Will make a minimal repro case after small child is fed and asleep
<headius[m]> Great thank you
subbu is now known as subbu|lunch
nirvdrum has quit [Remote host closed the connection]
<headius[m]> Looks like a fix for the json issue will be in the major OpenJDK versions next month
<headius[m]> also Freaky if you did not see this
<kalenp[m]> Yup, now to watch for openjdk release updates.
<Freaky> yeah, I saw
<headius[m]> enebo: we don't really have a milestone or label for "third party issue" so I am not sure how to mark this
<headius[m]> non-release is probably closest
<enebo[m]1> yeah
ur5us_ has joined #jruby
snickers has joined #jruby
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<travis-ci> jruby/jruby (master:ad53bd9 by Thomas E. Enebo): The build has errored. https://travis-ci.com/jruby/jruby/builds/219025952 [213 min 28 sec]
<enebo[m]1> oh travis
<headius[m]> 🤦‍♂️
subbu|lunch is now known as subbu
travis-ci has joined #jruby
<travis-ci> jruby/jruby (master:f91fc8b by Charles Oliver Nutter): The build has errored. https://travis-ci.com/jruby/jruby/builds/219027941 [207 min 45 sec]
travis-ci has left #jruby [#jruby]
<headius[m]> sigh
<headius[m]> enebo: I guess we just need to start moving to GHA
<enebo[m]1> travis is unhappy
<travis-ci> jruby/jruby (master:3b37a8b by Charles Oliver Nutter): The build passed. https://travis-ci.com/jruby/jruby/builds/219029989 [208 min 58 sec]
travis-ci has joined #jruby
travis-ci has left #jruby [#jruby]
<headius[m]> enebo: I added GH release for 9.2.16.0: https://github.com/jruby/jruby/releases/tag/9.2.16.0
<enebo[m]1> headius: ah yeah. I should have asked yesterday
<enebo[m]1> It is on the list too
<headius[m]> enebo: I'm going to do some lambda cleanup to eliminate inner classes where we can
<headius[m]> starting with ObjectAllocators for example
<enebo[m]1> headius: funny I just mentioned that due to intellij wanting it done :)
<headius[m]> yeah I have gotten tired of seeing them
<enebo[m]1> I think I have no more NORMAL going through call
<headius[m]> most of these can be method references to ::new so they will remove inner classes and lambda methods
<enebo[m]1> yeah nice
<enebo[m]1> I think in some paths we do at least 2 lambda arity checks
<enebo[m]1> and two path manglings
<headius[m]> I am not surprised
<enebo[m]1> when not a proc
<enebo[m]1> This has been helpful
<enebo[m]1> I mean at one level the overhead of this is very small but nonetheless blocks are pretty confusing
<enebo[m]1> I partially would like LambdaBlockBody and ProcBlockBody etc...
<enebo[m]1> And even dimensionality for callDirect vs no
<enebo[m]1> but that is not an ocean for this week
<enebo[m]1> Ultimately though I guess there is some polymorphic decision but I believe we are already not mono/bi for layers of this dispatch
<enebo[m]1> Also it is too early to think about this very much as I want to get the arg massaging logic simplified and easy to emulate as IR
<jeremyevans> headius[m]: Is https://bugs.ruby-lang.org/issues/11194 still an issue?
<headius[m]> it is
<jeremyevans> Now that the uri lib is on GitHub, do you think you could submit a pull request for what you want?
<headius[m]> I never got back to upstreaming anything and we still maintain our own fork of uri/generic
<jeremyevans> I don't think it should be a problem to have RUBY_ENGINE checks in the library, as long as CRuby backwards compatibility is maintained
<headius[m]> ok sure, I will see what I can put together
<jeremyevans> headius[m]: OK. Technically, uri is maintained by akira, but he doesn't seem to be active. I can review and merge after the PR is submitted.
<headius[m]> sure, looks like our diff is pretty small
<headius[m]> jeremyevans: the only thing JRuby-specific this touches is our "java env" ENV_JAVA... would it be best to defined?(ENV_JAVA) or use RUBY_ENGINE?
<headius[m]> for example I don't think that Truffleruby has this constant, but they might want to add it to reuse this functionality
<jeremyevans> headius[m]: RUBY_ENGINE == 'jruby' is probably the best way
<headius[m]> I suppose we can change it later if that happens
<headius[m]> https://github.com/ruby/uri/pull/18 but I am looking over other diffs in URI
<headius[m]> jeremyevans:
<jeremyevans> headius[m]: merged :)
<headius[m]> so there is one other diff that is maybe a small issue: use of bind_call
<headius[m]> that is 2.7+ only which means the gem will not work on 2.6-
<headius[m]> JRuby will not have a 2.7+ release until much later this year
<headius[m]> I will open an issue for this
<jeremyevans> uri gem doesn't specify required_ruby_version, which seems like a mistake
<headius[m]> is the intent that this only supports 2.7+?
<headius[m]> I know it was not gemified in 2.6 but if someone is able to install and activate it on JRuby it will break at these calls
<jeremyevans> Probably expected since it was gemified after 2.6. However, that doesn't mean we cannot make it backwards compatible with 2.6.
<headius[m]> ok, I just imagine someone might start adding these gems to deps and this one will get activated and break
<headius[m]> heh it is only used by two inspect methods
<byteit101[m]> headius: speaking of releases, a friendly reminder that my PR is awaiting a review and answers to a few todo's in the code
<headius[m]> byteit101: there will be two minor conflicts in this PR with yours
<headius[m]> and yeah I realized when I caused these conflicts that I need to review
<byteit101[m]> Allocators? I saw that and was worried :-)
<headius[m]> just converting them to lambdas or method references
<headius[m]> I will let you look at branch before I merge it in case this causes more hassle than we want
<headius[m]> enebo: 90 fewer classes and probably half that many fewer lambda methods
<enebo[m]1> sweet
<byteit101[m]> sounds good
<byteit101[m]> headius: cool, making dinner right now, but will try to check this evening
<jeremyevans> headius[m]: https://github.com/ruby/uri/pull/20 # Can you review and merge?
<byteit101[m]> headius: Looks good, easy merges, but I realized that 9ccc321a1180fabaad86307fae2c87600c898ff1 is a really nasty merge for my PR
<byteit101[m]> 9ccc is enebo's arity->signature code
<byteit101[m]> (from remove_block_stuff)
<headius[m]> Ahh yeah that is a bit more invasive
<headius[m]> jeremyevans I wonder if it is worth keeping the bind_call with the overhead of respond_to
ur5us_ has quit [Ping timeout: 240 seconds]
<headius[m]> All bind call gets us is skipping the bound Method object
<jeremyevans> headius[m]: The way I implemented it, there is no cost at runtime, since it defines different methods
<jeremyevans> headius[m]: Purely switching bind_call to bind.call would make things slower. Granted, inspect is not a fast path :)
<headius[m]> Oh right, did was not great on mobile
<headius[m]> Diff
<headius[m]> Yeah seems fine them
<jeremyevans> Great. I guess either merge it or approve it and I'll merge it.
<headius[m]> Ok gimme one min
<jeremyevans> headius[m]: The CI was already setup for Ruby 2.4-2.7, so it looks like it was expected to work on Ruby 2.4+, so I think setting the required_ruby_version to 2.4 is fine.
<headius[m]> Yeah and I saw you added tests as well 👍
<headius[m]> Approved