On 2019-07-24 15:51, ph10 wrote:
If I understand you correctly, your proposal would mean that every
non-anchored pattern would give a partial, empty-string, hard partial
match at the end of a non-matching segment, and never return "no match".
Yes. And I like this idea.
With it we could
On Wed, 24 Jul 2019, ND via Pcre-dev wrote:
> In terms of multisegment matching this may be say: partial hard match occurs
> when current segment is not last and it's content not enough to exactly
> determine, what match (or nomatch) would have WHOLE subject from this start
> position.
Yes, more
On 2019-07-23 20:20, ND wrote:
On 2019-07-22 17:32, ND wrote:
Now it can be useful to try putting into words, what exactly in
applying > to multisegment matching means "local no match" and what
means "partial > match".
>
Doc's says:
A partial match occurs during a call to pcre2_match() when
On 2019-07-22 17:32, ND wrote:
Now it can be useful to try putting into words, what exactly in applying
to multisegment matching means "local no match" and what means "partial
match".
Doc's says:
A partial match occurs during a call to pcre2_match() when the end of the
subject string
On 2019-07-22 16:32, ph10 wrote:
The characteristic of these is that the pattern can match an empty
string. I have now added this condition (which was easily done with no
repeated test) and those patterns now give partial matches.
It's excellent!!
Now it can be useful to try putting into
On Sun, 21 Jul 2019, ND via Pcre-dev wrote:
> /(?![ab]).*/
> ab\=ph
> 0:
>
> /c*+/
> ab\=ph,offset=2
> 0:
The characteristic of these is that the pattern can match an empty
string. I have now added this condition (which was easily done with no
repeated test) and those patterns now give
On Sun, 21 Jul 2019, ND via Pcre-dev wrote:
> New algorithm still have another parts of discussed oversight. For example it
> returns full match instead of partial in following cases:
>
> /(?![ab]).*/
> ab\=ph
> 0:
>
> /c*+/
> ab\=ph,offset=2
> 0:
The answer to that may lie in thinking about
New algorithm still have another parts of discussed oversight. For example
it returns full match instead of partial in following cases:
/(?![ab]).*/
ab\=ph
0:
/c*+/
ab\=ph,offset=2
0:
Alternative suggestion don't have this troubles. It simplify calculations
that main application must
I have just committed a patch that makes some small changes to the way
partial matches are handled in the interpreter. I hope Zoltán will in
due course pick these up for the JIT. (There are new tests at the end of
testinput2 which have no_jit set at the moment.)
The changes are really quite
On 2019-07-18 16:48, ph10 wrote:
On Wed, 17 Jul 2019, ND via Pcre-dev wrote:
Let us ignore for the moment whether there should be a new option or
not, and try to figure out what new logic might be needed. I am going to
experiment with the suggestion I made earlier:
If a hard partial match is
On Wed, 17 Jul 2019, ND via Pcre-dev wrote:
Let us ignore for the moment whether there should be a new option or
not, and try to figure out what new logic might be needed. I am going to
experiment with the suggestion I made earlier:
If a hard partial match is possible, return PCRE2_PARTIAL if
On 2019-07-17 16:55, ph10 wrote:
On Mon, 15 Jul 2019, ND via Pcre-dev wrote:
This option is added ten years ago EXACTLY for multisegment matching.
> Please read a very first proposal post and thread about it. Thats how
> partial_hard is born:
>
On Mon, 15 Jul 2019, ND via Pcre-dev wrote:
> This option is added ten years ago EXACTLY for multisegment matching.
> Please read a very first proposal post and thread about it. Thats how
> partial_hard is born:
> https://lists.exim.org/lurker/message/20090524.142622.cb850f3a.en.html
Your memory
> I am still not entirely convinced this change should be made. Zoltán,
> what do you think? It would involve making changes to JIT, of course.
I don't really see where we are heading now, and the situation feels chaotic. I
wouldn't increase maintenace burden without strong reasons.
Regards,
On 2019-07-15 15:24, ph10 wrote:
My point about partial matching meaning "may be incomplete" is still
true. Partial matching was not invented originally for multi-segement
matching, but for dynamically checking input. For example, if a user is
typing an 8-digit number, as each character is
On Mon, 15 Jul 2019, I wrote:
> However, there does exist the PCRE2_NOTEOL option. At the moment, this
> is applied only to the $ meta character, not \z or \Z. Perhaps it
> should.
Or perhaps an entirely new option PCRE2_NOTEOS (not end of subject)
should be invented, to stop \z ever
On Sun, 14 Jul 2019, I wrote:
> I am still not entirely convinced this change should be made.
And thinking about it overnight has not changed my mind. Requesting a
partial match was never intended to have the implication "this is not
the end segment".
However, there does exist the
On Sat, 13 Jul 2019, ND via Pcre-dev wrote:
> At its core \z is positive lookahead assertion that want to inspect next
> character of subject.
I must admit I had not thought of it like that. I considered it just to
be "are we at the end of the subject?".
> I propose following algorithm (for
On 2019-07-13 16:47, ph10 wrote:
On Sat, 13 Jul 2019, ND via Pcre-dev wrote:
PCRE2_PARTIAL_HARD is intended for multisegment matching. I think when
this
> option is set it means: this subject IS incomplete, it's only a
non-last part
> of a certain "entire" subject.
It was never intended to
On Sat, 13 Jul 2019, ND via Pcre-dev wrote:
> PCRE2_PARTIAL_HARD is intended for multisegment matching. I think when this
> option is set it means: this subject IS incomplete, it's only a non-last part
> of a certain "entire" subject.
It was never intended to mean "this subject is incomplete",
On 2019-07-13 11:44, ph10 wrote:
In this case PCRE2 finds a *complete* match before it finds a partial
match. The pattern says "assert we are at the end of the subject"; that
is true. Then it says "end of pattern" - so it returns a complete match.
It never gets the chance to consider a partial
On Sat, 13 Jul 2019, ND via Pcre-dev wrote:
> It seems this example introduce not partial matching but "regular" matching
> bug.
>
> PCRE2 version 10.33 2019-04-16
> /(?<=(?=(?<=a)))b/
> ab
> No match
>
>
> While Perl is correctly match "b".
Probably the same bug as in your previous message.
On Fri, 12 Jul 2019, ND via Pcre-dev wrote:
> > > > >PCRE2 version 10.33 2019-04-16
> > > >/(?<=(?=.(?<=x)))/
> > > >ab\=ph
> > > >Partial match: b
> > > > Why it matched b?
> >Again, it has inspected at least one character, and if you add "x" itmatches.
>
> But I not try to add x. I inspect
On 2019-07-12 15:31, ND wrote:
On 2019-07-12 15:17, ph10 wrote:
> On Fri, 12 Jul 2019, ND via Pcre-dev wrote:
>> This is about my second example.
> > But it seems first example have another issue:
> >> >PCRE2 version 10.33 2019-04-16
> > >/(?<=(?=.(?<=x)))/
> > >ab\=ph
> > >Partial match: b
> >>
On 2019-07-12 15:17, ph10 wrote:
On Fri, 12 Jul 2019, ND via Pcre-dev wrote:
This is about my second example.
> But it seems first example have another issue:
>> >PCRE2 version 10.33 2019-04-16
> >/(?<=(?=.(?<=x)))/
> >ab\=ph
> >Partial match: b
>> Why it matched b?
Again, it has inspected at
On Fri, 12 Jul 2019, ND via Pcre-dev wrote:
> This is about my second example.
> But it seems first example have another issue:
>
> >PCRE2 version 10.33 2019-04-16
> >/(?<=(?=.(?<=x)))/
> >ab\=ph
> >Partial match: b
>
> Why it matched b?
Again, it has inspected at least one character, and if
On 2019-07-12 07:08, ph10 wrote:
On Thu, 11 Jul 2019, ND via Pcre-dev wrote:
I guess you told about second example (in first example "x" don't
adds). I
> believed empty match at the end of string is not counted as partial.
This is a documentation issue. Instead of "empty match" read "match in
On Thu, 11 Jul 2019, ND via Pcre-dev wrote:
> I guess you told about second example (in first example "x" don't adds). I
> believed empty match at the end of string is not counted as partial.
This is a documentation issue. Instead of "empty match" read "match in
which no characters are
On 2019-07-11 16:18, ph10 wrote:
Why? "Partial match" means "if you add some more characters to the
subject, it MAY match". If you add "x", it matches.
I guess you told about second example (in first example "x" don't adds). I
believed empty match at the end of string is not counted as
On Wed, 10 Jul 2019, ND via Pcre-dev wrote:
> PCRE2 version 10.33 2019-04-16
> /(?<=(?=.(?<=x)))/
> ab\=ph
> Partial match: b
>
>
> /(?<=.(?=x))/
> ab\=ph
> Partial match: b
> <
>
> Isn't both results should be "no match" instead of "partial match"?
Why? "Partial match" means
Good day!
Here is 2 pcre2test listings:
PCRE2 version 10.33 2019-04-16
/(?<=(?=.(?<=x)))/
ab\=ph
Partial match: b
/(?<=.(?=x))/
ab\=ph
Partial match: b
<
Isn't both results should be "no match" instead of "partial match"?
Thanks.
--
## List details at
31 matches
Mail list logo
