ur5us has joined #jruby
Aethenelle has joined #jruby
Aethenelle has quit [Client Quit]
lucasb has quit [Quit: Connection closed for inactivity]
ur5us has quit [Ping timeout: 240 seconds]
jeremyevans has joined #jruby
ur5us has joined #jruby
ur5us has quit [Ping timeout: 240 seconds]
_whitelogger has joined #jruby
nirvdrum has quit [Ping timeout: 272 seconds]
enebo[m] has quit [Ping timeout: 240 seconds]
rdubya[m] has quit [Ping timeout: 240 seconds]
nirvdrum has joined #jruby
nirvdrum has quit [Ping timeout: 268 seconds]
rusk has joined #jruby
drbobbeaty has joined #jruby
nirvdrum has joined #jruby
rwilliams[m] has quit [Quit: killed]
lopex[m] has quit [Quit: killed]
OlleJonssonGitte has quit [Quit: killed]
BlaneDabneyGitte has quit [Quit: killed]
jellymann[m] has quit [Quit: killed]
aemadrid[m] has quit [Quit: killed]
CharlesOliverNut has quit [Quit: killed]
headius[m] has quit [Quit: killed]
daniel_jruby_que has quit [Quit: killed]
kares[m] has quit [Quit: killed]
shellac has joined #jruby
snickers has joined #jruby
shellac_ has joined #jruby
shellac has quit [Ping timeout: 246 seconds]
headius[m] has joined #jruby
bastilian has joined #jruby
harald[m] has joined #jruby
mischa[m] has joined #jruby
lopex[m] has joined #jruby
kasaltie[m] has joined #jruby
ksawery[m] has joined #jruby
nieve[m] has joined #jruby
pedran[m] has joined #jruby
annette[m] has joined #jruby
louis[m] has joined #jruby
MattPattersonGit has joined #jruby
JulesIvanicGitte has joined #jruby
kares[m] has joined #jruby
FlorianDoubletGi has joined #jruby
liamwhiteGitter[ has joined #jruby
cshupp[m] has joined #jruby
TimGitter[m]1 has joined #jruby
RomainManni-Buca has joined #jruby
rebelwarrior[m] has joined #jruby
ThomasEEneboGitt has joined #jruby
sandio[m] has joined #jruby
JesseChavezGitte has joined #jruby
enebo[m] has joined #jruby
rtyler1 has joined #jruby
anubhav8421[m] has joined #jruby
ilikeorangutans[ has joined #jruby
KarolBucekGitter has joined #jruby
ChrisSeatonGitte has joined #jruby
claudiuinberlin[ has joined #jruby
TimGitter[m] has joined #jruby
aemadrid[m] has joined #jruby
daniel_jruby_que has joined #jruby
JasonRogers[m] has joined #jruby
xardion[m] has joined #jruby
olleolleolle[m] has joined #jruby
UweKuboschGitter has joined #jruby
aaronkelton[m] has joined #jruby
amiracam[m] has joined #jruby
fzakaria[m] has joined #jruby
rwilliams[m] has joined #jruby
ezzeddine[m] has joined #jruby
CharlesOliverNut has joined #jruby
rdubya[m] has joined #jruby
XavierNoriaGitte has joined #jruby
jellymann[m] has joined #jruby
OlleJonssonGitte has joined #jruby
MarcinMielyskiGi has joined #jruby
BlaneDabneyGitte has joined #jruby
drbobbeaty has quit [Ping timeout: 260 seconds]
rusk has quit [Read error: Connection reset by peer]
rusk has joined #jruby
drbobbeaty has joined #jruby
snickers has quit [Quit: Textual IRC Client: www.textualapp.com]
shellac_ has quit [Quit: Computer has gone to sleep.]
lucasb has joined #jruby
shellac has joined #jruby
nirvdrum has quit [Ping timeout: 240 seconds]
<headius[m]> good morning
<headius[m]> so today I will continue looking at rubygems upgrade
<headius[m]> there are two failures for gems within a jar
<headius[m]> hmm
<headius[m]> I'm thinking RG changed to not search load path as though it's a gem home
<enebo[m]> wow...so loading should get faster?
<headius[m]> possibly?
<enebo[m]> I guess order would matter
<headius[m]> so the two cases that fail now are in JRuby suite, in test/jruby/test_jarred_gems.rb
<headius[m]> one case requires a jar that has a GEM_HOME structure in it and then expects gem list to show that gem
<headius[m]> it does not add anything to GEM_HOME or repoint GEM_HOME
<headius[m]> the other case does something similar and then tries to load the gem
<headius[m]> so it's the same cause
<headius[m]> in both cases it seems that RG is not searching new load path entries as if they were gem homes
<enebo[m]> GEM_PATH?
<enebo[m]> I cannot remember all those envs :)
<headius[m]> whatever
<headius[m]> I just mean it has that structure
<enebo[m]> yeah I just mean perhaps the test should just use the gem specific env and accept this is a rg change and not our change
<headius[m]> actually I'm wrong... one of the test does change GEM_PATH to point at the jar and then try to require the gem
<headius[m]> so that case could also be that GEM_PATH is only looked at once at boot
<enebo[m]> unless that doesn't work
<enebo[m]> yeah feels like in a dynamic env like Ruby requiring it to be right as something which only bootstraps before user code is strange
nirvdrum has joined #jruby
<headius[m]> I'm not sure how the first case ever worked since all it would do is add the gem.jar contents to load path
<enebo[m]> yeah that looks like some ancient magic
<headius[m]> er sorry I mean second case with the require
<enebo[m]> yeah
<headius[m]> GEM_PATH case seems like it should work but doesn't anymore
<headius[m]> only this file fails though
<enebo[m]> how about MRI
<headius[m]> it's a jar
<enebo[m]> well I don't mean the jar part but just adding GEM_PATH in general
<enebo[m]> I assume it works but maybe they removed it or something in the major update
<enebo[m]> I would be surprised if they removed GEM_PATH
<headius[m]> GEM_PATH seems fine
<headius[m]> I'm wondering if they added something to check for dirs
<enebo[m]> Seemingly perhaps some jruby override maybe no longer happens or something
<headius[m]> and jar shows up as not-dir
<enebo[m]> "or something" gotta cover all the bases
<headius[m]> gem path still works with jar unpacked
<enebo[m]> ok that is something.
<enebo[m]> although I suppose we knew that
<headius[m]> ahh I may have found the load path change
<headius[m]> # if +check_load_path+ is true (the default), then find_files also searches
<headius[m]> # $LOAD_PATH for files as well as gems.
<headius[m]> well I'm in the right place
<headius[m]> ugh markdown
<enebo[m]> ## foobar
<headius[m]> there is some good news out of this
<headius[m]> I realized in this process that MRI runs its test quite with --disable-gems
<headius[m]> so I turned that on on the update_rubygems branch and now MRI suites are running in under 15 min
<headius[m]> and green
<enebo[m]> how long was it before?
<headius[m]> over 15 minutes? it wasn't a big jump I guess but it's well under 15 min for them now
<headius[m]> refined_send merge was 12, 15, 15
<headius[m]> I guess my question is how long should I spend trying to figure out this change in gem discovery from a jar
<enebo[m]> it begs a question of who uses it
<headius[m]> indeed, and who would break if we shipped it
<headius[m]> it's just this one test file failing
<headius[m]> sigh I'll try to bisect RG
<headius[m]> it's too big for me to just throw arts
<headius[m]> darts
<headius[m]> or arts
<headius[m]> so it begins
<enebo[m]> yeah the epic arc of a JRuby bisect
<headius[m]> the most likely outcome is that it would require an RG patch to fix
<headius[m]> 28c1f2247d420506c70acea8aeb54f6c83f159eb
<headius[m]> Speed up globbing relative to given directories
<enebo[m]> monkeypatch?
<headius[m]> so it's a change to how it tries to glob for gems in the paths given
<headius[m]> probably breaks because it's doing blind File.join(jar, file)
<headius[m]> the old one did Dir[jar] { } and searched for the files that way, which I guess was "slower"
<headius[m]> Dir[] works properly with jar contents, joining the file with the jar clearly would not
<enebo[m]> yeah this is multiple places
<enebo[m]> a fix would be to not join to that helper I guess
<headius[m]> perhaps use old logic if the path is not a dir
<headius[m]> that would fall back on smart Dir[] logic
<enebo[m]> yeah that would work too
<enebo[m]> the fact that join is baked into calling the helper makes what Isaid difficult. and not all callers use same number of pre-join args
<headius[m]> yeah
<headius[m]> well it looks like skipping the 2.5 branch there makes it work again on rubygems master
<headius[m]> but strangely not in our copy
<headius[m]> ok nevermind it works
<headius[m]> I think I patched the wrong file
rusk has quit [Remote host closed the connection]
shellac has quit [Read error: Connection reset by peer]
sagax has quit [Ping timeout: 268 seconds]
subbu is now known as subbu|away
sagax has joined #jruby
<headius[m]> enebo: ok so this will require some work but I have a reduced case
<headius[m]> call me crazy but I'm thinking we ship with it and disable the test and fix it afterwards
<headius[m]> I think it only affects these specific cases where you're requiring a jar or setting GEM_PATH to a jar
<headius[m]> the first case returns [] so it doesn't find the gems in the jar
<headius[m]> that's the case that runs in the "if >= 2.5" section of rubygems/util.rb
davydotcom has joined #jruby
<davydotcom> has anyone seen an issue since upgrading from jruby 9.1.17 to 9.2.x when running in tomcat with embedded gems a weird invalid argument error
<davydotcom> 2020-02-14_20:00:34.61712 Errno::EINVAL: Invalid argument - /opt/morpheus/lib/tomcat/webapps/ROOT/WEB-INF/classes/specifications/winrm-2.3.4.gemspec
<davydotcom> file does exist
<davydotcom> sysopen at org/jruby/RubyIO.java:1236
<headius[m]> Hmm that's new to me
<davydotcom> its driving me nuts lol
<davydotcom> works fine local in dev
<davydotcom> fails running in tomcat 8 java 8 ubuntu OS
<davydotcom> its something with SysOpen
<davydotcom> screenshot of stack trace if this helps
* rwilliams[m] uploaded an image: Screenshot_20200214-120957.jpg (57KB) < https://matrix.org/_matrix/media/r0/download/matrix.org/EbZlGNjJxHjiZBbedhkoYZja >
<rwilliams[m]> What is this? I get them every few weeks
<davydotcom> not sure what that is
<headius[m]> huh
<headius[m]> well it's chanserv from freenode IRC, must be getting confused by the matrix bridge
<headius[m]> I don't know why it would invite you
ur5us has joined #jruby
<headius[m]> davydotcom: I think you should file it as an issue and try to narrow it down to a specific 9.x that starts to fail
<rwilliams[m]> Yeah. I can't find a way to disable random invites
<headius[m]> without more info I can't really tell what it might be
<headius[m]> so there's the bug for the remaining failiures with RG update
<davydotcom> it started failing at 9.2.x
<headius[m]> I think we should disable the test and go ahead with RG 3.0.6 in 9.2.10
<headius[m]> davydotcom: that covers almost a year of releases
<enebo[m]> headius: yeah I think so to
<headius[m]> thousands of commits
<headius[m]> do you mean it fails in 9.2.0?
<davydotcom> yea
<headius[m]> enebo: ok, then there's nothing else to do on that branch
<davydotcom> ill do some more testing see if i can narrow it more
<davydotcom> standby
<headius[m]> the stack overflow is an issue in all MRI too, it's just an incompatiblity between the RG warn patch and that weird warn+ super test
<headius[m]> davydotcom: cool, thanks
<headius[m]> if you have a small app we can use to test it that would also be a huge help
<headius[m]> otherwise we kinda have to guess at it
<davydotcom> i had to bump due to a CVE on snakeyaml breaking 9.1.18
<davydotcom> i had to bump due to a CVE on snakeyaml breaking 9.1.17
<headius[m]> lovel
<headius[m]> lovely
<headius[m]> ok I disabled the test...branch should go green now and I'll merge it
<headius[m]> I picked RG 3.0.6 because it's what CRuby 2.5.7 seems to ship with
<headius[m]> suppose I better confirm there's not some CVE
<headius[m]> huh ruby-lang.org is down
ur5us has quit [Quit: Leaving]
<headius[m]> enebo: we should start putting the version-specific bits from release notes in the tag commit
<headius[m]> then it will show up under github releases
<headius[m]> maybe it's just me but MRI suite definitely seems faster now
<headius[m]> enebo: another change to discuss is the thing the Azul folks found
<enebo[m]> headius: assuming their is no impact with it I don't care setting that on oneclass but I would not want to risk that if we have any doubt
<headius[m]> well in theory it should be totally fine when using OneShotClassLoader to load only one thing
<enebo[m]> headius: It certainly is really unimportant...so perhaps just try it for 9.3.0.0 and then get some time to notice
<headius[m]> I can throw it in a PR and mark for 9.3
<headius[m]> it's literally just calling registerAsParallelCapable in OneShotClassLoader.clinit
<enebo[m]> yeah it probably is worthwhile to observe any effects over a longer period of time
<enebo[m]> yeah I guess not knowing how important that setting is (which appears to add a synchronoize block)
<headius[m]> I read an article on it... seems like it basically reduces some heavy-weight locking in legacy ClassLoader if you don't need it
<headius[m]> so it's an opt-out of full synchronization
<headius[m]> fixing this on OSCL and JRCL might improve loading times a bit too
<headius[m]> JRCL does more magic though so I'm reluctant to just make the change blindly there
<headius[m]> hmm looks lke most risky stuff in JRCL is already synchronized
<headius[m]> perhaps I should throw parallel capable on that too for the PR
<headius[m]> enebo: down to 8 open issues after some punts
ur5us has joined #jruby
ur5us has quit [Ping timeout: 240 seconds]
<davydotcom> headius: confirmed my issue is also in jruby 9.2.1.0+
<davydotcom> loading spec classloader SysOpen Err::Invalid
<headius[m]> 9.2.0 is ok?
<davydotcom> no
<davydotcom> is this by chance related to ffi?
<headius[m]> It could be
<headius[m]> I am confused about which version is broken
<headius[m]> You said 9.2.1+
<davydotcom> that is what ive tested back to so far
<davydotcom> latest 9.1.17 worked fine
<davydotcom> im verifying 9.2.0.0 again just in case
<davydotcom> when i built this i package the gems into the war and the ffi version did change as well from before
subbu|away is now known as subbu
nirvdrum has quit [Ping timeout: 272 seconds]
nirvdrum has joined #jruby
lucasb has quit [Quit: Connection closed for inactivity]
nirvdrum has quit [Ping timeout: 240 seconds]
davydotcom has quit [Remote host closed the connection]