I understand where you are coming from. Word order is not important as long as you understand how things will be interpreted, and that understanding matches what actually happens. I think this discussion has ranged across several useful applications for a formalized parser, including:
1) My original intent, which is to clean up and normalize gcode input so that subsequent filters can be much more naive yet still safe. The parser in this case would fail on malformed input, disambiguate lines to make things as clear as possible and normalize output, including things like white space. I could probably achieve my original use case (wrapping a Y axis around an A axis) for my specific input files in a very short python program, and it would serve my purpose. But that is something I wouldn't feel responsible releasing to others (even with caveats) because ultimately the code would be used to move machines, etc. As a result my work would be a development dead end and there would be no benefit to LinuxCNC. I expect there are one-off translation scripts like this all over the place that will never see the light of day because of the lack of robustness. I know I have several. Since I have some modest experience as a software developer writing parsers, this is something (along with the Y->A wrapper filter) I can work on and hopefully contribute back in exchange for all of the benefits I have accrued from LinuxCNC. 2) If this parser/validator existed and was portable, it could be used to verify gcode in general, serving what some developers call a "lint" function against gcode (http://en.wikipedia.org/wiki/Lint_%28software%29). This might have a positive effect for gcode in the wild, as CAM and motion control developers could check their output and those considering extending the language might realize sooner that there are good and bad ways to extend the language. 3) Further, if the parser/validator was sophisticated enough to understand the LinuxCNC extensions and could be integrated via C/C++, it could be used as a front-end to the LinucCNC gcode interpretation process, hopefully providing more robust parsing and validation, more clear error messages, and better ability for developers to understand and enhance the parsing process. That is the discussion so far at least as far as I understand it. Michael has done a nice job of providing some requirements for case #3, which is probably the hardest case, but those requirements impact how we might go about #1 and #2 as well, in that we would ideally want to pick a parser generator that would let us re-use the grammar. Hope that helps clarify, others please check me if I have this wrong. Scott On Sun, Jan 22, 2012 at 9:09 AM, John Harris <jdhhar...@customstage.net>wrote: > I have followed this thread for a day or two, but I cannot understand > what would be achieved by the parsing. The beauty of gcode is its > simplicity, a whole block is read and decoded before any action is > taken, so why is word order important? > Are you looking for: > Letter codes without values, or values without letter codes? > Wrong type values? > Motion with zero speed set? > > I am currently working on a gcode reader in 'C' for a small 3-axis > machine, and wonder if I am missing something? > > __________________________________________________________ > John Harris > E-Mail jdhhar...@customstage.net > > > On 1/22/2012 2:46 AM, Michael Haberler wrote: > > Am 22.01.2012 um 04:36 schrieb Scott Hasse: > > > >> I agree there is a large and difficult problem with respect to the > semantic > >> checking if the desire is to assure that a program will run properly. > I'm > >> really aiming for a step or two below that, where the code would be > parsed, > >> any semantic checks that can be done statically would be done, the words > >> would be re-ordered on the blocks in a standard way, and blocks split > up in > >> a standard way to more clearly disambiguate the order of execution. > > so you're really looking at source-to-source translation and I guess AST > rewriting, cool > > > >> Unfortunately I don't have the C chops to be of much assistance with an > >> interpreter rewrite (I am a Java guy primarily, getting into Python), > but > > -^^^^^^^^^^^^^^^^^^^ I'm already sit in that pit > > > >> I'd be glad to help with work on a common grammar, even though that is > only > >> a small part of the problem, as you say. > > well, my requirements for a vehicle would be roughly like so: > > > > - industrial-strength error diagnosis and recovery, LALR(1) capable > > - can generate a C/C++ scanner/parser from grammer, lexical definition > > - the parser/scanner can be used from C/C++ or Python > > - optional parse tree generation a plus > > - mainstream/widely used code base a plus > > > > that probably suggests some bison or byacc base; I'd refrain from a > Python-only solution like PLY because that's bound to diverge from the > current interpreter since it cant be easily used a frontend; however, there > was some discussion about moving the interpreter to fully-Python. I think > thats overly ambitious given the resources though. > > > > I have zero Java clue and would try to avoid adding another language to > the linuxcnc language plethora, which needs to be pruned rather than be > added to > > > > I'd be interested what you think. > > > > - Michael > > > > > > > > > > > > > ------------------------------------------------------------------------------ > > 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 > ------------------------------------------------------------------------------ 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
