<headius> I am sure the Kotlin folks have hit on some JIT bugs like we did years ago
<lopex[m]> but mostly wrt method size isnt it ?
<lopex[m]> or complexity
<lopex[m]> I guess it's all about patterns generated
<lopex[m]> if so java standard is not what it claims to be
<lopex[m]> or at least native compilers
Cameronian has joined #jruby
Cameronian has quit [Quit: Leaving]
Cameronian has joined #jruby
MatrixTravelerbo has quit [Quit: Bridge terminating on SIGTERM]
ahorek[m] has quit [Quit: Bridge terminating on SIGTERM]
enebo[m] has quit [Quit: Bridge terminating on SIGTERM]
lopex[m] has quit [Quit: Bridge terminating on SIGTERM]
basshelal[m] has quit [Quit: Bridge terminating on SIGTERM]
byteit101[m] has quit [Quit: Bridge terminating on SIGTERM]
KarolBucekGitter has quit [Quit: Bridge terminating on SIGTERM]
XavierNoriaGitte has quit [Quit: Bridge terminating on SIGTERM]
demon36[m] has quit [Quit: Bridge terminating on SIGTERM]
TimGitter[m] has quit [Quit: Bridge terminating on SIGTERM]
headius has quit [Quit: Bridge terminating on SIGTERM]
kares[m] has quit [Quit: Bridge terminating on SIGTERM]
MattPattersonGit has quit [Quit: Bridge terminating on SIGTERM]
MarcinMielyskiGi has quit [Quit: Bridge terminating on SIGTERM]
AnilJaiswal[m] has quit [Quit: Bridge terminating on SIGTERM]
CharlesOliverNut has quit [Quit: Bridge terminating on SIGTERM]
BlaneDabneyGitte has quit [Quit: Bridge terminating on SIGTERM]
CrisShupp[m] has quit [Quit: Bridge terminating on SIGTERM]
fzakaria[m] has quit [Quit: Bridge terminating on SIGTERM]
OlleJonssonGitte has quit [Quit: Bridge terminating on SIGTERM]
ChrisSeatonGitte has quit [Quit: Bridge terminating on SIGTERM]
mattpatt[m] has quit [Quit: Bridge terminating on SIGTERM]
rebelwarrior[m] has quit [Quit: Bridge terminating on SIGTERM]
jswenson[m] has quit [Quit: Bridge terminating on SIGTERM]
TimGitter[m]1 has quit [Quit: Bridge terminating on SIGTERM]
JesseChavezGitte has quit [Quit: Bridge terminating on SIGTERM]
RomainManni-Buca has quit [Quit: Bridge terminating on SIGTERM]
UweKuboschGitter has quit [Quit: Bridge terminating on SIGTERM]
kai[m]1 has quit [Quit: Bridge terminating on SIGTERM]
FlorianDoubletGi has quit [Quit: Bridge terminating on SIGTERM]
Bi[m] has quit [Quit: Bridge terminating on SIGTERM]
liamwhiteGitter[ has quit [Quit: Bridge terminating on SIGTERM]
NoraHoward[m] has quit [Quit: Bridge terminating on SIGTERM]
meckispaghetti[m has quit [Quit: Bridge terminating on SIGTERM]
Leonardomejiabus has quit [Quit: Bridge terminating on SIGTERM]
klobuczek[m] has quit [Quit: Bridge terminating on SIGTERM]
JulesIvanicGitte has quit [Quit: Bridge terminating on SIGTERM]
JasonvanZyl[m] has quit [Quit: Bridge terminating on SIGTERM]
Bi[m] has joined #jruby
ahorek[m] has joined #jruby
enebo[m] has joined #jruby
kai[m] has joined #jruby
MatrixTravelerbo has joined #jruby
lopex[m] has joined #jruby
JasonvanZyl[m] has joined #jruby
MattPattersonGit has joined #jruby
ChrisSeatonGitte has joined #jruby
JulesIvanicGitte has joined #jruby
JesseChavezGitte has joined #jruby
liamwhiteGitter[ has joined #jruby
CharlesOliverNut has joined #jruby
UweKuboschGitter has joined #jruby
FlorianDoubletGi has joined #jruby
basshelal[m] has joined #jruby
OlleJonssonGitte has joined #jruby
KarolBucekGitter has joined #jruby
byteit101[m] has joined #jruby
fzakaria[m] has joined #jruby
BlaneDabneyGitte has joined #jruby
MarcinMielyskiGi has joined #jruby
XavierNoriaGitte has joined #jruby
mattpatt[m] has joined #jruby
klobuczek[m] has joined #jruby
RomainManni-Buca has joined #jruby
TimGitter[m] has joined #jruby
NoraHoward[m] has joined #jruby
demon36[m] has joined #jruby
Leonardomejiabus has joined #jruby
rebelwarrior[m] has joined #jruby
CrisShupp[m] has joined #jruby
kares[m] has joined #jruby
meckispaghetti[m has joined #jruby
jswenson[m] has joined #jruby
AnilJaiswal[m] has joined #jruby
TimGitter[m]1 has joined #jruby
headius has joined #jruby
<headius> I see
<headius> Weird, I did not send that
byteit101[m] has quit [Ping timeout: 268 seconds]
Cameronian has quit [Remote host closed the connection]
Cameronian has joined #jruby
Cameronian has quit [Quit: Leaving]
Cameronian has joined #jruby
Cameronian has quit [Client Quit]
<headius> enebo: I will finish stdlib update today but there are obviously a number of gems out there that need to be finished and released
<headius> with jruby support I mean
<headius> strscan and stringio both need work to pass tests
<headius> pp has rubyvm stuff in it and I have a PR to fix that plus backport to work on 2.6
<headius> digest is almost done
<headius> I have been updating the comment here and will make it into a new issue after this merges: https://github.com/enebo/jrubyish/pull/3#issuecomment-926235545
<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
<enebo[m]> so someone asks a question and it gets no replies
<enebo[m]> so I don't know
<enebo[m]> lunch bbsoon
<headius> coffee
<headius> grr
<headius> we pass open3 tests otherwise
<enebo[m]> lol
<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
<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?
<headius> lots of new and interesting warnings
<headius> woot 3897 tests, 1726159 assertions, 151 failures, 144 errors, 12 skips
<enebo[m]> It was about that without any of the gem changes you made but I also find it likely some stuff maybe was not running
<headius> not too bad for test:mri:core at this stage
<enebo[m]> I was doing test:mri but it was ~244 F/E total for whole run
<headius> yeah I'm not sure how you were running it because the runner.rb was not working after your 3.0 update
<enebo[m]> but that also was before the last merge I did
<headius> aha, ok
<headius> I do not know when these tests were updated either but maybe you did that already?
<enebo[m]> yeah things broke and I had local changes as well for at least one unparsable and on never ending test
<headius> runner.rb was updated in your "update for 3.0 stdlib" commit so perhaps you updated everything there
<enebo[m]> Yeah they are definitely 3.0 tests
<enebo[m]> it is possible they are not 3.0.1 but I think they are
<headius> pushed my changes to update_stdlib since at least test:mri:core completes again
<enebo[m]> great
<headius> I have been doing 3.0.2 so that will need another small update
<headius> enebo: I had to disable test_refinement for https://github.com/jruby/jruby/issues/6867
<enebo[m]> 3.0 does prepend differently as well
<enebo[m]> It maintains all prepend targets so anything added later gets seen by everything
<enebo[m]> but likely that has nothing to do with this
<headius> open3 support is basically ready: https://github.com/ruby/open3/pull/3
<headius> I tried to run tests with the ProcessBuilder logic but it hangs (after several tests run, though)
<headius> oh and I forgot tests won't run because it loads pp and that tries to access rubyvm (pr is still unmerged unreleased)
<headius> you can just delete that from local pp.rb if you want to try runs
<enebo[m]> headius: yeah kill the line and we will get it whenever it is updated
<headius> I can't kill it... it's coming from gem now
<enebo[m]> oh hahah postprocess script
<headius> yeah submit a feature request
<headius> NotImplementedError: flip-flop is no longer supported in JRuby
<headius> my favorite error
<headius> updated test:mri:core numbers: 2454 tests, 749897 assertions, 201 failures, 129 errors, 12 skips
<headius> this is with a few tests omitted or excluded due to problems loading the files or tests that blow up memory/threads/resources
<headius> that's including pretty much everything in test/mri/ruby after updating from 3.0.2 so still pretty good
<headius> enebo: I'm going to temporarily vendor a modified pp
<enebo[m]> ok
byteit101[m] has joined #jruby
<byteit101[m]> Is there a built-in classLoader that works for all reified ruby classes?
<headius> byteit101: what do you mean? Not runtime.getJRubyClassLoader?
<byteit101[m]> java.lang.ClassNotFoundException: rubyobj.Person
<byteit101[m]> this is java code (javafx reflecting the fxml file into jva objects)
<headius> I guess javafx would have to be loaded in the same or a child classloader of the one that defined Person
<byteit101[m]> Yes, so I can pass a classloader
<byteit101[m]> and passing Person.java_class.classLoader works
<headius> yeah
<byteit101[m]> but only for Person
<headius> ah right
<byteit101[m]> if it tries to access FormattedTableCellFactory, it fails
<byteit101[m]> I need a "get me everything, please" CL
<headius> I think we might need a way to have related reified classes to load in the same CL
<headius> java_class_loader_group :MyJavaFXApp
<headius> or something
<byteit101[m]> Those are two unrelated classes
<headius> hmm
<headius> that is a JavaFX class?
<headius> if it is loaded anywhere above the Person classloader it should be visible to it
<byteit101[m]> No, Ruby
<byteit101[m]> that's the sample I was testing this with
<headius> mmm so the app classes would need to be in same or child classloader as jrubyfx classes
<byteit101[m]> No, I pass the classloader as an argument
<headius> I would have expected the jrubyfx classes to be in the main JRubyClassLoader and the Parent class to be in a child of it
<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]> the sample is being updated, but that is/will be here: https://github.com/jruby/jrubyfx/blob/master/samples/contrib/fxmltableview/FXMLTableView.rb#L40
<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