>>> 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
100% ACK >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 I think the main problem is not dedicated to the language but to a clean design before implementing something. But I agree that C++ requires a lot of discipline and experience to implement a good design in a proper way. An other option might be plain C with good coding rules. GTK is a good example that you can do a "object orientated approch" even in C. On the other hand I have seen code written in Python that lacks any prettiness. What might help are coding rules together with a kind of review process. Tools like GitHub are excellent candidates for such a review process. Relevant code fragmentes can be discussed until they are accepted. >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. That's right. It's not a high performance application. But I think latency could be a point if the controller core runs on a small embedded system and the gui is attached via network. But currently it's just a gut feeling without any hard facts. >the one who tackles the task gets to choose the language, so here comes your >chance I already thought about this option :-) Sascha ------------------------------------------------------------------------------ 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
