On Sun, 22 Jan 2012 20:16:40 -0600 Scott Hasse <scott.ha...@gmail.com> wrote:
> 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. OUCH! I've become quite used to g-code with no white spaces and would hate to see that forced on user. If it is an option I have no problem. Just my preference. Dave > > 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 ------------------------------------------------------------------------------ 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
