karabo.cpp 3.0.7__tar.gz → 3.0.9__tar.gz

{karabo_cpp-3.0.7 → karabo_cpp-3.0.9}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: karabo.cpp
-Version: 3.0.7
+Version: 3.0.9
 Summary: Karabo's C++ API and Python bindings thereof
 Keywords: Karabo,SCADA,async,control system
 Author-Email: European XFEL GmbH <opensource@xfel.eu>
@@ -13,7 +13,7 @@ Project-URL: Homepage, https://github.com/European-XFEL/Karabo
 Project-URL: Bug Reports, https://github.com/European-XFEL/Karabo/issues
 Project-URL: Source, https://github.com/European-XFEL/Karabo
 Requires-Python: ==3.12.*
-Requires-Dist: karabo-native==3.0.7
+Requires-Dist: karabo-native==3.0.9
 Description-Content-Type: text/markdown
 
 # Karabo SCADA Framework - C++ API and Service Devices

{karabo_cpp-3.0.7 → karabo_cpp-3.0.9}/extern/requirements-pre.txt

@@ -5,5 +5,5 @@ wheel==0.42.0
 setuptools==69.1.1
 setuptools-scm==8.0.4
 pip==24.0
-conan==2.16.1
+conan==2.21.0
 pyyaml==6.0.1

{karabo_cpp-3.0.7 → karabo_cpp-3.0.9}/pyproject.toml

@@ -3,7 +3,7 @@ requires = ["scikit-build-core"]
 build-backend = "scikit_build_core.build"
 
 [project]
-version = "3.0.7"
+version = "3.0.9"
 name = "karabo.cpp"
 description = "Karabo's C++ API and Python bindings thereof"
 readme = "README.md"
@@ -38,7 +38,7 @@ classifiers = [
 # For an analysis of this field vs pip's requirements files see:
 # https://packaging.python.org/discussions/install-requires-vs-requirements/
 dependencies = [
-  "karabo-native==3.0.7",
+  "karabo-native==3.0.9",
   ]
 
 
@@ -126,9 +126,9 @@ manylinux-pypy_aarch64-image = "quay.io/pypa/manylinux_2_28_aarch64"
 # Additionally, openssl requires PERL to configure. We need to ensure a full
 # installation is available.
 before-all = "dnf -y install perl gettext"
-before-build = "pip3 install conan==2.19.0 && pip3 install numpy==2.0.1 && python -c 'from prepare_extern import prepare; prepare()' && /project/extern/build.sh /project/extern/build ALL"
+before-build = "pip3 install conan==2.21.0 && pip3 install numpy==2.0.1 && python -c 'from prepare_extern import prepare; prepare()' && /project/extern/build.sh /project/extern/build ALL"
 
 test-requires = ["pytest"]
 # these are minimally required for a C++ server to start
-before-test = "mkdir /karabo && mkdir /karabo/var && mkdir /karabo/var/data && mkdir /karabo/plugins && pip install karabo.native==3.0.7 --index-url 'https://gitlab-ci-token:glcbt-64_rQzK5PzG5pw-grW5ESAR@git.xfel.eu/api/v4/projects/5003/packages/pypi/simple' --extra-index-url https://pypi.org"
+before-test = "mkdir /karabo && mkdir /karabo/var && mkdir /karabo/var/data && mkdir /karabo/plugins && pip install karabo.native==3.0.9 --index-url 'https://gitlab-ci-token:glcbt-64_GbmzzsfDDNQWDakqqY2b@git.xfel.eu/api/v4/projects/5003/packages/pypi/simple' --extra-index-url https://pypi.org"
 test-command = "KARABO=/karabo KARABO_BROKER=amqp://xfel:karabo@exfl-broker-1:5672 pytest {project}/wheel_tests"

{karabo_cpp-3.0.7 → karabo_cpp-3.0.9}/pyproject.toml.template

@@ -128,7 +128,7 @@ manylinux-pypy_aarch64-image = "quay.io/pypa/manylinux_2_28_aarch64"
 # Additionally, openssl requires PERL to configure. We need to ensure a full
 # installation is available.
 before-all = "dnf -y install perl gettext"
-before-build = "pip3 install conan==2.19.0 && pip3 install numpy==2.0.1 && python -c 'from prepare_extern import prepare; prepare()' && /project/extern/build.sh /project/extern/build ALL"
+before-build = "pip3 install conan==2.21.0 && pip3 install numpy==2.0.1 && python -c 'from prepare_extern import prepare; prepare()' && /project/extern/build.sh /project/extern/build ALL"
 
 test-requires = ["pytest"]
 # these are minimally required for a C++ server to start

{karabo_cpp-3.0.7 → karabo_cpp-3.0.9}/src/karabind/PyCoreDeviceClient.cc

@@ -582,16 +582,15 @@ void exportPyCoreDeviceClient(py::module_& m) {
                           HandlerWrap<const std::string&, const Schema&>(handler, "schemaUpdate monitor"));
                 },
                 py::arg("callbackFunction"),
