$TSTing positional vars

[whenever]

http://code.google.com/hosting/search?q=label:proxy

The below filter seems cause a loop so the page won't stop loading.

Code:

Google: Multi URL Untangler     8.04.04 (multi) [sd jjoe] (d.s)

[sidki3003]

Thanks whenever.

I've split this post, because i'd like to explain what's happening here, because you don't get any hints from the "dbug.." view. It's an undocumented Prox quirk:

Empty positional vars temporarily aren't empty but contain the maximum bytes possible, until the respective positional var knows that it is supposed to be empty. That doesn't matter, unless you $TST the respective var.

Test filter:

Code:

[Patterns]
Name = "New HTML filter"
Active = FALSE
Bounds = "<test>*</test>"
Limit = 256
Match = "*111\0222*"
        "&$TST(\0=\1)"
Replace = "\1"

Test code 1 (things go wrong -- \0 has nothing real to grab):

Code:

<test>xxx111222xxx</test>

Test code 2 (thing work as expected -- \0 has a whitespace to grab):

Code:

<test>xxx111 222xxx</test>

As for the Google untangler, if you change "\sonmousedown" to "onmousedown", then \7 can grab a space.

[whenever]

(Feb. 04, 2009 02:18 PM)sidki3003 Wrote:  Empty positional vars temporarily aren't empty but contain the maximum bytes possible

I saw the result in the test code 1. Thanks for this information.

(Feb. 04, 2009 02:18 PM)sidki3003 Wrote:  until the respective positional var knows that it is supposed to be empty.

What does this mean?

(Feb. 04, 2009 02:18 PM)sidki3003 Wrote:  As for the Google untangler, if you change "\sonmousedown" to "onmousedown", then \7 can grab a space.

That fixed the issue.

[sidki3003]

(Feb. 05, 2009 05:06 AM)whenever Wrote:  

(Feb. 04, 2009 02:18 PM)sidki3003 Wrote:  until the respective positional var knows that it is supposed to be empty.

What does this mean?

Above explanation is my working hypothesis, so could be incorrect.

Positional vars were designed to be expanded only in the replacement.
Except for a few commands that can expand them immediately, like $LOG and $ADDLST.
The $TST command is rather new, IIRC.

[JJoe]

Testing against

Code:

<title>google</title>

Code:

[Patterns]
Name = "A -- incorrect: \0 is empty, $TST(\0=*) should not match"
Active = FALSE
Bounds = "<title*</title>"
Limit = 256
Match = "*o\0o*"
        "&$TST(\0=*)"

Name = "B -- correct: \0 is empty, $TST(\0=*) does not match with workaround"
Active = FALSE
Bounds = "<title*</title>"
Limit = 256
Match = "*o(|\0)o*"
        "&$TST(\0=*)"

Test filter "A". This filter should not match but does!
Test should fail because \0 should have no value.

Test filter "B". Test should fail because \0 should have no value and does fail.
The left side of "(|\0)" matches 'nothing' and keeps \0 empty.

Is there a better workaround?



Of interest, the test window results aren't always the same as the real world.

Code:

[Patterns]
Name = "C -- incorrect: \0 is empty, $TST(\0=*) should not match"
Active = TRUE
Bounds = "<title*</title>"
Limit = 256
Match = "*o\0o*"
        "&$TST(\0=\1)"
Replace = "\\0 is \0\r\n"
          "\\1 is \1\r\n"
          "\\1 is \1\r\n"

Test window shows

Code:

\0 is
\1 is ogle</title>
\1 is ogle</title>

Actual page shows

Code:

<Match: C -- incorrect: \0 is empty, $TST(\0=*) should not match >
<title>Google</title>
</Match>
\0 is
\1 is ogle</title>

[sidki3003]

(Oct. 21, 2010 02:19 AM)JJoe Wrote:  The left side of "(|\0)" matches 'nothing' and keeps \0 empty.

Is there a better workaround?

