I'm really thinking aloud here - I'd be grateful for opionions nevertheless.
I'm puzzled at how line number is set on interplist nodes - I find 2 methods: 1. coming down from the interpreter as a canon/queuedcanon call parameter: - in canon in: STRAIGHT_TRAVERSE RIGID_TAP STRAIGHT_PROBE UNLOCK_ROTARY ARC_FEED - in queuedcanon in: enqueue_STRAIGHT_FEED enqueue_STRAIGHT_TRAVERSE enqueue_ARC_FEED 2. set by task, which calls interp.line() to and sets the line in interpl.set_line_number(), plus emcStatus->task.readLine - this is the way how all other NML messages obtain their linenumber (1) seems logical - the interpreter always knows the current location (2) worked as long as execution followed the 'read a line/execute a line' pattern, even if the source name, type etc isnt passed along when calling oword procedures. This strikes me as odd design - it assumes that task somehow is in the know when a line number changes, and that knowledge isnt really task's business; it goes wrong as soon as the 'read a line/execute a line, and then the line number changes' assumption is violated; in the very minimum it is violated by python glue code, and there's the chance that stale location information is queued. Also, the negative pseudoMdiLinenumber introduces a numbering scheme which is incompatible with the interpreters internal view. Actually its a wonder the whole thing lasted that long. -- IMO it would be cleaner to retrieve that information at the point of use - namely whenever an interplist node is appended, the interpl code would *call back* into the current interp (method interp.line() or whatever it eventually will be) to set location. I'd use the same method for the canon and queuedcanon commands in (1). The upside is that avoids a gazillion of new canon call parameter just to pass location. Then task could just retrieve linenumber/location from the interpl when the next NML command is fetched, and mirror that in emcStatus->task.readLine and friends. Single source of information and no chance on a missed update. It's dawning on me that the right place to manage source contexts (filenames, MDI strings etc) and their id's is also the interpl code - that's where everything has to go through. -- what I'll do to as a first step to validate the approach: - add a canon, and queuedcanon callback into the interp to retrieve location; with some extra care to obtain the right information in the queuedcanon case - same in the interplist code - drop the set_line_number() use from task and exclusively *consume* that information from the interplist, - the only authoritative source of location information will be the interpreter. That means pseudoMdiLinenumber will vanish too. and see how far I come. Actually. the strict oword checking code then can come back in too: http://git.linuxcnc.org/gitweb?p=emc2.git;a=commit;h=73dcf03ed13064416219f2eff7150bb683e53530 . -Michael ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
