subbu has quit [Quit: Leaving]
sagax has joined #jruby
subbu has joined #jruby
subbu has quit [Client Quit]
subbu has joined #jruby
subbu has quit [Ping timeout: 240 seconds]
subbu has joined #jruby
<enebo[m]> lopex: jruby -e 'p "abcdbce".partition(/b\Kc/)'
<enebo[m]> lopex: I think the last time I asked you said lookbehind works.
<enebo[m]> lopex: interesting 2.7 is same as JRuby for 3.0 is putting the 'b' onto first element
<enebo[m]> lopex: ah match data is correct. our result index does not match begin in first match.
<lopex[m]> enebo: you mean 'keep' ?
<enebo[m]> \K so heh yeah I am messing up on name
<lopex[m]> so what changed in 3.0 ?
<enebo[m]> in the above partition the first element is now 'ab' where it was 'a' before
<enebo[m]> our will return 1 so we use 'a'.
<enebo[m]> I can change it to use matchdata[0].begin which works but that is not really a working solution
<lopex[m]> what about simpler case ?
<enebo[m]> you mean something with just a regexp?
<lopex[m]> yeah
<enebo[m]> I almost feel like I will make this more complicated because I would have to add a capture '
<enebo[m]> So my current understanding is matchdata made for \K is doing it right. begin is 2 in the first search in partition
<enebo[m]> our result from is returning 1
<lopex[m]> I cant see some changes for 3.0 in #partition
<enebo[m]> match(1) in joni will return 1 so it is not adding the \K part of the match
<enebo[m]> struct re_registers *regs = RMATCH_REGS(match);
<enebo[m]> pos = BEG(0);
<enebo[m]> actually this is 3.0. So I guess they do look at the beg of the first matchdata
<lopex[m]> do we use get_pat_quoted ?
<enebo[m]> nope
<enebo[m]> We just look if it is an instance of regexp
<enebo[m]> I find that method to be strange
<enebo[m]> In the case of String or Regexp it will just perform a syntax check
<enebo[m]> we will get that naturally
<enebo[m]> but the it is "something else" will rb_check_string_type then see if it is a regexp
<enebo[m]> which is weird
<enebo[m]> you know we do this wrong in our impl
<lopex[m]> so, I'm kind of lost, is it a partition of a match data issue ?
<enebo[m]> we search then we subpat again
<enebo[m]> I am now thinking this is a bug in only partition
<lopex[m]> cant see that pos = BEG(0); in 2.7
<enebo[m]> We use the result of search and then do the regexp a second time which is wasteful
<enebo[m]> yeah I was wrong this is a 3.0 change
<enebo[m]> I believe I will see this behavior all over with regexp coden ow
<lopex[m]> sep = rb_str_subseq(str, pos, END(0) - pos); vs sep = rb_str_subpat(str, sep, INT2FIX(0));
<lopex[m]> 3.0 vs 2.7
<enebo[m]> yeah
<enebo[m]> \K aside it makes me wonder why this was done line this to begin with
<enebo[m]> It could be a simple regexp call
<enebo[m]> I guess it is now :)
<enebo[m]> lopex: Thanks for the help. I guess I just needed to chat with you
<enebo[m]> I hope things are going well
<enebo[m]> To answer my own question...match data with \K would give a different result pre-3.0 so they had to do two regexp invocations
<enebo[m]> The 3.0 behavior seems much nicer to me
<lopex[m]> and all string methods changed wrt that ?
<enebo[m]> I think so I can see now both rpartition and split have same failure
<lopex[m]> bleh
<enebo[m]> That partition example looks more "correct" to me in 3.0
<lopex[m]> but it looks like it could break a lot of things
<enebo[m]> yeah I don't know. It definitely will break people using \K but I wonder how many people use \K in these methods
<lopex[m]> yeah, an obscure one
<enebo[m]> I would almost bet money people will just report it as a bug
<enebo[m]> the pre-3.0 behavior
<lopex[m]> \K has some tests in joni
<lopex[m]> 8 actually
<lopex[m]> :P
<lopex[m]> and one commented out
<lopex[m]> / x2s("a\\K?a", "aa", 0, 2); // error: differ from perl
<lopex[m]> not sure if it's still broken
<enebo[m]> the question is who commented it out
<enebo[m]> comment sounds like a oniguruma comment
<lopex[m]> yep
<lopex[m]> # x2("a\\K?a", "aa", 0, 2) # error: differ from perl
<lopex[m]> lol that hash
<lopex[m]> so at least it adds to our confidence wrt compliance :P
<lopex[m]> onigmo tests are in python, I wonder if we could use jythin for that
<enebo[m]> good question
<enebo[m]> index and rindex fixed
subbu has quit [Quit: Leaving]
<mattpatt[m]> hey all. Was looking at the last snapshot deploy github action failure
<mattpatt[m]> actually failed in javadoc generation, and not at the Sonatype maven publish stage
<mattpatt[m]> enebo: is there any chance you could run another manual snapshot publish?
<mattpatt[m]> wondering if that was a weird shouldn't-have failure
<mattpatt[m]> also wondering if the sonatype stuff is working now
<enebo[m]> mattpatt: I will re-run on master
<mattpatt[m]> thanks
<enebo[m]> yeah hopefully it was something transient which will never happen again :)
<headius> There are a few new intermittent failures now that we have moved everything to get hub that either need to be fixed or excluded
<headius> Could be related to different timing or different number of cores or different network configuration
<headius> That has kept the full build plus deploy from having many green runs
<headius> s/get/github/, s/hub//
<enebo[m]> hmm
<enebo[m]> looks like we are using too new of a JVM?
<enebo[m]> zulu 11!
<enebo[m]> so it says 8 in .yml but it appears to be 11
<headius> I don't think the Java doc generation is working at all on Java 9 and higher for us because we are not fully modularized and it throws a fit
<headius> Is not working
<headius> Whatever... I had to change the deploy build to Java 8 because it was complaining about a similar module visibility issue
<enebo[m]> That error appears to be an export issue with modules so perhaps once that works the javadocs stuff will just explode
<headius> Hmm, did I not merge my pull request correctly?
<enebo[m]> maybe I reran something before over again?
<enebo[m]> I thought I just clicked run workglow
<headius> Yeah I think your commit might be just before this got merged
<enebo[m]> aha I ran master as well
<enebo[m]> not sure if you merged this or not
<headius> I accidentally merged it to master first but I did a second merge to 9.3
<enebo[m]> ok so it should be on both
<headius> It should be on both but I wouldn't be surprised if something got messed up
<enebo[m]> hmm this is a little confusing
<enebo[m]> I ran manual-snapshot-deploy action is that right?
<enebo[m]> just fired off a jruby-9.3 version of manual to see
<headius> I think it should work but it should also be running along with every push to 9.3 or master
<enebo[m]> but maybe we can rename one of the two workflows since they have the same textual name in actions page
<headius> Oh but I think it is using the wrong hash so it has an old version of the actual snapshot deploy workflow
<headius> Compare the hash in ci.yml with the one in the manual deploy YML
<enebo[m]> I am on master so I can see the '8' as java-version
<enebo[m]> ok jruby-9.3 has same java 11 issue
<enebo[m]> uses: jruby/jruby/.github/workflows/snapshot-publish.yml@a144fdb39a1e2844322d9e439d02d378593a08d4
<enebo[m]> yeah I think this should be 6cd0d4d96d9406635183d81cf91acc82cd78245f
<enebo[m]> I will change it and push to master (since I am on master)
<enebo[m]> Setting Java 8.0.312+7 as the default
<enebo[m]> yay
<enebo[m]> mattpatt: ok manual works (and other one will also work). The original issue was not using 8 which headius fixed and the manual failure was not updating the hash to the fixed non-manual action
<mattpatt[m]> woo