Skip to content

Remove the parameter queue and use the write_pending flag instead #237

Open
Guzz-T wants to merge 4 commits intoBouni:mainfrom
Guzz-T:issue/221/remove-queue
Open

Remove the parameter queue and use the write_pending flag instead #237
Guzz-T wants to merge 4 commits intoBouni:mainfrom
Guzz-T:issue/221/remove-queue

Conversation

@Guzz-T
Copy link
Contributor

@Guzz-T Guzz-T commented Feb 5, 2026

With these changes, the data to be written is stored directly in the field object, so that the values can also be set directly in the field via value.

This is indirectly a breaking change, as the value of the field changes when set() is called. This was not the case before. @Bouni, was there a specific reason why it was implemented this way?

Previously:

parameters.get(2)        >> 1°C
parameters.set(2, 2) 
parameters.get(2)        >> 1°C

Now:

p2 = parameters.get(2)   >> 1°C
parameters.set(2, 2)
parameters.get(2)        >> 2°C
p2.value = 3
p2                       >> 3°C                        

Relates to #221

With these changes, the data to be written is stored directly in the field object, so that the values can also be set directly in the field via `value`.
@github-actions
Copy link

github-actions bot commented Feb 5, 2026

Coverage

Coverage Report
FileStmtsMissCoverMissing
luxtronik
   __main__.py25250%3–66
   collections.py125199%304
   datatypes.py412299%61, 133
   discover.py58198%63
luxtronik/cfi
   interface.py1681392%80–93, 243–244, 249
luxtronik/definitions
   __init__.py237199%172
luxtronik/scripts
   __init__.py35586%7–16, 51
   discover_shi.py60600%8–98
   dump_cfi.py14657%18–25, 29
   dump_shi.py15660%21–28, 32
   performance_shi.py63630%7–89
   update_screen.py1058222%6, 20–41, 46–48, 51–61, 64, 70–75, 78, 81–85, 88–92, 95–97, 100–103, 106–111, 115–116, 119–126, 129–136
   watch_cfi.py321650%36–47, 50–56, 60
   watch_shi.py331652%38–49, 52–58, 62
luxtronik/shi
   contiguous.py121298%224–225
TOTAL243929988% 

Tests Skipped Failures Errors Time
381 0 💤 0 ❌ 0 🔥 35.728s ⏱️

parameters.queue = {}
for index, field in parameters.data.items():
if field.write_pending:
field.write_pending = False
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be set to False even though nothing has been written at this point? The code could still fail in the next couple of lines? Just wondering if it makes more sense to set it to false after the value has been written and/or read back?

Copy link
Contributor Author

@Guzz-T Guzz-T Feb 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When assigning a value to raw, the write_pending flag is reseted.

Copy link
Contributor Author

@Guzz-T Guzz-T Feb 16, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would have first avoided a situation where a error during writing would lead to recurring errors. This most closely resembles the previous behavior, wherever the queue was cleared.

I am also considering whether to offer user-adjustable settings, which would allow the behavior to be configured.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants