Re: [Emc-users] parsing the current language dialect, and describing as EBNF
On 2/7/2012 5:48 PM, Steve Blackmore wrote: However, fun though that might be, I doubt it would reach completion, or gain any sort of market acceptance outside a very small subset of LinuxCNC users, and almost certainly wouldn't expand outside our project. Agreed - May be interesting as an academic exercise, but has little practical merit. Fanuc style or RS274 Gcode is pretty much universally understood, quite a lot of minor variations, but the majority of code is easily translatable from one controller type to another. It doesn't take much effort or academic aptitude to grasp. I honestly can't see the point in trying to reinvent the wheel? Steve Blackmore Steve: This isn't a reply to you so much as it is a coda to the thread for which your message seems to be the most recent. I see that I last participated on the first of February. I was diagnosed with pneumonia the next day and have been out of it since. I recently fired up my email client and found over 400 emc-users messages waiting. Yikes. You folks have been busy bees. After reading all the messages in this thread and its companion Do CAM instead? thread in rapid succession, I confess my brain hurts:-) In a way I'm glad I was out of the loop for so long. It prevented me from firing off spur-of-the-moment replies that probably would not have advanced the cause. We seem to be the proverbial blind men trying to agree a description of an elephant when each is touching a different part. One of my personality traits is to encourage academic exercises. Even when their result has no practical merit they usually help illuminate the subject; however, often they lead to practical improvements, and occasionally they lead to entirely new ways of doing things. I see no reason why the present speculative line of inquiry can't proceed alongside the continued maintenance and extension of our existing LinuxCNC program. As long as there are LinuxCNC users who depend on CAM-system post-processors or use multiple commercial machine controllers or employ other software tools that interoperate in the same environment there will be a need for a LinuxCNC RS274/NGC interpreter. So be it. Even if RS274/NGC were the only game in town, I'd still like to see work done to describe the interpretation process more formally. At the same time, I see no reason why this speculative line of inquiry about our command language can't consider alternative methods of telling CNC machines what to do. Market acceptance doesn't seem to me to be a useful metric here. The market has a funny way of making up its collective mind---I won't bore with a recitation of successes and failures in technology-driven markets---but it can only accept or reject technologies that have been reduced to practice. Besides, what market are we talking about? I'm a LinuxCNC user who doesn't use commercial CAM software. Granted, the command language we use is reasonably well described and I've been able to write files myself, using text editors or various G-code wizards, but I'd be happy also to have more facile ways available to create a part. I suspect but can't prove this is true for a number of LinuxCNC users. As well, some LinuxCNC users are working with machines whose behaviors lie well outside the envelope of traditional CNC machining centers. I suspect they also would not be unhappy to see new ways of commanding LinuxCNC. Even among hardcore industrial users of traditional CNC machining centers there is an embryonic market for alternatives to the status quo. As only one external example, there is the long-running STEP-NC project that includes some very big global players who clearly wish for something better. The bottom line is, I hope we continue our inquiries. Regards, Kent -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] parsing the current language dialect, and describing as EBNF
Kent A. Reed wrote: I see that I last participated on the first of February. I was diagnosed with pneumonia the next day and have been out of it since. Whew! Been there, done that a few years ago. Hope you are doing better! Jon -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] parsing the current language dialect, and describing as EBNF
On Mon, 6 Feb 2012 10:03:20 +0200, you wrote: However, fun though that might be, I doubt it would reach completion, or gain any sort of market acceptance outside a very small subset of LinuxCNC users, and almost certainly wouldn't expand outside our project. Agreed - May be interesting as an academic exercise, but has little practical merit. Fanuc style or RS274 Gcode is pretty much universally understood, quite a lot of minor variations, but the majority of code is easily translatable from one controller type to another. It doesn't take much effort or academic aptitude to grasp. I honestly can't see the point in trying to reinvent the wheel? Steve Blackmore -- -- 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
Re: [Emc-users] parsing the current language dialect, and describing as EBNF
On 6 February 2012 04:35, Erik Christiansen dva...@internode.on.net wrote: Granted, if I had them ingrained in my brain, after decades of use, I would not change either. There is no reason to. An optional input filter only provides flexibility to anyone wanting more. The filter I'm playing with will offer decluttered old syntax, and a more human readable form. Should it be completed, its use is discretionary. I think that any existing and working file with the .ngc extension has to carry on working, but if folk want to smarten up the interpreter to work without tags and O-numbers in the control structures, that seems fair. However I see no reason why we shouldn't consider starting from scratch with a new machine-control language, possibly based on Python syntax. I would prefer to see that translated directly into motion commands in LinuxCNC rather than into any sort of G-code, though. However, fun though that might be, I doubt it would reach completion, or gain any sort of market acceptance outside a very small subset of LinuxCNC users, and almost certainly wouldn't expand outside our project. -- atp The idea that there is no such thing as objective truth is, quite simply, wrong. -- 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
Re: [Emc-users] parsing the current language dialect, and describing as EBNF
From: andy pugh bodge...@gmail.com To: emc-users@lists.sourceforge.net Sent: Monday, February 06, 2012 8:03 AM snip However I see no reason why we shouldn't consider starting from scratch with a new machine-control language, possibly based on Python syntax. I would prefer to see that translated directly into motion commands in LinuxCNC rather than into any sort of G-code, though. However, fun though that might be, I doubt it would reach completion, or gain any sort of market acceptance outside a very small subset of LinuxCNC users, and almost certainly wouldn't expand outside our project. I agree with Andy's last paragraph. There are, however, pursuasive reasons for a change from G-codes if we could allow the machine tool to understand enough about what it is doing to be (self-)adaptive. There is a current example in cutter wear compensation. The machine (if fitted with laser metrology) or operator (with a micrometer) can adjust the control to compensate for a tool that is wearing - no need to re-CAM the part!. Generally though the control dumbly obeys orders (from the CAM) - e.g. executing lots of line or arc segment with no notion they define the wall of a pocket. As we know, trouble comes if G42 comp is on and a sharp internal corner shows up. There has been international work on a project (STEP-NC) that aims to give enough information about the design intent of a part so that the control can optimise finish, metal removal, accuracy, or, WHY depending on the stiffness of the machine, how blunt the tooling is, variations in the workpiece etc. This is very ambitious and I have no idea if it is still active or got stalled but a higher level machining abstraction could make it worth passing on the obvious advantages of the familiar G-codes. John Prentice -- 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
Re: [Emc-users] parsing the current language dialect, and describing as EBNF
sure, but either way you look at it: if there's a language change, there still
be a need for recognizing the old syntax, either for in-place compatibility or
external automatic conversion
-m
Am 04.02.2012 um 22:25 schrieb Kenneth Lerman:
The use of matching labels to resolve ambiguity was just a cheap trick
to lower the cost of implementation. There is no reason that we should
keep the labels on control structures. We should then follow the same
rules that C uses.
Ken
On 2/4/2012 10:25 AM, Michael Haberler wrote:
{this is a bit of language/compiler theory, but then the thread started
here; sorry;)}
One of ideas floating around was to to document the current language as an
EBNF, or an equivalent railroad diagram. An EBNF is a notation for a
context-free languages.
That will not work, because the current LinuxCNC RS274NGC dialect cannot be
described by a context-free grammar in the first place, and hence not as an
EBNF, if one tries to include the control structures as language elements.
This is different from the original language: the pre-oword syntax was
context-free, which is why there's a meaningful EBNF in the Tom Kramer
report, and working context-free parsers based on ANTLR and bison like here:
http://fennetic.net/irc/emc3/src/emc/interpreter/)
To see why the current language is context-sensitive, consider just one
example:
program start
o label1 do
...
o label2 while ..
...
o label3 endwhile
...
o label4 while ..
eof
You cannot determine by looking at a context-free grammar alone wether the
interpretation should be either:
1: (do ... while) (endwhile...while) or:
2: (do ... (while ... endwhile) ... while)
To resolve the ambiguity in scope, one needs to match the label *values*:
(label1 == label4) (label2 == label3) - interpretation 1 (in the
current language)
(label1 != label2) - an error at 'endwhile'
This also applies to if/then/elsif/else and repeat/endrepeat.
So the labels constitute the context. Technically, since the labels are
variable keywords, this means a language with a theoretically infinite
alphabet.
This has a couple of consequences:
- writing an EBNF is only possibly on a line-by-line basis, not including
the control structures . But then such an EBNF will not tell you wether a
given program is correct wrt current scoping rules, or not, and as such
fairly useless.
- it also means explains why my first attempt at a bison/flex parser *for
the current language* failed to properly recognize current control
structures because as it the stands the parser fails at the above
ambiguities. This also applies to other tools.
This does not mean these tools are unusable, it just means the scanner needs
to tie into the parser or scope stack. It does however mean an EBNF will not
fully encompass all aspects of the language. This might be useful already.
- Michael
ps: this is a clarification of what we have, not a critique - C, and C++
have similar issues and work just fine, too.
psps: so much for the comment 'G-code is extremely easy to parse.' ;)
--
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
Re: [Emc-users] parsing the current language dialect, and describing as EBNF [Was: question on gcode parsing]
I must admit I've I've watched this thread unfold with a bit of apprehension. Certainly the current direction has evolved to the point where the result will likely not be usable for my purposes. I don't see a way of using a flex/bison-based parser from python apart from native bindings, so in terms of having a portable parser or lint-type tool this would not result in one AFAIK. The grammar might provide a good starting point for me, though. Secondly, although gcode is certainly not a great language, I'm not sure I fully understand the motivation behind yet another custom gcode syntax extension. I have always thought decoupling was a good basic idea, and IMO the practical interface between LinuxCNC is a gcode file. As long as this interface is stable, and ideally as concise and standard as possible, it allows myriad CAM tools to reliably generate input files. Keeping it dumb IMO has great benefits. It allows CNC educational programs and those who learned basic gcode a long while back to continue to be productive. For the relatively smaller edge case of those wanting to hand-code sophisticated machine control, gcode (even the LinuxCNC flavor) is already a terrible starting point. Wouldn't it make more sense to just develop something like a simple python API that corresponds to (results in) machine motion operations (it could ultimately generate gcode), and modify the LinuxCNC interface to interpret those files line-by-line (the code displayed and stepped through would be the e.g. python, not gcode). Then you would have as much looping, conditional, file inclusion, etc. as you could hope for. Language design is fun, and there certainly is a trend toward domain-specific languages, but we already have many good choices for scripting languages that could be employed to be much more capable than any sort of gcode extension could ever be. Of course, I typically use low-end CAM or write gcode generators, and I am a relative LinuxCNC newbie, so perhaps I am not understanding the use case for an incrementally better custom gcode vs. using a mature scripting language. My two cents, Scott On Sat, Feb 4, 2012 at 9:48 PM, Erik Christiansen dva...@internode.on.netwrote: On 04.02.12 16:25, Michael Haberler wrote: This is different from the original language: the pre-oword syntax was context-free, which is why there's a meaningful EBNF in the Tom Kramer report, and working context-free parsers based on ANTLR and bison like here: http://fennetic.net/irc/emc3/src/emc/interpreter/) It is worth noting here that the link points to another grammar which is empty of working gcodes. Look in: http://fennetic.net/irc/emc3/src/emc/interpreter/rs274ngc-flex-bison/parser.ypp Below the top-level block structure, we see grammar for only expressions and parameter settings. Like the empty grammar posted upthread, it is devoid of any grammar for gcodes. After checking both parser.ypp and the lexer (scanner.l) several times, I find that the letter 'G' is passed through, like a dose of epsom salts, without touching the sides. The so-called parser does not even know that a gcode exists. It looks like an Alphabet parser with some expressions. The empty grammars(*1) put up so far look disappointingly like that first 2% of a grammar that a uni student has to whack together in order to pass computer science 101. All the hard work remains to be done. I wonder if there is one out there with any gcodes in it? On 04.02.12 16:25, Kenneth Lerman wrote: The use of matching labels to resolve ambiguity was just a cheap trick to lower the cost of implementation. There is no reason that we should keep the labels on control structures. We should then follow the same rules that C uses. +1 Erik (*1) Empty of any handling of the input. There's not even a yyerror() function to generate syntax error messages. Since a yacc/bison parser calls that function on any syntax error, it's hard to see how these toys can be called a working grammar. -- The Roman Rule The one who says it cannot be done should never interrupt the one who is doing it. -- 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
Re: [Emc-users] parsing the current language dialect, and describing as EBNF [Was: question on gcode parsing]
For the relatively smaller edge case of those wanting to hand-code sophisticated machine control, gcode (even the LinuxCNC flavor) For a lot of us hand coding is not an edge case, the available free open source cam tools simply do not cater for anything over 3 axis milling. which is just a subset of the users. The poor syntax of the current gcode held me back for a while. Wouldn't it make more sense to just develop something like a simple python API that corresponds to (results in) machine motion operations (it could ultimately generate gcode), and modify the LinuxCNC interface to interpret those files line-by-line (the code displayed and stepped through would be the e.g. python, not gcode). I see no need for anything pythonesk in machine control. This just adds an obscure level of abstraction from the real machine. I too wrote a gcode generator for some of my standard shapes but found it was more elegant to do it in gcode as I could use sensible(ish) variable names. why enter in a form, generate code, transfer, when it is a simple edit to a standard gcode file. Gcode needs bringing up to date we no longer need cater for paper tape. Dave Caroline -- 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
Re: [Emc-users] parsing the current language dialect, and describing as EBNF [Was: question on gcode parsing]
I see no need for anything pythonesk in machine control. This just adds an obscure level of abstraction from the real machine. I too wrote a gcode generator for some of my standard shapes but found it was more elegant to do it in gcode as I could use sensible(ish) variable names. why enter in a form, generate code, transfer, when it is a simple edit to a standard gcode file. Gcode needs bringing up to date we no longer need cater for paper tape. To me your first sentence does not seem congruent with your second. Surely a real scripting language would allow for much more elegance and expressiveness than a gcode language extension. One does not seem necessarily more obscure or abstract than the other to me. Although I must admit I would rather point someone at an existing scripting language tutorial for variables, looping and conditionals than try to explain the LinuxCNC gcode extensions for the same, even with sweeter syntactic sugar. In that sense, using an existing scripting language seems much less obscure. Also, I am not proposing an intermediate step such as filling out a form, generating gcode, etc. The scripting API would be directly interpreted by LinuxCNC, allowing the sort of edit-in-place you describe. Whether it generated gcode or made NML calls (or some other approach) would be an API implementation detail not visible to the person running the program. Hope that helps clarify, Scott -- 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
Re: [Emc-users] parsing the current language dialect, and describing as EBNF [Was: question on gcode parsing]
Am 05.02.2012 um 19:07 schrieb Scott Hasse:
I must admit I've I've watched this thread unfold with a bit
of apprehension. Certainly the current direction has evolved to the point
where the result will likely not be usable for my purposes. I don't see a
way of using a flex/bison-based parser from python apart from native
There is no decision on a language change, or any tools to use at it, at least
I dont see one. I dont even see a proposal.
Btw my post was about a property of the current language, not a tool. That
property poses certain restrictions wrt to the current language on the kind and
way any tool would be used. I've thought myself a bit of Antlr since, and so
far I believe these restrictions apply here as well. I would love to be proven
wrong on that.
bindings, so in terms of having a portable parser or lint-type tool this
would not result in one AFAIK. The grammar might provide a good starting
point for me, though.
Secondly, although gcode is certainly not a great language, I'm not sure I
fully understand the motivation behind yet another custom gcode syntax
extension. I have always thought decoupling was a good basic idea, and IMO
the practical interface between LinuxCNC is a gcode file. As long as this
interface is stable, and ideally as concise and standard as possible, it
allows myriad CAM tools to reliably generate input files. Keeping it dumb
IMO has great benefits. It allows CNC educational programs and those who
learned basic gcode a long while back to continue to be productive.
Whatever happens, I think that the basic concept of a G-code block must be
retained - there is too much knowledge and experience and code out there.
This is why a similar idea like the author package never caught on (see
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?PythonBindings). Note also the current
interpreter has a fairly complete set of Canon Python bindings at the G-code
remapping level, I'm not sure anybody except me used them so far - too low
level, just a building block.
The control structure work added by Ken is very useful. I've worked on flow
control, fixed several issues, and added a feature here and there. However,
there are limitations given the current design. For instance, your lint-type
tool will not be able to decide in the general case whether a given program
*flow* will run or error (just think of subroutine names derived from
parameters - whether that works depends on the parameter value).
Another issue is that the current language drives a machine nicely, but
severely lacks in introspective capabilities. Predefined named parameters
helped a bit, HAL pin access helps a bit, but overall it's not thrilling. I
think I fixed the some aspect of the extensibility deficit with the remapping
work which *embeds* Python, but that works 100% under the hood. Run-from-line
needs work. Conditional breakpoints and the ability to change values during a
breakpoint would be nice.
--
That said, I concur with you that cooking up yet another scripting language is
not necessarily a good idea. Inventing one is fun, but then there's building,
documenting, teaching and maintaining a language with yet another set of
control structures, execution model and syntax, plus the not-so-fun aspect of
backwards compatibility.
Fact is, this project has scarce manpower to work on that. I would thing this
community would be better off reusing other work to the maximum extent
possible, in particular in areas which are not terribly relevant to improve the
actual machine control part of the system, which is the core asset. It's
positively not 'scripting'. And the question remains whether the result will
be worth the effort compared to other alternatives. If the end result doesnt
look all that different from another scripting language, I dont see the
rationale for a build, or extend decision in the first place.
I think using Python would be a terrific and stable base for control structures
and execution model, and would bring the rest of the language for free,
including its documentation, tuorials for humans, an outsourced stream of fixes
and upgrades, IDE's, an active community, other data types, a better
Run-from-Line, conditional breakpoints, you name it. For instance, the recent
proposal to add a string datatype - well, thats in place, and in a better shape
than we ever could.
Again, G-code blocks must be there, there is no point in forcing everybody to
dissolve blocks into a series of function calls.
One option is to retain rs274ngc as a 'domain specific language' in Python.
As an example for what the end user impact would be:
0100 if [#4711 GT 23]
G1 x10 y20
0100 endif
would mutate into something like
if param[4711] 23:
g('G1 x10 y20...')
For linear code old style scripts, and MDI in GUI's, the g('') noise can be
made to disappear if so desired. Flow control would move exclusively to the
Python level. Parameter arithmethic
Re: [Emc-users] parsing the current language dialect, and describing as EBNF
On 05.02.12 18:35, Dave Caroline wrote: For the relatively smaller edge case of those wanting to hand-code sophisticated machine control, gcode (even the LinuxCNC flavor) For a lot of us hand coding is not an edge case, the available free open source cam tools simply do not cater for anything over 3 axis milling. which is just a subset of the users. +1 The constructs of the LinuxCNC extended gcode language are fine for my purposes too. It's just that the current parser infrastructure does not meet the requirements expressed by a number of users: 1) Document the legal grammar. 2) Accept the current gcode extensions without useless obfuscating trash characters surrounding keywords and variable names. (They are only there because the current parser can't cope without. They are not there for user benefit.) 3) In Addition to accepting the _current_gcode_syntax_ (minus the unhelpful guff surrounding keywords and variable names), accept _also_ a more human readable form of the very same _current_gcode_syntax_. Several contributors have expressed interest in exploring this direction. My interpretation is that the other form of the LinuxCNC dialect should make clearer _what_ is programmed, rather than just recording raw machine code, which requires more mental translation effort, and can lead to wasted workpieces when under pressure, or on a hot Friday afternoon. Here, an example or two may be clearer than general arm waving. The HR (human readable) part of my growing dual grammar for an input filter for LinuxCNC currently accepts this input: » ; Setting of the coordinate system to one of the 9 workspaces uses ; a curious hotch-potch of numbers, masquerading as commands. ; Here instead, we state _what_ is happening. Workspace: 1 Workspace: 7 Workspace: 9 Workspace: 10 End « to generate: » G54 G59.1 G59.3 ; - Modal Error: Illegal Workspace M2 « Now the numbering is the same as for G10 L2, and we don't need to remember that G57 is married to G10 L2 P4. Because that part of the grammar and its handling were only written last night, the error handling does not yet display the offending source line. (Perhaps later today. The comments are handled too, but need not be repeated in this post.) Should we, though, be more verbose, using syntax like: » Select Workspace 2 ; Needs to be differentiated from G10 L2: Define Workspace 2 X3.2 Y6.4 « Now, for hand written gcode programs, does such explicitness improve clarity? (Here, I'll duck for cover, and count to fifty. :-) Incidentally is there any documentation for G10 L20 which more clearly explains what it does? Do the two wiki sections mean that L2 sets the nominated workspace origin to axes, expressed in the currently active coordinate system, while L20 sets the current position in the currently active coordinate system to be the position in the nominated workspace given by axes? The grammar also currently translates: Plane: XY to G17 etc. The poor syntax of the current gcode held me back for a while. It seems to be worth working on, then. Wouldn't it make more sense to just develop something like a simple python API that corresponds to (results in) machine motion operations (it could ultimately generate gcode), and modify the LinuxCNC interface to interpret those files line-by-line (the code displayed and stepped through would be the e.g. python, not gcode). I see no need for anything pythonesk in machine control. This just adds an obscure level of abstraction from the real machine. +377 I too wrote a gcode generator for some of my standard shapes but found it was more elegant to do it in gcode as I could use sensible(ish) variable names. why enter in a form, generate code, transfer, when it is a simple edit to a standard gcode file. Yes, my aim is to remain true¹ to the LinuxCNC dialect, just with optionally different pronunciation in one of the two grammars. e.g. End instead of M2, and End_Pallet instead of M30. Gcode needs bringing up to date we no longer need cater for paper tape. May I borrow that for my sig quotes? :-)) I have long felt that it was for paper tape and discrete valve controllers with 8 bytes of memory that those funny numbers were used instead of real commands which humans can read. Granted, if I had them ingrained in my brain, after decades of use, I would not change either. There is no reason to. An optional input filter only provides flexibility to anyone wanting more. The filter I'm playing with will offer decluttered old syntax, and a more human readable form. Should it be completed, its use is discretionary. Its formally documented grammars seem an appropriate foil to the python free-reign available at the other end of the LinuxCNC interpreter, also optional. Erik ¹ That doesn't mean including the useless clutter characters which
[Emc-users] parsing the current language dialect, and describing as EBNF (was: question on gcode parsing)
{this is a bit of language/compiler theory, but then the thread started here;
sorry;)}
One of ideas floating around was to to document the current language as an
EBNF, or an equivalent railroad diagram. An EBNF is a notation for a
context-free languages.
That will not work, because the current LinuxCNC RS274NGC dialect cannot be
described by a context-free grammar in the first place, and hence not as an
EBNF, if one tries to include the control structures as language elements.
This is different from the original language: the pre-oword syntax was
context-free, which is why there's a meaningful EBNF in the Tom Kramer report,
and working context-free parsers based on ANTLR and bison like here:
http://fennetic.net/irc/emc3/src/emc/interpreter/)
To see why the current language is context-sensitive, consider just one example:
program start
o label1 do
...
o label2 while ..
...
o label3 endwhile
...
o label4 while ..
eof
You cannot determine by looking at a context-free grammar alone wether the
interpretation should be either:
1: (do ... while) (endwhile...while) or:
2: (do ... (while ... endwhile) ... while)
To resolve the ambiguity in scope, one needs to match the label *values*:
(label1 == label4) (label2 == label3) - interpretation 1 (in the current
language)
(label1 != label2) - an error at 'endwhile'
This also applies to if/then/elsif/else and repeat/endrepeat.
So the labels constitute the context. Technically, since the labels are
variable keywords, this means a language with a theoretically infinite alphabet.
This has a couple of consequences:
- writing an EBNF is only possibly on a line-by-line basis, not including the
control structures . But then such an EBNF will not tell you wether a given
program is correct wrt current scoping rules, or not, and as such fairly
useless.
- it also means explains why my first attempt at a bison/flex parser *for the
current language* failed to properly recognize current control structures
because as it the stands the parser fails at the above ambiguities. This also
applies to other tools.
This does not mean these tools are unusable, it just means the scanner needs to
tie into the parser or scope stack. It does however mean an EBNF will not fully
encompass all aspects of the language. This might be useful already.
- Michael
ps: this is a clarification of what we have, not a critique - C, and C++ have
similar issues and work just fine, too.
psps: so much for the comment 'G-code is extremely easy to parse.' ;)
--
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
Re: [Emc-users] parsing the current language dialect, and describing as EBNF
The use of matching labels to resolve ambiguity was just a cheap trick
to lower the cost of implementation. There is no reason that we should
keep the labels on control structures. We should then follow the same
rules that C uses.
Ken
On 2/4/2012 10:25 AM, Michael Haberler wrote:
{this is a bit of language/compiler theory, but then the thread started here;
sorry;)}
One of ideas floating around was to to document the current language as an
EBNF, or an equivalent railroad diagram. An EBNF is a notation for a
context-free languages.
That will not work, because the current LinuxCNC RS274NGC dialect cannot be
described by a context-free grammar in the first place, and hence not as an
EBNF, if one tries to include the control structures as language elements.
This is different from the original language: the pre-oword syntax was
context-free, which is why there's a meaningful EBNF in the Tom Kramer
report, and working context-free parsers based on ANTLR and bison like here:
http://fennetic.net/irc/emc3/src/emc/interpreter/)
To see why the current language is context-sensitive, consider just one
example:
program start
o label1 do
...
o label2 while ..
...
o label3 endwhile
...
o label4 while ..
eof
You cannot determine by looking at a context-free grammar alone wether the
interpretation should be either:
1: (do ... while) (endwhile...while) or:
2: (do ... (while ... endwhile) ... while)
To resolve the ambiguity in scope, one needs to match the label *values*:
(label1 == label4) (label2 == label3) - interpretation 1 (in the current
language)
(label1 != label2) - an error at 'endwhile'
This also applies to if/then/elsif/else and repeat/endrepeat.
So the labels constitute the context. Technically, since the labels are
variable keywords, this means a language with a theoretically infinite
alphabet.
This has a couple of consequences:
- writing an EBNF is only possibly on a line-by-line basis, not including the
control structures . But then such an EBNF will not tell you wether a given
program is correct wrt current scoping rules, or not, and as such fairly
useless.
- it also means explains why my first attempt at a bison/flex parser *for the
current language* failed to properly recognize current control structures
because as it the stands the parser fails at the above ambiguities. This also
applies to other tools.
This does not mean these tools are unusable, it just means the scanner needs
to tie into the parser or scope stack. It does however mean an EBNF will not
fully encompass all aspects of the language. This might be useful already.
- Michael
ps: this is a clarification of what we have, not a critique - C, and C++ have
similar issues and work just fine, too.
psps: so much for the comment 'G-code is extremely easy to parse.' ;)
--
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
Re: [Emc-users] parsing the current language dialect, and describing as EBNF [Was: question on gcode parsing]
On 04.02.12 16:25, Michael Haberler wrote: This is different from the original language: the pre-oword syntax was context-free, which is why there's a meaningful EBNF in the Tom Kramer report, and working context-free parsers based on ANTLR and bison like here: http://fennetic.net/irc/emc3/src/emc/interpreter/) It is worth noting here that the link points to another grammar which is empty of working gcodes. Look in: http://fennetic.net/irc/emc3/src/emc/interpreter/rs274ngc-flex-bison/parser.ypp Below the top-level block structure, we see grammar for only expressions and parameter settings. Like the empty grammar posted upthread, it is devoid of any grammar for gcodes. After checking both parser.ypp and the lexer (scanner.l) several times, I find that the letter 'G' is passed through, like a dose of epsom salts, without touching the sides. The so-called parser does not even know that a gcode exists. It looks like an Alphabet parser with some expressions. The empty grammars(*1) put up so far look disappointingly like that first 2% of a grammar that a uni student has to whack together in order to pass computer science 101. All the hard work remains to be done. I wonder if there is one out there with any gcodes in it? On 04.02.12 16:25, Kenneth Lerman wrote: The use of matching labels to resolve ambiguity was just a cheap trick to lower the cost of implementation. There is no reason that we should keep the labels on control structures. We should then follow the same rules that C uses. +1 Erik (*1) Empty of any handling of the input. There's not even a yyerror() function to generate syntax error messages. Since a yacc/bison parser calls that function on any syntax error, it's hard to see how these toys can be called a working grammar. -- The Roman Rule The one who says it cannot be done should never interrupt the one who is doing it. -- 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
