<headius>
The M1 builds are failing everywhere, I have to tweak some environment for the service... so that is just env work
<headius>
test:jruby fails on Windows and I have not started investigating Windows
<headius>
spec:ruby:fast:jit seems to be failing due to some kwargs handling... I'm not sure when this regressed
<headius>
test:jruby:aot crashes Zulu JDK on GHA but not locally, so that needs further investigation
<enebo[m]>
yeah I suspect kwargs handling for jit has been broken a long time with my frobnicate weirdness problem you fixed
<enebo[m]>
which just means we wouldn't probably have ever seen it greem
<headius>
the Sequel suite is still not passing on JRuby, have not investigated
<headius>
-Ptest on OpenJ9 fails, have not investigated
<headius>
other than that almost all of our core suites are green, with the expected MRI and WIP spec suites failing
<headius>
I could probably merge this and incrementally look at the last few that should not be failing
<headius>
they are all special cases of other suites so they should pass
<enebo[m]>
I don't see why not if you get full green runs from some jobs
<enebo[m]>
May as well just create new branches for remaining work in one or more swipes
<headius>
I will merge in your fix for the Struct key thing and then merge
<enebo[m]>
As far as kwargs failures I am down to I think a single ruby2_keyword issue on spec:ruby:fast (removing all tags)
<enebo[m]>
but in test:mri there are still 14E/16F on test_keyword
<enebo[m]>
not all of those are important but a few could explain rails problem which is still not working
<headius>
hey where was that struct failure? I have it fixed locally so I have forgotten
<enebo[m]>
as in the spec?
<headius>
yeah
<enebo[m]>
spec/ruby/core/struct/new_spec.rb
<enebo[m]>
going to make lunch
<headius>
thank you
<enebo[m]>
but as a conclusion once I get interp finished the JIT part will be simple since I just have to push a temp for existing instrs and then add a simple impl for getting the keywords itself which is just doing an IRRuntimeHelpers call
<enebo[m]>
I may do JIT this afternoon even if I don't since I do not anticipate any design changes now
<headius>
FYI to_s does not appear to be needed to get the symbol name without :
<headius>
I just pass symbol into RubyStringBuilder.str as I showed you
<enebo[m]>
ah cool
<headius>
I've merged it into master
kaleemullah123[m has joined #jruby
<kaleemullah123[m>
Hello Guys
<kaleemullah123[m>
I need your help on a problem specific to JRuby 9.2.10
<kaleemullah123[m>
On JRuby 9.2.9 it's working fine.
<kaleemullah123[m>
I'm loading a jar file in my ruby class
<kaleemullah123[m>
Jar file (Package -> Class)
<kaleemullah123[m>
and it's methods are not accessible.
<kaleemullah123[m>
headius: any help to debug this furthet?
<kaleemullah123[m>
Just to inform, it's does not work with 9.2.10 onwards for any version.
<kaleemullah123[m>
fidothe: any help?
<headius>
I'll be back at my desk shortly and see if I can help you figure this out
<kaleemullah123[m>
thank you!
<JasonLunn[m]>
headius: Did JRuby end up submitting a GSoC application this year?
<headius>
Jason Lunn: unfortunately not, we could have joined the Ruby organization but it would have been me and I just didn't have time to get together ideas and so on
<headius>
I'm not sure we're going to have free cycles to do mentoring over the summer anyway
<JasonLunn[m]>
Got it. I'm gearing up to finalize approvals to move forward on JRuby support for grpc. When I get to technical design, are you still interested in reviewing it before we break ground?
<kaleemullah123[m>
headius: do you have some time now?
<headius>
kaleemullah123: sorry, had a few things to do
<headius>
so it does find the class and constructs it ok... could you show the output of `authenticated_encryption.methods.sort` please?
<headius>
Jason Lunn: Yeah sure! I am looking into some download numbers to get a rough idea of things on our end
<kaleemullah123[m>
and you can see ":encrypt" and ":decrypt" methods
<headius>
right, that makes sense for when JRuby would let you call methods on private or protected or package-visible classes
<headius>
I assume this is not the way a Java user would call this API but since you were able to do it you did it this way
<headius>
do you control that class or is it a third-party library?
<kaleemullah123[m>
it's (.jar) a third party library.
<headius>
Jason Lunn: quick maven central stats show around 30-40k downloads per month with an uptick recently (9.3.4.0 most likely)
<headius>
that's 30-40k across all versions so occasional old ones in there too
<headius>
9.2.20.1 is still the most downloaded as the last stable release of the previous major version 9.2
<headius>
the jruby-complete jar which contains all of JRuby and the ruby stdlib averages 300k-350k downloads per month, but it is used by all the JRuby-based build tools and by nearly everyone embedding Ruby into Java apps
<headius>
the 30-40k stats were for the standard JRuby dist tarball that unpacks into a working Ruby install
<headius>
jruby-base is a stripped-down jar that only contains JRuby and has averaged 5000-7000 downloads a month and climbing since we introduced it in Oct
<headius>
this is just maven central though so no stats on federated servers and mirrors
<JasonLunn[m]>
Are those stats somewhere anyone can see them or are they visible only to the maintainers?
<headius>
this is only via the sonatype OSS maven hosting console, I'm not sure if they're public
<headius>
kaleemullah123: ok back to you
<kaleemullah123[m>
thanks :)
<kaleemullah123[m>
headius: Can you please guide me how can I fix this issue?
<headius>
well the short answer is that you can't... we don't bind methods on package-visible classes because on Java 9+ we simply can't (modules prevent it or warn loudly about it)
<headius>
kaleemullah123: could I get you to open a discussion about this? I'm not sure if we have a workaround for you but we can discuss it there and try to get you an alternative or workaround
<headius>
if it is not public, then you would not be able to call it from a Java class so we do not bind its methods
<kaleemullah123[m>
Sure! Should I open an issue in github?
<headius>
I think a discussion would be better, since this isn't really a bug (we made the choice for a reason)
<headius>
but either way is fine, I can turn an issue into a discussion
<kaleemullah123[m>
I'll open a discussion for it.
<kaleemullah123[m>
Between, Thank you so much for your time and support! 🙏
<headius>
yeah sorry we don't have an answer for you now but we'll work through it
<JasonLunn[m]>
<headius> "this is only via the sonatype..." <- Thanks. When you have a spare minute, would you mind snapping a screenshot or two and sending them to me by email so that I can forward it internally?