On Aug 11 2013 11:34 AM, Michael Haberler wrote: > 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
if someone has that much trouble with OO abstraction with C++, they are not going to be any better with OO abstraction in Python. The one thing that python really buys you is that it is interpreted and does not require a compiler. Running from an interpreter comes at a cost (between 3x to 10x depending on if you use numpy and similar libraries which are simply C bindings to Python anyway). So I would ask you: "is this section of code time critical?" If so, then you are looking at running at least 3x (and probably more like 10x) slower than a similar implementation in C/C++. The one thing that might save our bacon with switching languages is if you can clean really things up, and maybe implement things using more advanced algorithms. > 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 real question is that if you are going to strip this out and reimplement it with a different language, then how is this going to interface with the rest of the code. Is this a standalone tool? If so, you should not have much of an issue. If not, then you have to demonstrate that it will tie back into everything. If you are looking to rewrite everything in python I would like to see *those* latency charts. EBo -- ------------------------------------------------------------------------------ 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
