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