Page 6 of 41
Posted: 02 Mar 2008 14:32
by 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...
Posted: 03 Mar 2008 08:07
by admin
jacky wrote:admin wrote: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.)
Posted: 03 Mar 2008 08:45
by admin
jacky wrote: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
).
Re: Scripting Bugs
Posted: 17 Sep 2008 19:54
by 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!
Re: Scripting Bugs
Posted: 17 Sep 2008 20:19
by admin
TheQwerty wrote: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.
Re: Scripting Bugs
Posted: 29 Sep 2008 16:48
by 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...
Re: Scripting Bugs
Posted: 29 Sep 2008 17:52
by 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.
Re: Scripting Bugs
Posted: 30 Sep 2008 11:22
by admin
jacky wrote: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.
Re: Scripting Bugs
Posted: 30 Sep 2008 11:45
by admin
jacky wrote: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!
Re: Scripting Bugs
Posted: 01 Oct 2008 01:58
by jacky
admin wrote: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)
Re: Scripting Bugs
Posted: 01 Oct 2008 07:52
by admin
jacky wrote:admin wrote: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
Re: Scripting Bugs
Posted: 01 Oct 2008 20:13
by 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?
Re: Scripting Bugs
Posted: 01 Oct 2008 20:50
by admin
PeterH wrote: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...
Re: Scripting Bugs
Posted: 01 Oct 2008 21:15
by jacky
admin wrote: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.
Re: Scripting Bugs
Posted: 01 Oct 2008 22:06
by 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')?