<distant[m]> Good morning! :D
DylanCamilleri[m has joined #jruby
<DylanCamilleri[m> Good morning :)
<DylanCamilleri[m> Is this the correct place to ask questions regarding jRuby?
JesseChavez[m] has quit [Quit: You have been kicked for being idle]
genpaku has quit [Remote host closed the connection]
genpaku has joined #jruby
<headius> Dylan Camilleri: sure is!
<headius> enebo: I think we need to yank this jar-dependencies update and try again for next release
<headius> perhaps we can make the update version still compatible with older versions but this is a bit of a quagmire
<enebo[m]> ok
<headius> ok two PRs reverted and gem yanked... I re-marked the original issue for 9.2.8
<headius> s/2/3/
<headius> yeah this is a nasty chicken and egg situation
<headius> I have a few outstanding PRs for 9.3.7 that are based on the buggy jar-dependencies line so I'm going to rebase or remerge those to get green results
<headius> looks like there's a couple failures on latest run but nothing related to jar-dependencies anymore
<headius> rebased PRs looking pretty good
<headius> this one is green now: https://github.com/jruby/jruby/pull/7288
<headius> clearing errinfo in finalizers so bad finalizers that raise errors don't stack up causes
<headius> rsim figured out the problem
<headius> this only failed something in concurrent-ruby and I think there's still a few flaky tests in there: https://github.com/jruby/jruby/pull/7280
<headius> eliminate the constant replacement warning in JI because it warns for top-level constants and doesn't align with how other const replacement warnings work
<headius> not a major issue but annoying enough folks have filed bugs
<headius> and the AOT/JIT/IR serialization filename fix seems to be going green now as well: https://github.com/jruby/jruby/pull/7292
<headius> enebo: got a minute to confirm these are all good?
<headius> minor changes but changes nonetheless
<enebo[m]> yeah
<headius> the errinfo and filename ones are actual fixes, with the warning thing just being annoying
<enebo[m]> yeah all three look reasonable with the errinfo being the scariest looking :)
<enebo[m]> but as you said last week we do this when entering JI
<headius> that was a pretty recent change but I think it's valid here too
<headius> I'll go ahead and merge, everything is green after some re-runs and also gren on master
<enebo[m]> so we can rephrase that as we got no reports on that change
<enebo[m]> yet anyways
<headius> yeah
<headius> it is just another case of cleaning up Ruby-specific thread-local state upon leaving Ruby
<enebo[m]> The protected JI error had me thinking. We changed extension so that we are really using the subtype as an actual subtype with byteit101 feature
<headius> and this case is even clearer because finalizer runs should be more isolated and CRuby also clears it after finalizer runs
<enebo[m]> I guess if we could compile all original scope methods into the type we generate it would work since it would really just be Java permissions
<enebo[m]> I can also see why that is problematic since we allow java proxies as open types in Ruby
<headius> right so this is just a more general version of the initialize/super thing that was fixed by splitting
<enebo[m]> The example script is pretty reasonable that doesn't work so I am trying to think how this can work in module land
<headius> we don't have to split here but still need to rewrite supers as java-aware supers in concrete subtypes
<enebo[m]> yeah so if I remember right the constructor is properly generated and actually on a type we make
<enebo[m]> the def itself is not really a java method though
<enebo[m]> in 'def accept'
<headius> I know we do generate super stubs but apparently this falls into a gap where we don't wire that up right
<headius> the open class thing does complicate it
<enebo[m]> Hmm. we could just make a method on the generated type which only does super.foo(...)
<enebo[m]> the ruby method in the bag could call that method (and that method would be public)
<headius> we do that already for some cases
<headius> but I think only for methods that we see overridden at instantiation time
<headius> when we know we are overriding something from a superclass we generate a super stub to call it
<enebo[m]> oh
<enebo[m]> weird. This example seems like it should work then
<headius> right
<headius> so I was also confused as to what we are missing
<enebo[m]> fwiw I have never tried running the example
<headius> byteit101 said he would be able to help us look after he's back from vacation so maybe we just punt this for now
<headius> I think we also have a flag that will turn protected methods back on and that might be a workaround
<headius> this fails because it does not wire up a special super call and then doesn't see any super method bound to the Ruby proxy
<headius> so it is a simple Ruby failure because the super method is protected and not bound
<enebo[m]> ah ok. I am ok with that. My ripper+parser combine is beating me down but I know I am close to figuring this out
<headius> ok
<headius> I will try to figure out workaround for this and punt it
<enebo[m]> It will be nice to have them both in the same file
<headius> other than that the only real bugs marked for 9.3.7 are loongarch (in progress in JNR, will punt) and an inaccessible file option we'll need to do some other way (I can look into it or punt)
<headius> I think there may be a blessed way to do the file open but it is unclear from JDK doco
<headius> yeah I am excited to see the big parser rework land
<headius> ok so I have my marching orders for this afternoon then
<enebo[m]> I just tried the script in 9.4 land with only changing some import to java_import and it works fine in Java 8 (which I suppose is not surprising)
<headius> yeah it might also work with an add-opens flag
<enebo[m]> Exception in thread "AWT-EventQueue-0" org.jruby.exceptions.NoMethodError: (NoMethodError) super: no superclass method `accept' for #<FocusTraversalManager:0x5940b14e @potential_searching=false>
<enebo[m]> at RUBY.accept(../snippets/ji10.rb:38)
<enebo[m]> So yeah module obviously
<enebo[m]> jruby -J--add-opens=java.desktop/javax.swing=org.jruby.dist ../snippets/ji10.rb
<enebo[m]> whoops
<headius> nice
<enebo[m]> So this is just a simple module problem I guess. Is there even a fix for this? I mention adding all add-opens of the jdk but that seems a bit overkill :)
<headius> I replied to that idea
<headius> we could consider binding non-callable methods with a helpful error pointing them to add-opens
<enebo[m]> haha I should have asked here instead of issue but is there a mechanism to know module of a class reflectively?
<headius> with that add-opens workaround we can safely punt this though
<headius> yes
<headius> so we could say "oops, this method is not callable without add-opens=blah/blah=com.jruby.dist
<headius> and link to info page
<enebo[m]> assuming they are using dist
<headius> we can tell that too
<headius> if it is org.jruby.complete the error would reflect that
<headius> pun intended
<enebo[m]> ok cool. Yeah this seems to be the correct solution for non-common APIs
<enebo[m]> err non-common modules
<headius> we have a few add-opens built in but only things we need for compat and we have been trying to reduce those anyway
<headius> moving to newer JDKs that open up hidden features in a blessed way will help that
<enebo[m]> It is not quite a cool as it could be in a statically typed lang in that we will only error upon encountering it so we cannot give a complete command line for all modules you need to add
<headius> right
<headius> that's the power of Ruby
<headius> finally downloading a Windows VM to use for some testing... I will figure out this file share delete thing and then we are done with 9.3.7 issues in tracker