r is Mark Taylor. Mark can be reached at:
> mk...@ucla.edu. Your list owner is Cara Quinn - you can reach Cara at
> caraqu...@caraquinn.com
>
> The archives for this list can be searched at:
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mail-archive.com
gt;> will be working.
>>>>> -Original Message-
>>>>> From: viphone@googlegroups.com On
>>>>> Behalf Of Jennie Facer
>>>>> Sent: Sunday, 21 June 2020 9:00 AM
>>>>> To: viphone@googlegroups.com
>>>
then that's all I can
>> offer.
>>
>> Sent from my iPhone
>>
>>>> On May 26, 2020, at 5:32 PM, Ekstrand, Pamela A. -ND
>>>> wrote:
>>>
>>> Hi Mary,
>>>
>>> I am not totally sure how I have done thi
utlook.com/?url=http%3A%2F%2Fwww.mail-archive.com%2Fviphone%40googlegroups.com%2Fdata=02%7C01%7Cpamela.a.ekstrand.-nd%40disney.com%7C7815ccc2ffe4486c91cc08d801c34fa4%7C56b731a8a2ac4c32bf6b616810e913c6%7C1%7C0%7C637261285651771341sdata=%2FRCn%2BlqX5CZ4B1O5efaHlOjofH%2FTS46z7yoVdyyFobU%3Dreserved=0
---
Yo
PCRE2 version 10.34-RC1 2019-04-22
/\A(?:\1b|(?=(a)))*?\z/
ab
No match
/\A(?:\1b|(?=(a)))*\z/
ab
No match
Both patterns must successfully match after second iteration.
But PCRE2 have following rule:
It is possible to construct infinite loops by following a group that can
match no
tion.outlook.com/?url=http%3A%2F%2Fwww.mail-archive.com%2Fviphone%40googlegroups.com%2Fdata=02%7C01%7Cpamela.a.ekstrand.-nd%40disney.com%7C3a5089625d9040b8a9b608d7ed22b469%7C56b731a8a2ac4c32bf6b616810e913c6%7C1%7C0%7C637238605622834051sdata=WhY1WfdQj7p7xOzo%2BlJfHClq%2F5Wtvjpj4eSHIM67JWk%3Dr
Hi All,
I have an application with multiple menu items, each of them is a
sub-application with its own routes, module, and many pages/components.
Now, I want to decouple this umbrella application to a base application
(main container) with multiple sub-applications by launching the main
Thanks,
Aaron Tracy
Hagridaaron.com
@hagridaaron
On 4/8/20, 4:51 PM, "dragon788" wrote:
I'd also recommend checking out https://github.com/boxcutter/windows and
https://github.com/chef/bento and check out the ps1 scripts they have for doing
updates.
--
This mailing list is
Good afternoon,
I was wondering if there was a way to monitor the data flow into NiFi and also
from NiFi to our storage device.
We have approximately 15 streams of files coming into NiFi at a rate of a file
per minute, 24/7, 365 days, varying in size from 4MB to 12MB each. We need a
way to
Hi,
Has anyone had any luck scanning a credit card into the payment area of the
Lyft app? It is supposed to scan it in automatically once you allow the app
access to the camera, but I could not get it to do anything.
I ended up entering the info in manually, but just wondered if there were
Hi,
Has anyone had any luck scanning a credit card into the payment area of the
Lyft app? It is supposed to scan it in automatically once you allow the app
access to the camera, but I could not get it to do anything.
I ended up entering the info in manually, but just wondered if there were
drop your wrist, so don't do that if you want it to stay awake.
Best,
Anna
> On Dec 27, 2019, at 6:46 PM, Ekstrand, Pamela A. -ND
> wrote:
>
> Hi All,
>
> I have a new Apple Watch 5th generation, and have a couple of questions.
>
> First, is there a way to turn off the
Hi All,
I have a new Apple Watch 5th generation, and have a couple of questions.
First, is there a way to turn off the sounds or at least lower their volume
when you move around the watch face with voiceover?
Second, it seems that if I am doing something in an app on the watch such as
All,
I currently have a second generation watch and am looking at possibly
upgrading. Would it be worth considering the 4th generation rather than the
5th if I can get it significantly cheaper, or are there enough improvements
from the 4th to the 5th generation that this would not be a good
Hi All,
We are considering buying a Synology NAS DiskStation for backing up files and
our music collection. We would also like to play that music from our receiver.
Can anyone comment on the accessibility of the app that would need to be used
for this?
Thanks.
Pam
--
The following
.-nd%40disney.com%7Cab97fdceea804b171f8208d7774f18d4%7C56b731a8a2ac4c32bf6b616810e913c6%7C1%7C0%7C637109053912030455sdata=F8a3yRYgEiTjfIZ05njmKoMgTXMb399DOyPwBtAtU0o%3Dreserved=0
---
You received this message because you are subscribed to the Google Groups
"VIPhone" group.
To unsubs
be searched at:
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mail-archive.com%2Fviphone%40googlegroups.com%2Fdata=02%7C01%7Cpamela.a.ekstrand.-nd%40disney.com%7Cc68d4e267e7a45d6eee208d75e4ef0dd%7C56b731a8a2ac4c32bf6b616810e913c6%7C1%7C0%7C637081565449325501sdata=XkVFXpfe
%7Cpamela.a.ekstrand.-nd%40disney.com%7Cde098f9b31604fa9d93b08d7525e43c9%7C56b731a8a2ac4c32bf6b616810e913c6%7C1%7C0%7C637068437127457763sdata=jpTcd9m24YrmKXiBZkUUK%2BViWKMt%2BhYXJIcUmj%2BjJkM%3Dreserved=0
---
You received this message because you are subscribed to the Google Groups
"VIPhone" group.
To u
ooglegroups.com/<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.mail-archive.com%2Fviphone%40googlegroups.com%2F=02%7C01%7Cpamela.a.ekstrand.-nd%40disney.com%7Cb4d337e251704496625408d74d8ea3a2%7C56b731a8a2ac4c32bf6b616810e913c6%7C1%7C0%7C637063147336648639=qJ5BKjVSiWnA0Bg%2FL1ZE%2B6pzMAVE6XEAR
Good day!
There is a function find_minlength()in pcre2_study.c that calculates min
subject length.
1. It drops patterns that have (*ACCEPT) verb.
/* ACCEPT makes things far too complicated; we have to give up. In
fact,
from 10.34 onwards, if a pattern contains (*ACCEPT), this
..@aira.io> directly
___
Ohio-Talk mailing list
ohio-t...@nfbnet.org<mailto:ohio-t...@nfbnet.org>
http://nfbnet.org/mailman/listinfo/ohio-talk_nfbnet.org<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnfbnet.org%2Fmailman%2Flistinfo%2Fohio-talk_nfbnet.org=02%7C01%7Cp
писал(а) в своём письме Sat, 10 Aug 2019 14:03:50
+0300:
- bugs
- performance issues
- brings excessive work to user
Now I report only about potential bugs.
Unfortunately I believe we have reached the limit of what can be done to
the existing PCRE2 design to support multi-segment matching
On 2019-08-08 16:59, ph10 wrote:
On Sat, 3 Aug 2019, ND via Pcre-dev wrote:
May be it can be useful to have ability to set a limits of lookbehind
search
> for performance reasons.
> I can imagine a rule: If nonfixedlength lookbehind immediately
preceded by
> capt
May be it can be useful to have ability to set a limits of lookbehind
search for performance reasons.
I can imagine a rule: If nonfixedlength lookbehind immediately preceded by
capture group, then it is restricted to start position of this group.
For example in pattern
abc(\w++)(?<=\d+)
On 2019-08-03 04:44, Zoltán Herczeg wrote:
I was faced with a need of nonfixed length lookbehind two times:
> 1. when data came by stream of 24kB blocks and I need to find a last
>numeric in each of it
> /.{24000}(?<=(\d++)\D*+)/g
Even if this would work, the result of this would be always the
On 2019-08-01 08:20, Zoltán Herczeg wrote:
If we would use your idea for doing (0,n-1) match, that could be too
slow for large subject, and people would complain.
Yes, it could be slow. But:
- we can use [\G,n-1]
- we can honestly warn about it in docs. Performance of X(?<=Y) will be
On 2019-07-29 10:45, Zoltán Herczeg wrote:
I am open to other names, but I would propose the following control
verbs:
(*MOVE:mark_name)
- This verb changes the current string position to the position
recorded by the last mark which name is mark_name.
(*SETEND:mark_name)
- This verb
Good day!
pcre2test output:
/b(?Why "a" showed as text that was consulted during a successful pattern
match, but "c" not?
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
On 2019-07-27 10:50, ND wrote:
\A and \G may be considered as (?
It seems it no truth for \G.
\G need more investigation
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Good day!
There are some kinds of problems that exist with max_lookbehind:
- bugs
- performance issues
- brings excessive work to user
Now I report only about potential bugs.
Here is pcre2test output:
PCRE2 version 10.34-RC1 2019-04-22
/(?<=(?=(?<=.)).)/info,allusedtext
Capture group
On 2019-07-27 08:46, ph10 wrote:
For an anchored pattern, the "must be present" code unit value is set
only if it follows a variable length item in the pattern.
This is a judgement that it will probably be faster in most cases and it
will avoid the really bad case: suppose, instead of "abx"
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 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
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
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
018.
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.produceretailer.com%2Farticle%2Fnews-article%2Finstacart-lowers-grocery-delivery-feedata=02%7C01%7Cpamela.a.ekstrand.-nd%40disney.com%7C9a81b179dd854b3a23a408d70e465b79%7C56b731a8a2ac4c32bf6b616810e913c6%7C1%7C0%7C6369935676717
do after matching of every segment. It also
have more common and simple (for user understanding) algorithm and can
have simpler docs.
ND quoted /(*COMMIT)(*F)/ as a
simple example. Is (*COMMIT) the only way this might happen?
Not only. It may also happen with anchored patterns
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
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:
> https://lists.exim.org/lurke
On 2019-07-17 09:00, ph10 wrote:
On Sat, 13 Jul 2019, I wrote:
> May be "[^a]" can use the same algorithm as "[^ab]"?
>> [^a] is optimized into a different (faster) opcode; I will see if this
> can easily produce the same starting code units as [^ab] for tidyness.
I
> do not expect it will
On 2019-07-14 11:54, ph10 wrote:
I am sorry that I cannot help, but I don't even use Windows, let alone
MSVC. All the information I put in NON-AUTOTOOLS-BUILD was sent to me by
other people.
Thanks. Now I can successfully compile PCRE svn versions.
It achieved not directly by MSVisualStudio
On 2019-06-05 15:54, ph10 wrote:
On Wed, 5 Jun 2019, ND via Pcre-dev wrote:
May be there is a some space for optimization there.
>> PCRE analyze subpattern in lookaround and say:
> First code unit = 'a'
> Last code unit = 'c'
>> So it already knows that "Subject length
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 2019-07-13 19:21, ND wrote:
On 2019-07-13 16:50, ph10 wrote:
> On Sat, 13 Jul 2019, ND via Pcre-dev wrote:
>> Unfortunately PCRE2 svn version is not compiled for me with Microsoft
> Visual
> > Studio 2019 on Windows 7x64.
>Can you compile the released source versi
On 2019-07-13 16:50, ph10 wrote:
On Sat, 13 Jul 2019, ND via Pcre-dev wrote:
Unfortunately PCRE2 svn version is not compiled for me with Microsoft
Visual
> Studio 2019 on Windows 7x64.
Can you compile the released source versions? (There shouldn't be any
difference, but I just wonde
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 wa
On 2019-07-13 11:22, ph10 wrote:
I have done this work, and committed the patches. The new code supports
both (*napla: and (*naplb:
It's great! Thanks a lot!
I was meat a (*napla necessity some time ago when try to construct a
pattern for this task:
I review a text of research article with
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
Good day!
PCRE try to detect starting code units in attempt to apply a start
optimization.
As we can see from next two examples, it detects starting code units for
"[^ab]", but don't doing this for "[^a]". I think it looks a bit curiously.
May be "[^a]" can use the same algorithm as
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
> > >/(?<=(?=.(?&l
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 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
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
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
On 2019-07-09 13:53, ph10 wrote:
On Mon, 8 Jul 2019, ND via Pcre-dev wrote:
And if we disregards Perl's bugs then it seems (*COMMIT) in Perl works
in a
> following manner:
>> 1. Backtracking can't move to the left of COMMIT (this is PCRE
behaviour too)
> 2. If COMMIT occurs the
And if we disregards Perl's bugs then it seems (*COMMIT) in Perl works in
a following manner:
1. Backtracking can't move to the left of COMMIT (this is PCRE behaviour
too)
2. If COMMIT occurs then no advance match to any other position of subject
can happen. No matter there are any other
Good day!
PCRE2 version 10.33 2019-04-16
/(?0)/
abc
Failed: error -52: nested recursion at the same subject position
As I can see interpreter recognize this endless recursion right away.
But JIT don't. It recursed unless memory is run out:
Failed: error -46: JIT stack limit reached
May
On 2019-06-22 16:03, ph10 wrote:
On Sat, 22 Jun 2019, ND via Pcre-dev wrote:
Sorry for my bad English.
> I need to find word that is closest to the end of text and occurs at
least 10
> times in that text.
Yes, I understand that now. I will think about it.
Non-atomic lookaroun
On 2019-07-03 17:33, ph10 wrote:
On Tue, 2 Jul 2019, ND via Pcre-dev wrote:
It seems a Perl is so buggy or have really different conception of
(*COMMIT)
> then PCRE.
I am waiting for further information from the Perl developers, but I
suspect that I won't want to change PCRE2, except perh
On 2019-07-02 14:34, ph10 wrote:
A Perl developer has admitted there is some ambiguity, but suggests that
(*COMMIT) just means "never advance the starting point". That patterncan
find a match without advancing the starting point. I have pointedout
that, in that case, /.*(*COMMIT)c/ should
On 2019-07-01 10:28, ph10 wrote:
On Sun, 30 Jun 2019, ND via Pcre-dev wrote:
PCRE2 version 10.33 2019-04-16
> /\A(?:.|..)(*THEN)c/
> abc
> No match
>>> Perl is match "abc".
> I suppose "next innermost alternative" is interpreted differently by
PCRE
On 2019-07-01 10:28, ph10 wrote:
I think this is a bug in Perl and I will report it as such.
It's great.
As you participate in Perl regex development can you take a look at
another Perl bug please:
PCRE2 version 10.33 2019-04-16
/\A(?:.(*COMMIT))*c/
abcd
No match
But Perl reports
Good day!
Here is pcre2test listing:
PCRE2 version 10.33 2019-04-16
/\A(?:.|..)(*THEN)c/
abc
No match
Perl is match "abc".
I suppose "next innermost alternative" is interpreted differently by PCRE
and Perl.
If so, may be PCRE should go Perl way in this matter?
Thanks.
--
## List
On 2019-06-25 09:30, Zoltán Herczeg wrote:
> It seems JIT is 16 times!! slower than interpreter for such simple
pattern.
I did some improvements on the SSE2 accelerated search and /(?s).*/
search. You can try them now. However I have never seen such big
differences in my measurements. The
On 2019-06-23 04:33, ND wrote:
Or this calculations occurs at compile time while partial matching flag
is set at matchtime?
Oh! Now I read docs about it.
It seems that PARTIAL are compiletime option only for JIT. So it seems
that disabling of this calculations may matter to JIT only. May
Or this calculations occurs at compile time while partial matching flag is
set at matchtime?
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Good day!
Here is pcre2test listing:
/(?<=ab)cde/info
Capture group count = 0
Max lookbehind = 2
First code unit = 'c'
Last code unit = 'e'
Subject length lower bound = 3
ab\=ph
Partial match: ab
<<
We can see that PCRE calculates first code unit, last code unit and
subject
On 2019-06-22 15:20, ph10 wrote:
On Sat, 22 Jun 2019, ND via Pcre-dev wrote:
Your example is not working right (let's change 10 to 3 for
simplicity):
>> /\A.*\b(\w++)(?>.*?\b\1\b){2}/
> word1 word1 word2 word2 word2 word1
> 0: word1 word1 word2 word2 word2
> 1: word2
>
I attempt to second try with another example:
PCRE2 version 10.33 2019-04-16
/(?<=(?<=a)b)c.*/info
Capture group count = 0
Max lookbehind = 1
First code unit = 'c'
Subject length lower bound = 1
abc\=ph
Partial match: bc
<
Why max lookbehind=1, but not 2?
--
## List details
Updated docs:
If (*SKIP) is used inside a lookbehind to specify a new starting
position...
I suggest to remove "inside a lookbehind".
A new starting position that is not later than the starting point of the
current match may occur without lookbehind:
PCRE2 version 10.33 2019-04-16
On 2019-06-22 08:56, ph10 wrote:
On Fri, 21 Jun 2019, ND via Pcre-dev wrote:
Imagine that we have a text. There are some words in this text that
occurs at
> least 10 times. We want to find from they a word that is most closer
to the
> end of text.
>> If lookahead asse
On 2019-06-22 08:51, ph10 wrote:
There must be plenty of examples where removing \z changes what is
matched. How about /[ab]*\z/ matched against "aaaxxxbbb"?
I believed it was obviously that we told about matching from one position
of subject. Sorry that I don't say it explicitly.
In your
Thanks a lot for clarifying docs and for your patience with me.
On 2019-06-21 16:18, ph10 wrote:
On Mon, 17 Jun 2019, ND via Pcre-dev wrote:
Second of my little concern is that "X*\z" and "X*" both matches and
matches
are different.
I understand why it is from proc
On 2019-06-20 15:40, ph10 wrote:
(?:(?=X)|(?=Y))Z means "if X matches, try to match Z; if that fails, if
Y matches try to match Z". In the simple case the second match of Z will
be the same as the first, so will always fail. However, if X and Y are
complex and contain capturing parentheses, I
On 2019-06-20 16:29, ph10 wrote:
I have updated the documentation.
Updated docs:
If (*SKIP) is used inside a lookbehind to specify a new starting point
that is
not later than the starting point of the current match, it is ignored, and
the
normal "bumpalong" occurs.
May be "it is
On 2019-06-20 16:15, ph10 wrote:
You can see all this by making use of the "auto-callout" feature
Thanks a lot, Philip. I quite well understand what is really happened.
My concern is about how this is documented.
In the first example, the same thing happens, but after (?=b) ismatched,
\z
On 2019-06-20 15:53, ph10 wrote:
I have updated the doc to use your example, but it can be done easily
with other PCRE2 facilities:
(?|(ab)c|(a))
does the same thing. If "a" is complex, and you do not want to write it
out twice, you could DEFINE it and use a subroutine call.
I don't say
On 2019-06-19 20:00, Zoltán Herczeg wrote:
Assertions are like "if" statements in structured languages. A condition
part of an "if" is never retried.
(?=x|y) looks much more ergonomical than (?:(?=x)|(?=y))
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Good day!
In ASSERTIONS chapter I can't find words that assertions are atomic. This
information can be seen much far for this chapter in backtracking control
verbs part.
It can be important IMHO to put this info in ASSERTIONS chapter.
But why assertions are atomic? I guess answer is:
On 2019-06-19 17:15, ph10 wrote:
At present, lookarounds do not take part in minimum length calculations,
I see lookarounds takes part: first and last code units are searched in
lookarounds too.
So this is another reason in opposition to my poroposal.
So I suggest to close this thread.
(*ACCEPT) can't leave lookaround borders. So ACCEPT's that are inside
lookarounds can't influence minimum length claculation, if lookaround
entrails are not participate in this calculation (is this true?).
Thus more preferable may be to turn off minimum length scan not for all
patterns
On 2019-06-17 15:44, ph10 wrote:
Why do you expect 4? The matcher goes back 2, then matches two
characters, so it is back at the start. Then it goes back 6.
You are right, Philip. My fault. I'm sorry.
Close thread.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
It seems you don't understand or I don't. Sorry for my bad English.
I don't ask to calculate real subject_length_lower_bound in patterns with
ACCEPT.
I ask to set subject_length_lower_bound to 0 in all such patterns.
On 2019-06-17 15:07, ph10 wrote:
If a pattern contains (*ACCEPT) the
Hello!
Here is pcre2test listing:
PCRE2 version 10.33 2019-04-16
/(?<=.{2}(?<=.{6}))/info
Capture group count = 0
Max lookbehind = 6
May match empty string
Subject length lower bound = 0
abc\=ph
No match
Expected maxlookbehind=4, not 6.
May be calculation algorithm could be corrected.
Hello!
Chapter ISSUES WITH MULTI-SEGMENT MATCHING of pcre2partial.html includes
item 2 with description how to process with lookbehind assertions.
I think it's important to add to this algorithm a some words about "no
match":
If result of partial match is "no match" then last
Hello!
In pcre2test docs in chapter RESTARTING AFTER A PARTIAL MATCH there is
example:
data> 23ja\=P,dfa
What matching option "P" is? May be it should be corrected to "ph" or "ps"?
Thanks.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
On 2019-06-04 16:59, ND wrote:
1. Start optimizer brakes a result to "no match" from "match". Is there
documented (I remember only example with (*COMMIT) where optimizer can
make "match" from "no match")? May be there is a way to correct this
PCRE
Good day!
Here is pcre2test listing:
PCRE2 version 10.33 2019-04-16
/(?:a|ab){1}+c/
abc
0: abc
No match expected, but pattern matched.
Thanks.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Good day!
I don't find in docs behaviour of SKIP when corresponding position is
before or equal start_offset.
It seems that in this case a "bumpalong" advance is 1, not SKIP or
associated MARK position.
/(?<=a(*SKIP)x)|c/
abcd\=offset=2
No match
/(*SKIP)x|c/
abcd
No match
Good day!
Docs says:
It is possible to construct infinite loops by following a group that can
match no characters with a quantifier that has no upper limit, for example:
(a?)*
Earlier versions of Perl and PCRE1 used to give an error at compile time
for such patterns. However, because
On 2019-06-10 16:47, ph10 wrote:
I have done this, and committed the result. However, it seems to me that
/a(*ACCEPT)??bc/ is the same as a(?:bc|) though if a, b, and c are
complex it may be easier to read.
A following example was included in docs (pcre2pattern.html) :
A(*ACCEPT)??BC
t itself.
>
> Your V iPhone list moderator is Mark Taylor. Mark can be reached at:
> mk...@ucla.edu. Your list owner is Cara Quinn - you can reach Cara at
> caraqu...@caraquinn.com
>
> The archives for this list can be searched at:
> https://nam04.safelinks.protection.outlook.com/?url=ht
ct
>>>> the owners or moderators directly rather than posting on the list
>>>> itself.
>>>>
>>>> Your V iPhone list moderator is Mark Taylor. Mark can be reached at:
>>>> mk...@ucla.edu. Your list owner is Cara Quinn - you can reach Cara
&
Good day!
pcre2test unlike Perl don't report MARK value that is insight a successful
condition of condition group.
PCRE2 version 10.33 2019-04-16
/a(?(?=(*:1)b).)/mark
ab
0: ab
May be this incompatibility should be fixed.
Thank you.
--
## List details at
On 2019-06-05 16:53, ph10 wrote:
Perl gets it wrong:
/(a(?:(*ACCEPT))??bc)/
axy
No match
/a(*ACCEPT)??bc/
axy
No match
It seems a bug of Perl start optimizer. It say:
"Did not find floating substr "bc"...
Match rejected by optimizer"
Please look at PCRE start optimizer. It seems correction
On 2019-06-05 08:16, ph10 wrote:
Because PCRE2 isn't clever enough to deal with lookarounds whencomputing
the minimum length.
May be there is a some space for optimization there.
PCRE analyze subpattern in lookaround and say:
First code unit = 'a'
Last code unit = 'c'
So it already knows
Repetition is allowed for groups such as (?:...) but not for individual
backtracking verbs
It seems Perl does not rise error with "(*ACCEPT)??". And generates
expected code.
Is there weighty reason to be not compatible with Perl in this situation?
(for which it is meaningless).
It's
Good day!
pcre2test:
PCRE2 version 10.33 2019-04-16
/(?=abc)/I
Capture group count = 0
May match empty string
First code unit = 'a'
Last code unit = 'c'
Subject length lower bound = 0
Why Subject length lower bound = 0, not 3?
--
## List details at
Good day!
Here is pcre2test listing:
PCRE2 version 10.33 2019-04-16
/A(?:(*ACCEPT))?B/
A
No match
/A(?:(*ACCEPT))?B/no_start_optimize
A
0: A
/A(*ACCEPT)?B/
Failed: error 109 at offset 10: quantifier does not follow a repeatable
item
A
I have a two questions with it:
1. Start
On 2019-05-29 16:52, ph10 wrote:
On Wed, 29 May 2019, ND via Pcre-dev wrote:
Since anybody put MARK verb at the beginning of pattern then it is
assumed
> that this verb is definitely needed in pattern logic.
But maybe only for successful matches?
So is there any reason to ap
101 - 200 of 2010 matches
Mail list logo
