<puritylake[m]> Ok think it's working
<puritylake[m]> Or not cause I'm stupid lol
<puritylake[m]> Screw it I'll get back to it tomorrow with a clear mind
<Freaky> headius: what Linux's did you have in mind when you mentioned java_home?
<Freaky> seems specific to macOS, but it's a bit awkward to search for ;)
<kares[m]> headius: we stopped releasing jruby-openssl to maven - the gem is already pushed (and downloaded 3k+ times) on RGs
<kares[m]> still use maven to build the final gem package (w the release profile) - so I might have deployed to sonatype but not intent to release there.
<kares[m]> I adjusted the tests for the expected file grow (due a bigger BC packaed) on the 9.2 PR, there's still CI azure jobs broken atm - seems unrelated
joast has quit [*.net *.split]
mlaug has quit [*.net *.split]
mlaug has joined #jruby
joast has joined #jruby
<enebo[m]> kares: thanks for looking at the size increase. We seem to have set pretty narrow margins in checkversions job
<headius> good morning
<headius> enebo: it is just a MB boundary and we usually just pick the next largest
<enebo[m]> yeah I know
<enebo[m]> I am just saying it seemed pretty close
<headius> yeah I have never paid attention to how close to the actual size we are when I bump up the size check
<enebo[m]> I actually am not saying I am against putting it close. Just making an observation
<enebo[m]> I think the larger issue is in evaluating growth at all and figuring out what increased the size
<headius> we have never tracked that much but it would be interesting to know
<enebo[m]> When I have looked at it we tend to increase on native platform updates and stdlib updates
<enebo[m]> our code does also increase but it is quite a bit slower
<headius> the base JRuby jar has shrunk a bit in the last year or two
<headius> mostly from your parser lambda change
<enebo[m]> but when it does I unpack last release and then try and figure out what is different hoping (if it seems weird we changed the build and started bundling garbage)
<headius> at least we know we won't accidentally ship a 100MB tarball
<enebo[m]> yeah it is part of why I am not against it.
<headius> I restarted the jnr PR but it may still be stale and I don't feel like wrestling with the cache
<headius> if it fires before the artifact is present it will cache that failure for like 24h
<enebo[m]> I clicked on one run and it is actively running tests
<enebo[m]> I think it must have cleared
<headius> yay
<headius> JNR PR is green other than the azure jobs that have been failing for a while
<headius> I should just remove those on the 9.2 branch
<headius> we have moved away on master and could add a GitHub or Travis job for Windows
<enebo[m]> headius: I think we are in agreement to ship newer openssl for 9.2 as well?
<headius> enebo yeah
<enebo[m]> ok I will merge that as well
<enebo[m]> headius: one other one : https://github.com/jruby/jruby/pull/6889
<enebo[m]> this is for 9.3
<danieljrubyquest> Hi all! Regarding my message yesterday about getting an `NoMethodError` calling map on a Java `Java::JavaUtil::Collections::UnmodifiableRandomAccessList`: looking at `class.ancestors` before and after the upgrade from 9.2.19 to 9.3.1, I notice that `Enumerable` is part of the ancestor chain in 9.3.1 but not 9.2.19. Is that a recent change? And did this work via some method other than mixing in `Enumerable` previously?
<headius> hmm ok
<headius> danieljrubyquestionasker: what Java version are you running?
<danieljrubyquest> I'm confused by why the version *without* Enumerable is the one that allows map to be called -- seems backward in my mind but not familiar with how this works internally.
<danieljrubyquest> I'm running Java 11.0.9
<headius> yeah that is backward to me too
<headius> ok, I am trying to get an instance of this class locally
<headius> I am thinking something in that hierarchy also defines a "map" and it is interfering with this dispatch
<headius> like some private or protected "map" function on one of the Java classes that overrides the one from Enumerable
<headius> you could print out object.class.instance_methods to see if map might still be there but not public
<danieljrubyquest> Good point, thanks! Will do. Will take a minute (I am unfortunately dealing with a system I can only run in CI atm so have to wait for a build :thisisfine:)
<headius> it does appear to work for me on JRuby master:
<headius> oh duh it won't print because it is empty
<headius> but no error
<headius> does that command line above error for you?
<danieljrubyquest> That command doesn't error for me. But also the ancestor list is different from what I have in my service:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/af8bcc853db29c9844ba87b0775c252c92787db0)
<danieljrubyquest> So maybe this is an issue with some other mixins that are happening to the list somewhere?
<danieljrubyquest> Working on printing out the instance methods
<danieljrubyquest> But looking up those extra modules, I do not believe any of them should be messing with map...
<headius> since the example I gave works then we can assume it is likely caused by the other classes in the hierarchy
<headius> I agree though none of those look suspicious
<headius> if you could come up with a way to reproduce locally it would be a big help... right now I don't have much to go on
<danieljrubyquest> Makes sense. Thanks for your help with not a lot to work with!
<headius> it would be pretty weird for some Ruby library to remove or hide `map` so there could be something broken in JRuby with refinements or prepends or something
<headius> some complicated hierarchy that results in us not seeing the method anymore
<headius> danieljrubyquestionasker: a full error backtrace would be good too... if you like, open a bug so we can track discussion better
<headius> if it turns out not to be a bug, no big deal
<headius> the fact that it works in 9.2 makes me assume we regressed in some way
<danieljrubyquest> Thanks! I should also mention that separately from this (or maybe related?) the rspec tests for our JRuby service are hitting an OOM error after the upgrade, and still do so even if I double the memory from what they have used historically
<headius> danieljrubyquestionasker: that definitely should go in a bug report
<headius> we can offer you some guidance investigating what is taking up so much memory
<headius> you already took the first step we'd suggest so if double the memory doesn't work there's something wrong
<headius> enebo: looking over diffs from the merge
<headius> nothing jumping out so far but the install4j file gained some ^M
<headius> pretty much the whole file
<headius> sorry this is actually diffing master against the WIP branch
<headius> so it could be a recent change on master that brought in the ^M
<headius> a couple gems that go away in 3 returned too so I will remove those
<enebo[m]> yeah as I said there was virtually nothing in the merge which was a conflict
<headius> yeah looks pretty good
<headius> enebo: I never got the 9.2 jnr update merged so doing that in 9.3 and master now
<headius> it landed on 9.2 and then I spaced out the rest
<enebo[m]> I merged it this morning
<headius> yeah but that was into 9.2 branch
<headius> I was going to merge it to master after that and forgot
<enebo[m]> yeah but I also thought I merged to 9.3 before making that brnach
<headius> doesn't appear so
<enebo[m]> oh hmm
<headius> I just did a merge from 9.2 to 9.3 branches and those updates are missing
<enebo[m]> ok
<headius> it's fine, I'll have it fixed in a moment
<enebo[m]> That is odd. I wonder what I did
<enebo[m]> maybe I merged to master
<headius> that's possible
<headius> I will find out soon
<enebo[m]> ok
<headius> so the sequence for changes is potentially now: change 9.2, merge 9.2 to 9.3, merge 9.3 to master
<enebo[m]> yeah
<headius> hopefully we will be able to move away from much 9.2 work soon
<enebo[m]> I do this every time there is anything on ARJDBC
<enebo[m]> I am pretty surprised I made this mistake as I did it within 2 minutes of making the new branch
<headius> enebo: I removed two defunct gems that got re-added in the merge and pushed 9.2 merge cascade everywhere
<enebo[m]> oh yeah those were the ones I mentioned.
<headius> ok
<headius> now I have three working copies locally so intellij doesn't freak out
<danieljrubyquest> Thanks for the help today! As suggested, I have filed https://github.com/jruby/jruby/issues/6914 to document the issue with the `map` method (and, it appears, other Enumerable methods) disappearing from UnmodifiableRandomAccessList when other modules are being included. Please let me know if there's any more useful info I can provide!
<danieljrubyquest> I am thinking that the issue where my app OOMs newly with the version upgrade might best be filed separately. It is actually happening on a separate Java version from the other issue. Does that make sense?
<headius> Yes please