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.
This would let through plenty of bad programs, but for me it would still be of value to me when writing gcode filters/post processors, as they could then be much more naive (or conversely take advantage of the parse tree and be more sophisticated) than the post processor macro approach I tend to see from CAM vendors. 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'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. Scott On Sat, Jan 21, 2012 at 9:14 PM, Michael Haberler <mai...@mah.priv.at>wrote: > > Am 22.01.2012 um 03:17 schrieb Scott Hasse: > > > Perhaps it is a lost cause, but having some sort of > > what I would call a "gcode lint" tool would allow people who sometimes > take > > a naive approach to gcode extension to have an reality check. > > a parser with one of the mentioned tools surely can be done > > however, from a "gcode lint" perspective the parser only might be of > limited value because syntax is the easy part, especially with postwar tools > > note that many syntactic correct G-code programs may fail execution, > because combinations of legit syntactic constructs and > interpreter/machine/config state may be invalid > > the tough part is the semantic checking, where a scanner/parser generator > isnt much help; there's not much wiggling around replicating the execution > model and state, which basically leads you to a rewrite of the existing > interpreter > > -- > > that might be a worthwhile project in its own though because the current > interpreter doesnt exactly use bleeding-edge scanning & parsing practices, > leading to a steep learning curve and lots of oddities > > drop me a note if you're interested > > -m > > > > > ------------------------------------------------------------------------------ > 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
