Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

@EVAL has changed?

May
12,807
161
v29:

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

v30:

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

What's up with that?
 
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.

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

v:\> echo %@eval[666 1 ms + log(foo)]
666
 
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).
 
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.

Code:
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.
 

Similar threads

Back
Top