Am 20.06.2011 um 01:15 schrieb Viesturs Lācis: > 2011/6/20 Michael Haberler <[email protected]>: >> >> do you refer to "G-code from some external source" or really "NML commands >> from some external source"? > > My idea was the first option - "G-code from some external source".
Very good point. I think the answer to this is "not in the current state of the interpreter". To have that capability, one would need to be able to instantiate the Interpreter without undesirable side effects. Currently once can instantiate the Interpeter - it's a C++ class - but instances are essentially useless for your purpose, and many good other uses. This is why: Conceptually, the state of the Interpreter consists of: - the world model (machine state) - modal settings (state which persists beyond blocks) - configuration state (ini info) - a canon layer, and associated NML queue - interpreter execution state (line number, am I in an o-word procedure, which O-word name/number, etc etc) Of these, instances should share the first two, could share the third and forth, and should NOT share the last state component. If you had that, you could instantiate the Interpreter, and feed it some commands which do what you want - your example, an MDI command, an O-word subroutine, a remapped code. At the end, you could throw away the temporary instance and rest assured that world model and modal settings are consistent. Now, the current state of affairs is: the above five state items are hidden in a hodgepodge of 132 local *static* variables in the interpreter, all nicely sorted by name so no logical grouping would be accidentially disclosed ;-). The result is severe contortions executing, for instance, MDI commands (just look at the bugtracker for consequences), because effectively everything needs to be packed into a single interpreter instance. Or O-word code. Or - in the future -multi-spindle, multi-changer machines. And it has bitten me with the remapping effort as well. So far the bitching. Now, I actually did look into fixing this, because it became apparent to me that removing these limitations would have quite an upside. So I divided up the interpreter state into POD classes - which would eventually be instantiation parameters - and looked how far I get. The result was: It is hard, but not that hard - I got very far within three days and most of it can be done by automatic editing and refactoring with Eclipse. The toughest part is actually canon, which needs to be wrapped in a class as well. The good news is that this restructuring should not affect semantics at all - all that changes is variable names, and where they are stored. The impact only becomes visible when instantiating and using an Interpreter and using it in new ways. I actually would like to do that properly, and feed it back into EMC. I estimate the effort about a week full-time. However, it is substantial and I would do that only if there is agreement that this is worthwhile despite some drag, and it's not just considered a Haberler hobby effort. - Michael > > Viesturs > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
