WAD Bug in @TIMER Function

[Jay Sage]

I think there is a problem with the output of the @TIMER function.

TCC(30.00.22): C:\>echo %@timer[2,ms]
17727 ms

The units are now added after the number for precision of ns, us, and ms. That caused a script of mine to fail because the @EVAL function was not happy the 'ms' string.

 

[vefatica]

Interesting! No units are printed for s, m, and h. Ms, us, and ns should be the same. I shouldn't have to be reminded what I asked for.

 

[vefatica]

The units are now added after the number for precision of ns, us, and ms. That caused a script of mine to fail because the @EVAL function was not happy the 'ms' string.

Weren't they always?

 

[Jay Sage]

Weren't they always?

No. I had made no changes to my bulk mail script, which ran perfectly when I last used it with version 27. Today was the first time I used it with the new version.

The behavior contradicts the help information -- in which I just noticed another problem. It says that the default resolution is milliseconds. That is not correct. The default is hours:minutes:seconds.

TCC(30.00.22): C:\>echo %@timer[1]
0:01:46.868

TCC(30.00.22): C:\>echo %@timer[1,]
0:03:28.695

TCC(30.00.22): C:\>echo %@timer[1,ms]
241480 ms

 

[vefatica]

I dunno. v27 prints the units (ms, us, ns) for me.

v:\> ver
TCC 27.01.24 x64
Microsoft Windows 10 Pro for Workstations
10.0.19045.3086 (2009, 22H2)

v:\> timer /2 on
Timer 2 on: 17:42:18

v:\> echo %@timer[2,ms]
11070 ms

 

[vefatica]

It's @EVAL that has changed. See new thread.

 

[Jay Sage]

Thanks for figuring that out, Vince. As you can tell, I did not check and just assumed that @TIMER was the problem. After all, it didn't make sense that three units of precision did not append the unit, while three others did.

I have now changed my code to extract word 0 from the timer output and sidestep the problem.

The current behavior of @EVAL (not accepting extraneous text in the argument) makes more sense than the old behavior. @TIMER should be fixed, but who knows what sort of issues that might raise with old scripts that made use of the information.

 

[vefatica]

The current behavior of @EVAL (not accepting extraneous text in the argument) makes more sense than the old behavior. @TIMER should be fixed, but who knows what sort of issues that might raise with old scripts that made use of the information.

Agreed. Agreed. If an old script simply used @WORD[0,...] it should still work if the units aren't there.

 

[Jay Sage]

I updated my mailmerge script to use %@word[0,%@timer[2,ms]], but I really should not have to do that, unless for some reason the precision unit is ALWAYS included with the output (and there is a good reason to do that and it is so stated in the documentation).

Right now, the documentation says (emphasis added):

@TIMER accepts an optional second argument to return the timer split as a floating-point numeric value suitable for arithmetic.

As it currently works, it is not suitable for arithmetic.