The pyvcp test suffers from a timing issue on machines that are slow or very busy. The output below was seen from two runs, both with rip-and-test-clang. The problem is that the mypanel component is a loadusr -Wn mypanel pyvcp -c mypanel test.xml command that is spawned by halcmd. In turn, halcmd will complain with "Waiting for component..." when the spawned process is not producing a component within "some" time.
When the user component is running, then the output is correct. However, the test fails because halcmd added a line of output. The three extra dots at the end of the line means that the command took at least 2.3 seconds to produce a ready component (probably more if the CI machine was really busy).
In principle, all tests relying on a component to appear (quickly) and use the output in the test will suffer from the same problem. The output changes when the machine is slow. And, boy, has the github CI been jittery lately...
Running test: /home/runner/work/linuxcnc/linuxcnc/tests/pyvcp
--- /home/runner/work/linuxcnc/linuxcnc/tests/pyvcp/expected 2026-07-29 14:51:45.923218748 +0000
+++ /home/runner/work/linuxcnc/linuxcnc/tests/pyvcp/result 2026-07-29 15:02:24.467199329 +0000
@@ -1,3 +1,4 @@
+Waiting for component 'mypanel' to become ready....
mypanel float OUT 0 mypanel.dial-a-out
mypanel float OUT 0 mypanel.dial-b-out
mypanel float IN 0 mypanel.dial-c-in
*** /home/runner/work/linuxcnc/linuxcnc/tests/pyvcp: XFAIL: result differed from expected
************** result:
Waiting for component 'mypanel' to become ready....
mypanel float OUT 0 mypanel.dial-a-out
mypanel float OUT 0 mypanel.dial-b-out
mypanel float IN 0 mypanel.dial-c-in
mypanel float OUT 0 mypanel.dial-c-out
mypanel float OUT 0 mypanel.dial.0.out
mypanel float IN 0 mypanel.dial.0.param_pin
mypanel float IN 0 mypanel.dial.1.param_pin
mypanel float IN 0 mypanel.dial.2.param_pin
mypanel float OUT 0 mypanel.scale-a-out-f
mypanel s32 OUT 0 mypanel.scale-a-out-i
mypanel float OUT 0 mypanel.scale-b-out-f
mypanel s32 OUT 0 mypanel.scale-b-out-i
mypanel float IN 0 mypanel.scale-c-in
mypanel float OUT 0 mypanel.scale-c-out-f
mypanel s32 OUT 0 mypanel.scale-c-out-i
mypanel float OUT 0 mypanel.scale.0-f
mypanel s32 OUT 0 mypanel.scale.0-i
mypanel float IN 0 mypanel.scale.2.param_pin
mypanel float OUT 0 mypanel.spinbox-a-out
mypanel float OUT 0 mypanel.spinbox-b-out
mypanel float IN 0 mypanel.spinbox-c-in
mypanel float OUT 0 mypanel.spinbox-c-out
mypanel float OUT 0 mypanel.spinbox.0
mypanel float IN 0 mypanel.spinbox.2.param_pin
************** stderr:
+ set -e
+ xvfb-run halrun -s do-test.hal
+ sed -i '/mypanel/!d' result
+ exit 0
**************
The pyvcp test suffers from a timing issue on machines that are slow or very busy. The output below was seen from two runs, both with rip-and-test-clang. The problem is that the
mypanelcomponent is aloadusr -Wn mypanel pyvcp -c mypanel test.xmlcommand that is spawned by halcmd. In turn, halcmd will complain with "Waiting for component..." when the spawned process is not producing a component within "some" time.When the user component is running, then the output is correct. However, the test fails because halcmd added a line of output. The three extra dots at the end of the line means that the command took at least 2.3 seconds to produce a ready component (probably more if the CI machine was really busy).
In principle, all tests relying on a component to appear (quickly) and use the output in the test will suffer from the same problem. The output changes when the machine is slow. And, boy, has the github CI been jittery lately...