Scripting Bugs

[admin]

I could only repro it with radical heredocs. Fixed (toughy).

[TheQwerty]

Singly-quoted expressions trick operators.

Code: Select all

"A story of two literals..."
  if ('a' != 'b') {
    echo 'They are different...';
  }

  if ('a' == 'b') {
    echo '... but they are the same.';
  }

  if ('a' != 'b' && 'a' == 'b') {
    echo 'Maybe they are differently the same?';
  }

  if ('a' UnLike 'b') {
    echo 'They hate each other...';
  }

  if ('a' Like 'b') {
    echo '... but they like each other.';
  }

  if ('a' UnLike 'b' && 'a' Like 'b') {
    echo 'Guess love breaks mathematical laws?';
  }

In all fairness this likely never happens except if you're testing to see if the Like operators automatically surround the pattern with wildcards.

[admin]

Confirmed and fixed. Wow, I did not expect such a basic parsing bug after so many years. And, of course, you would find it.

Don't know about the wildcards... does it? Probably not...

[TheQwerty]

Don't know about the wildcards... does it? Probably not...

Now that I think about it I'm not sure I ever got back to whatever it was I was attempting...

It's going to be a long October...

[TheQwerty]

From a fresh copy of v13.60.0010 (the fresh SC won't work here...):
1) Open XY
2) Enable Scripting > Step Mode
3) From a command prompt run:

Code: Select all

XYplorer.exe /script="::SaveSettings;" /flg=2

4) Repeat step 3 without responding to the Stepping Through a Script dialog.

At this point the stepping dialog becomes an XYplorer - Scripting dialog and has an error:

The current script appears to be recursive.
The stack size is 0.

And an Error dialog pops up:

Error: 400 (0x00000190)
Desc: Form already displayed; can't show modally
Dll: 0
Proc: script_Process

Source: XYplorer
XY ver: XYplorer 13.60.0010
OS: Windows 7 Professional (Service Pack 1), 64-bit
Locale: 1033
ANSI: 1252
ACP: 1252 (ANSI - Latin I)
DBCS: No
DPI: 96 (100%)

Date: 1/15/2014 7:51:22 AM

5) Close the error dialog.
6) Continue or Cancel the script.
7) Repeat step 3.

Now only an error dialog pops up:

Error: 9 (0x00000009)
Desc: Subscript out of range
Dll: 0
Proc: script_Process

Source: XYplorer
XY ver: XYplorer 13.60.0010
OS: Windows 7 Professional (Service Pack 1), 64-bit
Locale: 1033
ANSI: 1252
ACP: 1252 (ANSI - Latin I)
DBCS: No
DPI: 96 (100%)

Date: 1/15/2014 7:53:35 AM

This will appear with every attempt to run any script until XY is restarted.

Admittedly, this is partially the case of a user error but XY could be more graceful in its handling of the situation.

[admin]

This is such bad manners that I could not test it for ethic reasons. But I attempted an air-fix. Check next beta...

[medder]

Hello. After upgrading from 13.00 to 13.60 I've noticed, that some of my scripts work in some strange way.
After doing some digging, I discovered that XYplorer now deals with numbers in a different way or even makes some serious errors.

The few things i noticed:
1) The behavior of the function ROUND() has changed.

Let's take an example from the help file:

Code: Select all

echo round(172.7368, 0);  //173

The earlier versions returned 173 (simple mathematical rounding).
The current version returns 172 (just removes the digits after the decimal point).

Even the example from the Help file doesn't work correctly.

2) Talking about decimal point: XYplorer now uses the comma symbol instead of the period.
Example: lets divide 1010 by 1024.
Earlier versions return 0.986328125 (with period). The current version returns 0,986328125 (with comma).

Moreover XYplorer is unable to use these returned values (with comma) in later calculations.

In current version:

Code: Select all

echo 1+0.986328125 // displays 1,986328125 (correct, but again with comma)
echo 1+0,986328125 // displays 1 (XYplorer ignores 0,986328125)
echo 1+(0,986328125) // the only possible way to overcome this error

In any way, using comma as decimal point is wrong.
Comma is already being used as parameter delimiter in functions.

3) XYplorer is unable to treat strings with numbers as numbers.
Example:
In earlier versions: "1010 some text"/1024 would return 0.986328125
In current version "1010 some text"/1024 returns 0.

So I had to modify my scripts and crop the text part using regexreplace(), which takes more time.


I've checked the builds between 13.00 and 13.60. The changes in behavior happened in 13.30.



Some of these changes can lead to serious errors in some scripts. So I have to downgrade to 13.20.

[TheQwerty]

This is such bad manners that I could not test it for ethic reasons.

I don't understand this statement at all.

But I attempted an air-fix. Check next beta...

Bad news... no difference noticed with v13.60.0013, even the error messages are the same.

[admin]

This is such bad manners that I could not test it for ethic reasons.

I don't understand this statement at all.

But I attempted an air-fix. Check next beta...

Bad news... no difference noticed with v13.60.0013, even the error messages are the same.

Hm, weird!

