[Feature proposal] Macro validation

[kareltucek]

Assume I write a solution that can validate smart macros, same as the config is validated via a dry run.

It would mean some nonnegligible amount of code clutter.

Do you find it worth the effort and the added maintenance burden (due to the code clutter)?

[kareltucek]

Pros:

• The user gets warnings about errors and deprecations immediately upon saving the configuration.
• Same deprecation warning is not repeated with every use of the command. (I assume that warnings would be enabled only during the dry run.)

Cons:

• Code clutter and related decrease in code readability.
• Obviously costs time to implement.

[mondalaci]

Depends on the amount of code clutter. In my view, about a hundred extra lines may be worth it, but not a thousand lines.

Increased power consumption is also a consideration. Would you run this validation on firmware bootup and configuration saves?

[kareltucek]

Like a one additional return somewhere in implementation of every command (~100 lines in total?), plus a ~50 line function to take care of traversing all the commands and dry-run them.

I assume I would run this validation on configuration saves, and maybe on bootup. It seems to me that config validation does not bring much added value on bootup and so if power consumption is a concern, I would leave that out.

[mondalaci]

Can you prefix the warnings/errors with the related macro names? If so, how much would prefixing increase clutter, assuming it'd increase it at all?

[kareltucek]

Current errors do contain macro name whenever issued while some macro is evaluated, so that would be the case during validation with no additional work/clutter.

Current error format is:

Error at {macroName} {actionIndex}/{commandAddress}: {errorMessage}: {command}

E.g.:

Error at tstErr 0/0: unrecognized command: asdfadsfasdf

(If you wish me to change it, let me know. I can imagine that for instance outputting line numbers instead of command addresses would be more user friendly, at the expense of some coding and clutter.)

[mondalaci]

How actionIndex and commandAddress differ from line numbers?

[kareltucek]

[mondalaci]

Gotcha, thanks. Line numbers would be much more useful than command addresses. How much extra clutter to expose them?

[kareltucek]

Either

• 30 lines of ugly and possibly buggy code that will be pain to maintain
• or 30 bytes of memory and 10 lines of code which will be lesser pain to maintain

[mondalaci]

Picking the second option is a no-brainer here. Please make it happen.

[kareltucek]

Allright!

(I will simply assume it is a yes also to the original proposal of this ticket 😃.)

[mondalaci]

It is. :)

When there are smart macro related errors/warnings, configuration saves will always succeed, and then the errors and warnings will be put into the status buffer, right?

[kareltucek]

Yes!

[mhantsch]

Would you make Agent automatically retrieve the status after config save, so user gets an immediate response within Agent whether their macros are good? (Instead of having to look at the UHK display, then do some printStatus magic...)

[kareltucek]

Yes!

[mondalaci]

@mhantsch This will naturally happen as part of the planned Agent feature that exposes errors and warnings to the user.