<headius> mac failed again with a bizarre failure (something in scriptingcontainer) but I think we're almost back to green on this PR
<headius> other than unstable tests that will always need some investigation
<headius> yeah it didn't fail a second time... mystery
<headius> huzzah, green
<headius> merging
lavamind has quit [Remote host closed the connection]
lavamind has joined #jruby
subbu has joined #jruby
subbu has quit [Ping timeout: 250 seconds]
subbu has joined #jruby
subbu has quit [Ping timeout: 250 seconds]
subbu has joined #jruby
adam12 has quit [Quit: Ping timeout (120 seconds)]
adam12 has joined #jruby
subbu has quit [Ping timeout: 240 seconds]
subbu has joined #jruby
subbu has quit [Ping timeout: 268 seconds]
peko[m] has joined #jruby
subbu has joined #jruby
<headius> comparing true virtual threads with async/await is hardly a fair comparison
<headius> virtual threads are not cooperatively scheduled like async/await and won't automatically deschedule at blocking boundaries
<headius> but I'm glad to see that loom virtual threads are kicking ass here
<headius> enebo: I am on 9.3.4 stuff now
<headius> do you have any input on the joni thing, especially wrt that sunday search change? Otherwise it's ready to merge (and release)
<enebo[m]> I just commented funny
<enebo[m]> as far as sunday search it has always been that and never used and not working so I don't think we need action on that past his change
<enebo[m]> If someone enables it then it becomes a new issue if it is not working
<headius> but I thought you said you enabled it
<enebo[m]> I am confused though I really thought when I reverted the perf thing it was reenabling sunday search but perhaps only partially to use fast forward/reverse char stuff
<headius> yeah I am confused too
<enebo[m]> I just reverted some code which did faster searches and lopex said it was sunday search
<headius> ah ok
<enebo[m]> It is in there I think but perhaps it is not entirely sunday search
<headius> your other solution for perf is good too, just polymorphize stuff if it actually is a problem
<lopex[m]> sunday is a modification of boyer-moore
<lopex[m]> slight one
<lopex[m]> I think we can get rid of this flag entirely
<enebo[m]> ah yeah. so we really just re-added boyer-moore
<enebo[m]> sunday within that is off
<lopex[m]> yeah
<headius> ok
<headius> so I will merge and release today then?
<enebo[m]> lopex: since we are all here ....
<lopex[m]> we need to fix that sundays search map
<enebo[m]> lopex: you had said you isolated that one bug to returning wrong value for length but that MRI also diid
<lopex[m]> havent got fat though apart from identifying that it trncates the char on lookup
<enebo[m]> but somehow MRI still works
<enebo[m]> yeah
<lopex[m]> mri has that +1 failover, but I'm not sure it's that
<lopex[m]> advance +1 on broken char
<enebo[m]> you had said previously (I think as initial speculation) that MRI also had more lax mbc length code too
<enebo[m]> Not sure if it applies here but you have an open issue about that on joni
<enebo[m]> +1 could fix this case but it also sounds like it is trying to work around invalid strings vs a valid one with the wrong length result :)
<lopex[m]> and onigenc_mbclen_approximate
<lopex[m]> it's more constrly, but it's not used everywhere
<enebo[m]> lopex: but they are not using this in B-M code?
<lopex[m]> some things might have changes too since then
<enebo[m]> lopex: would it be too much trouble to see if you can add the +1 and see if we work in that case to line up more with MRI?
<enebo[m]> Even if that is not the right eventual fix it may just be one which gets us further along without trying to fix that table
<headius> I will hold off on releasing if we might have some possible fixes to try
<lopex[m]> so the problem is bm_search_notrev_ic
<lopex[m]> - /* Boyer-Moore-Horspool search applied to a multibyte string (ignore case) */
<lopex[m]> and str_lower_case_match which blows
<enebo[m]> so it returns broken char (I think you said -2)
<lopex[m]> yeah, er it was mbcCaseFold
<enebo[m]> golden fix is to fix table since it is a valid right?
<lopex[m]> I dont know
<headius> I'm rebasing my PRs marked for 9.4.3 so there may be a backlog for a while
<lopex[m]> not without debugging
<enebo[m]> so the table might return broken for non-broken chars
<enebo[m]> lopex: I am asking about what it should do and not what it does do
<lopex[m]> I guess it's not the table bu that + 1 arg if (str_lower_case_match(enc, case_fold_flag, target, target_end, s, se + 1))
<enebo[m]> oh it only +1 is it is true?
<lopex[m]> that +1 essentially truncated that 4 byte char to 2
<enebo[m]> oh yeah I remember this. one path (slow) uses se and B-M does +1
<enebo[m]> err I am wrong
<enebo[m]> sunday search is s + 1
<enebo[m]> which apparently is off :)
<lopex[m]> but, mri essentialy has to use char head, not the entire char as an index
<lopex[m]> so that's where I'm confised
<lopex[m]> *confused
<lopex[m]> I'll need to debug mri
<enebo[m]> s is being used for us and that should be char head as long as length is not broken right?
<lopex[m]> no idea
<lopex[m]> I'm speculating
<enebo[m]> ok I would just hope that s+= in search is advancing by length
<lopex[m]> se = s + tlen1;
<lopex[m]> that does the advancing
<enebo[m]> yeah
<lopex[m]> er
<lopex[m]> actually
<lopex[m]> there's that inner loop s += enclen(reg->enc, s, end);
<enebo[m]> we are talking about BM_FORWARD/BACKWARD?
<headius> we could push this through in this joni release: https://github.com/jruby/joni/pull/59
<headius> it has been deprecated for a few months and the migration path is trivial
<enebo[m]> BM_IC_FORWARD
<enebo[m]> lol
<enebo[m]> ok I was in wrong method
<headius> it also avoids allocating a region array when there's only one region
<headius> I'll rebase
<enebo[m]> so s+1 for lower case match is the weird bit
<lopex[m]> bleh I was looking at bm_search_notrev
<lopex[m]> lol
<enebo[m]> hahah yeah I was on normal BM for a minute
<lopex[m]> there's bm_search_notrev_ic too
<enebo[m]> p, s+1 feels like the two values of importance
<enebo[m]> p I think is meant to be char head but pehaps it is just not end but s+1 is the end for the search
<enebo[m]> s - (targetEnd - targetP) + 1
<enebo[m]> This seems to be current s - length + 1 to I guess advance 1 past last search?
<enebo[m]> to be honest something about this code feels like a different use of addressing would make these values clearer
<enebo[m]> I realize this is a port of C code but there is a lot of math to twiddle things +1 or the length subtraction
<enebo[m]> from debugging statements I can tell we are also hitting the use_byte_map loop too
razetime has joined #jruby
<headius> hey enebo lopex if you get a chance review https://github.com/jruby/joni/pull/59
<headius> I've rebased now... it completes the privatization of Region innards and splits it into SingleRegion and MultiRegion to avoid an array alloc in the former case
<enebo[m]> headius: looks good to me.
<headius> just realized I can drop numregs field and just do begEnd.length / 2
<headius> I could also make it an array of long and pack them in but perhaps that's overkill
<headius> wouldn't save any space
<headius> enebo: that's an interesting one
<headius> I'll see if anything has changed in that pool recently
<headius> recently as in 9.3.11 timeframe
<enebo[m]> he links to a fairly big PR
<headius> yeah it's probably not that
<headius> that is all about improving the handling of handle_interrupt and thread events
<headius> it doesn't really touch IO other than in places where the new API for interrupts should be used
<enebo[m]> tough with out repro
<headius> yeah I missed that he can't repro
<headius> enebo: lopex I will merge my region change then... this will bump joni to 2.2 because of the API change
<headius> CI is much faster now but still room for improvement
<headius> enebo: anything else coming for joni?
<headius> enebo: I do not have enough info for https://github.com/jruby/jruby/issues/7804
<enebo[m]> yeah I asked for them to do --dev
<enebo[m]> but I did not try ethon tests locally
<enebo[m]> headius: not sure on joni...I will look through but the error with the weird pipe char hopefully can get fixed
<headius> ok
<headius> no rush other than wanting that release for jruby 9.4.3
razetime has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
<enebo[m]> I wonder how this will fare on windows: https://github.com/jruby/jruby/pull/7452/files
<lopex[m]> enebo: yeah, afair it was only about accessors ?
<lopex[m]> did that eager region make any difference for your changes ?
<enebo[m]> sorry I am not following
<lopex[m]> that, "eager" was just to reuse preallocated region
<lopex[m]> do we reuse matcher instances for methods like scan, gsub, split etc now ?
subbu has quit [Ping timeout: 250 seconds]
<headius> lopex: within a loop I assume we do
<headius> enebo: I landed all of my PRs that are going into 9.4.3. There's one working on improving object shaping but what's there is probably not worth shipping right now.
<enebo[m]> ok
<headius> looking at other targeted bugs now
<enebo[m]> yeah we have some non-specific things in that list like 3.1 features which can be punted sooner than later out of the list
<headius> yeah lots of kicking the can in here
<headius> never seem to circle back to these in time for release
<headius> enebo: placeholder for testing and so we don't forget to update joni: https://github.com/jruby/jruby/pull/7807
<lopex[m]> numbers!
<lopex[m]> those configurable joni flags are all good, but some are in really thigh hot paths
<lopex[m]> I'm not against that, just raising my concerns
<lopex[m]> we need perf ci, and this comes all again ad again
<lopex[m]> *and