@EVAL has changed?

[vefatica]

v29:

v:\> echo %@eval[666 ms/1000]
666

v30:

v:\> echo %@eval[666 ms/1000]
TCC: Syntax error "666 ms/1000"

What's up with that?

 

[rconn]

Not sure what your issue here is - you want to feed bad input to @EVAL and have it ignored?

 

[vefatica]

I have no issue. I am simply curious about the change to a long-standing behavior. It's not exactly clear what triggers the error message.

v:\> echo %@eval[666 ms]
TCC: Syntax error "666 ms"

v:\> echo %@eval[666 1 ms + log(foo)]
666

 

[Jay Sage]

Not sure what your issue here is - you want to feed bad input to @EVAL and have it ignored?

The issue is that we expect to be able to use timer values from @TIMER in calculations in @EVAL. That used to work when @EVAL ignored the fact that sometimes @TIMER returned strings after the value.

The current behavior of @EVAL makes sense; the behavior of @TIMER does not (and does not agree with the documentation).

 

[rconn]

I have no issue. I am simply curious about the change to a long-standing behavior. It's not exactly clear what triggers the error message.

v:\> echo %@eval[666 ms]
TCC: Syntax error "666 ms"

v:\> echo %@eval[666 1 ms + log(foo)]
666

A long-standing bug was fixed when v30 added octal numbers and new integer argument operators.

Still not sure exactly what you're driving at here - you want to know all the possible bad arguments you can pass that @EVAL won't complain about? Something like %@EVAL[666 1] isn't an invalid argument - a dumb and useless argument, but not invalid. (You're asking for an integer no-op.) When you start adding random text (which could be interpreted as variables, function names, or string operators) you are unlikely to be pleased with the results.

%@EVAL[666 ms] is interpreted as "Do a no-op with the nonexistent variable ms", which throws an error because you probably don't want to use non-existent variables. %@EVAL[666 1 ms] is interpreted as "Do a no-op with an integer, then ignore everything until the next operator". And relying on undocumented parser behavior will get you in trouble every time.