-                "registerSchemaUpdatedMonitor(handler): Register a callback handler \"handler\" to be "
+                "registerSchemaUpdatedMonitor(handler): Register a callback handler \"handler\" to\nbe "
                 "triggered if an instance receives a schema update from the distributed system\nThe "
                 "handler function should have the signature handler(instanceId, schema) where:\n"
                 "\"instanceId\" is a string containing name of the device which updated schema\n"
-                "\"schema\" is the updated schema\n\nNote: Currently, registering only a schema update "
-                "monitor with an instance\nof a DeviceClient is not enough to have the registered callback "
-                "activated.\nA workaround for this is to also register a property monitor with the\n"
-                "same instance of DeviceClient that has been used to register the schema\nupdate monitor.\n\n")
+                "\"schema\" is the updated schema\n\nNote: To have the handler reliably called, "
+                "for a given deviceId, one has\nto call 'registerDeviceForMonitoring(deviceId)' as well\n"
+                "(and 'unregisterDeviceFromMonitoring(deviceId)' if of no interest anymore).")
 
-          .def("registerPropertyMonitor", &DeviceClientWrap::registerPropertyMonitor, py::arg("instanceId"),
+          .def("registerPropertyMonitor", &DeviceClientWrap::registerPropertyMonitor, py::arg("deviceId"),
                py::arg("key"), py::arg("callbackFunction"))
 
           .def(
@@ -608,7 +607,7 @@ void exportPyCoreDeviceClient(py::module_& m) {
                               userData);
                     }
                 },
-                py::arg("instanceId"), py::arg("callbackFunction"), py::arg("userData") = py::none())
+                py::arg("deviceId"), py::arg("callbackFunction"), py::arg("userData") = py::none())
 
           .def(
                 "setDeviceMonitorInterval",
@@ -618,11 +617,15 @@ void exportPyCoreDeviceClient(py::module_& m) {
                 },
                 py::arg("milliseconds"))
 
