Scripting Bugs

[admin]

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?

Correct, in terms of operator precedence it's like you say. Within the same group of operators the default is left to right, so
echo 3 > 2 == 2; // 1 == 2 = 0
echo (3 > 2) == 2; // same
echo 3 > (2 == 2); // 3 > 1 = 1

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')?

It's not possible to solve. My last attempt to solve it (by surrounding comparison operators with blanks) was not welcomed by forum users - and rightly so!

This is the state of the art and I don't see anything better:

Code: Select all

v7.60.0010 - 2008-09-15 22:08
    * Scripting: It is not necessary anymore (but allowed) to surround 
      comparison operators with blanks.
      However, to avoid ambiguities in parsing, you have to put XY 
      internal variables (<curpath>, <xyver>...) within doubled quotes 
      strings _IF_ they are to be interpolated!
        ::msg <xypath>;         = okay, variable is isolated
        ::msg "<xypath>";       = okay, variable is isolated & quoted
        ::msg "XY = ".<xypath>; = okay, variable is isolated
        ::msg XY = <xypath>;    = NOT okay, variable is interpolated
                                  but not quoted
        ::msg "XY = <xypath>";  = okay, variable is interpolated & 
                                  quoted

The reason for this "problem" is simple. XY vars are extremely malformed from the POV of scripting syntax since they contain operators in the name. This of course has historical reasons: XY vars are older than scripting. They always have been interpolated within (implied) strings. Now you can (if you isolate them using parentheses or concatenators) use them as if they were real variables, but only because I wrote extra code for that special situation. I could do that because I think an isolated instance of <var> can never be meant to be a comparison. I cannot safely make such an assumption in non-isolated occurences.

I still say: the recommended way to use XY vars in scripting is: quote them!

[admin]

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 ??

See my reply to PeterH ...: http://www.xyplorer.com/xyfc/viewtopic. ... 120#p27120

[PeterH]

OK, I understand.
But I don't like the idea of "quoted variables". Though I see it's a special situation for special variables.
To me it seems the problem is the ambiguous use of <> for compare and for xy-vars. So back to the ignored part of my prev post: why not use functions to resolve XY-vars? The most global form would be like:
xyvar(name [,operands...]) that is xyvar("xypath") or xyvar("date", "w")
Other possible form would be like:
xypath() or date("w")

In this way all variables could be addressed, and the variability for modifiers (date-format etc.) is kept.
So you would lose the ambiguity of <>.
If, in a script, one variable is used several times, it could be read to local variable, and be used multiple after only one function call.

Another solution would be to pre-fill "normal" variables like $xypath with values - but this would lose variablility for date-formats etc.

[admin]

OK, I understand.
But I don't like the idea of "quoted variables". Though I see it's a special situation for special variables.
To me it seems the problem is the ambiguous use of <> for compare and for xy-vars. So back to the ignored part of my prev post: why not use functions to resolve XY-vars? The most global form would be like:
xyvar(name [,operands...]) that is xyvar("xypath") or xyvar("date", "w")
Other possible form would be like:
xypath() or date("w")

In this way all variables could be addressed, and the variability for modifiers (date-format etc.) is kept.
So you would lose the ambiguity of <>.
If, in a script, one variable is used several times, it could be read to local variable, and be used multiple after only one function call.

Another solution would be to pre-fill "normal" variables like $xypath with values - but this would lose variablility for date-formats etc.

Sure, all this would work. But it would mean additional work for me. For me the current state is totally okay, and I will move on to other challenges.

[PeterH]

XY vars are extremely malformed from the POV of scripting syntax since they contain operators in the name.

For me the current state is totally okay, and I will move on to other challenges.

For me a strange combination of facts.

By the way: one thing isn't right I think? XY vars do not contain operators, as then they would mean "less" or "greater". They only contain characters that can be interpreted as operators. And sometimes they will be misinterpreted (mis-parsed) as such by mistake.
Here you talk to users of scripting-syntax, but tell about your programming of that syntax - these are different things and will easy lead to misunderstanding. Surely by parsing you find the character (or sign) "less than", but then you must decide if it's meaning is "compare less" or "mark an XY var". And as this isn't always unique you must force the script programmer to define what he wants by more explicite syntax, using parantheses. You could do this very general by defining: an XY-var is in form (<name>) - in the current state this is unique. But, of course, it would be an additional misuse of parantheses...

[jacky]

I guess this one is obvious:

Code: Select all

 msg ("+" == "-"); // returns true (1) !!

[admin]

I guess this one is obvious:

Code: Select all

 msg ("+" == "-"); // returns true (1) !!

Yup, fixed. Merci!

[admin]

