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
