- Mar 12, 2025
-
-
Jens Georg authored
-
Jens Georg authored
-
- Feb 14, 2025
-
-
Martin Killenberg authored
-
- Feb 04, 2025
-
-
Martin Christoph Hierholzer authored
-
- Jan 30, 2025
-
-
Martin Christoph Hierholzer authored
-
- Jan 22, 2025
-
-
Martin Christoph Hierholzer authored
-
- Dec 06, 2024
-
-
Martin Christoph Hierholzer authored
When terminating the application while poll-type inputs are waiting for initial values from other ApplicationModules, we need to interrupt() those blocking initial-value reads. This requires a corresponding change in DeviceAccess to allow calling interrupt() without wait_for_new_data.
-
- Nov 28, 2024
-
-
Martin Christoph Hierholzer authored
-
- Oct 16, 2024
-
- Oct 15, 2024
-
-
vaeng authored
Closes #379
-
- Oct 14, 2024
-
-
Martin Christoph Hierholzer authored
-
- Oct 04, 2024
-
-
Martin Christoph Hierholzer authored
We were holding an std::vector of an incomplete type (VariableNetworkNode) in a struct (ProcessVariableProperties), which is not allowed. This fix changes it into an std::vector of shared_ptrs. Since we are exposing this vector via ProcessVariableProxy::getNodes(), this presents a breaking API change. Since this is used mostly internally, this should not break much.
-
Martin Christoph Hierholzer authored
-
Martin Christoph Hierholzer authored
-
-
- Sep 27, 2024
-
-
- Sep 24, 2024
-
-
Jens Georg authored
-
Jens Georg authored
Fixes #7879
-
- Aug 27, 2024
-
-
Martin Christoph Hierholzer authored
-
- Aug 26, 2024
-
-
Martin Christoph Hierholzer authored
-
Martin Christoph Hierholzer authored
-
Martin Christoph Hierholzer authored
The fix in the DeviceManager is more like a work-around for a false positive of gcc 13.
-
- Aug 13, 2024
-
-
* most useful with StatusOutputs, where automatic propagation of 'data invalid' status is often not wanted * Change default behavior of StatusOutput and StatusWithMessage. By default, they no longer propagate DataValidity=invalid of owning module. They still propage DataValidity=invalid of explicitly set for the output. * Adapt test of DataValidity propagation for StatusOutput * Adapt test of StatusMonitor to new StatusOutput behaviour
-
"!sometag" is a negated tag which annihilates with "sometag" negated tags can be added like normal tags, and are used to remove their counterparts
-
- Aug 08, 2024
-
-
Martin Killenberg authored
-
- Jul 19, 2024
-
-
Martin Christoph Hierholzer authored
-
Martin Christoph Hierholzer authored
boost::thread::id seems not to be trivially copyable for the old boost version, so we implement our own atomic access with a lock here.
-
- Jul 16, 2024
-
-
Martin Christoph Hierholzer authored
-
- May 30, 2024
-
-
CircularDependencyDetector was running into infinite recursion (causing stack overflow) in a situation of two Modules which are both waiting on each other for initial values
-
- May 15, 2024
-
-
Martin Christoph Hierholzer authored
-
Martin Christoph Hierholzer authored
-
- May 02, 2024
-
-
Martin Christoph Hierholzer authored
-
- Mar 15, 2024
-
-
Jens Georg authored
* fix: Ignore data validity through return channels * chore: Minor linter fixes
-
- Feb 01, 2024
-
-
Martin Christoph Hierholzer authored
-
- Jan 22, 2024
-
-
Jens Georg authored
* fix: Do not modify model while iterating in XML generator * fix: Change XML generator for TriggerReceivers Give it a chance to comply with the XSD we provide * fix: Update XML output XSD for changed output - Add Void and Boolean - Add TriggerReciever - Make class optional * chore: Update test for XML generator Add a DeviceModule whose absence was causing the XML generator to fail unnoticed
-
- Jan 16, 2024
-
-
Martin Christoph Hierholzer authored
-
- Jan 15, 2024
-
-
Martin Christoph Hierholzer authored
Modifying the model while visiting is not allowed because the modification invalidates the iterators used for visiting. This lead in this case to a very subtle crash (segfault) only appearing under very specific circumstances (only when running in ctest and only on some Ubuntu 20.04 machines).
-
Martin Christoph Hierholzer authored
ProcessVariableProxy::removeNode() was effectively taking a reference to a shared pointer as an argument and is removing the same (effective) shared pointer from a list. This poses a problem if the reference passed points to the list directly and is the last shared pointer to this object so it gets freed, because removeNode() is accessing the object after removing it from the list.
-
- Jan 03, 2024
-
-
Martin Christoph Hierholzer authored
-
- Nov 23, 2023
-