On 02/01/2012 10:45 AM, Michael Haberler wrote: > > Am 01.02.2012 um 13:36 schrieb Erik Christiansen: > >> 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. > > Probably folks use the term 'parser' to mean different things, which might be > part of the confusion. I use in the Dragonbook/Compilers 101 sense - a > program which recognizes certain syntactic constructs and nothing else. > > For me the term 'parser' does NOT include static semantic checks, or > executable semantics. The term 'interpreter' for me denotes executable > semantics, which is different from 'parser', which is a context-free affair > so to speak. > >> Does it have any purpose, if it does not >> do that? > A better definition of the language than we currently have it, executable or > in the manual? For instance, we dont have anything like a railroad diagram or > a current BNF. And it would be great to have that in particular for > beginners. Also an executable version at least as point of reference, and as > a vehicle for other software. > > Some examples: > > 1. Expression syntax > my parser actually found an error, or rather my misunderstanding of the > current language, in one of the files in emc2-dev/nc_files > see line 30 of > http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=nc_files/m6demo.ngc;h=85a3c0f7f031a7735e1660403f22beee90302b4e;hb=50d82f006b489a0e2795e60bd617759c902fdafd#l30 > : > > O<m6demo_spindle_off> if [#<tool_change_with_spindle_on>] EQ 0 > > now if you read http://www.linuxcnc.org/docs/devel/html/gcode/o-code.html, > the 'if' examples have bracketed expressions. > So I though, gee, must be in the language. > Well guess what, it isnt - the current interpreter (at least at that point) > accepts the above line just fine, and I think it skips from the closing > bracket to end-of-line - one would have to read the source code to determine > acceptable language. > > Incidentally the interpretation of 'if [#<tool_change_with_spindle_on>]' and > 'if [[#<tool_change_with_spindle_on>] EQ 0]' happen to be the same, but one > can do better. Blame me. Part of my "specification" (which was never written) is that the interpreter executes correct programs correctly. I did not implement complete error detection. Oword handling is particularly nasty. A "call" will execute from the first matching oword sub up to and including the matching oword that might be a return or a endsub. > 2. Is a (comment) whitespace? > Whitespace is squashed, we hear. Comments are removed, so I assumed they are > gone at the language execution level, and are de-facto whitespace. > Really? let's see: > > $ rs274 -g > ... > READ => s100m3 > 17 N..... SET_SPINDLE_SPEED(100.0000) > 18 N..... START_SPINDLE_CLOCKWISE() > READ => s 100 m 3 > 19 N..... SET_SPINDLE_SPEED(100.0000) > 20 N..... START_SPINDLE_CLOCKWISE() > READ => s 100 (on) m 3 > 21 N..... COMMENT("on") > 22 N..... SET_SPINDLE_SPEED(100.0000) > 23 N..... START_SPINDLE_CLOCKWISE() > READ => s(hundred) m 3 > bad number format (conversion failed) parsing '' > s(hundred) m 3 > > That kind of 'language spec' can stand improvement.. so my parser doubles as > a reverse-engineering tool;) I believe that the comment IS being ignored. The objection isn't to the comment; it is to the letter m.
Regards, Ken > 3. backplot for CAM programs > HeeksCad sports some minimalistic understanding of the Gcode it generates, > for backplotting the generated tool path. Guess what it uses: a regexp-based > 'parser'. Sure. > >> 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. > You'd be suprised on what incredible junk gcc accepts as 'legit grammar' once > you amputate the backend ;) > > Currently I dont see a formal way to describe the interdependencies of > several words on a block. You can do the optional parameter words in the > language but you cant recogize the conflicts and multiple uses within a block > that way. It would be nice to have. > >>> 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. > Good to see somebody is reading this after all.. > > But 'remapping' is a bit of a misnomer: while a few codes can be 'remapped' > (aka changed), practically unlimited new M- and G-codes can be introduced, > with new optional and required word parameters. All this happens at the > block/word level of the current parser. I never thought of runtime extensions > - this is a configuration time thing. > >> 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. > we violently agree > >> 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? > I'd like to see an unambiguous grammar reference. > > So that parser is a start in that direction. Eventually the real thing should > actually execute that grammar, there's no point in having an executable doing > one thing and the LinuxCNC interpreter something slightly different. That's > not urgent though. > > In any cleanup/extension effort an executable grammar will help, in > particular wrt avoiding backwards compatibility issues. > > -m > > > ------------------------------------------------------------------------------ > 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 ------------------------------------------------------------------------------ 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