It depends on the actual situation. Normally you can rearrange your matching expression, so that the positional variable always has something to capture. Which is what i prefer. As a rule of thumb, matching is quicker than failing.

If rearranging isn't possible, your workaround looks fine.

Quote:Of interest, the test window results aren't always the same as the real world.

The last (third) replace line in the page code example is still there, but further down the page.

[JJoe]

(Oct. 21, 2010 03:13 PM)sidki3003 Wrote:  

Quote:Of interest, the test window results aren't always the same as the real world.

The last (third) replace line in the page code example is still there, but further down the page.

I missed seeing that but I did see the Proxomitron incorrectly adding and removing code (some unintelligible).

Code:

[Patterns]
Name = "Test1"
Active = TRUE
Limit = 256
Match = "go\0ogle$TST(\0=\1)"
Replace = "go\1**\1"

Test1 doesn't match every "google". **ogle is not where it might be expected to be (search the page).

Code:

[Patterns]
Name = "Test2"
Active = TRUE
Limit = 256
Match = "go\0$SET(\1=\0)ogle$TST(\1=\2)"
Replace = "\2"

Doesn't match...

[sidki3003]

(Oct. 21, 2010 06:03 PM)JJoe Wrote:  

Code:

[Patterns]
Name = "Test1"
Active = TRUE
Limit = 256
Match = "go\0ogle$TST(\0=\1)"
Replace = "go\1**\1"

Test1 doesn't match every "google". **ogle is not where it might be expected to be (search the page).

Yeah, same effect as with the "C" filter in your last post: \0 is filled with a whole lot of chars, more than 256 (byte limit) anyway. See post #2.

Quote:

Code:

[Patterns]
Name = "Test2"
Active = TRUE
Limit = 256
Match = "go\0$SET(\1=\0)ogle$TST(\1=\2)"
Replace = "\2"

Doesn't match...

That's the 6a case (new 1-11 numbering):

Techniques.txt Wrote:6a You can't test a positional variable that has been previously assigned with
$SET(), unless you expand it immediately.

Examples:
$SET(0=foo)$TST(\0=foo) test fails
$SET(0=foo)$TST((\0)=foo) test succeeds
$SET(1=foo)$SET(2=bar)$TST((\1\2)=foobar) test succeeds

[JJoe]

Agreed but I guessed otherwise for variables.

From help

SRL Wrote:The value a variable is set to isn't "expanded" until it's actually called in the replacement text. This means if \1 is "fish" and you use a SET command like $SET(\2=\1 food), the \2 will not become "fish food" but will be literally set to "\1 food". However this will be expanded to "fish food" when \2 is printed in the replacement section.

Regardless,

Code:

[Patterns]
Name = "Test3"
Active = FALSE
Limit = 256
Match = "go\0ogle$TST((\0)=\1)"
Replace = "**\1**"

Doesn't match google.
Does match gostuffhereogle but doesn't fill \1.
$TST((\0)=*) would provide a test for value, however.

Best advice is 'If rearranging isn't possible, use (|\X).'

[sidki3003]

(Oct. 21, 2010 09:29 PM)JJoe Wrote:  From help

SRL Wrote:The value a variable is set to isn't "expanded" until it's actually called in the replacement text. This means if \1 is "fish" and you use a SET command like $SET(\2=\1 food), the \2 will not become "fish food" but will be literally set to "\1 food". However this will be expanded to "fish food" when \2 is printed in the replacement section.

This thread as well as mentioned "Techniques.txt" document is about undocumented "nuances" (as Mona labeled them). "undocumented" means "not part of the official documentation".

Each statement in Techniques.txt is followed by examples, allowing you to verify it.

[JJoe]

Ummm. I wasn't disagreeing or intending to express doubt or disrespect. Simply "thinking out loud" and then explaining myself.

Sorry

[whenever]

Just a quick note that the latest version of the "Google: Multi URL Untangler" filter is causing the same issue as what the post one described again. Sorry I don't have time to look into it though.

Code:

Google: Multi URL Untangler     11.08.13 (multi) [sd jjoe] (d.s)