 |
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
 Posted: Tue Dec 04, 2007 5:02 am
[2.14a] Compatability Report Improvements
|
Oh yeah! Thanks for reminding me about the compatibility report. Plaase put '%-1' into the same category as '%1'. The change in the regex is something like '\%-?\d{0,2}'. I know I never reported it, but I have "found" a few old scripts to have this problem after hours of debugging.
|
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
 |
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Tue Dec 04, 2007 5:28 am
|
First victim 
Viji's regex is correct. You can also use negative lookbehinds or [^~] to not match special characters that've been quoted. The former is better because I doubt that the latter will match if the character is at the start of the string. |
|
|
|
|
Asilient_1
Apprentice
Joined: 26 Apr 2007
Posts: 113
|
Posted: Tue Dec 04, 2007 5:30 am
|
| Vijilante wrote: |
| Change the regex that detects detects the <> to also check for a tilde not being there. [^~], or if the tilde has a problem being passed to the regex engine you can use [^\176]. |
That's the post I was referring to.
http://forums.zuggsoft.com/forums/viewtopic.php?t=28773&highlight=
For the thread. |
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Tue Dec 04, 2007 8:33 pm
|
This time I am definitely done messing with %ref in quotes.
| Code: |
| ^(?>(?:[^\042]|\176\042)*?\042(?!(?:[^\042]|\176\042)*?(?<!\176)\%\{?(?:[tx-]?\d+|[ijklmnop])\}?(?:[^\042]|\176\042)*?)(?:[^\042]|\176\042)*?(?<!\176)\042)*(?:[^\042]|\176\042)*?(\042(?:[^\042]|\176\042)*?(?<!\176)\%\{?(?:[tx-]?\d+|[ijklmnop])\}?(?:[^\042]|\176\042)*?(?<!\176)\042) |
The first and only back reference produced is the quote section containing the offending % reference.
This properly goes through multiple lines.
I am not going to edit this again. |
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Tue Dec 04, 2007 10:32 pm
|
Wow...now that's a scary looking regex. I'll give it a try and see how it works. I might implement some sort of two-level test where it uses a simple reg ex first, and only if the first reg ex matches then it tries the second, more accurate reg ex. That way we won't have problems with the Compatibility report getting really slow from complex regexes like this.
|
|
|
|
|
Asilient_1
Apprentice
Joined: 26 Apr 2007
Posts: 113
|
Posted: Wed Dec 05, 2007 9:44 pm
|
That's a monster regex. O.o
Wouldn't having two levels of checks have some speed impact on the compatability report?
Saying that, I think if you can afford a lack of speed anywhere, it would be the compatability report, people would rather it gets everything and they get a clean result over it being fast, but giving the same errors over and over (regardless of how much they change it.) |
|
|
|
|
Vijilante
SubAdmin
Joined: 18 Nov 2001
Posts: 5182
|
Posted: Wed Dec 05, 2007 10:09 pm
|
Actually my testing with that particular regex showed it was very fast because it works to completely eliminate backtracing. I probably actually went overboard with how I force it to not backtrack. My method of testing it was to use %regex(%alias(something),"pattern") in the command line. I was checking both time and return values while testing it.
|
|
_________________
The only good questions are the ones we have never answered before.
Search the Forums |
|
|
|
Fang Xianfu
GURU
Joined: 26 Jan 2004
Posts: 5155
Location: United Kingdom
|
Posted: Wed Dec 05, 2007 11:22 pm
|
| Asilient_1 wrote: |
| Wouldn't having two levels of checks have some speed impact on the compatability report? |
Yes, they'd make it faster, and that'd be the point. It'd be slower in a case where you match every single regex in the first layer, because then all the second-layer regexes will be run as well. The chances of that happening are pretty low, though - more likely most of the regexes will be rejected quicker, leaving only a couple of slower checks to be run, which will be faster than using a single-layer system with the more complex regexes.
Notwithstanding the anti-backtracking Viji's built into that specific regex, of course. |
|
|
|
|
Asilient_1
Apprentice
Joined: 26 Apr 2007
Posts: 113
|
Posted: Wed Dec 05, 2007 11:39 pm
|
I meant to slow it down, really, but I get the idea. :P
|
|
|
|
|
Zugg
MASTER
Joined: 25 Sep 2000
Posts: 23379
Location: Colorado, USA
|
Posted: Thu Dec 06, 2007 2:29 pm
|
In fact, I'm considering adding a "pre-trigger" pattern to CMUD triggers in some future version. CMUD would test the "pre-trigger" pattern first, and only if that matched would it test the full pattern. You'd be able to leave the "pre-trigger" blank to get the exact same result as the current version, but adding a pre-trigger to really complex triggers could help get some additional speed. But not for the 2.x public version.
|
|
|
|
|
Seb
Wizard
Joined: 14 Aug 2004
Posts: 1269
|
Posted: Sat Dec 08, 2007 2:56 am
|
| Zugg wrote: |
| In fact, I'm considering adding a "pre-trigger" pattern to CMUD triggers in some future version. CMUD would test the "pre-trigger" pattern first, and only if that matched would it test the full pattern. You'd be able to leave the "pre-trigger" blank to get the exact same result as the current version, but adding a pre-trigger to really complex triggers could help get some additional speed. But not for the 2.x public version. |
Interesting idea. It made me think of another: a pre-trigger that groups several other similar triggers. Say that you currently have 10 (or 100) triggers that have nearly the same pattern: you might be able to optimize them by having a pre-trigger that contains the common part of the pattern. Structured in a similar way to trigger states. I suppose you might already be able to do this with the ReParse trigger state, or with manually enabling and disabling classes full of triggers based on another trigger, so long as the priorities of the other triggers are lower. Am I right? Hmm, I guess this idea is actually covered by the ReParse trigger state already. In fact, that can already do "pre-trigger" patterns, so I'm not sure there is a use for that, other than being a bit more obvious. |
|
|
|
|
Arde
Enchanter
Joined: 09 Sep 2007
Posts: 605
|
Posted: Sat Dec 08, 2007 9:18 am
|
| Seb wrote: |
| It made me think of another: a pre-trigger that groups several other similar triggers. Say that you currently have 10 (or 100) triggers that have nearly the same pattern: you might be able to optimize them by having a pre-trigger that contains the common part of the pattern. |
In this case I try to make 1 trigger (*) common-keyword(s) with following #SWITCH (*). If pre-triggers will be faster than #SWITCH, it would be nice. |
|
|
|
|
Seb
Wizard
Joined: 14 Aug 2004
Posts: 1269
|
Posted: Sat Dec 08, 2007 2:15 pm
|
| Arde wrote: |
| Seb wrote: |
| It made me think of another: a pre-trigger that groups several other similar triggers. Say that you currently have 10 (or 100) triggers that have nearly the same pattern: you might be able to optimize them by having a pre-trigger that contains the common part of the pattern. |
In this case I try to make 1 trigger (*) common-keyword(s) with following #SWITCH (*). If pre-triggers will be faster than #SWITCH, it would be nice. |
Yeah, I thought of that, but if you have a lot of possible patterns in the #SWITCH, it could make for somewhat unmaintainable/untidy code, especially if the code they execute is different. In some cases, I expect it would work nicely though. |
|
|
|
|
|
|
|
