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
> capture group, then it is
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
> capture group, then it is restricted to start position of this group.
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
Hi,
> 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 last position
of the subject, and
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
> I think MOVE verb like a goto operator in programming languages impacts
> the clarity of pattern structure and make it error-prone. It is
> undesirable in my opinion.
Yes. The idea has already dropped.
> I think it will be better to use standard "(?<=)" for lookbehinds, not
The problem is
On Wed, 31 Jul 2019, Zoltán Herczeg wrote:
> You have already convinced me to drop MOVE :)
> The question is whether we keep the other construct. Or "rematching" a
> capturing block in an assertion like fashion would solve this problem better.
I don't think that would solve the original
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
On Wed, 31 Jul 2019, Zoltán Herczeg wrote:
> If we consider the following pattern:
> /(*napla:a|a)+/
>
> is the same as:
> /(?:(*napla:a|a))+/
>
> Then we have an empty match if I understand correctly the behavior of
> this new construct.
Oh, sorry, I was thinking of
> > You are right. Since you can put it into a group, it is not possible
> > to prevent repetitions. However the rule that empty matches break
> > (non-fixed) loops may solve this problem.
> ... but it's not an empty match.
If we consider the following pattern:
/(*napla:a|a)+/
is the same as:
On Wed, 31 Jul 2019, Zoltán Herczeg wrote:
> You are right. Since you can put it into a group, it is not possible
> to prevent repetitions. However the rule that empty matches break
> (non-fixed) loops may solve this problem.
... but it's not an empty match.
> I start to understand why perl
> as normal groups, not as assertion groups. What happens when they are
> repeated must be defined - or maybe they should not be allowed to
> repeat, because once again that might be an easy way to infinite loops.
You are right. Since you can put it into a group, it is not possible to prevent
On Tue, 30 Jul 2019, Zoltán Herczeg wrote:
> > (*MOVE) is a small addition and solves ND's non-atomic assertion
> > requirement. Perhaps we can just start with (*MOVE).
>
> Yes, if we choose this option to implement.
It occurs to me that (*MOVE) gives scope for infinite loops:
> Let me see if I understand that: does (*match:{1}pattern) mean "apply
> the pattern to the string that is currently captured by group 1"?
> Without looking at the interpreter code, I'm not sure if this is easy or
> hard to implement.
This is just throwing some ideas. We could also decide that
On Tue, 30 Jul 2019, Zoltán Herczeg wrote:
> Thinking about practical use cases. With the proposed changes, doing a
> submatch is quite overcomplicated:
>
> (*:A)submatch(*:B)(*MOVE:A)(*SETEND:B)match-submatch-again(*MOVE:B)(*SETEND)
>
> Perhaps the other idea, use capturing brackets for this
:hzmes...@freemail.hu) >
Dátum: 2019 július 29 18:51:34
Tárgy: Re: [pcre-dev] Remove some restrictions of lookbehind assertions
Címzett: pcre-dev@exim.org < pcre-dev@exim.org (Link ->
mailto:pcre-dev@exim.org) >
> > (*SETEND:mark_name)
> > - This verb changes the end pos
> > (*SETEND:mark_name)
> > - This verb changes the end position to the position recorded by the last
> > mark which name is
> mark_name. If the position is smaller than the current string position, it is
> set to the current string > position.
> By "end position" do you mean "end of subject"?
On Mon, 29 Jul 2019, Zoltán Herczeg wrote:
> > May be it not quite effective and still have restrictions but is useful.
> > Is it simple to add such functionality?
>
> Definitely not easy in JIT.
Not easy in the interpreter either.
> I have an alternative solution which might be able to solve
> May be it not quite effective and still have restrictions but is useful.
> Is it simple to add such functionality?
Definitely not easy in JIT.
I have an alternative solution which might be able to solve many of the issues
raised here. We already have (*SKIP:name), so we need to record
20 matches
Mail list logo
