Use an iterative method for expanding commands now #90
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This merge request switches the methods "expand, buildByteCode and compileCommand" to using an iterative approach. I understand that the recursive approach used so far, looks more elegant at first glance. But it can give problems in the form of segfaults (see background story below) when trying to parse and process a large number of commands from a config file.
Switching to an iterative method introduces the "*All" wrapper methods to the source base (not so nice), but makes the overall process of parsing commands more robust (very nice).
Background: I'm currently starting to use vcontrold/vclient for monitoring and controlling my Vitodens200 (WBC2). Since I still don't know a few of the memory addresses, I wrote a Python script that can generate a "special"
vito.xml
. In thisvito.xml
I will define a single command "getVitoXXXX" for each address in a configurable range (seecreate_shell.py
andcreate_vito.py
in "scripts" folder of https://github.com/dirkbaechle/pyvctrl ). By checking all memory addresses before and after I changed the wanted values at the Vitodens200 directly, I can then do a simple diff to find the memory addresses by brute-force. When starting thevcontrold
daemon with avito.xml
file for the addresses 0x2000-0x4000 (yes, that's a lot) the process crashes on my mini laptop (Samsung EE PC, 32bit, 2GB RAM, Linux Mint 19.3).With the code from this branch
vcontrold
is running fine...