Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
This class member is a way for dialin to present all the valve states in a list like so: >>> fp = FP() >>> fp.valves.valve_states_enum [0, 0, 0, 0, 0, 0, 0] It is organized in the order of the e...

This class member is a way for dialin to present all the valve states in a list like so:

>>> fp = FP()
>>> fp.valves.valve_states_enum
[0, 0, 0, 0, 0, 0, 0]


It is organized in the order of the enum that was used to iterate. This is purely for presentation / Quality of life feature for the dialin user. We can remove it if we know users are no longer using it for monitoring

Can you review this with Michael G and find out if this is even needed? Can we remove? If not, what is it doing and why?

Can you review this with Michael G and find out if this is even needed? Can we remove? If not, what is it doing and why?

I see it as a list, don't know why it is named enum or what the original purpose of it was. It was never updated, so I added the update part at least, so it will at least reflect the current states...

I see it as a list, don't know why it is named enum or what the original purpose of it was.
It was never updated, so I added the update part at least, so it will at least reflect the current states instead of always stating zeros.

I don't think it's an enum at all. It was a list, but it was never updated, so I added that part to it.

I don't think it's an enum at all. It was a list, but it was never updated, so I added that part to it.

Is this a dynamic enum?

Is this a dynamic enum?

What is happening here? Is this a dynamic enum? Where is it used?

What is happening here? Is this a dynamic enum? Where is it used?

LEAHI-DIALIN-LDT-2994_IOFP valve data is inaccurate
LEAHI-DIALIN-LDT-2994_IOFP valve data is inaccurate
- fixed valve_state_enums to be updated - Fixed balancing chamber broadcast processing

  1. … 2 more files in changeset.
-Fixed valve broadcast update - Fixed Beta 1.0 enums

  1. … 2 more files in changeset.
Merge branch 'LDT-3214-override-refactor' into staging

  1. … 46 more files in changeset.
I added the unique decorator back, except for the few that have aliases

I added the unique decorator back, except for the few that have aliases

Renamed, also flagged for future type change.

Renamed, also flagged for future type change.

"No one should interact with it or be aware of it's existence, so the name shouldn't matter." *it matters to those who read the code in inconsistent intervals ( like those who participate in code...

"No one should interact with it or be aware of it's existence, so the name shouldn't matter."

  • it matters to those who read the code in inconsistent intervals ( like those who participate in code review or teaching ).


"As we only have 2 version in test at the same time."

  • Currently. By summer, i'd expect dialin to be considering 1.0's, 1.9s, and 2.0s/DVTs.


We have the choice to handle the redesign effort then or now.


Edit:
Follow up comment.

Looking at the other files. Users of dialin will not be aware of existence, but developers of dialin will as it impacts the behavior of overrides like temp & pressure.

yes. that's the design consideration. Are we okay with our unit tests no longer checking for duplicate values? ( they will currently pass as i remember they expect an exception due to the unique ke...

yes. that's the design consideration. Are we okay with our unit tests no longer checking for duplicate values? ( they will currently pass as i remember they expect an exception due to the unique keyword to fail. These will not trigger an exception ).

I am not sure I can assign unique to the dynamic enums. Also with unique you can't add aliases and some(for example: temperature) overrides use the aliases to determine which msg id to call and how...

I am not sure I can assign unique to the dynamic enums. Also with unique you can't add aliases and some(for example: temperature) overrides use the aliases to determine which msg id to call and how much to shift value for it.
Making an alias is more dynamic and not needing separate variables to be maintained for this.

Enum content of Beta 1.0 and Beta 1.9 is different. The new sensors messing up the order for the old HW's override and broadcast data allocation. Making it dynamic makes it that when the beta test ...

Enum content of Beta 1.0 and Beta 1.9 is different. The new sensors messing up the order for the old HW's override and broadcast data allocation.
Making it dynamic makes it that when the beta test config is called the enums are switching content to reflect that.

Reasons: *No one should interact with it or be aware of it's existence, so the name shouldn't matter. *As we only have 2 version in test at the same time, I am making an internal variable name th...

Reasons:

  • No one should interact with it or be aware of it's existence, so the name shouldn't matter.
  • As we only have 2 version in test at the same time, I am making an internal variable name that I don't need to rename every 3 months or so.
    Needing to make a review smaller with editing less thing makes it faster to be completed...


In case a situation arrives when we will test more version at the same time Alpha, Beta, Beta 1.9, it will require a redesign on the part of enum generation too.