Added optional wait variance

[shawarden]

Added an optional argument to wait to the amount of time wait can vary between between the 2 specific values. 2nd 'vary' argument is ignored if value is less than 1st 'time' argument. This more closely resembles parse.py's description of wait as having a range value and it's handy to have for automation obfuscation.

[sezanzeb]

Thanks a bunch! A new unit-test would be very nice

[sezanzeb]

_resolve makes rpc calls. Though I doubt it would be noticeable by a user, on paper it would most likely be a lot better for performance if _resolve was called once for vary and time, and then the result stored in a local variable within task to reference it later on, instead of resolving time redundantly three times. It also reduces the risk of race conditions.

[shawarden]

Fair. When I made the initial changes the vary > time comparison didn't work and my knowledge of python isn't spectacular.

[sezanzeb]

you need to resolve them in task. _resolve looks up variables, and they can change during runtime. If you do it outside of _task they are resolved when the macro is parsed, and then never again.

[shawarden]

I've moved the _resolve into _task. I'm not sure how to set the default value for max_time to be None as it throws an error comparing 'NoneType' and 'int' when the second argument isn't set. Again, my python is not amazing.

A slightly off-topic aside: In testing I found a way to test if macro variable is set or not by if_eq($var, None, then=unset_macro, else=set_macro). Would it be worth amending the examples documentation to illustrate it as a roundabout if_unset() function? Using wait with an unset variable can softlock keys if you have something like key_down(a).wait($unsetvariable).key_up(a) as the wait dies so key_up(a) never fires and having the macro always set unsetvariable first negates changing the value elsewhere.

[sezanzeb]

as it throws an error comparing 'NoneType' and 'int' when the second argument isn't set.

yeah, you would need to do something like if max_time is not None and max_time > ...

this way, you are not comparing 'NoneType' and 'int', because it never reaches the comparison if max_time is None.

---

Do you mean something like

if_eq(
  $unsetvariable,
  None,
  then=set(unsetvariable, 1000),
  else=?
).key_down(a).wait($unsetvariable).key_up(a)

?

[sezanzeb]

unittests are used in pipelines, like this one: https://github.com/sezanzeb/input-remapper/actions/runs/11427747182/job/31792217401 (Click on "Run tests" to see them)

They are used, so that we immediately see if something broke with our changes. In that case, github will display an error icon for us, like here:

Other than that, people rarely look at the test-output. And nobody is going to look at the output of a test each time they make a commit, to verify if things still work.

This is what I mean with "automated". Unittests should automatically check if the result is as expected (time within an acceptable margin of error), and if not, raise an exception (self.assertLess does that for us in the example below)

Here is how a test can work. It passes if 5 iterations of wait sleep between 45ms and 55ms on average.

    async def test_wait_1(self):
        mapping = DummyMapping()
        mapping.macro_key_sleep_ms = 0
        macro = parse("repeat(5, wait(50))", self.context, mapping, True)

        start = time.time()
        await macro.run(self.handler)
        time_per_iteration = (time.time() - start) / 5

        self.assertLess(abs(time_per_iteration - 0.05), 0.005)

[sezanzeb]

Automated tests are extremely important and every project should have them.

[sezanzeb]

I'll finish the pull request later if you don't have more time, that's fine. :)

[shawarden]

I've re-added the float inputs for the required time and as well as the optional max_time and carried that through the entire function while also making sure it didn't get flattened by the various ints. Also added debug output to the add_wait macro but it's not reflected in testing.

Using your unit testing it looks like they're all within desired +/-0.005s limits. All but a double variable retrieval are under 0.001 withwait($a,$b) breaking 0.002 even on my ancient work laptop.

[sezanzeb]

If you remove the time randomization from add_wait, your tests will still pass, therefore they are not able to verify if the randomization works.

I have made some changes and a pull request to your branch: shawarden#1. In shawarden@dc98ddb you can see how I ended up designing the tests.

Once you merge that one into your main branch, I'll merge this pull request.

[sezanzeb]

What is the reason for removing float as supported datatype? If this feature is released and someone used wait(10.5), then I believe their macro will suddenly crash.

[shawarden]

I was trying to make the wait macro accept a variable as input as it either didn't or I'd broken it somehow.

[sezanzeb]

Merged in #986