On 10/30/2013 9:06 AM, Bertho Stultiens wrote: > For a future as a secondary/pluggable interpreter, it would be required > to finalize the grammar, discuss required built-in functionality, > discuss how to handle rotational axes and get a grip on all bugs.
It seems to me your to-do list is relevant independently of whether gcmc remains a standalone tool or mutates into another LinuxCNC interpreter. It would be nice to have a wiki page, forum section, or some such where we can capture feedback, discussions, and desiderata. These email discussions get disjointed and are difficult to mine after the fact. As for added functionality, I'd certainly want to see a meta-level ability in gcmc to include* user-defined units of functionality** at runtime. Otherwise I have to do it myself while preparing an input file to gcmc. This forces me to do bookkeeping better left to the computer. Some other messages have flashed by which border on programming-language bashing. I hope we can avoid yet another flame-war and concentrate on scoping, completing, and using your gcmc. Regards, Kent * name it what you like in the grammar---include, import, call, whatever. **again, I can live with whatever this external chunk of code is named. ------------------------------------------------------------------------------ Android is increasing in popularity, but the open development platform that developers love is also attractive to malware creators. Download this white paper to learn more about secure code signing practices that can help keep Android apps secure. http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
