Scripting Bugs

[jacky]

Function #113 not found!

No, I didn't made up that number: File / To Clipboard / Item Base(s)
#112 (File / To Clipboard / Item Short Path/Name(s)) doesn't work either, I don't know about any other.

BTW when using command text does the text has to be selected ? I don't really like that...

[admin]

Alas, there's one problem: in a search results list you can have more than one "file.ext". Then "- selected : gets/stays selected" will never select the next "file.ext".

hmm.. yeah, but really, when will that be needed?!

Seriously though, I see you've done this along with the fixes mentioned above quietly, and it seems that the syntax sel "[text]" doesn't work in Finding Tabs, with or without wildchars.
Is that a recent change ? I honestly never used it on SR before...

Yep, quietly.

The latter issue solves the former! Because I forgot to mention: in find mode you have to state a pattern that matches the full path. So you should to "*\[file.ext]". (Obvious reason: This allows you to select by path as well.)

[admin]

Function #113 not found!

No, I didn't made up that number: File / To Clipboard / Item Base(s)
#112 (File / To Clipboard / Item Short Path/Name(s)) doesn't work either, I don't know about any other.

BTW when using command text does the text has to be selected ? I don't really like that...

Oh yes, ever since... Fixed.

Selected: I think you are right, I took it away (quietly ).

[TheQwerty]

Execute from a script file:

Code: Select all

/* ' */

"The most important script ever!!!!"
	Status "Hello World!";

The apostrophe says to hell with your script, you puny human!

[admin]

Execute from a script file:

Code: Select all

/* ' */

"The most important script ever!!!!"
	Status "Hello World!";

The apostrophe says to hell with your script, you puny human!

Ha! Good find! And fixed.

[jacky]

Seems we can't use concatenation in ternaries :

Code: Select all

msg (1 == 1) ? "o"."k" : "nope"; // (1 == 1) ? "o""k" : "nope"

Okay, so add some parentheses and it works

Code: Select all

msg (1 == 1) ? ("o"."k") : "nope"; // ok

Or does it??

Code: Select all

  msg (1 == 1) ? ('<xypath> is a variable') : 'uh?'; // 1
  $a = 42;
  msg (1 == 1) ? ('$a is a variable') : 'uh?'; // 42 is a variable

