ezmsg-org / ezmsg

Pure-Python DAG-based high-performance SHM-backed pub-sub and multi-processing pattern
https://ezmsg.readthedocs.io/en/latest/
MIT License
9 stars 4 forks source link

Typo in ezmsg_generator.py #111

Closed John3927 closed 2 months ago

John3927 commented 2 months ago

Hi, I was running ezmsg_generator.py and realized a typo

        def network(self):
            return (
                (self.SEND.OUTPUT, self.POW_3.INPUT),
                (self.SEND.OUTPUT, self.LOG_IN.INPUT),
                (self.POW_3.OUTPUT, self.ADD_12.INPUT),
                (self.ADD_12.OUTPUT, self.POW_0_5.OUTPUT),  # here
                (self.POW_0_5.OUTPUT, self.LOG_OUT.INPUT),
            )

The POW_0_5.OUTPUT really should be an input.

I hope this helps!

cboulay commented 2 months ago

Hi,

You are correct. Would you like to create a PR or would you prefer one of us to do it? Also, this will be updated in the dev branch immediately, but it won't go into the main branch until the next release.

Thanks!

John3927 commented 2 months ago

You guys can do it. Thanks!

griffinmilsap commented 2 months ago

Thanks for the report, @John3927! This issue has bit me a few times and there's not really a warning for it. The reason there's not a great warning for it stems from #11; it is currently reasonable to connect an OutputStream of a Component to an OutputStream of a Collection. There's currently a one-to-one correspondence of OutputStream to Publisher with respect to Units but when we use OutputStreams in collections, they're .. not really associated with a Publisher in the backend, and OutputStream specific keyword arguments are simply ignored (things like force_tcp, etc).

Depending on how we fix #11 would allow us to change the definition of ez.NetworkDefinition to disallow connecting OutputStreams to OutputStreams and we could catch stuff like this in linting (which would be a huge quality of life enhancement)

Thanks for the report!