Cogging for fun and boilerplate-win

Trying an experiment lately with Python3+Cog.py. The point is to bring down maintenance burden a bit.

Problem Background: Some requests have come in for more turing machine related modules. Every new module requires at minimum adding an extern Model* something definition in one header, a separate Model* something = ... initializer in a separate file. And with V1 it seems (incorrect assumption?) we are also to maintain json manifests of our plugins.

Cog Background: Cog reads arbitrary files looking for source markers, runs the python contained within those regions and outputs the result to a separate region. So you can load JSON files or other scripts, do Jinja templates, anything really. The results are saved back to the original files where they can enter source control, be debugged, caught by Phabricator review rules, inspected by the walled gardeners, and so forth.

Current level is simply to bring simple plugin information (tags, names, slugs) in to a python dictionary. Then the dictionary is imported by cog regions in one plugin file to ensure all the externs are up to date always. Then a separate cog region ensures the instantiations are up to date. And yet another cog region imports the headers to keep that in line as well.

Fringe benefit to this is you can write a unit test (ex. test_modules.py, which runs stand-alone or with nose2 etc.) There’s a few indie game devs that have spoken to “testing your configs,” which can do things like ensure the right naming convention is used, checks to see if a documentation file is present for the module somewhere.

Since turing machine modules actually have no “special” behavior other than setting up parameters/loading an svg and such, their widget headers are nearly blank. A next experiment would be to generate these “simple” plugins as well. Works much less well with the What Note? that does a custom draw, but being able to eliminate a few more headers is a worthy goal I think.

This sounds very cool!

Does it have much impact on build times? Do you have it hooked into the Makefile so that running make will pull in changed metadata automatically?

Another good use would be updating the widget positions in the C++ when the SVG changes.

None. I have to re-run cog when the source data for something cog is generating changes, otherwise it becomes the same as any hand-written code.

I might hook it up to a doit.py file. Or a separate maintainer makefile. The makefile that gets run by the plugin team I have little interest in touching as I want as little issues as possible for everyone on that side.

This would indeed be nice.

1 Like