Ken, yes, "Run-from-Line" is a misnomer. It really should be named "run and dont output any canon commands until you get here", but then that's not very comprehensible.
My example with the 'run from some line in a subroutine' maybe was a bit non-obvious. The point was: the RFL-decision (useful) is made at the wrong place (not useful), and that is because the control scheme has outlived its usefulness: The original assumption was: - you have a linear sequence of G-code commands in a file - since there are no control structures, you can tell the interpreter 'read the next line, execute the next line', something predictable will happen, the line number advances by one, and task can deduce the state of the interpreter somehow. Now the interpreter execution internals have advanced considerably: you added control structures, I added remapping on top. So the "read/execute/I know where things are"-assumption just doesnt hold any more, but the control scheme in task has not advanced in parallel. That gave rise to some very murky code for instance for MDI and oword calls, and it made the remapping code way more complex than it need have been. The solution to this issue IMO is to drop the 'read a line/execute a line/guess the state' scheme in task, and switch to a model where the interpreter just tells what it needs when it reaches a certain point, instead of task trying to be all clever and deduce what to do next. This could look roughly look like so: - Interp becomes a separate thread. - the Interp read() and execute() methods become private. - commands are fed through a queue of files, or MDI commands, which the interpreter fetches and executes in turn. - the interpreter keeps executing a file, or MDI command, on its own, even if it several lines, subs etc - the read/execute loops moves into interp. - when the interpreter determines 'intervention required' it signals that via an IPC mechanism (eg condition variable) telling what's required, and goes to sleep. - 'Intervention required' could be for instance: -- 'I reached queuebuster. Sync me when you get here and tell me to continue when done.' -- 'I reached a breakpoint, tell me when it's ok to go ahead', for instance when stepping 'lines', or RFL. The source of interp state would be the interpreter itself, not task trying to guess. The input and canon queues need locking but other things become more simple, like readahead basically comes for free, and some of the bizarre flows in the interpreter suddenly become very simple and linear. Aborting a run needs some thought. In the stepping/RFL context this means: stepping decisions should be made in the interpreter, not post factum by staring at the canon queue. The watchpoint code is an attempt to move that intelligence into the interpreter, but barring the change of the execution model as I laid out above, it will be a half-baked thing. I'll respond to the state-rollback idea in separate mail, because its a different them but I think that would be great to have at least a viable approach laid out, even if nobody did it right away. - Michael Am 11.04.2012 um 14:44 schrieb Kenneth Lerman: > Thank you for working on this. I think the hard part will be making > run-from-line bullet-proof. > > It is not clear what it means to run from a location in a subroutine. It > *could* mean something like run from a particular line with the calling > context the same as the calling context was the last time it was run. My > understanding is that run from line should more properly be called > "re-run from line." If the line was not previously run, it would be > "start at line". > > If I had my choice (and a team of programmers who would listen to me and > do it my way), I would want a system that kept a record of every line > that was executed. The display would be able to be scrolled backwards to > select a line. If the line were a subroutine call, it would be possible > to show just the call (hiding the actual subroutine lines) or to expand > the call (showing the subroutine lines). > > One could then select the line one wished to run from. Of course, when > displaying this, it would be possible to show the values of all > registers, subroutine arguments, and other variables as they existed at > the time of the line execution. > > The above takes care of the re-run from line case. The start from line > case has the extra quirks that probing and other inputs need to be > simulated or have the values otherwise specified. > > I'm sure that all of this is doable. Most of it is not needed by the > typical user (heck, it's not clear the subroutines are needed by the > typical user). > > Unfortunately, given the nature of open software developed by a mixed > group of varying interests, it will not be easy to get this done -- > certainly not in a single step. It might be possible to do this in > multiple phases, though. > > The first phase would be for someone to step up and build the > interpreter support. After that was done, we wold need someone to make > the gui work with that support. > > One downside of what I have in mind is that it would require > significantly more CPU resources to implement. That might mean that it > would run slowly on ten year old computers with 256Meg of memory. Some > of us might have to upgrade to five year old computers :-). > > Thank you taking this on, Michael. I'm sure that whatever changes you > make will be an improvement. > > Regards, > > Ken > > On 4/9/2012 8:13 AM, Michael Haberler wrote: >> I've threatened to do this, and since it is slowly moving towards master, I >> thought I'd reduce the surprise factor by laying out plan and status: >> >> The rundown of what it aims to fix: >> >> • GUI's will be able to highlight source location wherever it comes from: >> main.ngc, an oword subroutine, Python code, MDI strings .. >> • run-from-line should become more bullet-proof. >> • run-from-line will work on arbitrary conditions, not just line numbers; >> from locations in subroutines, or depending on variables. >> • a new 'Run up to here and pause' GUI option similar to RFL should be easy >> to add. >> • a call stack display should be easy to do >> • the Interpreter's handling of O-words can be firmed up substantially, the >> following statements should cause an error message during parsing: >> • a 'return' or 'endsub' not within a sub defintion >> • a label on 'repeat' which is defined elsewhere >> • a label on 'while' which is defińed elsewhere and not referring to a >> 'do' >> • a label on 'if' defined elsewhere >> • a undefined label on 'else' or 'elseif' >> • a label on 'else', 'elseif' or 'endif' not pointing to a matching 'if' >> • a label on 'break' or 'continue' which does not point to a matching >> 'while' or 'do' >> • a label on 'endrepeat' or 'endwhile' no referring to a corresponding >> 'while' or 'repeat' >> >> The gory details: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?SourceContext >> >> This *will* eventually affect code I dont know very well, mainly the GUI's >> (note 'affect' != 'break without further changes', or so I hope). >> >> >> I'd appreciate feedback on this. >> >> - Michael >> ------------------------------------------------------------------------------ >> For Developers, A Lot Can Happen In A Second. >> Boundary is the first to Know...and Tell You. >> Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! >> http://p.sf.net/sfu/Boundary-d2dvs2 >> _______________________________________________ >> Emc-developers mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers > > ------------------------------------------------------------------------------ > Better than sec? Nothing is better than sec when it comes to > monitoring Big Data applications. Try Boundary one-second > resolution app monitoring today. Free. > http://p.sf.net/sfu/Boundary-dev2dev > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