I guess this one is obvious:

Code: Select all

 msg ("+" == "-"); // returns true (1) !!

Yup, fixed. Merci!

PS: What kind of meditations do you do, jacky, to find these kinds of bugs?

[Twisten]

well, not sure if its a bug. sure was annoying to deal with suddenly broken scripts.
it seems the the . (dot) character is now somehow ignored in script files (this cropped up sometime after 7.4 i belive, it is present in 7.6).

example 1: rename s , ABCDEFGHIJKLMNOPQRSTUVWXYZ_>>abcdefghijklmnopqrstuvwxyz. ;
you'll be risking doing yourself some bodily harm trying to figure why all of a sudden the two sides aren't the same lenght.

workaround: rename s , "ABCDEFGHIJKLMNOPQRSTUVWXYZ_>>abcdefghijklmnopqrstuvwxyz." ;

example 2: rename s , .Blah!/ ;
zen moment, if a dot was replaced with nothing and you weren't watching the screen should it still be there?

workaround: rename s , ".Blah!/" ;

oh, and if you get that message about the > missing in a regex rename possibly you pattern ended with \. and pacman went to town. the workaround above works for that too (but leave the space before and after the >).

hope this help

[admin]

well, not sure if its a bug. sure was annoying to deal with suddenly broken scripts.
it seems the the . (dot) character is now somehow ignored in script files (this cropped up sometime after 7.4 i belive, it is present in 7.6).

example 1: rename s , ABCDEFGHIJKLMNOPQRSTUVWXYZ_>>abcdefghijklmnopqrstuvwxyz. ;
you'll be risking doing yourself some bodily harm trying to figure why all of a sudden the two sides aren't the same lenght.

workaround: rename s , "ABCDEFGHIJKLMNOPQRSTUVWXYZ_>>abcdefghijklmnopqrstuvwxyz." ;

example 2: rename s , .Blah!/ ;
zen moment, if a dot was replaced with nothing and you weren't watching the screen should it still be there?

workaround: rename s , ".Blah!/" ;

oh, and if you get that message about the > missing in a regex rename possibly you pattern ended with \. and pacman went to town. the workaround above works for that too (but leave the space before and after the >).

hope this help

If you upgraded from 7.4 to 7.6 you should have seen a big fat note about this when starting the app the first time. I have furthermore posted this everywhere I could, including the What's New page, the Help file, the Tour, the Forum, and it's surely also found in the XYwiki.

But no problem, here it comes again:

Dots (.) now function as string concatenators. Hence now, strings containing dots have to be quoted to preserve the dots!

Sorry for any trouble with broken scripts.

[Twisten]

wierd, i still missed it somehow. thank you.

[jacky]

Seems readfile() doesn't like it when the file read is empty :

Error 9 (00000009)
Desc Subscript out of range error
Dll 0
Proc script_Process

Source XYplorer
XY ver 7.80.0000
OS WinXP (Service Pack 2)
Date 06/11/2008 23:25:59

[admin]

Seems readfile() doesn't like it when the file read is empty :

Error 9 (00000009)
Desc Subscript out of range error
Dll 0
Proc script_Process

Source XYplorer
XY ver 7.80.0000
OS WinXP (Service Pack 2)
Date 06/11/2008 23:25:59

Whoops, thanks!

[jacky]

Little bug when XY won't apply the sort order for some reason after having created a new file :

Code: Select all

  sortby name, d;
  new "tmp";
  sortby name, a; // doesn't work!

I know we've discussed this already, but I honestly fail to remember the conclusion. What I know is whether it's a bug that should be fixed, or a behavior I really don't like at all, since I consider it to be a bug.

Code: Select all

  msg <date w>; // 7
  msg <date w> - 1; // 1 !??

Seems command incr has a problem and doesn't support global vars or something, somehow...

Code: Select all

  $a = 42;
  msg $a; // 42
  incr $a;
  msg $a; // 43
  
  global $a;
  $a = 42;
  msg $a; // 42
  incr $a;
  msg $a; // 1 !!

I think TheQwerty had this idea a while back already, and I believe you liked it as well, so here it goes again : it would be pretty neat to be able to have a new command html for example, that would be like text only with a HTML content (like tips) Would be quite useful for many things, like better "help" for scripts, better results/"reports" after a script execution, ability to show HTML report() without having to use the panel preview (or the need to write a file!), etc

[jacky]

Little bug in calculations, it seems XY always do additions before substractions instead of going left to right...

Code: Select all

  msg 5 - 2; // 3
  msg 5 - 2 + 1; // 2 !!
  msg (5 - 2) + 1; // 4
  msg 5 - (2 + 1); // 2