callLevel will be non-zero if executing a subroutine. When subroutines are
executing, EMC_TASK_STAT::file gets set to the file name of the subroutine
(remap as well I think).
Exporting the call level in the task status allows us to ignore file name
changes in hal_glib and avoid sending bogus signals to things
such as hal_gremlin and hal_sourceview.
Signed-off-by: Moses McKnight <moses@texband.net>
if interpreter is reading or waiting, the new file
is a remap procedure, with the following test we
do avoid that a signal is emitted in that case, causing
a reload of the preview and sourceview widgets
ToDo : Find a way to avoid signal when the line changed due to
a remap procedure, because the signal do highlight a wrong
line in the code
Signed-off-by: Norbert Schechner <nieson@web.de>
the signals were inconsistant (order) at start up.
makes more sence to just emit when there is an actual change of
state rather then also at initialization.
The state of things is pretty easy to assume at start-up and can be
checked inside a program.
this includes the main script, some of the GUIs, the Python module,
the Tcl package, some image fies.
On a sim system, axis, tkemc, xemc all start. runtests pass.
a system with realtime wasn't yet tested.
packaging probably requires additional changes and was not yet tested.
GPin provides GObject interface to HAL Pin. Currently it provides
'value-changed' signal which is emitted when pin's value is changed.
On GPin creation update callback is scheduled for each 100ms.
