Scripting Bugs

[admin]

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

Is it a bug? True, it's different from PHP, and probably from math standard (?). But I cannot change it easily. The parser is constructed in a way that presupposes a strict operator precedence. It's * > / > + > -

But, wait... there might be a way... EDIT: okay, done.

[jacky]

Is it a bug? True, it's different from PHP, and probably from math standard (?). But I cannot change it easily. The parser is constructed in a way that presupposes a strict operator precedence. It's * > / > + > -

Well, yes I noticed how your parser worked, but it surely was a bug, because it was not just different from PHP but any scripting/programming language, or just basic math rules indeed! So, yeah, glad you solved it

[PeterH]

Well, yes I noticed how your parser worked, but it surely was a bug, because it was not just different from PHP but any scripting/programming language, or just basic math rules indeed! So, yeah, glad you solved it

Very right. And it was not only different from all other ways I know of, but even different from all ways I can imagine.

I hope you also have solved it for * and / ?

[admin]

I hope you also have solved it for * and / ?

Yep, solved also.

[admin]

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

1. Thanks!
2. quote it: msg "<date w>" - 1;
3. Thanks!
4. Later.

[jacky]

2. quote it: msg "<date w>" - 1;

Yeah, I know, but that was my point actually, that's what i see as a "bug". Because i don't see why we should have to quote a variable to use it, especially when it's a numeric variable and we want to do a math operation with it! Why should we turn it into a string first ??

I know it's a parsing issue on your side, but it's not the first time I do a $a = <date w> + 1; or ($check) ? <date yyyy> : <date yyyy> + 1; only to realize that it should be quoted, which seems unnatural if not illogical (to me)...

Also, I would say the same about this one :

Code: Select all

 msg (<date hh> < 10) ? "only ".<date hh>." -- why so early?" : "sun is up";

I wish that one would work without the need for additional parenthesis just because I use concatenation...

</pita>

[PeterH]

2. quote it: msg "<date w>" - 1;

Yeah, I know, but that was my point actually, that's what i see as a "bug". Because i don't see why we should have to quote a variable to use it, especially when it's a numeric variable and we want to do a math operation with it! Why should we turn it into a string first ??

I know it's a parsing issue on your side, but it's not the first time I do a $a = <date w> + 1; or ($check) ? <date yyyy> : <date yyyy> + 1; only to realize that it should be quoted, which seems unnatural if not illogical (to me)...

Exactly.
And reason is, as said before, the "strange" form of these varnames, containing characters < and >, that are confusable with operators. I think everything but replacing this naming syntax will lead to more or other problem situations.
For some ideas for possible solutions see posts of 02 Oct 2008 ...

[admin]

2. quote it: msg "<date w>" - 1;

Yeah, I know, but that was my point actually, that's what i see as a "bug". Because i don't see why we should have to quote a variable to use it, especially when it's a numeric variable and we want to do a math operation with it! Why should we turn it into a string first ??

I know it's a parsing issue on your side, but it's not the first time I do a $a = <date w> + 1; or ($check) ? <date yyyy> : <date yyyy> + 1; only to realize that it should be quoted, which seems unnatural if not illogical (to me)...

Also, I would say the same about this one :

Code: Select all

 msg (<date hh> < 10) ? "only ".<date hh>." -- why so early?" : "sun is up";

I wish that one would work without the need for additional parenthesis just because I use concatenation...

</pita>

Could not handle the last one (ternary with concatenators), but the others will work now.

[jacky]

Could not handle the last one (ternary with concatenators), but the others will work now.

Excellent news! I can live with the last one, it was the first that bugged me the most... Thanks!

[admin]

2. quote it: msg "<date w>" - 1;

Yeah, I know, but that was my point actually, that's what i see as a "bug". Because i don't see why we should have to quote a variable to use it, especially when it's a numeric variable and we want to do a math operation with it! Why should we turn it into a string first ??

I know it's a parsing issue on your side, but it's not the first time I do a $a = <date w> + 1; or ($check) ? <date yyyy> : <date yyyy> + 1; only to realize that it should be quoted, which seems unnatural if not illogical (to me)...

Exactly.
And reason is, as said before, the "strange" form of these varnames, containing characters < and >, that are confusable with operators. I think everything but replacing this naming syntax will lead to more or other problem situations.
For some ideas for possible solutions see posts of 02 Oct 2008 ...

The "strange syntax" is there for a good reason: These variables work within path specs. That's actually the historical origin and still their strong point.

[jacky]

One is a bug, one is a wish, but I'll post the two of them here since they're tiny

- the bug: using SC rename to rename a file on a folder that's not the current location, but a file that has the same name as a file in the current location (e.g. rename D:\www\index.htm while on E:\test\www where there is also an index.htm) then the XY will wrongly update the List, "renaming" (visually) the file index.htm to the new name.

The actual rename of the file was right and performed on the correct file, but to see it renamed on List (i.e. wrong file/folder) is quite disturbing!

- the wish: I'd like it if command new, when given a full path/name, would create the file/folder in the specified path, instead of dropping the path and create it in the current location instead.

[PeterH]

The "strange syntax" is there for a good reason: These variables work within path specs. That's actually the historical origin and still their strong point.

Sorry - I missed this one.
I see your points. And it seems your current solution works well. (In the moment I paused scripting - I'm waiting for if/grouping/looping ) So we can hope you will be lucky and have no more problems with this - but I'm not sure of this.
Result: if another problem with the current syntax (i.e. <xxx> names) should arise, you could start thinking about changing it to a more php-compatible version without <>.

[admin]

One is a bug, one is a wish, but I'll post the two of them here since they're tiny

- the bug: using SC rename to rename a file on a folder that's not the current location, but a file that has the same name as a file in the current location (e.g. rename D:\www\index.htm while on E:\test\www where there is also an index.htm) then the XY will wrongly update the List, "renaming" (visually) the file index.htm to the new name.

The actual rename of the file was right and performed on the correct file, but to see it renamed on List (i.e. wrong file/folder) is quite disturbing!

- the wish: I'd like it if command new, when given a full path/name, would create the file/folder in the specified path, instead of dropping the path and create it in the current location instead.

As usual: Good bug, good wish. Fixed & done.

[jacky]

One is a bug, one is a wish, but I'll post the two of them here since they're tiny

- the bug: using SC rename to rename a file on a folder that's not the current location, but a file that has the same name as a file in the current location (e.g. rename D:\www\index.htm while on E:\test\www where there is also an index.htm) then the XY will wrongly update the List, "renaming" (visually) the file index.htm to the new name.

The actual rename of the file was right and performed on the correct file, but to see it renamed on List (i.e. wrong file/folder) is quite disturbing!

- the wish: I'd like it if command new, when given a full path/name, would create the file/folder in the specified path, instead of dropping the path and create it in the current location instead.

As usual: Good bug, good wish. Fixed & done.

As usual: Excellent lightenning fast support. Pleasure to keep you busy

[Per128]

Hi,
I'm testing XYPlorer v7.7 under XP64 and have a problem with the following script:
"test_writefile" writefile("temp.txt", "text")

Scripting->Load Selected Script File on the above (contained in <xypath>\scripts\test.xys) gives me:
Scripting error window: "'writefile' is not a valid script command."

The problem is obvious; I get a scripting error on a basic command that should work just fine. A forum search on this revealed nothing of relevance.
Any idea what may be causing this?