On 01.02.12 11:48, Michael Haberler wrote: > Am 01.02.2012 um 09:23 schrieb Erik Christiansen: > > The grammar specifies expression and control flow constructs, but seems > > 100% devoid of any explicit gcode grammar. I've scrolled up and down > > twice now, but still can't see any rapids, moves, feedrates, or > > toolchanges. Nuffin! > > Yes, and that is a feature.
At some point, LinuxCNC needs to interpret the gcode. The "parser" you've put up does not do that. Does it have any purpose, if it does not do that? A user need which has been expressed in this thread is for a documented gcode grammar. We'd like to know what is legal gcode, and what is not. If no grammar policing exists in the so-called parser, then either almost any input is accepted, or the real parser is elsewhere. ... > b) the language we have *is already runtime extensible* at the word level According to the documentation here: http://www.linuxcnc.org/docview/devel/html/remap/structure.html#_introduction_extending_the_rs274ngc_interpreter_by_remapping_codes you're almost wholly correct in saying: > and your idea kills this property by downgrading it to a compile-time affair. because having a documented grammar in the parser would only allow run-time _extending_the_rs274ngc_interpreter_by_remapping_codes. It would only permit remapping of standard gcodes by changing the grammar. But the need to remap gcodes half way through a swarf-making job, without allowing a compile, is probably a rare requirement. So perhaps the real point is that a highly flexible infrastructure for customising the interpreter exists, and no-one is proposing changing it. The main thread is about a filter to supply some things lacking in the current interpreter. One of those is a definition of the standard grammar - the one which allows us to exchange gcode programs, if we haven't pythoned a G0 into a G76. ... > c) language preferences: > > I remember the original topic to be about an executable language > description, reducing syntactic noise, and lint-type tools or > prettyprinting for that matter. > It was not about rewriting the current interpreter, but if that is your > topic: No, if you look at my posts, you'll see repeated reference to a gcode filter. A couple of times I've had to answer posts which suggested merging the filter with the interpreter. I don't think that I have at any time adopted that suggestion from you or anyone else. ... > > You've prompted me to dig out the parser I started in July, and since > > there isn't any actual gcode in yours, I'm probably better off dusting > > it off, and playing with it. > > Sharing any better ideas or results would be helpful. This thread is intended to discover if there is anything to share, and if there is sufficient consensus on what is needed by the users. So far, the same desires as seen in previous years are: o A documented gcode grammar. o Some decluttering of the input, for readability. o More use of meaningful names, for readability. While some users may want to python their machines to use a personal private gcode dialect, used by no-one else, my interest lies at the other end of LinuxCNC and the use-case spectrum: Re-using the standard gcode grammar, but cleaning up its appearance. [snipped lotsa stuff on an apparently variable grammar.] > any opinions on that? At this stage, I only have a few questions: Do we implement a "default grammar", which we could document in BNF? Is it sufficiently static to warrant the effort of documenting it? Erik PS Thanks for provoking me into reading some of the doco on gcode extensions. It is flexible to a scary degree. -- Do not do unto others as you would they should do unto you. Their tastes may not be the same. - George Bernard Shaw ------------------------------------------------------------------------------ Keep Your Developer Skills Current with LearnDevNow! 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-d2d _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
