I must admit I've I've watched this thread unfold with a bit of apprehension. Certainly the current direction has evolved to the point where the result will likely not be usable for my purposes. I don't see a way of using a flex/bison-based parser from python apart from native bindings, so in terms of having a portable parser or lint-type tool this would not result in one AFAIK. The grammar might provide a good starting point for me, though.
Secondly, although gcode is certainly not a great language, I'm not sure I fully understand the motivation behind yet another custom gcode syntax extension. I have always thought decoupling was a good basic idea, and IMO the practical interface between LinuxCNC is a gcode file. As long as this interface is stable, and ideally as concise and standard as possible, it allows myriad CAM tools to reliably generate input files. Keeping it dumb IMO has great benefits. It allows CNC educational programs and those who learned basic gcode a long while back to continue to be productive. For the relatively smaller edge case of those wanting to hand-code sophisticated machine control, gcode (even the LinuxCNC flavor) is already a terrible starting point. Wouldn't it make more sense to just develop something like a simple python API that corresponds to (results in) machine motion operations (it could ultimately generate gcode), and modify the LinuxCNC interface to interpret those files line-by-line (the code displayed and stepped through would be the e.g. python, not gcode). Then you would have as much looping, conditional, file inclusion, etc. as you could hope for. Language design is fun, and there certainly is a trend toward domain-specific languages, but we already have many good choices for scripting languages that could be employed to be much more capable than any sort of gcode extension could ever be. Of course, I typically use low-end CAM or write gcode generators, and I am a relative LinuxCNC newbie, so perhaps I am not understanding the use case for an incrementally "better" custom gcode vs. using a mature scripting language. My two cents, Scott On Sat, Feb 4, 2012 at 9:48 PM, Erik Christiansen <dva...@internode.on.net>wrote: > On 04.02.12 16:25, Michael Haberler wrote: > > This is different from the original language: the pre-oword syntax was > > context-free, which is why there's a meaningful EBNF in the Tom Kramer > > report, and working context-free parsers based on ANTLR and bison like > > here: http://fennetic.net/irc/emc3/src/emc/interpreter/) > > It is worth noting here that the link points to another grammar which is > empty of working gcodes. Look in: > > http://fennetic.net/irc/emc3/src/emc/interpreter/rs274ngc-flex-bison/parser.ypp > > Below the top-level block structure, we see grammar for only expressions > and > parameter settings. Like the empty grammar posted upthread, it is devoid > of any grammar for gcodes. > > After checking both parser.ypp and the lexer (scanner.l) several times, > I find that the letter 'G' is passed through, like a dose of epsom > salts, without touching the sides. The so-called parser does not even > know that a gcode exists. It looks like an "Alphabet parser with some > expressions." > > The empty grammars(*1) put up so far look disappointingly like that > first 2% of a grammar that a uni student has to whack together in order > to pass computer science 101. All the hard work remains to be done. > > I wonder if there is one out there with any gcodes in it? > > On 04.02.12 16:25, Kenneth Lerman wrote: > > The use of matching labels to resolve ambiguity was just a cheap trick > > to lower the cost of implementation. There is no reason that we should > > keep the labels on control structures. We should then follow the same > > rules that C uses. > > +1 > > Erik > > (*1) Empty of any handling of the input. There's not even a yyerror() > function to generate syntax error messages. Since a yacc/bison parser > calls that function on any syntax error, it's hard to see how these > toys can be called a "working grammar". > > -- > The Roman Rule > The one who says it cannot be done should never interrupt the one who > is doing it. > > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
