<headius> going to try to land fiber crap today or tomorrow... rebasing it now
<headius> it isn't as good as I'd like but it fails nothing new and passes most of the 3.1 specs
<headius> I may be emulating semantics that are not really to spec, and that emulation limits how closely I can be compatible with obscure features that are in spec
<headius> byteit101: merged
<headius> enebo: are we still dueling XML element ordering? I thought the polyglot update would fix this
<headius> I have diffs on master when I build now, but perhaps your merge from 9.3 did not include a rebuild?
<headius> doesn't matter if I build with Java 8 or 9+, which is where the diff came from before
<headius> kares and byteit101 you too, if you build from clean master do you get xml diffs?
<headius> I don't want to commit these if I'm the only one seeing them
<enebo[m]> headius: still on your branch or did you land it?
<headius> still on my branch because of the xml diffs
<headius> phooey... when I build on mac there's no diffs
<enebo[m]> I mean I just fetched your branch and did a build so wouldn't that not change xml in that case?
<enebo[m]> the xml is checked in so unless you did not check in your last build then I would not expect the xml to change
<headius> this is what I'd hoped to avoid with the polyglot extension update
<enebo[m]> yeah and I got that on your branch but it was not a clean checkout ... but... I don't think that should matter in this case
<headius> seems like there's still something relying on JDK hash ordering during the model generation of polyglot
<headius> and apparently my JDK on linux orders differently than yours
<headius> openjdk version "11.0.16" 2022-07-19
<headius> OpenJDK 64-Bit Server VM (Red_Hat-11.0.16.0.8-1.fc36) (build 11.0.16+8, mixed mode, sharing)
<headius> OpenJDK Runtime Environment (Red_Hat-11.0.16.0.8-1.fc36) (build 11.0.16+8)
<enebo[m]> yeah that may be or we use a similar strategy but it is seeded or something
<enebo[m]> I used OpenJDK Runtime Environment (AdoptOpenJDK)(build 1.8.0_242-b08)
<headius> yeah I have mostly been using the Red Hat builds for Fedora
<enebo[m]> It seems polyglot should use an ordered hash as the ultimate solution
<enebo[m]> having consistent ordering is "good enough" but I think an ordinary expectation would be same order as ruby
<headius> yeah it must not just be using ours because order would be stable then
<headius> doesn't matter if I use 8 or 11 I still get these diffs
<headius> my 8 is some other build
<enebo[m]> yeah I guess maybe make an alias to check those out and after 9.4 we spend the time to work on this?
<kares[m]> <headius> "kares and byteit101 you too..." <- nope all clean
<kares[m]> actually I've tried 9.3 branch
<enebo[m]> ok well if I am the only person seeing this then I am ok with the annoyance of this but I still think ordered hash should happen at some point
<headius> enebo: I think I am the only one seeing this
<enebo[m]> yeah I don't normally see this issue with 8
<enebo[m]> I have seen it on some other jdks but I don't recall when
<enebo[m]> So likely some jvm is built in a way giving different hashing
<headius> do you see the old ordering here:
<enebo[m]> yeah that was what it looked like on your branch
<headius> what branch are you testing locally for this
<headius> I'm still confused if you are seeing it or not
<headius> a clean build of master for me, with any of my local JDKs, produces diffs like this
<enebo[m]> update_polyglot was the branch (pretty confused why history does not show this but I can see it in my scrollback)
<enebo[m]> but jruby-9.3 and master do not cause this for me normally (but it has happened I suspect using a newer or exotic jvm
<enebo[m]> and by exotic I don't mean strange but just not something I would dev with
<enebo[m]> I also do not typically retrieve the newer JVMs that often
<headius> yeah seems like your release commits flipped the elements back from what was on my polyglot branch
<enebo[m]> Not sure I remember why I am keeping graal 19.2 around. Something significant with perf I think
<headius> so it sounds like I'm the only one seeing these diffs then
<headius> I will get the xml diffs out of fiber PR then
<enebo[m]> build the git co of those two files into your PS1 prompt
<headius> hah
<enebo[m]> yeah but I suppose one of us will also start seeing this and a light bulb will go off
<headius> the fix I saw in polyglot specifically mentioned property ordering, but I'd hoped they normalized element ordering too... seems not
<enebo[m]> getting closer
<headius> ok there were a few regressions... not sure if I forgot to commit some minor fixes or if I just didn't notice them
<headius> they're fixed now and enumerator and fiber specs are green with mspec ci and there's only a few Fiber#raise wip tags left
<headius> one is something about disallowing message and keywords (passed to exceptionClass#exception I suppose?), one is about raising against an unborn fiber (should raise fiber error but does not) and one is raise twice against a thread should re-raise the last exception (so I guess some implied $! context within the fiber, unclear)
<headius> I will let the PR settle and merge what I have
<headius> took me a bit to get my head around the semantics again
<headius> time to kick this release out of bed
<headius> I'm going to spend rest of week greening stuff up and assessing remaining fails
<byteit101[m]> oh i was actually going to add a test for setters change
<enebo[m]> headius: I think your fiber changes broke test:jruby somehow
<enebo[m]> only a single failure but I do not see it on the merge commit I made yesterday but I do in your Pr
<headius> I'll look at it
<enebo[m]> byteit101: just open another PR for the test
<headius> NPE in an enumerator spec, it's probably my stuff
<headius> this is nearly the same NPE I just fixed... so there's a bogus NEVER value leaking into execution
<enebo[m]> I am going to work on Warning#warn and do something relatively easy
<enebo[m]> My combined parser and include/prepend stuff has lowered my confidence :)
<enebo[m]> heh...maybe we are not the problem
<enebo[m]> This seems to be added for uplevel for rubygems but I think warn has more kws
<headius> oh lovely
<headius> I wish they'd at least box changes like this to a specific version range
<enebo[m]> but I don't see why we don't support uplevel
<enebo[m]> it adds frame info so maybe we lose something
<enebo[m]> err heh I need to read code before commenting
<enebo[m]> this is specifically called if uplevel is not called which I guess maybe we did not support kws on warn and they worked around it this way
<headius> I think I have it
<headius> probably me being overzealous in using an object instead of null to mark "no data" being transferred... I need all edges to recognize that it is the NEVER object when returning to Ruby, and convert that to nil
<enebo[m]> I had a similar problem fixing that Time#at but it was passing nil but nil is a valid input which causes an error. Actually completely the opposite issue but similar
<headius> I pushed a fix, bbl
<enebo[m]> ok
<headius> enebo: looks good, I'm merging it and we'll improve on master as needed
<headius> WIP specs do not complete, could be fiber related since it fails somewhere during that, but could also just be an unimplemented feature that causes rake to bail out
<headius> I will investigate that tomorrow
<headius> ok a Fiber#transfer spec hung and that ended up killing the run... only those specs and a SortedSet spec did not complete so I'll look into transfer