My first statement was meant jokingly but I guess the joke failed to pass the language border. Anyway, I cannot do anything about this issue now since the main cause is user error. This lowers its priority.

PS: Well, I tried one more air-fix...

[admin]

1) The behavior of the function ROUND() has changed.

Indeed, a bug. Thanks lot! Fix comes.

2) Talking about decimal point: XYplorer now uses the comma symbol instead of the period.

Not a bug, but a change of behavior. Since v13.30.0008 - 2013-11-18 12:13 the returns of mathematical operations are in locale aware format. If your locale uses comma as decimal separator XY will use it too. But only in strings. Now all return values in XY's scripting are to be seen as strings. XY's script language is not really typed and the only place where there is an implicit difference in types is when you use number quoted (as numeric strings) or not quoted (as numbers).

For better illustration I repeat the change log here:

Code: Select all

v13.30.0008 - 2013-11-18 12:13
    + Scripting | Math Operations: Now, in German Windows, you can enter 
      fractional constants in international format (decimal separator = 
      dot) by leaving them unquoted. This is obviously the preferred way 
      to go now for locale-independent scripts.
      Examples that now work in any Windows:
        echo 17.5 * 2;        //35
        echo -17.5 * 2;       //-35
        echo 17.5 + 17.5;     //35
        echo format(17.5);    //17,5
        echo format(17.5, "00.00");  //17,50
      Note: This only works in German Windows as "17,5" is no number in 
      English Windows:
        echo format("17,5", "00.00");  //17,50
      Note: Entering a fraction with dot in German Windows will not work 
      as "17.5" is no number in German Windows:
        echo "17.5" * 2;      //0
      Note: Do not enter the German decimal separator unquoted:
        echo format(17,5 , "00.00");  //5 (totally invalid syntax)
      Note: Here format() sees the dot as German thousand separator and 
      simply ignores it when determining the value of the number:
        echo format("17.5");  //175
        echo format("17.5", "00.00");  //175,00
    - Scripting | Math Operations: Removed the change in v13.30.0007. 
      Now you can do any of the following in German Windows:
        $n = "17,5"; echo $n; //17,5
        $n = 17.5; echo $n;   //17,5
      This will NOT work as expected since you must not enter German 
      decimal separator unquoted:
        $n = 17,5; echo $n; //17!

3) XYplorer is unable to treat strings with numbers as numbers.
In earlier versions: "1010 some text"/1024 would return 0.986328125
In current version "1010 some text"/1024 returns 0.

Well, frankly I think the current way is the correct one. "1010 some text" is not a number, and a non-number is auto-converted to 0 (zero) when it is found in a mathematical operation.

[TheQwerty]

PS: Well, I tried one more air-fix...

It works, but I think it would probably be preferable, at least safer, to just ignore the attempts made while the stepping dialog is visible, rather than running them while a previous script is stepping.

Granted, for my purposes the behavior of v13.60.0015 is fine so maybe it can just stay that way for now.

the main cause is user error

To defend myself... I have a batch file which runs XY with a SaveSettings script periodically, and I'd occasionally come back to find those errors because I had forgotten to disable stepping after doing something else.

My error was just forgetting to disable stepping rather than ignoring or refusing to respond to the dialog.
It's not like I was purposely trying to run another script while the previous one was stepping.

[admin]

PS: Well, I tried one more air-fix...

It works, but I think it would probably be preferable, at least safer, to just ignore the attempts made while the stepping dialog is visible, rather than running them while a previous script is stepping.

I had thought about this, and decided that stepping is rather a debugging tool than a safety net, so I decided to let them run unhindered.

[TheQwerty]

PS: Well, I tried one more air-fix...

It works, but I think it would probably be preferable, at least safer, to just ignore the attempts made while the stepping dialog is visible, rather than running them while a previous script is stepping.

I had thought about this, and decided that stepping is rather a debugging tool than a safety net, so I decided to let them run unhindered.

That's fair reasoning... I concur.

[TheQwerty]

Well here's a fun one...

Code: Select all

"It's All Unicode"
 $tests = 'abc|€|';
 $results = '';
 foreach ($test, $tests, '|') {
    $verdict = IsUnicode($test) ? 'is' : 'is not';
    $results = $results . "'$test' $verdict unicode.<crlf>";
 }
 Text $results;

Strictly speaking it is not an XY bug - IsUnicode returns the correct values.
The problem is those values are the strings "True" and "False".

Technically the documentation is wrong since it implies the function returns 1 and 0 when it says:

return: True (1) if wide characters are present in string, else False (0).

For once I'm going to argue that we should break compatibility with old versions and correct this so that IsUnicode returns 1 or 0.

My searches point to this thread as the likely only time anyone has used this function. Between it being unresolved and this being the first time anyone has bothered to report the issue I feel it is fair to conclude no one is using this function and therefore we can cure this insanity now that I want to use it.


If you do not agree then I'm going to have to insist the documentation recommend always wrapping IsUnicode within Eval.

[Marco]

Agreed, also because True and False are localized, thus potentially generating execution problems in localized instances of XY.