Am 11.08.2013 um 18:49 schrieb Sascha Ittner <sascha.itt...@modusoft.de>:
>> Note that once conversion is done there remains no code in task which has to >> be >> C++, as Python bindings for all moving parts will be available. I would have >> no >> parting pains with the task code, and if somebody would want to redo this in >> Python, it is time to start thinking to bring the - sorry, pathethic - >> implementation of the task state machine into a comprehensible and adaptable >> form, for instance by using the fysom.py state machine framework. > > I agree that a clean redesign of that part would be a big progress as I > experienced the pain caused by the attempt to understand the code. But I'm not > sure if Python is adequate for such a integral component (I'm thinking about > the > usage on resource limited systems). Why not try a clean implementation in C? > > Sascha the current bloat is caused by a ton of repetitive low level operations, poor functional abstractions, tons of globals with no acessor methods (EMC_STAT being the mother of all globals) and a gazillion of ad-hack patches here and there; the insanity of operating the interpreter as a subroutine and trying to guess what it might need, instead of making it a process or thread and have it tell what it needs; and choosing a method to implement a humungous state machine which literally guarantees illegibility those are the reasons why very few people around here touch task, and if so, with a 10ft pole so the issue on the table is a structural redesign, and for the first time we have the option not to use C++, which definitely is a deterrent in this community; just have a look how happily UI's are build these days with Python by non-gurus, there is just no way this would happen with C++ which is why Python would be my preference another reason is that the current task semantics isnt particularly enticing esp regarding mode changes between MDI and auto, and other people mike need something simpler and less prescriptive, for instance the 3d printer crowd, so adaptibility of the FSM is a plus; heck, it might be loadable the actual functionality of that clunker is moderate, and so are the performance requirements, so there's just no reason I could see to retain the C++ deterrent the one who tackles the task gets to choose the language, so here comes your chance ;) -m ------------------------------------------------------------------------------ Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
