subbu has quit [Quit: Leaving]
Albertico[m] has quit [Quit: Client limit exceeded: 20000]
<basshelal[m]> I wonder if anyone has faced any similar problems in JRuby then because of this problem
<ahorek[m]1> LoadError: load error: delayed/backend/mongoid -- java.lang.StackOverflowError: null
<ahorek[m]1> has anyone seen this before? it happens reliably on jruby 9.2.20(.1)
<ahorek[m]1> require at org/jruby/
<ahorek[m]1> 9.2.19. and are fine, any idea what could fix it? there aren't many changes, but none of them seems to be related
<enebo[m]> ahorek: load/require stuff had huge changes for 9.3
<enebo[m]> not sure if this is from that or not but it is happening resolving dependencies so it would be my bet
<ahorek[m]1> newrelic is still testing ancient stuff like rails 3 :-( which is no longer supported on jruby 9.3
<enebo[m]> ahorek: and sorry I misread this. You are saying is having the issue
<ahorek[m]1> 9.2.19 passes, 9.2.20 broken, broken and 9.2 dev branch is ok again
<enebo[m]> ahorek: I don't think Ruby 2.6 will even run Rails 3
<enebo[m]> wot!
<ahorek[m]1> it doesn't make much sense, but it happens reliably, same environment, same java....
<enebo[m]> The only thing remotely maybe would be 3dc0362ba93ee7365a995f3d841747873a0ad918
<enebo[m]> I don't see how but it is pushing a new frame which was there before
<enebo[m]> was/wasn't
<ahorek[m]1> I may just give up and upgrade their CI to 9.3 :) but it's pretty complex, they're testing combinations with rails 3 - rails 7....
<enebo[m]> My brain is broken this morning
<enebo[m]> I keep reading stuff wrong :)
<ahorek[m]1> I'll try that commit, thanks
<enebo[m]> that SHA is something I could see "fixing" since it is working again
<enebo[m]> since you said branch is working again
<enebo[m]> the dregex fixes have been broken as long as 9.x has existed
<enebo[m]> dedup is something which can change whether we have multiple instances or not of a string but I just don't see that affecting much
<enebo[m]> jffi failing or no longer failing loading something else?
<enebo[m]> Just randomly typing stuff at this point
<ahorek[m]1> good morning guess @enebo :)
<ahorek[m]1> s/@//
<enebo[m]> ok cool!
<enebo[m]> So will be golden again
<ahorek[m]1> yep
<enebo[m]> firm handshakes
MatrixTravelerbo has quit [K-Lined]
subbu has joined #jruby
subbu has quit [Client Quit]
subbu has joined #jruby
drbobbeaty has quit [Quit: Textual IRC Client:]
drbobbeaty has joined #jruby
<byteit101[m]> enebo: you have windows, right? can you reproduce this? I can't on linux:
<enebo[m]> byteit101: I don't have 17 but I will have to set something up in the morning I guess
<enebo[m]> I also need to get a packaged javafx
<byteit101[m]> I recommend zulu
<enebo[m]> I think?
<byteit101[m]> zulu 17 has a "JDK FX" with it pre-packaged
<byteit101[m]> I've migrated to only using zulu for fx stuff, much easier
<enebo[m]> cool
<enebo[m]> oh I see and he is using zulu too
<enebo[m]> I will try to repro in the morning
<headius> enebo:
<headius> byteit101: that is a nice all in one option, maybe we should recommend it in jrubyfx
<enebo[m]> blerg
<headius> enebo: get to work
<byteit101[m]> Yes, I was going to do that when 2.0 is released
<enebo[m]> haha I think we can eventually get that in but I don't find it very pressing
<headius> actually the way I'm approaching some of these JRuby ext gems will be to have a jruby-whatever version of the gem and release a -java of the stdlib gem that depends on it
<headius> in some of these cases we already have our own gem for it, like openssl
<enebo[m]> ah yeah
<headius> then we are not completely beholden to the ruby/* repo
<enebo[m]> My main issue is it is not trivial to build it since I built it so long ago and now that I think I can use a community edition of VS to build it we can make it simpler to build
<enebo[m]> but that may take days and I just don't think it is too important
<enebo[m]> we can just bundle what we have with no ability to build it from source
<enebo[m]> Windows may still be but was so lame because they had no portable scripted way to build shit
<enebo[m]> I think that has changed now though (or I think it has).
<enebo[m]> There was a reason beyond needing header files (which used to not be freely distributed) where I had to use icc to build the jni piece
<enebo[m]> anyways. thanks for making the issue anyways. It will happen but not until 9.4 is out
<headius> yeah there are a half dozen or more gems that we need answers for
<headius> this is a low priority
<enebo[m]> I marked some issue for 9.3 this morning. That elon one not getting all the data may be our big break on the openssl problem (since it appears we are not getting all data from the network connection)
<headius> nobody installs and builds the gem on Windows... they use the one that's shipped
<headius> and our users can install the prebuilt jruby version if they need it
<headius> aha yeah that could be a good pointer
<headius> I will push first commit for stdlib update to a PR shortly
<headius> updated gems and I went through the list and added commented entries for anything we can't use the gem yet, with links if there's an issue or PR
<headius> a few more libs moved out to gems, some defaults moved to bundled, and some were just deleted
<enebo[m]> I am curious if anything changes in test results after that
<enebo[m]> we are at 237 or so for spec:ruby:fast which has some stdlib in it
<headius> yeah could help
<enebo[m]> test:mri:stdlib has an asanine amount of failures :)
<byteit101[m]> btw got rather busy this week, should have more time friday or the weekend to fix a few bugs and clean up the @ivar pr
<byteit101[m]> the comments on the config seem reasonable
<byteit101[m]> though I would like to know the best exception class to use for the binder failures
<enebo[m]> see ya all tomorrow
<enebo[m]> byteit101: I will try zulu out in the morning
<byteit101[m]> thanks! Just commented on the issue
<headius> new time gem depends on date (native ext) and new open-uri gem depends on stringio (native ext)
<headius> so those need to get bumped up in priority
<headius> git st
<headius> oops
subbu has quit [Quit: Leaving]