-          .def("unregisterPropertyMonitor", &DeviceClientWrap::unregisterPropertyMonitor, py::arg("instanceId"),
+          .def("unregisterPropertyMonitor", &DeviceClientWrap::unregisterPropertyMonitor, py::arg("deviceId"),
                py::arg("key"))
 
           .def("unregisterDeviceMonitor", &DeviceClientWrap::unregisterDeviceMonitor, py::arg("instanceId"))
 
+          .def("registerDeviceForMonitoring", &DeviceClient::registerDeviceForMonitoring, py::arg("deviceId"))
+
+          .def("unregisterDeviceFromMonitoring", &DeviceClient::unregisterDeviceFromMonitoring, py::arg("deviceId"))
+
           .def(
                 "registerChannelMonitor",
                 [](const DeviceClientWrap::Pointer& self, const std::string& channelName, const py::object& dataHandler,

{karabo_cpp-3.0.7 → karabo_cpp-3.0.9}/src/karabo/CMakeLists.txt

@@ -66,10 +66,10 @@ endif()
 # Extracts KARABO_VERSION from the appropriate Git tag, writes to
 # a file to be used by the Karabo Framework at build time.
 message(STATUS "Resolving Karabo Version from Git repository")
-set(KARABO_VERSION "3.0.7")
+set(KARABO_VERSION "3.0.9")
 set(KARABO_VERSION_MAJOR "3")
 set(KARABO_VERSION_MINOR "0")
-set(KARABO_VERSION_PATCH "7")
+set(KARABO_VERSION_PATCH "9")
 message(STATUS "Karabo Version: ${KARABO_VERSION}")
 message(STATUS "Karabo Version Major: ${KARABO_VERSION_MAJOR}")
 message(STATUS "Karabo Version Minor: ${KARABO_VERSION_MINOR}")

{karabo_cpp-3.0.7 → karabo_cpp-3.0.9}/src/karabo/core/DeviceClient.cc

@@ -1800,8 +1800,8 @@ namespace karabo {
                 if (hash.has("doNotCompressEvents")) {
                     // magic: if the hash contains a change for the expected parameter "doNotCompressElements
                     // we are sending it directly, no throttling.
-                    // Note: Since we updated m_runtimeSystemDescription above, there is no problem if a previous
-                    // time: the next "flushing"  of m_runtimeSystemDescription will send the new value again.
+                    // Note: Since we updated m_runtimeSystemDescription above, there is no problem if the next
+                    // "flushing" of m_runtimeSystemDescription will send the new value again.
                     std::lock_guard<std::mutex> lock(m_devicesChangesMutex);
                     if (m_devicesChangesHandler) {
                         Hash deviceChanges(instanceId, hash);
@@ -1819,18 +1819,20 @@ namespace karabo {
                         std::lock_guard<std::mutex> lock(m_devicesChangesMutex);
                         if (m_devicesChangesHandler) m_devicesChangesHandler(statusChange);
                     }
-                    std::lock_guard<std::mutex> lock(m_signalsChangedMutex);
-                    // Just book keep paths here and call 'notifyDeviceChangedMonitors'
-                    // later with content from m_runtimeSystemDescription.
-                    // Note:
-                    // If there is path "a.b" coming, should we erase possible previous changes to daughters like
-                    // "a.b.c.d"? No - that should better be handled in merging into m_runtimeSystemDescription above
-                    // and then the invalid path "a.b.c.d" should be ignored 'downstream' when sending.
-                    std::set<std::string>& updatedPaths = m_signalsChanged[instanceId];
-                    hash.getPaths(updatedPaths); // extend by new updates
-
-                    // Do not send the same status update again later
-                    if (directlyForwardStatus) updatedPaths.erase(statusNode->getKey());
+                    if (!directlyForwardStatus || hash.size() > 1) { // Anything to throttle?
+                        std::lock_guard<std::mutex> lock(m_signalsChangedMutex);
+                        // Just book keep paths here and call 'notifyDeviceChangedMonitors'
+                        // later with content from m_runtimeSystemDescription.
+                        // Note:
+                        // If there is path "a.b" coming, should we erase possible previous changes to daughters like
+                        // "a.b.c.d"? No - that should better be handled in merging into m_runtimeSystemDescription
+                        // above and then the invalid path "a.b.c.d" should be ignored 'downstream' when sending.
+                        std::set<std::string>& updatedPaths = m_signalsChanged[instanceId];
+                        hash.getPaths(updatedPaths); // extend by new updates
+
+                        // Do not send the same status update again later
+                        if (directlyForwardStatus) updatedPaths.erase(statusNode->getKey());
+                    }
                 }
             } else {
                 // There is a tiny (!) risk here: The last loop of the corresponding thread
@@ -2099,6 +2101,10 @@ namespace karabo {
                  mapIt != mapEnd; ++mapIt) {
                 const std::string& instanceId = mapIt->first;
                 const std::set<std::string>& properties = mapIt->second;
+                if (properties.empty()) { // Shouldn't happen...
+                    KARABO_LOGGING_WARN("Trying to send throttled empty updates for '{}'", instanceId);
+                    continue; // merge(..) below would merge full device config into allUpdates!
+                }
                 // Get path of instance in runtime system description and then its configuration
                 const std::string path(this->findInstanceSafe(instanceId));
                 const data::Hash config(this->getSectionFromRuntimeDescription(path + ".configuration"));

{karabo_cpp-3.0.7 → karabo_cpp-3.0.9}/src/karabo/core/DeviceClient.hh

@@ -982,7 +982,7 @@ namespace karabo {
                   const std::function<void(const std::string&, const karabo::data::Hash&)>& callbackFunction);
 
             /**
-             * Registers a device to have its configurations changes monitored.
+             * Registers a device to have its configuration or schema changes monitored.
              *
              * @param deviceId of the device to be added to the set of monitored devices.
              *

{karabo_cpp-3.0.7 → karabo_cpp-3.0.9}/src/karabo/devices/PropertyTest.cc

@@ -1174,7 +1174,11 @@ namespace karabo {
 
 
         void PropertyTest::slotUpdateStatus(const std::string& status, int intProperty) {
-            set(Hash("status", status, "int32PropertyReadOnly", intProperty));
+            Hash update("status", status);
+            if (intProperty >= 0) {
+                update.set("int32PropertyReadOnly", intProperty);
+            }
+            set(update);
         }
 
 

{karabo_cpp-3.0.7 → karabo_cpp-3.0.9}/src/karabo/tests/core/DeviceClient_Test.cc

@@ -484,7 +484,7 @@ void DeviceClient_Test::testDeviceConfigurationsHandler() {
     for (size_t i = 0; i < numStatusUpdates; ++i) {
         const std::string status("Status " + toString(i));
         CPPUNIT_ASSERT_NO_THROW(
-              m_deviceClient->execute(devId, "slotUpdateStatus", KRB_TEST_MAX_TIMEOUT, status, int(i)));
+              m_deviceClient->execute(devId, "slotUpdateStatus", KRB_TEST_MAX_TIMEOUT, status, static_cast<int>(i)));
     }
     // Since execute is synchronous, all signal updates directly triggered by it have returned
     // to the client and that one has called our handler. But the simultaneous update of
@@ -501,18 +501,20 @@ void DeviceClient_Test::testDeviceConfigurationsHandler() {
     size_t numStatus = 0, numInt32 = 0;
     for (size_t i = 0; i < updates.size(); ++i) {
         const karabo::data::Hash& update = updates[i];
+        const std::string msg((toString(i) += ": ") += toString(update));
+        CPPUNIT_ASSERT_MESSAGE(msg, !update.has("deviceId"));
         if (update.has("status")) {
             // It is throttled, no other keys!
-            CPPUNIT_ASSERT_MESSAGE(toString(update), !update.has("int32PropertyReadOnly"));
+            CPPUNIT_ASSERT_MESSAGE(msg, !update.has("int32PropertyReadOnly"));
 
             const bool hasTimeAttrs = Timestamp::hashAttributesContainTimeInformation(update.getAttributes("status"));
-            CPPUNIT_ASSERT_MESSAGE(toString(update), hasTimeAttrs);
+            CPPUNIT_ASSERT_MESSAGE(msg, hasTimeAttrs);
             ++numStatus;
         } else if (update.has("int32PropertyReadOnly")) {
             lastInt32 = update.get<int>("int32PropertyReadOnly");
             ++numInt32;
         } else { // nothing else expected
-            CPPUNIT_ASSERT_MESSAGE(toString(update), false);
+            CPPUNIT_ASSERT_MESSAGE(msg, false);
         }
     }
     // Are all status updates received?
@@ -522,6 +524,42 @@ void DeviceClient_Test::testDeviceConfigurationsHandler() {
     // Some throttling should have taken place (can we be 100% sure?)
     CPPUNIT_ASSERT_LESS(numStatusUpdates, numInt32);
 
+    // Now check that a single "status" update does not trigger any additional handler call
+    // (as was still in 3.0.7...)
+    auto statusPromise = std::make_shared<std::promise<void>>();
+    auto statusFut = statusPromise->get_future();
+    auto lastCommandPromise = std::make_shared<std::promise<void>>();
+    auto lastCommandFut = lastCommandPromise->get_future();
+    updates.clear();
+    auto newHandler = [&updates, devId, statusPromise, lastCommandPromise](const Hash& changes) {
+        if (changes.has(devId)) {
+            const karabo::data::Hash& devUpdate = changes.get<Hash>(devId);
+            updates.push_back(devUpdate);
+            if (devUpdate.has("status")) {
+                statusPromise->set_value();
+            } else if (devUpdate.has("lastCommand")) {
+                lastCommandPromise->set_value();
+            }
+        }
+    };
+    m_deviceClient->registerDevicesMonitor(newHandler);
+    // -1: Only update "status"
+    CPPUNIT_ASSERT_NO_THROW(
+          m_deviceClient->execute(devId, "slotUpdateStatus", KRB_TEST_MAX_TIMEOUT, "A status update", -1));
+    result = statusFut.wait_for(std::chrono::seconds{KRB_TEST_MAX_TIMEOUT});
+    CPPUNIT_ASSERT_EQUAL(std::future_status::ready, result);
+    statusFut.get();
+    CPPUNIT_ASSERT_NO_THROW(m_deviceClient->execute(devId, "slotResetSchema", KRB_TEST_MAX_TIMEOUT));
+    result = lastCommandFut.wait_for(std::chrono::seconds{KRB_TEST_MAX_TIMEOUT});
+    CPPUNIT_ASSERT_EQUAL(std::future_status::ready, result);
+    lastCommandFut.get();
+    // Two updates: "status" and "lastCommand" (triggered by call of schema slot) and nothing else
+    CPPUNIT_ASSERT_EQUAL_MESSAGE(toString(updates), 2ul, updates.size());
+    CPPUNIT_ASSERT_EQUAL_MESSAGE(toString(updates[0]), 1ul, updates[0].size());
+    CPPUNIT_ASSERT_MESSAGE(toString(updates[0]), updates[0].has("status"));
+    CPPUNIT_ASSERT_EQUAL_MESSAGE(toString(updates[1]), 1ul, updates[1].size());
+    CPPUNIT_ASSERT_MESSAGE(toString(updates[1]), updates[1].has("lastCommand"));
+
     // Reset again
     m_deviceClient->setDeviceMonitorInterval(-1);
     m_deviceClient->registerDevicesMonitor([](const karabo::data::Hash&) {}); // not reset, but now no-op...