Am 23.08.2013 um 15:58 schrieb David Armstrong <[email protected]>:
> On 23/08/13 14:06, andy pugh wrote: >> On 23 August 2013 13:38, Michael Haberler <[email protected]> wrote: >>> Flatly I dont get it why folks just go straight to patching around in C++ >>> code, and inventing bizarre new control "features" instead of reading a >>> manual and trying examples >> Maybe because they see G71 as an addition to the LinuxCNC G-code >> language support, not an additional, optional, plug-in that requires >> users to configure Python files and create a unique system all of >> their own? >> >> I don't even know if this is an accurate description of the situation, >> but a G-code that only works for some people does seem like it might >> cause problems. >> > > I respectfully place this view . > > My point is that not all people are programmers or capable of scripting > or re-compiling , and what is now a resonable standard G Code , should > be supported as such and part of the mainstream build > i have come across many people thinking to use Linuxcnc , and because it > does not conform to their resonable standards out the box , in > comparison to x product they wont use it , due to machine down time and > perhaps the learning curve are other matters , but every controller on > the planet just about has canned cycles G71 as standard , so no learning > curve ! . > > which is perhaps one point why it keeps popping up on the lists and > forums .. > > the easier we make it to do the majority out the box the better . > we should support standards and leave scripting for the newer wizards .. that's all fine, the problem is you ask 10 people and get 15+ different views of what is 'standard' now if you go down the 'lets do it in C++' route everybody rams down his view everybody else's throat, including any aberration - see the murky control flow changes which are inacceptable as proposed IMV if you do a remapping config, that does not happen because its optional; the C++ patches are not made to be optional. -- Let's take an analogy, for instance Firefox and say Autocad. These are generic frameworks with a plugin capability, and it is very easy to adapt behavior by installing 'extensions', ad blockers, lisp files, what have you. Much of the functionality comes from plugins, and nobody would think of asking Autocad or Mozilla Foundation to recode their favorite plugin in the core code just because they love C++ so much. I dont see the interpreter as anywhere different. You dont like what you have, you provide an extension. In fact I would see a future interpreter as a minimal C/C++ framework wich generates an abstract syntax tree, and exposes this to an embedded Language, which provides 'the meat' (semantics). Then the difference between core and extension code goes away completely. That said, I concede that building such an extension isnt exactly the most straighforward thing on earth, it requires reading the manual and working through the examples. But people definitely use it. Now if it turns out to be more of a packaging problem what we are talking about here, then why dont we think a little bit about packaging extensions and make them easier installable? A remapped code is a .ini fragment, maybe a bit of Python, maybe an NGC file or several. Those could well be collected in a per-extension directory, and I could even imagine making these installable with say 'apt-get install rs274-g71-suchandsuch-flavor', and on startup that extension would be pulled in automatically because the interpreter scans a directory of installed extensions, which are one per subdirectory therein. That is for instance exactly what apache does, and gazillion of other demons which have some /etc/<commandname>.d/ directory where config fragments are assembled. - Michael > With all the changes Micheal and others are doing are for the best , yes > i agree , but missing out the basics .. should not be taken lightly , > everyone is thinking as a programmer .. or coder ... not as a user or > poor apprentice been given the task to program a machine . > > what can be easy for us to use , can be a nightmare of major proportions > for others . > > or are we displaying it to wider user the wrong way . > > > ------------------------------------------------------------------------------ > Introducing Performance Central, a new site from SourceForge and > AppDynamics. Performance Central is your source for news, insights, > analysis and resources for efficient Application Performance Management. > Visit us today! > http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
