Using a simple, hysteresis based approach… currently in this first
version the optimizer recursively moves modules out of a thread until a
certain timing target is reached; the "modules moved out" just mentioned
are then partitioned into new threads according to their latest time profile.
Very simple, but very effective.
Todo: Implement merging threads with (again) good behaving workloads.
I thought: Well, isn't it a bit redundant if I go ahead and say in my
config "import this-n-that and temp and load and alsa" while later
just giving register() the modules.
So register() (/ClassFinder as the backend) now support just naming a
module as the first parameter. That module is then imported and
searched for a class as usual.
Just for reference the synopsis of Status.register():
register(mod.SomeChecker())
register(mod, setting1=..., setting2=...)
register(mod, {"setting1:":, "setting2":...})
register("mod", setting=1..., setting2=...)
register("mod", {"setting1:":, "setting2":...})
Fun fact: Actually register() doesn't care for it's arguments.
They're passed straight into ClassFinder.instanciate_class_from_module
(something I should definitely rename), which checks if it's first
parameter is one of:
-Python module
=> It calls ClassFinder.get_class with the same parameters
=> get_class will search the module using ClassFinder.search_module
and return a matching class if and only if there is a single matching
class in the module
-string
=> It calls ClassFinder.get_module to import the module and calls itself
on the result
-something else
=> It returns that something
The actual variation in passing the settings (keyword arguments vs. dict)
is handled in SettingsBase.
ClassFinder:
Removed exclude argument, which is basically covered with
obj.__module__ == module.__name__ which ensures that no imported
classes are found, which was the only use case for exclude.
This didn't change the public "API" used by modules.
.core.io contains the IO classes, namely IOHandler, StandaloneIO and JSONIO
.core.util contains SettingsBase and ClassFinder
.core.exceptions contains all custom exceptions
This is 100pct. the same functionality as a complete module before :-)
But still, have to come up with some better way to manage these "templates".
And a place to stash them.
So I can have my old representation back... indeed you can
do pretty much anything now with it:
status.register(battery,
format="{consumption:.2f}W {percentage:.2f}% [{percentage_design:.2f}%] {remaining_hm}"
)
