Am 29.09.2013 um 16:08 schrieb Jeff Epler <[email protected]>: > On Sun, Sep 29, 2013 at 10:21:46AM +0200, Michael Haberler wrote: > [reasons to make _setup not be a static member of Interp snipped] >> I think it is one of this 'this finally has to go' things in linuxcnc, and >> this is the time >> >> what do you think? > > You always see things in a grand connected way that is a little bit beyond me. > > Coming at it from the other direction, the apparent dependencies on a static > _setup are small enough (in fact mostly or entirely due to the new Python > integration code!) that I don't see a reason to retain it. It starts to look > more like a simple accidental wart left over from the initial C++ > "conversion"... (it would have been needed when not everything was converted > to > a method, I think, and then you just forget to remove the unneeded 'static') > > If the fix ends up grotesquely ugly or leads to unexpected consequences we > might have to re-ask this question but for now it looks like getting rid of > static _setup is more like a low-hanging fruit than a long-term project, and > so probably fine for master even at this late stage.
I do think so too; in fact it can be done in moderate steps, one each for a static member composite (like _gees etc) for regression testing. When that is done and runtests ok, the second step is to get rid of the static interpreter instantiations here and there. Once the lifecycle of the interpreter instance(s) is under control, the segfault should be easy to fix (or rather just go away). The Python exposure needs a bit of repetitive work but its clear how that is to be done. What I would appreciate is a review to make sure all _setup members are properly initialized as instance variables. It might become a long list of initializations. -- the upside of my grand connected thinking ;) would be this - assume fast forward for a moment: - we have several motion command queues which can be switched during a pause, similar but generalized to what jog-while-paused does *) - you could have several interpreter instances in task which are tied to a motion queue **); a switch would cause a sync() of the activated interpreter - you might have UI support for several and switchable interpreters - for instance, an MDI window tied to a second interp instance while the primary runs a program - this is almost MDI-while paused *) generalized meaning 'can be fed into by task' - the jog-while-paused alternate queue is a motion-only affair right now **) this cannot be done right now because interpreter instances share the static members, execution of commands in one instance damage state in the other; past change it could be done in principle ***) 'almost' because there are least two more hurdles: the current teleop/free/coord mode switching tends to trample on the motion queue(s) and that gets in the way; second, the same operation needs to be applied to canon, which isnt a class proper and has lots of static variables - Michael ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
