filtration_purification.py

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Merge branch 'LDT-3214-override-refactor' into staging

  1. … 46 more files in changeset.
Merge branch 'LDT-3159-getter_for_fp_defeatured' into staging

  1. … 1 more file in changeset.
Renamed

Renamed

Moved it into login request

Moved it into login request

- Renamed command - Moved command from init to log in (as login is neccessary for it)

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.

This will always return 0 and delay init from completing by up to 0.5s as the user is not logged in at the time of init.

This will always return 0 and delay init from completing by up to 0.5s as the user is not logged in at the time of init.

The naming of this method is misleading as it sends the message to request defeatured status and it is retrieved in a separate callback. The 'get' implies that the value returned from this method i...

The naming of this method is misleading as it sends the message to request defeatured status and it is retrieved in a separate callback. The 'get' implies that the value returned from this method is the defeatured status. The value returned is not the defeatured status but rather a T/F condition on if the FW replied back to dialin successfully.

suggestion: cmd_request_defeatured_status()

"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 ).

That's how it's called in the FW, I just copied it. But yes, I suspect the Def is short for defeatured.

That's how it's called in the FW, I just copied it.
But yes, I suspect the Def is short for defeatured.

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.

previously we had the unique keyword above our classes as a developer sanity check to ensure the dev didnt duplicate values in the dict since we dont auto generate this defs. if i remember correct...

previously we had the unique keyword above our classes as a developer sanity check to ensure the dev didnt duplicate values in the dict since we dont auto generate this defs.

if i remember correctly, unique is checked when the enum class is imported. We test it our unit tests, both test_constructors and test_imports.

The reason we currently would want to keep unique is because the DialinEnum class has the method has_value(). Without knowing the current usage of this function from our users, it will impact users expected behavior.

My question to you: Should we continue to test and check how the defs for duplicates?

This should be renamed to be more concise and allow flexibility as more HW revisions come. What is next gen? All BETAs? BETA 1.9? Beta 2.0? DVT?

This should be renamed to be more concise and allow flexibility as more HW revisions come. What is next gen? All BETAs? BETA 1.9? Beta 2.0? DVT?

What is the intention of making our defs dynamic and a class object rather keeping it a class?

What is the intention of making our defs dynamic and a class object rather keeping it a class?

Based on it's code, doesn't look like it. That's why I removed the publish to not mislead.

Based on it's code, doesn't look like it. That's why I removed the publish to not mislead.