<headius>
most of the ext gems have JRuby equivalents but they would have to be removed from our codebase
<enebo[m]>
with these updates can you get a completing test run of spec:ruby:fast and/or test:mri?
<headius>
sure
<enebo[m]>
I am not saying passing just running to completion results
<enebo[m]>
merge what you have and let's chip as new gems are finished
<headius>
yeah will see how it goes... some of the gems like pp have breaking issues on load (accessing RubyVM)
<enebo[m]>
yeah there I believe is something using AST now ... maybe it is a external gem and not stdlib. I remember being annoyed at it :)
<headius>
pp uses iseq at least
<enebo[m]>
I think 9.4 punts on rbs too
<headius>
we have no Ractor defined so none of those tests are running either
<enebo[m]>
I do not think anyone uses Ractor but I am curious on amount of work since I have not looked into it yet. I suspect it will not be as difficult workwise as rbs
<enebo[m]>
It may have big ramifications though since it means migrating objects between runtimes
<enebo[m]>
That I think might be a big issue
<headius>
yeah unsure how visibility across runtimes works but it might half work just using the same runtime 😀
<enebo[m]>
hahah
<headius>
migrating will require work but it'
<headius>
it's fixable
<headius>
migrating guts or making shim types that can wrap an object passed between runtimes
<enebo[m]>
yeah I was thinking of this more purely from us having multi-runtimes but I don't know how a ractor starts...is it a clone of existing or a full bootstrap
<headius>
like the specialized Array objects, there could be another one that is RactorArray that maintains a reference to a single array object across runtimes
<enebo[m]>
I thought bootstrap but it has been a long time since I saw a talk
<headius>
need more info
<enebo[m]>
yeah I thought of that as well since he limits which types are allowed
<enebo[m]>
too bad we save runtime in every object :P
<headius>
my worry is less about the runtime reference and more about how do you handle object references to the migrated object
<enebo[m]>
I think indirecting through a wrapper will be only hope for shared instances rooted to "something"
<headius>
or does it just exist in both runtimes then? (frozen)
<enebo[m]>
yeah this is what I don't know
<enebo[m]>
if I have main instance and ractor and return an instance from that ractor and it goes away
<enebo[m]>
anyways ractor I think is also debatable for 9.4 at .0 time since I don't think anyone uses them
<headius>
true
<enebo[m]>
I asked on twitter about rbs and got no replies but I guess that may not mean much
<enebo[m]>
I have seen at least one post about how difficult it would be to integrate ractor into existing libs about a year back
<headius>
I have only seen posts showing how it's slower than just using a single runtime
<headius>
at least all this pain of getting JRuby support in place means we'll keep these libraries working from now on
<headius>
hah the longest CRuby CI run was 30s
<headius>
I'll put my money on 5min for JRuby
<enebo[m]>
so I wonder what the JIT support is for open3?
<headius>
you can see the commit there... it clears some JIT logs?
<headius>
it seems like something that might have been applicable when mjit was earlier but maybe not necessary
<headius>
I filed #2 to ask how to handle it, but here I just mask it out
<enebo[m]>
yeah that is not too informative
<enebo[m]>
I am not asking you to tell me just wondering :)
<headius>
oh, jruby + macos green in 2min
<headius>
I lose
<headius>
linux is slower though
<enebo[m]>
yeah I would have bet on minutes but it is going to just be a function of process spawns
<enebo[m]>
using --dev?
<headius>
no I did not add that because I wasn't sure how to do it just for JRuby
<headius>
and wanted to see how long it is
<headius>
2+3=5
<headius>
3m on linux
<enebo[m]>
I think I did it for some gem in the last year but I don't recall what
<headius>
pretty nice that we are green on this library after all these years
<headius>
windows is still using JDK logic but windows is stupid
<enebo[m]>
I have been fixing reported issues for 9.3.1.0
<headius>
ahh nice
<headius>
I have not looked
<enebo[m]>
I was leaving the backtrace ones for you though 🤑
<headius>
but they're so fun
<enebo[m]>
Is ivoanjo here?
<enebo[m]>
headius: I am thinking of re-adding java_kind_of?
<enebo[m]>
It has been marked as deprecated since 2016 but two people seem to still be using it and without replicating this method I am unsure how they do this since kind_of? does not work itself
<headius>
can we make kind_of? work right?
meckispaghetti[m has left #jruby [#jruby]
<enebo[m]>
headius: yeah that is the question...
<enebo[m]>
jruby -e 'a = java.util.ArrayList; p a.kind_of?(java.util.ArrayList)'
<enebo[m]>
Seems unintuive to not work
<headius>
right
<headius>
well you need to .new that, does it work then?
<enebo[m]>
doh :)
<enebo[m]>
HAHAHA thanks for seeing that. It does work
<enebo[m]>
I wonder if it will work with java subtypes/interfaces
<enebo[m]>
jruby -e 'a = java.util.ArrayList.new; p a.kind_of?(java.util.List)'
<enebo[m]>
cool
<enebo[m]>
So I think I will point this out and see if that works for people
<headius>
ok
<headius>
all the normal java classes and interfaces should work properly in kind_of, but the java.lang.Class instances will not
<headius>
like kind_of?(java.lang.Class.forName("java.util.List"))
<headius>
not sure what java_kind_of? supports that kind_of? does not
<enebo[m]>
yeah the reported issue is doing an instanceof check so it should be fine for that gem
<enebo[m]>
don't know about the second person but I suspect class type checks are going to be pretty uncommon
<headius>
enebo: I think I have changes working to get test:mri running again
<headius>
they restructured the runner and support libraries
<headius>
once I can run these to completion I'll push these changes
<headius>
after [3150/4468] (unit tests) there's 247 errors or failures (test methods)
<headius>
heh
<headius>
/Users/headius/projects/jruby/test/mri/ruby/test_literal.rb:581: warning: ... at EOL, should be parenthesized?
<byteit101[m]>
doing `fxml_root File.dirname(__FILE__), nil, FormattedTableCellFactory.java_class.classLoader` (or Person, or whatever) causes javafx to be able to load that class
<byteit101[m]>
I was debating making a class that extends classloader that is a meta-classloader for the provided ruby classes, but wasn't sure if such a thing existed already