The current method of cross-linking motion ids to line numbers is inadaequate. Consequences are:
This was acerbated by a problem in motion which let to the introduction of fake line numbers in MDI mode. As a consequence, stepping and source tracking in MDI mode was impossible, as well as some other consistency checks.
Up to now, we had a fairly simple source context:
Post-introduction we will have a source context for each command which generates a motion (basically everything which travels down the interplist).
Conceptually a unique command origin is identified by a tuple (line number, 'where did it come from').
The 'where did it come from' part is the source context. It consists of:
For ease of handling, a source context is referenced by a unique ID. The interpreter tracks source contexts, and can be queried for the current source context by id through a new method - get_source_context(), which will pass all parts needed to uniquely denote the origin of a motion command:
NML commands put on the interplist so far carried only the line_number.
Now they will also carry source type and context id in the NML_INTERP_LIST_NODE structure (the NML messages themselves remain unchanged). There is no point in tagging every NML command with the source name, and it is a bit bulky. If task needs to know about it, for instance to update emcStatus, it can query the interpreter if the source context id changed.
The cache of source contexts of the interpreter can be cleared explicitly by exexcuting interp.set_source_context(SC_CLEAR, 0, NULL). This would typically happen in task before opening a new file, or running an MDI command.
For 'highlight current line' type feedback, GUI's tracked several variables to determine 'where we are':
3) is set from 2) only if > 0, which implies 'if not in MDI mode' in the current line number logic. During MDI commands it remains 0, which stops source highlighting for MDU .
These variables are used for highlight eg here:
from emc_interface.py ca line 481 (used in touchy):
if self.emcstat.id == 0 and (self.emcstat.interp_state == self.emc.INTERP_PAUSED or self.emcstat.exec_state == self.emc.EXEC_WAITING_FOR_DELAY): self.listing.highlight_line(self.emcstat.current_line) elif self.emcstat.id == 0: self.listing.highlight_line(self.emcstat.motion_line) else: self.listing.highlight_line(self.emcstat.id or self.emcstat.motion_line)
I understand this is to mean:
Tracking the source context entails some new state variables:
Motion will have a new pin: motion.source_context_id (s32).
emcStatus will have new fields:
emcstatus.current_source_context_id (the context of the current command processed by task pulled from the interplist) emcstatus.current_source_context_type emcstatus.current_source_name
emcstatus.motion_source_context_id (as currently executed in motion) emcstatus.motion_source_context_type emcstatus.motion_source_name emcstatus.call_level (this could be used to display the call stack of source locations currently executing.)
These fields are updated within task, through interp.get_source_context(), primarily for consumption by the GUI's.
GUI's are expected to watch the *source_context_id values for changes.
A change of the *context_id means 'display the new source context', for example:
if id changed: retrieve emcstatus.*_source_name depending on logic above if *_context_type means 'a string', switch the source window to display the string (this could be multi line). if *_context_type means 'a file', switch the source window to open and display the file. highlight the line as denoted by *_line.
For now, GUI's may continue to watch current_line, motion_line and id, but will not be able to display different source contexts or the call stack.
To enable source-higliht of MDI, this implies that the negative line number handling in task needs to be removed, which impacts upon the GUIs. If one doesnt want to do the full file/string tracking thing, a small mod of the 'what should I highlight' code should be a workaround. (basically a test for source_context_type == MDI string - then dont display it).
The best place to detect a start condition for run-from-line is the interpreter itself. For this purpose, watchpoints will be used (see http://wiki.linuxcnc.org/cgi-bin/wiki.pl?WatchPoints). The interpreter will support several watchpoints, of which 2 are predefined:
The usage pattern in task is as follows: