On 23/08/13 16:55, Michael Haberler wrote:
> 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.
I think it's more a question of ease of use , for the non
programmers , and for it to be included by default in an extension
directory , rather than an addition by whatever means
so why not a directory structure where these ' plugins can reside ' ,
but to the user they are transparent and need no manipulation to work
i.e installed by default , so yes i agree it's more of a packaging and
'Yes it works out the box ' rather than ' oh you need to do this for x
to work ! '
so yea i think thoughts on it's structure may be the best way , and by
far i'm not the one to suggest how to implement it , i am by far not
criticising how it is now , just how the hell to make it better
from the user point of view , that knows enough to be dangerous with
linux .. and a machine attached
> --
>
> 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
>
>
------------------------------------------------------------------------------
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
