XYplorer Beta Club

jacky wrote: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

admin wrote: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 * > / > + > -

jacky wrote: 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 wrote:I hope you also have solved it for * and / ?

jacky wrote: 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

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

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

jacky wrote:

admin wrote: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)...

jacky wrote:

admin wrote: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>

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

PeterH wrote:

jacky wrote:

admin wrote: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 wrote: 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 wrote: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.

admin wrote:

jacky wrote: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.