Heavy Internals : Fix it up?

[dgbillotte]

There are a number of changes, all small for now, that I think should be made as I'm going through the code. I'd like to get folks buy-in before changing stuff all around.

First one up: this is is a double header.

Q1a: dup'd from the discord forum:

Question Setup: hvcc/generators/ir2c/HeavyObject.py defines base implementations of several methods that are meant to be overridden as needed to emit c-code in diff places. There are a couple methods however, get_C_process() and get_C_onMessage(), where I see them called in ir2c.py and defined in HeavyObject subclasses, but they are not "officially" defined as part of HeavyObject.

I am of the opinion that those methods should have a base implementation in HeavyObject that is either a no-op or generates a sensible error if they are called without being overridden when they should have been. Currently it would generate a fatal error, so an error message is probably the way to go.

Is there something that could break by doing that that I haven't thought of or some other reason not to do that?

Q1b: follow up on HeavyObjectSubclass::get_C_process()

This method has this signature:

def get_C_process(clazz, obj_type, process_dict, objects):

while all the other similar methods have a signature like:

def get_C_init(clazz, obj_type, obj_id, args):

Interestingly, in the one place that get_C_process is called, it's objects parameter is actually getting what the other methods call args... https://github.com/Wasted-Audio/hvcc/blob/develop/hvcc/generators/ir2c/ir2c.py#L228

With all that in mind, I propose that we make these changes to the get_C_process() signature:

• add obj_id as 3rd parameter, like other methods
• rename object -> args and make it the 4th param, like other methods
• make process_dict the last param

Since process_dict is very central to the method, I could see making it the second param and scooting the others down.

Either of these:

def get_C_process(clazz, obj_type, obj_id, args, process_dict):
# or
def get_C_process(clazz, process_dict, obj_type, obj_id, args):

I'd be happy to go change the 22 occurrences and submit that as a single PR.

thoughts?

[dgbillotte]

Looking closer I see that some implementations of get_C_process call the last param objects and some call it args, but it's not defined in HeavyObject.py... 🤷

[dromer]

So, basically this -> #72

[dgbillotte]

While I'm in hvcc/generators/ir2c/HeavyObject.py, there is one other thing that I'd like to do but I'm not as sure on the path for it.

The way that HeavyObject is setup to allow subclasses to generate c-code seems to be based on some specific model of interactions between Heavy_heavy and the heavyIR objects that I haven't seen the diagram for. I get which methods put code in which places, but don't really get the model that the designers were seeing.

For the time being I've added the following methods to HeavyObject so that I can put code where I want it (in the generated c files) without regard to the semantics. While this works and allows me to keep on going, it is strapped on and feels that way.

    @classmethod
    def get_C_obj_header_code(clazz, obj_type, obj_id, args):
        return []

    @classmethod
    def get_C_obj_impl_code(clazz, obj_type, obj_id, args):
        return []

    @classmethod
    def get_C_class_header_code(clazz, obj_type, obj_id, args):
        return []

    @classmethod
    def get_C_class_impl_code(clazz, obj_type, obj_id, args):
        return []

My aim is to get a deeper understanding of the lifecycle of the runtime parts and then to fix up the HeavyObject api with a coherent set of overrides that properly models the runtime dynamics of the objects but gives ultimate flexibility to the IR->C implementor to eek out efficiency/performance where ever possible.