I guess this is because it evaluates the expression (though I don't know why the last example gets a variable resolved while in single-quotes?? ), but then again concatenation doesn't work without parentheses...

[jacky]

hmm.. also date variables don't work unless quoted it seems :

Code: Select all

  msg <date dd-mm-yyyy>; // 0
  msg "<date dd-mm-yyyy>"; // 29-09-2008

I know quotes are required when we want them interpolated, but here it's only a date variables, nothing else.

[admin]

hmm.. also date variables don't work unless quoted it seems :

Code: Select all

  msg <date dd-mm-yyyy>; // 0
  msg "<date dd-mm-yyyy>"; // 29-09-2008

I know quotes are required when we want them interpolated, but here it's only a date variables, nothing else.

Because of the "-" char, it was interpreted as math!
Fixed by adding the same smartness that prevents "<xyver>" from being interpreted as comparison.

[admin]

Seems we can't use concatenation in ternaries :

Code: Select all

msg (1 == 1) ? "o"."k" : "nope"; // (1 == 1) ? "o""k" : "nope"

Okay, so add some parentheses and it works

Code: Select all

msg (1 == 1) ? ("o"."k") : "nope"; // ok

Or does it??

Code: Select all

  msg (1 == 1) ? ('<xypath> is a variable') : 'uh?'; // 1
  $a = 42;
  msg (1 == 1) ? ('$a is a variable') : 'uh?'; // 42 is a variable

I guess this is because it evaluates the expression (though I don't know why the last example gets a variable resolved while in single-quotes?? ), but then again concatenation doesn't work without parentheses...

Oh, yes, very nice bug deep in the complexities of recursive parsing. Fixed anyway!

[jacky]

Oh, yes, very nice bug deep in the complexities of recursive parsing. Fixed anyway!

Glad you enjoyed it

Got another one for you :

Code: Select all

  msg <date w>; // 4 (for now)
  msg <date w> - 1; // 1 (that's not it)
  msg "<date w>" - 1; // 3 (that's it)

[admin]

Oh, yes, very nice bug deep in the complexities of recursive parsing. Fixed anyway!

Glad you enjoyed it

Got another one for you :

Code: Select all

  msg <date w>; // 4 (for now)
  msg <date w> - 1; // 1 (that's not it)
  msg "<date w>" - 1; // 3 (that's it)

That's no bug but a consequence of the precedence of analysis. Comparisons are evaluated before math. If you don't want to rely on the default precedence: use parentheses!

msg 10 - 1 > 3 - 2; //1
is identical to:
msg (10 - 1) > (3 - 2); //1
but not identical to:
msg 10 - (1 > 3) - 2; //8!

msg <date w> - 1; // 1
is identical to:
msg ("" < "date w") > (-1); // 1 > -1 = 1
but not identical to:
msg (<date w>) - 1; // 4-1=3

In this case quoting is another way to keep things as you want them:
msg "<date w>" - 1; // 4-1=3

[PeterH]

I don't understand

Didn't you say: Comparisons are evaluated before math
Doesn't that mean
msg 10 - 1 > 3 - 2; / is identical to
msg 10 - (1 > 3) - 2; / I think the parantheses say to evaluate the comparison first?

After not understanding this I'm afraid to ask: isn't <data w> one token? And don't your descriptions say that it is just interpreted wrong?

[admin]

I don't understand

Didn't you say: Comparisons are evaluated before math
Doesn't that mean
msg 10 - 1 > 3 - 2; / is identical to
msg 10 - (1 > 3) - 2; / I think the parantheses say to evaluate the comparison first?

After not understanding this I'm afraid to ask: isn't <data w> one token? And don't your descriptions say that it is just interpreted wrong?

"evaluated" was a misleading term maybe.

Think like a parser: here's an expression "10 - 1 > 3 - 2", parse it!
(1) first look for comparison operators. aha, got one: >
(2) so we have 2 parts, left of >, and right of >: "10 - 1" and "3 - 2"
(3) now we parse each of the parts, and we find math operators
etc...

<data w> is one token for your brain which trained in pattern (gestalt) recognition. The parser is just a poor computer...

[jacky]

That's no bug but a consequence of the precedence of analysis. Comparisons are evaluated before math. If you don't want to rely on the default precedence: use parentheses!

I understand what you're saying, but I disagree. Why should I have to use quotes or parentheses here ??

There's no comparison involved, it's a mistake/bug to think so. All I'm doing is a math operation, e.g. 4 - 1, only instead of using numbers directly I use variables. That shouldn't and doesn't change anything with user variables, to use ::msg $nb - 1; it 100% correct, one don't need to do ::msg ($nb) - 1; or nothing, so why should XY variables be any different ?

If ::msg <date w>; works fine, and it obviously does, it's because this is a variable and treated as such. If I then use the concatenation operator, a comparison operator or a calculation operators that doesn't change the fact that it is nothing but a variable and should be treated as such.
I'm sorry but that using a calculation operators have XY to "change" things and then see a comparison when there's none, and "misinterpret" a completely valid XY variable is, to me, a bug.

[PeterH]

OK - two themes here.

Order of precedence: this is the sequence in that operators are resolved - no matter how they are parsed. (The latter is Don's job programming the logic - while we, the users, want to know how our statements are interpreted.)
I just had a look at php, it says:
< and > are lower than + and -, all these are lower than * and /
That is:
$a = 3 < 4 + 5 * 6; / should be same as
$a = 3 < (4 + (5 * 6)); / or am I wrong?

The other point is <date w>
I was afraid you said you have a "technical" problem on parsing. I do understand it in some way - but it still is wrong - as jacky said.
3 possible solutions:
- you say "it's this way"
- you do more programming to solve those problems
- you don't use such variables.
In this case maybe the last version is the best? Why not use a function date('w')?