subject:"Re\: \[Emc\-users\] question on gcode parsing"

On 01.02.12 20:32, Kenneth Lerman wrote:
 On 01/31/2012 11:14 PM, Erik Christiansen wrote:
  Any need to know the run-time state of a modality before run-time is
  illusory. That which needs to be known at run-time needs to be known at
  run time, not before. It is worth understanding that the run-time value
  of a modality is not part of the grammar. I'm not sure what you're
  basing these imaginary concerns on, but I can't relate them to reality,
  despite some effort  :-)
 
 In the past you've implied this,

When dragged off onto the topic of interpreters, I've had to discuss
what happens _at_ run-time. Now let's read the above paragraph again. ;-)

A language grammar specifies permissible input syntax. It knows nothing
about the (changing) run-time values of variables or states (modalities).

An interpreter _uses_ a grammar, not just to translate input into text
output, as a translator or compiler would, but to execute the code.
Now we have jumped into the run-time universe, and need to track state,
just as we track the values of all the variables.

My current understanding is that a modality ought be initialised at the
start of a gcode program, and changes state according to the run-time
path through the gcode, whether that's straight down the page or dizzy
as a fly dodging the corks dangling round the brim of a swaggy's hat.
That's run-time state, not grammar.

 and roughly three or four posts in the future, you bemoan the fact
 that Haberler's trial grammar is devoid of any explicit gcode
 grammar.  My concerns were based on previous statements that you
 thought this should be done.

Please put those concerns to rest. There is no intrinsic connection
between a grammar and run-time values.

The problem with the absence of gcode grammar from a trial grammar is
that we have moved no nearer to documenting the LinuxCNC dialect,
because the so-called parser was only a tokeniser, blindly passing any
text from G0 to G999.9 inclusive, without recognising any difference
between G76 and G497.6, as you can see here:

Lexer:
gcode   ({digit}{1,3}((\.{digit})?))

([Gg]{opt_ws}{gcode})   {RETURN_TOKEN(token::TGCODE);}

The parser, as shown upthread, does not receive a value with TGCODE, and
there is only this one token for all ten thousand gcodes that it passes
on like a hollow pipe. The parser does _not_even_know_ which gcode it
is blindly letting through. Thus, for LinuxCNC gcode, it is only a
tokeniser in effect, at this stage. Any handling of even one LinuxCNC
gcode remains to be added.

As we were warned when it was posted, it's experimental Mk. 0.1.
My comments just try to clarify what it does now.

 While you could put some grammar rules in place, it is my contention
 that no matter how good the grammar, you will need some semantic
 analysis.

There are clearly different needs out there. The two I'm repeatedly
running back to are; documented grammar, definitely executable, and (if
we can get away with it) a more literate optional input form of the same
LinuxCNC dialect we now use. (There will be some grumbling if it's mixed
in with the grammar for the kosher current form. I'll have to look at
keeping them visually separate, if possible.)
...

 In short, I'm suggesting that:
 1 -- An automated lexer would be useful
 2 -- An automated parser might be useful (if it can give reasonable 
 error messages, etc AND be reasonably modified.) If minor changes 
 require digging through shift/reduce conflicts and trying to resolve 
 them, that might be reason to avoid such technology.

:-)
It might be worth remembering that shift/reduce conflicts arise from an
ambiguous grammar. Their occurrence help us avoid that. Better a grammar
fix, than unpredictable results in the gcode, when swarf and coolant are
flying.

 3 -- A semantic analyzer (whether rule based or coded) will be necessary.

Do you want to prove some property of the gcode program, such as whether
it will ever reach the end?

Erik

-- 
Don't believe everything you hear, or anything you say.


--
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] question on gcode parsing

On 01.02.12 08:42, dave wrote:
 On Wed, 1 Feb 2012 19:34:09 +1100
 Erik Christiansen dva...@internode.on.net wrote:
 
  On 31.01.12 21:45, dave wrote:
  
   To my uncluttered mind ... read blank ... 
   is this a good way to set the state of a machine at any given line
   as a precursor to restart from line no?
  
  IIUC¹, running an interpreter through the code from line 1 to a given
  line, with all external actions suppressed, ought to set the state
  of a machine for that line, if the gcode takes no input, and does no
  probing. i.e. state is dependent only on the running of the gcode.
  (But that's just theory, aka a WAG. Experts may differ.)
  
  Erik
  
  ¹ I'm not sure what part of the 129 lines quoted constitute
  this. ;-)
  
 Erik, 
 The theory seems to work. Years ago I wrote such in C but I put in the
 dropbox and is has gotten lost in my transitions of machines and the
 apparent disappearance of the dropbox. 
 I was just wondering if there was a better way. 

Judging from the several posts warning us that tracking run-time values
of modalities is a problem, I'd say no-one has found a way. (That
doesn't mean ya can't do it with a Quantum computer, IIUC the hype which
surrounds them. ;)

Oh, the pain of losing the blood, sweat, and tears which went into a
good hand-hewn tool. (I have 8 copies of my favourite, and my 300+ pages
of software survival notes. My memory is crumbling 20 years earlier than
Gene's, so I _need_ those notes to remain efficient.)

Erik

-- 
Never worry about theory as long as the machinery does what it's
supposed to do. 
   - Robert A. Heinlein


--
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] question on gcode parsing

2012-02-02 Thread John Kasunich



On Thu, Feb 2, 2012, at 08:20 PM, Erik Christiansen wrote:
 On 01.02.12 20:32, Kenneth Lerman wrote:
  3 -- A semantic analyzer (whether rule based or coded) will be necessary.
 
 Do you want to prove some property of the gcode program, such as whether
 it will ever reach the end?

I've only been loosely following this thread, for example I'm
not sure of the precise distinction between lexer and parser,
etc., nor have I been keeping track of who wants to do what.
But I want to put my 2 cents in.

I think the property of a g-code program that a machinist
is most interested in is will it run on my machine.  That
implies far more checking than a simple parser would do.

For example, G1 without a feedrate set is an error, and needs
a meaningful error message.  Doesn't matter to the machinst
which stage in the parsing/interpreting process generates the
error.  Likewise for arcs that fail because the numbers aren't
precise enough and the endpoint doesn't line up, or an offset
toolpath that causes gouging.  

If you are going to invent a black box (parser, whatever) that
takes in some new dialog and spits out g-code, without doing
all the checks that the interpreter eventually will do, please
think about the machinist.  When the interpreter eventually
does spit out an error that says G3 line 125 endpoint doesn't
match, will the user be able to correlate that to the error
in his actual program?  Especially if the new dialect doesn't
even use the term G3, or if the translator doesn't preserve
line numbers (perhaps by discarding comments or blank lines).
-- 
  John Kasunich
  jmkasun...@fastmail.fm


--
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] question on gcode parsing

2012-02-02 Thread John Kasunich


On Thu, Feb 2, 2012, at 09:11 AM, John Kasunich wrote:
 
 If you are going to invent a black box (parser, whatever) that
 takes in some new dialog and spits out g-code, without doing

I meant dialect, not dialog, sorry

 all the checks that the interpreter eventually will do, please
 think about the machinist.  When the interpreter eventually
 does spit out an error that says G3 line 125 endpoint doesn't
 match, will the user be able to correlate that to the error
 in his actual program?  Especially if the new dialect doesn't
 even use the term G3, or if the translator doesn't preserve
 line numbers (perhaps by discarding comments or blank lines).

-- 
  John Kasunich
  jmkasun...@fastmail.fm


--
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] question on gcode parsing

On 02.02.12 09:11, John Kasunich wrote:
 On Thu, Feb 2, 2012, at 08:20 PM, Erik Christiansen wrote:
  On 01.02.12 20:32, Kenneth Lerman wrote:
   3 -- A semantic analyzer (whether rule based or coded) will be necessary.
  
  Do you want to prove some property of the gcode program, such as whether
  it will ever reach the end?
 
 I've only been loosely following this thread, for example I'm
 not sure of the precise distinction between lexer and parser,

OK, a lexer is basically a text scanner which tokenises the input.
It recognises e.g. any Gxxx word, and passes it to the attached parser,
normally with a different token value for each gcode. In contrast, a
numerical constant is passed as e.g. a CONST token, together with its
numeric value in a parser helper variable, e.g. yyval.

The lexer just lets the parser deal with whole language objects, or
tokens as the jargon goes.

 etc., nor have I been keeping track of who wants to do what.
 But I want to put my 2 cents in.

Thanks for bringing the discussion back toward the user perspective.
The more 2 cents worth, the closer we get to something potentially
useful.

 I think the property of a g-code program that a machinist
 is most interested in is will it run on my machine.  That
 implies far more checking than a simple parser would do.

Yep, I can see that, but as Alan Condit voiced, even a full gcode
grammar (which checks only for legal syntax) is non-trivial to
implement. (And we know that this actually means: Just because you
start, doesn't mean you have the stamina to finish.)

Don't we have the simulator for the purpose of checking whether our
latest gcode gem will it run on my machine? It will take longer to add
simulation-level checking to a front-end filter, originally only
intended to clean up and formalise input syntax.

 For example, G1 without a feedrate set is an error, and needs
 a meaningful error message.  Doesn't matter to the machinst
 which stage in the parsing/interpreting process generates the
 error.

It is the responsibility of an executable grammar to flag any syntax
error, in a human readable manner. Catching them all would be an
incremental affair, with v0.9 being much better than v0.1.

 Likewise for arcs that fail because the numbers aren't
 precise enough and the endpoint doesn't line up, or an offset
 toolpath that causes gouging.  

While technically that's not grammar, because we've now jumped into
semantics, it is quite feasible to embed enough maths in the grammar
leaf code for this terminal, to pick up the first error this early.

What I did in July does already check for some run-time conflicts which
I found in the doco, e.g. Turning on radius compensation in an illegal
plane:

compensation_modality:  RADIUS ON LEFT  {  if (Plane == YZ)
   error(Operation illegal in the YZ plane.) ;
emit( G41) ;
}
 |  RADIUS ON RIGHT { if (Plane == YZ)
   error(Operation illegal in the YZ plane.) ;
emit( G42) ;
}
 |  RADIUS OFF  { emit( G40) ; }
 ;

Note to self: Factorise that raw first cut of the grammar snippet, so
   the error handling code only appears once.

 If you are going to invent a black box (parser, whatever) that
 takes in some new dialog and spits out g-code, without doing
 all the checks that the interpreter eventually will do, please
 think about the machinist.  When the interpreter eventually
 does spit out an error that says G3 line 125 endpoint doesn't
 match, will the user be able to correlate that to the error
 in his actual program?  Especially if the new dialect doesn't
 even use the term G3, or if the translator doesn't preserve
 line numbers (perhaps by discarding comments or blank lines).

Oh. You've changed my mind about chucking out comments. Admittedly, we
couldn't hoik them all out anyway, because of the incomprehensible
weirdness of some comments not actually being comments, but display
statements instead, IIRC.  :-(

Yes, line numbers must correspond, to every feasible extent.
If the user has chosen to use the tool to take Rapid as input, in lieu
of G0, then hopefully he'll have a cheat-sheet on the wall, to cope
with the lower-level machine representation.

All these details are enthusing me for the task of picking up where I
left off, back in July, after a much less enthusiastic on-list
discussion.

Erik

-- 
Programs must be written for people to read, and only incidentally for
machines to execute.- Abelson and Sussman


--
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

Re: [Emc-users] question on gcode parsing

On 03.02.12 12:49, Erik Christiansen wrote:
 What I did in July does already check for some run-time conflicts which
 I found in the doco, e.g. Turning on radius compensation in an illegal
 plane:

The snippet can pick up the conflict in a simple fall-through gcode
program, but not if the axes are set in a function. Anyone doing that is
on their own.

Erik

-- 
Unix was not designed to stop you from doing stupid things,  because
that would also stop you from doing clever things.   - Doug Gwyn


--
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] question on gcode parsing

2012-02-01 Thread Erik Christiansen

On 31.01.12 21:45, dave wrote:

 To my uncluttered mind ... read blank ... 
 is this a good way to set the state of a machine at any given line as a
 precursor to restart from line no?

IIUC¹, running an interpreter through the code from line 1 to a given
line, with all external actions suppressed, ought to set the state of a
machine for that line, if the gcode takes no input, and does no
probing. i.e. state is dependent only on the running of the gcode.
(But that's just theory, aka a WAG. Experts may differ.)

Erik

¹ I'm not sure what part of the 129 lines quoted constitute this. ;-)

-- 
The difference between theory and practice is much smaller in theory
than in practice...


--
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] question on gcode parsing

2012-02-01 Thread Michael Haberler

Another interesting related trawling find, with a some ideas for syntax 
evolution:

A G code precompiler which parses a language based on C control structures, and 
generates rs274ngc gcode for LinuxCNC (including O-word constructs etc). It's 
by a fellow named Lawrence Yu, and its based on PLY/(Python lex yacc), and 
includes some basic yacc grammar for a G-code block syntax

an interesting concept I hadnt thought of: he uses whitespace and 
whitespace/newline combination as language tokens returned by the scanner

it makes a lot of sense to do that for rs274ngc and is a way to deal with Ken's 
'drop whitespace squashing' idea in a backwards-compatible/selectable way and 
within a single parser

its very well hidden from google:

http://tsemsb.blogspot.com/search/label/GCODE
http://tsemsb.blogspot.com/2010/04/cgcc-gcode-with-c-constructs.html

The code isnt online in a readable fashion - one need to download and unpack 
the zip archive:
http://sites.google.com/site/cgcccompiler/CGCC_v101.zip


-m

ps: unfortunately, a quick check of performance of pycparsers with a PLY based 
scanner/parser suggests it needs serious tuning, at least a faster scanner - a 
dozen or so example program needs near 0.5 sec of CPU time 

Am 23.01.2012 um 03:16 schrieb Scott Hasse:

 I understand where you are coming from.  Word order is not important as
 


--
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] question on gcode parsing

2012-02-01 Thread Alan Condit

I have been working for sometime on a subset of RS274ngc parser. I have a 
program on my Mac which reads a dxf file and converts it to RS274ngc and allows 
you to invoke some wizards along with it. The purpose of my parser is to 
re-read the RS274ngc files I create an allow them to be edited and see the 
output on the screen in terms of generated 3d paths.

Long intro but the reason for this post is to say that writing a parser that 
will make sense of the current state of RS274ngc code that is acceptable to 
linuxcnc, is non-trivial. Even the subset that I am trying to handle is not so 
easy. A EBNF parser should reject code (or at least flag it as error) that is 
not legal for linuxcnc. As long as we allow people to define gcodes and or 
mcodes on the fly, it is much more difficult.

I am one of those people who doesn't like code written without any whitespace 
but I have no problem with the current linuxcnc parser/interpreter. My goal 
was/is to be able to generate code that I like, formatted like I want, and that 
is still acceptable to linuxcnc.

I see no benefit to an EBNF parser that is so loose that it will pass anything 
that sort of resembles gcode without flagging invalid code.

Alan
---

Alan Condit
1085 Tierra Ct.
Woodburn, OR 97071

Email -- acon...@ipns.com
Home-Office (503) 982-0906

--
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] question on gcode parsing

2012-02-01 Thread dave

On Wed, 1 Feb 2012 19:34:09 +1100
Erik Christiansen dva...@internode.on.net wrote:

 On 31.01.12 21:45, dave wrote:
 
  To my uncluttered mind ... read blank ... 
  is this a good way to set the state of a machine at any given line
  as a precursor to restart from line no?
 
 IIUC¹, running an interpreter through the code from line 1 to a given
 line, with all external actions suppressed, ought to set the state
 of a machine for that line, if the gcode takes no input, and does no
 probing. i.e. state is dependent only on the running of the gcode.
 (But that's just theory, aka a WAG. Experts may differ.)
 
 Erik
 
 ¹ I'm not sure what part of the 129 lines quoted constitute
 this. ;-)
 
Erik, 
The theory seems to work. Years ago I wrote such in C but I put in the
dropbox and is has gotten lost in my transitions of machines and the
apparent disappearance of the dropbox. 
I was just wondering if there was a better way. 

Dave


--
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] question on gcode parsing

2012-02-01 Thread Kenneth Lerman

On 01/31/2012 11:14 PM, Erik Christiansen wrote:
 On 30.01.12 07:54, Kenneth Lerman wrote:
 On 01/30/2012 12:28 AM, Erik Christiansen wrote:
 What is being missed here is that the present parser does all that you
 fear above, just without the maintainability and documentation benefits
 conferred by a higher level implementation, using powerful tools.

 Erik

 No.  I don't think so.

 The current implementation does it; not the current parser. If we go
 back to the compilation/execution analogy, some error conditions are
 detected at run time; not at compile time.
 There is no compile time. Both the current and future parsers are
 interpreters only, AIUI.

 I don't see how the parser can require that G1 has an Fn clause
 defined on the same or some previously executed line.
 Nor can I. It doesn't. AIUI, gcode executes with whatever value of that
 modaility is current. It does that now, and any new interpreter easily
 does the same. The grammar then _permits_ an Fn clause where we choose.

 The parser knows nothing about execution order; only about lexical
 order. Since the Fn might be hidden away in some subroutine, the parse
 might not have seen it. I would think that knowing whether an Fn is
 active is a difficult problem when looking from the outside, but a
 simple problem from the inside of the run time environment. (Of
 course, feel free to prove me wrong.)
 Any need to know the run-time state of a modality before run-time is
 illusory. That which needs to be known at run-time needs to be known at
 run time, not before. It is worth understanding that the run-time value
 of a modality is not part of the grammar. I'm not sure what you're
 basing these imaginary concerns on, but I can't relate them to reality,
 despite some effort  :-)

In the past you've implied this, and roughly three or four posts in the 
future, you bemoan the fact that Haberler's trial grammar is devoid of 
any explicit gcode grammar.  My concerns were based on previous 
statements that you thought this should be done. While you could put 
some grammar rules in place, it is my contention that no matter how good 
the grammar, you will need some semantic analysis. Once we have that 
requirement, I believe that a framework that tests for appropriate 
semantics (including for example, that there MUST have been a previous 
-- in the execution sense, not the lexical sense -- Fword for G1) will 
be both necessary. If that exists, and I believe that it must, there is 
little extra benefit to having the formal grammar handle some of the cases.

In short, I'm suggesting that:
1 -- An automated lexer would be useful
2 -- An automated parser might be useful (if it can give reasonable 
error messages, etc AND be reasonably modified.) If minor changes 
require digging through shift/reduce conflicts and trying to resolve 
them, that might be reason to avoid such technology.
3 -- A semantic analyzer (whether rule based or coded) will be necessary.

Regards,

Ken
 Don't get me wrong. I agree that we need a better definition of the
 grammar and a more structured implementation. In general, though, I
 prefer recursive descent parsers such as the present parser that is used
 for each line. I consider the ability to generate excellent diagnostic
 and error messages to be worth the effort of hand coding.
 We usually prefer what we're good at. I'm as guilty of that as the next
 bloke. The actual merits of the alternatives have been kicked about
 upthread.

 I wouldn't propose replacing the current parser in the forseeable
 future. Since there is interest in a more readable input syntax,
 expressed several times per year by a subset of LinuxCNC users, I have
 upthread already discussed implementing a filter which supplements the
 existing parser, but does not replace it. That way, there is scope for
 pleasing two groups.

 I recognize that my control structure (o-word) implementation leaves a
 lot to be desired -- to say the least. About its only saving grace is
 that it enables us to do a lot of things we couldn't do before. It must
 be redone in a way that is obviously correct and maintainable.
 As they say, The perfect is the enemy of the good. An available
 practical implementation is superior to any imagined perfection which
 does not yet exist. If the limitations of the current parser have forced
 clutter upon the user, just to get the parser to work, not to improve
 readability, then no-one could do a better job with the current tools.

 And I sincerely want to express my thanks for the working gem that is
 LinuxCNC. It is so infuriatingly easy for someone to come along, after
 all the hard work of making something good out of nothing, and say Ya
 know, we could improve this bit here. But it isn't done to be a PITA.

 There is a large user base which is happy with the status quo. That is
 worth infinitely more than any amount of talk about making the syntax
 prettier. The current implementation satisfactorily makes swarf around
 the globe.

 I

Re: [Emc-users] question on gcode parsing

2012-02-01 Thread Kenneth Lerman

On 02/01/2012 03:34 AM, Erik Christiansen wrote:
 On 31.01.12 21:45, dave wrote:

 To my uncluttered mind ... read blank ...
 is this a good way to set the state of a machine at any given line as a
 precursor to restart from line no?
 IIUC¹, running an interpreter through the code from line 1 to a given
 line, with all external actions suppressed, ought to set the state of a
 machine for that line, if the gcode takes no input, and does no
 probing. i.e. state is dependent only on the running of the gcode.
 (But that's just theory, aka a WAG. Experts may differ.)

 Erik

 ¹ I'm not sure what part of the 129 lines quoted constitute this. ;-)

Unfortunately, if you have control structures that include loops and 
subroutines, the statement restart from line no may have no real 
meaning for some places in the code. Restart from the Nth execution of 
line no might be more meaningful, although it might be difficult for 
the user to determine the appropriate value of N.

A better way to get the desired functionality might be to jog backwards 
along the previously executed path until the desired place in the code 
has been reached. The display could show the runtime subroutine stack 
and any important variables with an ability for the user to select items 
of interest. Of course, the current line would be highlighted.

Then the user could say run from the current position.

Ken

--
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] question on gcode parsing

2012-01-31 Thread Kent A. Reed

On 1/31/2012 1:48 AM, Erik Christiansen wrote:
   3) tools that allow one to treat the grammar as an engineering object,
   e.g., view it, analyze it, manipulate it (refactor, group, etc), and
   extend it. This area was an arid desert the last time I did any related
   technical work.
 Well, BNF does that, and being more lexically inclined than visually,
 I'll admit to doing that sort of stuff for fun.

I'm uncertain about your phrase BNF does that.  Are you doing that 
sort of stuff by hand (the way, I'm sure, that  Tom Kramer created and 
checked his production rules for RS274/NGC) or using software tools that 
can track your work, keep versions, do the sorts of things I mentioned? 
I don't mean with something like CVS or git, which can track anything 
because they know nothing, but with a tool that knows the elements of 
BNF notation. These were totally lacking---my so-called arid 
desert---when I was working in data-exchange standardization.  I'm 
strongly lexically inclined as well (my wife says it's because I'm 
strongly left handed; my dad, in turn, used to joke I'm left handed 
because I was dropped on my head as a baby). Still, it's a bore doing 
all that bookkeeping in text, even if the text is maintained on a 
computer.

If your are using software tools, what tools are they?

 If you do it right, often with tools you've written yourself, then tools
 are the jet fighter of software development.

I totally agree. We used them all the time in the development of 
software driven by information modeling. The STEP activity created its 
own cottage industry for tools supporting the EXPRESS modeling language, 
as has also happened on a much larger scale in the UML world. It's just 
that when it came to parser generation we had only the downstream tools 
like lex/yacc. We had to code the grammars by hand in a form acceptable* 
to the tools. Debugging the grammars was a painful process.

 Yes. It's just the length of the journey, the path to be taken, and just
 precisely where we stop, that's subject to clarification.

Ah, yes, the famous stopping problem.

Regards,
Kent

*sidebar rant: I noticed in a Google search that unnecessary diversity 
of BNF notations apparently continues. If the grammar of any size is 
maintained by hand then there is great reluctance to change downstream 
toolsets if doing so means restating the grammar. I came across a nice 
paper published last year by Vadim Zaytsev BNF WAS HERE... describing 
the development of a meta notation based on the analysis of 77 published 
grammars (contained in language standards, etc.). He concludes that 
their notation allows them to define most of the 42 variant syntactic 
notations. The result supports their development of automatic grammar 
recovery tools.

--
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] question on gcode parsing

2012-01-31 Thread Erik Christiansen

On 30.01.12 07:54, Kenneth Lerman wrote:
 On 01/30/2012 12:28 AM, Erik Christiansen wrote:
  What is being missed here is that the present parser does all that you
  fear above, just without the maintainability and documentation benefits
  conferred by a higher level implementation, using powerful tools.
 
  Erik
 
 No.  I don't think so.
 
 The current implementation does it; not the current parser. If we go 
 back to the compilation/execution analogy, some error conditions are 
 detected at run time; not at compile time.

There is no compile time. Both the current and future parsers are
interpreters only, AIUI.

 I don't see how the parser can require that G1 has an Fn clause
 defined on the same or some previously executed line.

Nor can I. It doesn't. AIUI, gcode executes with whatever value of that
modaility is current. It does that now, and any new interpreter easily
does the same. The grammar then _permits_ an Fn clause where we choose.

 The parser knows nothing about execution order; only about lexical
 order. Since the Fn might be hidden away in some subroutine, the parse
 might not have seen it. I would think that knowing whether an Fn is
 active is a difficult problem when looking from the outside, but a
 simple problem from the inside of the run time environment. (Of
 course, feel free to prove me wrong.)

Any need to know the run-time state of a modality before run-time is
illusory. That which needs to be known at run-time needs to be known at
run time, not before. It is worth understanding that the run-time value
of a modality is not part of the grammar. I'm not sure what you're
basing these imaginary concerns on, but I can't relate them to reality,
despite some effort  :-)

 Don't get me wrong. I agree that we need a better definition of the 
 grammar and a more structured implementation. In general, though, I 
 prefer recursive descent parsers such as the present parser that is used 
 for each line. I consider the ability to generate excellent diagnostic 
 and error messages to be worth the effort of hand coding.

We usually prefer what we're good at. I'm as guilty of that as the next
bloke. The actual merits of the alternatives have been kicked about
upthread.

I wouldn't propose replacing the current parser in the forseeable
future. Since there is interest in a more readable input syntax,
expressed several times per year by a subset of LinuxCNC users, I have
upthread already discussed implementing a filter which supplements the
existing parser, but does not replace it. That way, there is scope for
pleasing two groups.

 I recognize that my control structure (o-word) implementation leaves a 
 lot to be desired -- to say the least. About its only saving grace is 
 that it enables us to do a lot of things we couldn't do before. It must 
 be redone in a way that is obviously correct and maintainable.

As they say, The perfect is the enemy of the good. An available
practical implementation is superior to any imagined perfection which
does not yet exist. If the limitations of the current parser have forced
clutter upon the user, just to get the parser to work, not to improve
readability, then no-one could do a better job with the current tools.

And I sincerely want to express my thanks for the working gem that is
LinuxCNC. It is so infuriatingly easy for someone to come along, after
all the hard work of making something good out of nothing, and say Ya
know, we could improve this bit here. But it isn't done to be a PITA.

There is a large user base which is happy with the status quo. That is
worth infinitely more than any amount of talk about making the syntax
prettier. The current implementation satisfactorily makes swarf around
the globe.

I honestly don't think it must be redone. If we make a filter which
pleases the new look enthusiasts, it'll just generate your o-word
code, for input into the current parser. Whether anyone then ever goes
so far as to merge the two, partly depends on how valuable a fully
documented interpreter grammar is.

 I haven't looked closely at modern automated tools for doing this in a 
 few decades. If they let us generate effective diagnostic information in 
 a straightforward way, we should be using them. On the other hand, the 
 grammar should be simple enough that a hand generated recursive descent 
 parser should do fine.

In practice, the grammar has to be the same as now for the old look,
just with optional # . etc., and optional Rapid instead of G0 for
the new. There cannot be substantial differences, or it's not just
prettified gcode.

And in your last sentence, s/hand generated/auto generated/.
There is no need to spend time or effort on actually writing code for
the parser. Only code snippets to implement the actions of each leaf,
i.e to spit out what we want after interpretation.

The O'Reily Lex  Yacc book is an easy introduction to using tools to
generate lexers and parsers with minimal effort. Admittedly, it takes
time and effort to tame them, but

Re: [Emc-users] question on gcode parsing

2012-01-31 Thread dave

On Wed, 1 Feb 2012 15:14:39 +1100
Erik Christiansen dva...@internode.on.net wrote:

 On 30.01.12 07:54, Kenneth Lerman wrote:
  On 01/30/2012 12:28 AM, Erik Christiansen wrote:
   What is being missed here is that the present parser does all
   that you fear above, just without the maintainability and
   documentation benefits conferred by a higher level
   implementation, using powerful tools.
  
   Erik
  
  No.  I don't think so.
  
  The current implementation does it; not the current parser. If we
  go back to the compilation/execution analogy, some error conditions
  are detected at run time; not at compile time.
 
 There is no compile time. Both the current and future parsers are
 interpreters only, AIUI.
 
  I don't see how the parser can require that G1 has an Fn clause
  defined on the same or some previously executed line.
 
 Nor can I. It doesn't. AIUI, gcode executes with whatever value of
 that modaility is current. It does that now, and any new interpreter
 easily does the same. The grammar then _permits_ an Fn clause where
 we choose.
 
  The parser knows nothing about execution order; only about lexical
  order. Since the Fn might be hidden away in some subroutine, the
  parse might not have seen it. I would think that knowing whether an
  Fn is active is a difficult problem when looking from the outside,
  but a simple problem from the inside of the run time environment.
  (Of course, feel free to prove me wrong.)
 
 Any need to know the run-time state of a modality before run-time is
 illusory. That which needs to be known at run-time needs to be known
 at run time, not before. It is worth understanding that the run-time
 value of a modality is not part of the grammar. I'm not sure what
 you're basing these imaginary concerns on, but I can't relate them to
 reality, despite some effort  :-)
 
  Don't get me wrong. I agree that we need a better definition of the 
  grammar and a more structured implementation. In general, though, I 
  prefer recursive descent parsers such as the present parser that is
  used for each line. I consider the ability to generate excellent
  diagnostic and error messages to be worth the effort of hand coding.
 
 We usually prefer what we're good at. I'm as guilty of that as the
 next bloke. The actual merits of the alternatives have been kicked
 about upthread.
 
 I wouldn't propose replacing the current parser in the forseeable
 future. Since there is interest in a more readable input syntax,
 expressed several times per year by a subset of LinuxCNC users, I have
 upthread already discussed implementing a filter which supplements the
 existing parser, but does not replace it. That way, there is scope for
 pleasing two groups.
 
  I recognize that my control structure (o-word) implementation
  leaves a lot to be desired -- to say the least. About its only
  saving grace is that it enables us to do a lot of things we
  couldn't do before. It must be redone in a way that is obviously
  correct and maintainable.
 
 As they say, The perfect is the enemy of the good. An available
 practical implementation is superior to any imagined perfection
 which does not yet exist. If the limitations of the current parser
 have forced clutter upon the user, just to get the parser to work,
 not to improve readability, then no-one could do a better job with
 the current tools.
 
 And I sincerely want to express my thanks for the working gem that is
 LinuxCNC. It is so infuriatingly easy for someone to come along, after
 all the hard work of making something good out of nothing, and say Ya
 know, we could improve this bit here. But it isn't done to be a PITA.
 
 There is a large user base which is happy with the status quo. That is
 worth infinitely more than any amount of talk about making the syntax
 prettier. The current implementation satisfactorily makes swarf around
 the globe.
 
 I honestly don't think it must be redone. If we make a filter which
 pleases the new look enthusiasts, it'll just generate your o-word
 code, for input into the current parser. Whether anyone then ever goes
 so far as to merge the two, partly depends on how valuable a fully
 documented interpreter grammar is.
 
  I haven't looked closely at modern automated tools for doing this
  in a few decades. If they let us generate effective diagnostic
  information in a straightforward way, we should be using them. On
  the other hand, the grammar should be simple enough that a hand
  generated recursive descent parser should do fine.
 
 In practice, the grammar has to be the same as now for the old
 look, just with optional # . etc., and optional Rapid instead
 of G0 for the new. There cannot be substantial differences, or it's
 not just prettified gcode.
 
 And in your last sentence, s/hand generated/auto generated/.
 There is no need to spend time or effort on actually writing code for
 the parser. Only code snippets to implement the actions of each leaf,
 i.e to spit out what we want after

Re: [Emc-users] question on gcode parsing

2012-01-30 Thread Mark Wendt

On 01/30/2012 01:14 AM, Erik Christiansen wrote:
snippage
 1) Be mnemonic. i.e. give some farnarckling clue as to what the command
 does. (Even MOV is orders of magnitude superior to 0x01 or g01.)


Erik, is this what you meant by farnarkling: 
http://mirror.uncyc.org/wiki/Farnarkling  ;-)  I haven't heard that term 
in years.

snippage
 Erik

Mark

--
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] question on gcode parsing

2012-01-30 Thread Kenneth Lerman

On 01/30/2012 12:28 AM, Erik Christiansen wrote:
 On 29.01.12 23:05, Kenneth Lerman wrote:
 Are you suggesting that a three axis machine where there is
 no A axis should have a different grammar than a four axis machine that
 does have an A axis.
 No, there is no such constraint in the current parser, and there is no
 reason to imagine that there might be in the new. A language like C does
 not constrain whether the user can count by twos or threes, and nor is
 there any connection between a gcode grammar and the peculiarities of a
 specific machine. One grammar handles them all. I think most users
 understand that the machine specifics are entirely dealt with by
 run-time configuration and the gcode input.

 It is worth understanding that the current parser _does_ have a fixed
 grammar, just like the proposed alternative. The significant difference
 is that in the current parser, it is not revealed in a concise
 human-readable form.

 As far as grammars go, the only structural change is transition from an
 amorphous hand-coded parser to a structured auto-generated parser, using
 a formal BNF grammar specification, instead of an undocumented one.

 How would you specify that G1 can have X Y Z values in any order, but
 only one of each? And that in some cases the X Y or Z values are
 optional if they use the same value as a previous line?
 That is trivial, and is achieved without writing any program code to do
 it. Multiple alternatives, independent of order, and optional
 parameters, are the most basic meat of writing a BNF grammar.

 A prior post today shows how a BNF grammar allows alternatives, in any
 order. Here is an example of how to allow an optional parameter:

 tool_options:  /* Empty */
  |  ',' spindle_directive

 As with the rest of the grammar, the code to implement our wishes is
 auto-generated. We just have to get the grammar right. ;-)

 If you read the early chapters in O'Reilly's Lex  Yacc book, you'll
 see how completely straightforward these simple cases are. :-)

 Remember, of course, that when we have subroutines, a previous
 line means a previously executed line.
 An interpreter must retain the state of any modal directive. That's
 rather simple. A translator benefits from doing the same, since it can
 then generate better error messages. The grammar example posted earlier
 today includes an example of this. It's also pretty simple.

 What is being missed here is that the present parser does all that you
 fear above, just without the maintainability and documentation benefits
 conferred by a higher level implementation, using powerful tools.

 Erik

No.  I don't think so.

The current implementation does it; not the current parser. If we go 
back to the compilation/execution analogy, some error conditions are 
detected at run time; not at compile time. I don't see how the parser 
can require that G1 has an Fn clause defined on the same or some 
previously executed line. The parser knows nothing about execution 
order; only about lexical order. Since the Fn might be hidden away in 
some subroutine, the parse might not have seen it. I would think that 
knowing whether an Fn is active is a difficult problem when looking from 
the outside, but a simple problem from the inside of the run time 
environment. (Of course, feel free to prove me wrong.)

Don't get me wrong. I agree that we need a better definition of the 
grammar and a more structured implementation. In general, though, I 
prefer recursive descent parsers such as the present parser that is used 
for each line. I consider the ability to generate excellent diagnostic 
and error messages to be worth the effort of hand coding.

I recognize that my control structure (o-word) implementation leaves a 
lot to be desired -- to say the least. About its only saving grace is 
that it enables us to do a lot of things we couldn't do before. It must 
be redone in a way that is obviously correct and maintainable.

I haven't looked closely at modern automated tools for doing this in a 
few decades. If they let us generate effective diagnostic information in 
a straightforward way, we should be using them. On the other hand, the 
grammar should be simple enough that a hand generated recursive descent 
parser should do fine.

Regards,

Ken

Ken

--
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] question on gcode parsing

2012-01-30 Thread Kent A. Reed

On 1/30/2012 7:54 AM, Kenneth Lerman wrote:
 On 01/30/2012 12:28 AM, Erik Christiansen wrote:
 On 29.01.12 23:05, Kenneth Lerman wrote:
 ...
 ...
 It is worth understanding that the current parser _does_ have a fixed
 grammar, just like the proposed alternative. The significant difference
 is that in the current parser, it is not revealed in a concise
 human-readable form.

 As far as grammars go, the only structural change is transition from an
 amorphous hand-coded parser to a structured auto-generated parser, using
 a formal BNF grammar specification, instead of an undocumented one.

 ..
 As with the rest of the grammar, the code to implement our wishes is
 auto-generated. We just have to get the grammar right. ;-)

 ...


 What is being missed here is that the present parser does all that you
 fear above, just without the maintainability and documentation benefits
 conferred by a higher level implementation, using powerful tools.

 Erik

 No.  I don't think so.

 ...
 Don't get me wrong. I agree that we need a better definition of the
 grammar and a more structured implementation. In general, though, I
 prefer recursive descent parsers such as the present parser that is used
 for each line. I consider the ability to generate excellent diagnostic
 and error messages to be worth the effort of hand coding.

 ...
 I haven't looked closely at modern automated tools for doing this in a
 few decades. If they let us generate effective diagnostic information in
 a straightforward way, we should be using them. On the other hand, the
 grammar should be simple enough that a hand generated recursive descent
 parser should do fine.

 Regards,

 Ken


Like Ken, I haven't looked closely either. I would hope for an 
integrated approach but my google-sense tells me the current situation 
is still one of disconnected islands of automation (not counting various 
student exercises; the work described in some recent theses looks quite 
enticing.)

I would hope for

1) a formal description of the grammar we already have. As Erik points 
out, the LinuxCNC interpreter implicitly defines a grammar. It's just 
hard to tell what the grammar is. It's hard to talk about the language 
without a description of it, and as some of Erik's requests have 
illustrated, the current description is cryptic. If the only outcome of 
the current activity is to come to agreement on this description, I will 
consider it a step forward.

2) a means to express and maintain the grammar in machine-processable 
form. Looking at and maintaining text is a bore.

3) tools that allow one to treat the grammar as an engineering object, 
e.g., view it, analyze it, manipulate it (refactor, group, etc), and 
extend it. This area was an arid desert the last time I did any related 
technical work.

4) tools like lex/yacc (flex/bison), antlr, etc., that can take this 
same machine-processable form and generate all the software goodness 
we've talked about.

My personal interest lies in the first three. I don't know if there is a 
commonly accepted phrase---I saw model-driven engineering in one 
student's thesis---but I became a believer when it came time for us to 
develop a next-generation IGES and discovered that despite the hundreds 
of pages of documentation we didn't have a formal model we could work 
from when it came time to talk about what we wanted. (In the end, we 
simply dumped IGES and created PDES which became STEP. Opinions differ 
on the appropriateness of that decision.)

Note that all of this is just ground work that I would hope gets done in 
advance of all the other topics that have been mixed into this thread 
such as simplified syntax, conversational coding, etc. Note also that it 
can became an endless academic exercise if not kept in leash (I came 
across a 2011 presentation entitled Why program by hand in five days 
what you could spend five years of your life automating?)

And, finally, much of this has already been said by you and others. 
Let's just say we're in violent agreement.

Regards,
Kent


--
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] question on gcode parsing

2012-01-30 Thread Erik Christiansen

On 30.01.12 12:37, Kent A. Reed wrote:
 On 1/30/2012 7:54 AM, Kenneth Lerman wrote:
 I would hope for
 
 1) a formal description of the grammar we already have. As Erik points 
 out, the LinuxCNC interpreter implicitly defines a grammar. It's just 
 hard to tell what the grammar is. It's hard to talk about the language 
 without a description of it, and as some of Erik's requests have 
 illustrated, the current description is cryptic. If the only outcome of 
 the current activity is to come to agreement on this description, I will 
 consider it a step forward.

If others will instruct me in what's legal syntax for any command, then
I'll formalise that in a BNF grammar. (We could look at the sample gcode
grammars on the web, but they're not ours. (And I have to get ready to
go out to dinner tonight, so can't look just now.))

Over a couple of months, we should be able to work out what we believe
the LinuxCNC parser wants to see.

 2) a means to express and maintain the grammar in machine-processable 
 form. Looking at and maintaining text is a bore.

BNF is the most universally comprehended, easy to read, and tools can
generate code from it.

 3) tools that allow one to treat the grammar as an engineering object, 
 e.g., view it, analyze it, manipulate it (refactor, group, etc), and 
 extend it. This area was an arid desert the last time I did any related 
 technical work.

Well, BNF does that, and being more lexically inclined than visually,
I'll admit to doing that sort of stuff for fun.

 4) tools like lex/yacc (flex/bison), antlr, etc., that can take this 
 same machine-processable form and generate all the software goodness 
 we've talked about.
...

 Note that all of this is just ground work that I would hope gets done in 
 advance of all the other topics that have been mixed into this thread 
 such as simplified syntax, conversational coding, etc.

Yes, that's a wise goal. But it is easy for a parser to make the # 
stuff optional, so that users can put it in or omit it, according to
taste. That might help keep us motivated, because we can then use it as
a filter which provides a benefit beyond documentation.

 Note also that it can became an endless academic exercise if not kept
 in leash (I came across a 2011 presentation entitled Why program by
 hand in five days what you could spend five years of your life
 automating?)

In 30 years of software development, I often had team members developing
custom tools (including custom compilers for our own state-machine
languages), and they always allowed us to finish projects faster, and
well within schedule. The very first one blew the socks off colleagues
in Munich, when they gave me telecommunications call-control protocol
changes daily at 9 a.m., and I had the software rejigged by lunch time,
every day. They could then test it in the afternoon. (It was a tiny
compiler which understood the problem-domain language used by the
protocol designers which did most of my work for me. After I'd written
it.)

If you do it right, often with tools you've written yourself, then tools
are the jet fighter of software development.

 And, finally, much of this has already been said by you and others. 
 Let's just say we're in violent agreement.

Yes. It's just the length of the journey, the path to be taken, and just
precisely where we stop, that's subject to clarification. ;-)

Erik

-- 
What is wanted is not the will to believe, but the will to find out, 
which is the exact opposite. 
   - Bertrand Russell, _Sceptical_Essays_, 1928


--
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] question on gcode parsing


Am 29.01.2012 um 06:37 schrieb Erik Christiansen:
 
 
 - wouldnt it be more readable to write:
 
 --
 $var1 = $foo + 1
 $var2 = 10
 
 if $var1  $var 2
  ...
 else
...
 endif
 --
 
 Indeedy, but even the '$' is unnecessary.

I'm not sure whether thats possible in all cases.

There are several syntactic constructs - blocks, expressions, assignments and 
control structures.

The noise in expressions really is only needed within blocks; in assignments, 
and expressions within control structure probably can be completely 'de-noised' 
and probably 'de-dollared' and partially 'de-hashed' too;).

as Ken laid out, the tough decision is disambiguating within blocks by 
re-introducing whitespace as delimiter; or stay with using brackets to delimit 
expressions.

I think its possible to:
- make the bracketing requirement for expressions and assignments in control 
structure tests optional; 
- drop the # requirement for named variables references and assignments in 
above; an introducer for numbered params is still needed
- make the bracketing requirement *within* expressions optional. 
- introduce more natural aliases for the EQ/NE/LT etc operators 

I'm unsure whether the () comment syntax can be disambiguated from normal 
function parameter lists like atan(param); this might need a backtracking 
parser or
stay with brackets and there isnt much that gain.


This is untested conjecture, but I think one could come up with a grammar which 
would still parse the current language and be able to write:

sub func
;blablah
endsub

baz = 0.45
foo = atan[bar * 47.11] ; possible
foo = atan(bar * 47.11) ; unsure - guess not; no much gain either

#43 = foo / 10

if foo  bar
   g10 x[foo * baz]
else
   g0 y[baz] z#43 x[func[10]] ; likely possible
   g0 y[baz] z#43 x[func(10)] ; I guess not
endif

that's less filling, but in effect requires bracketing expressions ins block, 
without requiring it elsewhere, which is a bit confusing. 

It's one possible route. The other is the 'dont squash whitespace' route. That 
is a big decision since the latter isnt backwards compatible.

What I could think of is use Scott's idea of a pretty printer for the current 
language, which could introduce whitespace in blocks as needed. The output 
would likely be compatible with a 'dont squash whitespace' parser. To stay with 
Ken's example, it could rewrite:

'X#AY#B'  into 'X#A Y#B' after which it is possible to drop the # 
variable delimiters and rewrite again into new syntax:

'XA YB'  which would be equivalent to 'X#A Y#B' in the old syntax (or 'X$A 
Y$A' - whatever the ensuing inspired discussion diligently shepherded by the 
EMC board will arrive at ;)

that would mean that despite the non-backwards compatible language change 
automatic upgrade is possible

 Both in the code, selected in the config file or on the command line,
 perhaps? Or mandate a gcode+ keyword on the first line of input, to
 allow either type at run-time?

the latter would break backwards compatibility - that keyword and the rest of 
the file in 'old rs274ngc' syntax wouldnt parse, at least not now and with old 
versions of linuxcnc.

 Manually, a custom regression testing framework, or move to DejaGnu?

IMO the next person to introduce another piece of TCL to linuxcnc should be 
damned to use Forth exclusively for the rest of her life. 
The primary benefit of TCL was to get John Ousterhout tenure at Berkeley, but 
then LSD and BSD came from there too, no coincidence IMO ;)

That shouldnt prevent us to look for a more comprehensive regression testing 
framework. Testing GUI applications 'end to end' is lacking sorely, btw.

 If we could move to a BNF specification of our permissible grammar, then
 the problem would diminish, I think.

An example of a flex/bison parser for something which might eventually resemble 
rs274ngc, in c++, plumbed into the linuxcnc build system (Submakefile) is in 

http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/parser-v2-dev

Its fairly useless and defunct right now but if somebody wants to play based on 
an example which builds its a start.

The grammar in the fennic.net parser needs a lot of work, and the EBNF from the 
Tom Kramer paper too.

-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

Re: [Emc-users] question on gcode parsing

On 29.01.12 09:31, Michael Haberler wrote:
 Am 29.01.2012 um 06:37 schrieb Erik Christiansen:
  --
  $var1 = $foo + 1
  $var2 = 10
  
  if $var1  $var 2
 ...
  else
 ...
  endif
  --
  
  Indeedy, but even the '$' is unnecessary.
 
 I'm not sure whether thats possible in all cases.
 
 There are several syntactic constructs - blocks, expressions,
 assignments and control structures.

 The noise in expressions really is only needed within blocks; in
 assignments, and expressions within control structure probably can be
 completely 'de-noised' and probably 'de-dollared' and partially
 'de-hashed' too;).

To 'de-hash' our cleaner gcode, an alternative means of identifying
numbered parameters would be required. Otherwise they'd be
indistinguishable from simple integers.

My personal preference would be to use the '$' freed up from variable
names to identify numbered parameters, freeing '#' for the comment
delimiter, thus completely disambiguating func (foo + $100) # Comment.

 as Ken laid out, the tough decision is disambiguating within blocks by
 re-introducing whitespace as delimiter; or stay with using brackets to
 delimit expressions.

Perhaps I'm failing to imagine sufficiently pathological syntax cases,
but the only inescapable need for whitespace floating before my eyes is
two consecutive names, and I don't think that occurs in gcode. There
will always be either a parenthesis or operator in between, I suspect.

 I think its possible to:
 - make the bracketing requirement for expressions and assignments in
 control structure tests optional; 
 - drop the # requirement for named variables references and
 assignments in above; an introducer for numbered params is still
 needed
 - make the bracketing requirement *within* expressions optional. 
 - introduce more natural aliases for the EQ/NE/LT etc operators 

+1

 I'm unsure whether the () comment syntax can be disambiguated from
 normal function parameter lists like atan(param); this might need a
 backtracking parser or stay with brackets and there isnt much that
 gain.

I know of no other laguage which has a similar comment kludge.
We can also move up to the standard of having an unambiguous comment
delimiter. One way is described above. It has the merit of increased
consistency with scripting languages encountered by LinuxCNC
integrators, reducing language whiplash when we go from one to another.

 This is untested conjecture, but I think one could come up with a
 grammar which would still parse the current language and be able to
 write:

 sub func
 ;blablah
 endsub
 
 baz = 0.45
 foo = atan[bar * 47.11] ; possible
 foo = atan(bar * 47.11) ; unsure - guess not; no much gain either

Language insularity does have an ongoing cost. I'd be interested to hear
whether the broad user base thinks the last line above looks more like a
function, than the preceding one.

Running with parallel distinct parsers, and a switch word in the input,
has the major advantage that there will be no regression in the old
parser due to the new, and grammar conflicts which might arise in a
combined parser are effortlessly avoided. Trying to be both Arthur and
Martha, at the one time, is usually much more difficult than settling
for alternation.

 #43 = foo / 10

While that could be 'de-hashed' without an alternative numbered
parameter identifier, I don't see how you'd propose to handle:

#43 = foo / #44

 if foo  bar
g10 x[foo * baz]
 else
g0 y[baz] z#43 x[func[10]] ; likely possible
g0 y[baz] z#43 x[func(10)] ; I guess not
 endif
 
 that's less filling, but in effect requires bracketing expressions ins
 block, without requiring it elsewhere, which is a bit confusing. 

With the minor grammar change outlined above, we could have:

g0 y[baz] z$43 x[func(10)]   # I guess so.

To declutter further, this is readily parsable with a simple grammar:

g0 y baz; z $43; x func(10);   # Jeez, readable or wot?

would not necessitate a ' ' delimiter.
And it would be just as parsable if written:

g0 ybaz; z$43; xfunc(10);   # Not as readable, is it?

I might need a stateful lexer to do that easily, but they're simple
enough in lex. (So I often use them straight off.)

Oh, even the latter form would allow names which start with an axis
letter, e.g.:

g0 yyaz; z$43; xzunc(10);   # Not as readable, is it?

 It's one possible route. The other is the 'dont squash whitespace'
 route. That is a big decision since the latter isnt backwards
 compatible.

Still haven't seen a case which needs space delimiters.
(While I like whitespace for readability, I don't favour dependence on
it in the grammar, because humans can't always find the space bar.
Be demanding in your output, but tolerant of your input. is a good
mantra for both a coder and (to a lesser extent) a grammar designer.)
...

  Or mandate a gcode+ keyword on the first line of input, to
  allow either type at run-time?
 
 the latter would break backwards compatibility - that keyword

Re: [Emc-users] question on gcode parsing

2012-01-29 Thread andy pugh

On 29 January 2012 12:29, Erik Christiansen dva...@internode.on.net wrote:

 While that could be 'de-hashed' without an alternative numbered
 parameter identifier, I don't see how you'd propose to handle:

 #43 = foo / #44

I am puzzled how you would handle
foo = 10
oo = 1
g1fooZ100

Is it not a significant problem that every single letter of the
alphabet is already a G-code command?

-- 
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] question on gcode parsing

2012-01-29 Thread Kent A. Reed

On 1/29/2012 12:37 AM, Erik Christiansen wrote:
 On 25.01.12 21:22, Michael Haberler wrote:
 [this should move to emc-developers, which is why I'm cc'ing there]
 It would be a pity if the rest of us were to be excluded. It is a very
 interesting discussion, and the EMC issue was secretive enough. Doing
 the same with possible user syntax improvements seems very unhelpful.


Erik:

There's nothing secretive about emc-developers. Anyone can subscribe 
to the list and anyone can peruse its archive of messages. (see the Wiki)

Perhaps they would feel less like exclusionary clubs had the two lists 
been named, say, emc-usage and emc-technical or emc-internals to 
reflect their topical themes rather than their target audiences.

I try to judge which list is more appropriate for any new message I 
compose. On the other hand, I read and respond to messages regardless of 
where they show up. The record shows the same to be true for Michael and 
many others. Hence, deeply technical discussions can break out on the 
emc-users list as the result of an initial question. Less frequently, 
questions and ensuing discussions typical of new-user problems pop up on 
emc-developers. No harm. No foul.

For me a bigger problem is the nature of email. We click reply and the 
subject line is copied over directly. This makes clear what message we 
are responding to but not what part of the message we are responding to. 
By the second reply, it isn't even clear which message, the original or 
one of its replies, is being responded to. Case in point: I am talking 
about administrative functioning of the email lists in response to a 
point you raised in your message about question of gcode parsing. This 
kind of cloaking happens daily, where the content of a series of replies 
may wander all over the map while the subject line stays distressingly 
constant.

The real world of information and its classification is considerably 
messier than the theoretical one. Sigh.

Regards,
Kent




--
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] question on gcode parsing

On 29.01.12 12:59, andy pugh wrote:
 On 29 January 2012 12:29, Erik Christiansen dva...@internode.on.net wrote:
 
  While that could be 'de-hashed' without an alternative numbered
  parameter identifier, I don't see how you'd propose to handle:
 
  #43 = foo / #44
 
 I am puzzled how you would handle
 foo = 10

If the concern is that it could be confused with F 10, then I'll
cheerfully admit that F should be a keyword in the grammar, as it is
to us, and so no variable may be named F. Thus, there is no problem.

If we imagine a case where disambiguation were not so simple, then a
quick way out is manually coded lookahead. That's not needed here.

 oo = 1

OK, O Codes. They'll all go in a declutter, replaced by their naked
keywords, sub, call, endsub, etc. Each is easily recognised by the
lexer, and a unique token ID passed to the parser, so that it
immediately knows which grammar subclauses apply.

We won't be able to have a variable called call, or a function called
endsub, but oo isn't a keyword, so here it's unambiguously a
variable name, since it is preceded by neither sub nor call.

 g1fooZ100

Is there an axis identifier missing here? If it's supposed to be:

g1YfooZ100

Then the gcode ends at the numeric - alpha transition. The grammar then
demands some {axis_identifier,magnitude} pairs, optionally with embedded
stuff like feedrate. Thus Y foo and Z 100 are easily picked out,
whether spaced or not. Since there is no '#' in front of 100, it is a
literal numeric.

There is no parsing complexity in any of these cases.

 Is it not a significant problem that every single letter of the
 alphabet is already a G-code command?

No, not of itself. So long as we have an unambiguous grammar, then the
parser has no trouble. The grammar tells the parser when a
[xXyYZzUuVvWw] is to be interpreted as an axis ID, rather than the first
letter of a name. To avoid the constraint that a name could not begin
with one of those letters, I would need to employ a stateful lexer, but
that is easy. The parser then fine tunes the lexer's eyesight, token by
token, as it walks along a line of gcode.

Incidentally, spaces in the input are usually eliminated by one line in
the lexer. The parser never sees spaces, so that one line is all the
space handling there is. (Well, that's how I do it, 'cos it's easier.)

The parser is automatically generated from the BNF grammar and its
embedded output actions (coded in C), so it's only necessary to write
the lexer, the grammar, and the leaf actions. The fun begins if the
grammar is ambiguous, resulting in conflicts. Debugging that adds to the
entertainment value.

But I haven't seen a troublesome gcode example yet. :-)

Erik

-- 
... with proper design, the features come cheaply. This approach is
arduous, but continues to succeed.-Dennis Ritchie


--
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] question on gcode parsing

2012-01-29 Thread andy pugh

On 29 January 2012 14:02, Erik Christiansen dva...@internode.on.net wrote:

 oo = 1

 OK, O Codes. They'll all go in a declutter, replaced by their naked
 keywords,

No, that is creating a second named parameter in order to be more
ambiguous later:

 g1fooZ100

 Is there an axis identifier missing here? If it's supposed to be:

 g1YfooZ100

And here is the question? What did I mean?

I was actually meaning feed at the rate defined by the parameter oo,
but how is the parser to know that is what I wanted rather than there
being a missing S (for example) in G1 Sfoo Z100 (not a totally random
case, my machine has a very reluctant S key, I very often type M31000
in MDI)

I think we should keep the # for all variables. It is what humans
reading G-code expect to see.

A linked point is that we seem to be discussing mainly human-generated
G-code, whereas a large proportion of G-code executed by EMC2 machines
is machine-generated. As well as discussing machine-parsing we also
might need to consider machine-generation.

-- 
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] question on gcode parsing

On 29.01.12 14:20, andy pugh wrote:
 On 29 January 2012 14:02, Erik Christiansen dva...@internode.on.net wrote:
 
  oo = 1
 
  OK, O Codes. They'll all go in a declutter, replaced by their naked
  keywords,
 
 No, that is creating a second named parameter in order to be more
 ambiguous later:

Yes, the variable assignment is unmistakable, but the sneaky intent
wasn't. :-)

  g1fooZ100
 
  Is there an axis identifier missing here? If it's supposed to be:
 
  g1YfooZ100
 
 And here is the question? What did I mean?
 
 I was actually meaning feed at the rate defined by the parameter oo,
 but how is the parser to know that is what I wanted rather than there
 being a missing S (for example) in G1 Sfoo Z100 (not a totally random
 case, my machine has a very reluctant S key, I very often type M31000
 in MDI)

As it should, a parser slavishly applies its grammar to the input which
we _do_ provide, not what we didn't. In the BNF grammar, we need to
specify that a feedrate_clause may appear after a g1, as an alternative
to an axis_motion. That causes the 'f' to be recognised as a keyword,
which in turn causes oo to be detected as a variable name. It is
equally straightforward to allow and optional 'S' clause to this part of
the grammar.

What further simplifies the task is that we can, for example, group the
clauses which are common to G0, G1, etc., and give them a name. The part
of the grammar tree for G1 then gets the handling of the common clauses
for free, and we only need to tack on the stuff that G0 doesn't have.
Not only does this reduce coding and testing effort, but it ensures
consistency across commands, where it should exist. i.e. Anything which
is even moderately common in gcode should be specified only once in the
grammar.

To allow removal of the square brackets currently containing an
axis_motion clause, we need alternative clause termination. Upthread I
suggested ';', as is used between elements of a for loop in most
languages. Your line then becomes:

g1foo;Z100

Or if we are in industry, and someone else might need to read it:

g1 foo; z100   # Either GFZ or gfz is easier on humans.

Now a LALR(1) parser can deal not only with that, but also with a
variable named foo or Foo, so long as we configure a stateful lexer,
which is able to look for only a keyword immediately after the G1, and
resume seeing a variable name after the f keyword is consumed.

 I think we should keep the # for all variables. It is what humans
 reading G-code expect to see.

That is admirably achieved by changing nothing, fully maintaining
historical authenticity. I respect such a preference.

The purpose of the proposed changes is expressly to eliminate such
useless visual clutter. My expectation is that if we proceed to
implementation, then users will choose to use one syntax or the other.
The two need to be equivalent in function, but the old clutter need not
adhere to the more readable alternative syntax.

 A linked point is that we seem to be discussing mainly human-generated
 G-code, whereas a large proportion of G-code executed by EMC2 machines
 is machine-generated. As well as discussing machine-parsing we also
 might need to consider machine-generation.

Yes, it needs to be considered, but I don't quite see an impact.
Compatible machine-generated gcode is currently in the historical
format, and it is adequately handled by the existing parser.

The purpose of the decluttered parser is to allow human-generated gcode
to become human readable. If, in time, some machine-generated gcode should
transition to the more readable format, then that's OK too.

One thing with a lex/bison based interpreter is that the implementation
itself contains a BNF specification of the legal grammar. Whether input
is legit or not is easily looked up in one place. And if error messages
are not sufficiently explicit, then it's fairly easy to see if steps can
easily be taken to fix it.

Erik

-- 
Habit is habit, and not to be flung out of the window by any man, but 
coaxed down-stairs a step at a time.
  - Mark Twain, Pudd'nhead Wilson's Calendar


--
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] question on gcode parsing

2012-01-29 Thread Kent A. Reed

On 1/29/2012 10:55 AM, Erik Christiansen wrote:

 ...

 What further simplifies the task is that we can, for example, group the
 clauses which are common to G0, G1, etc., and give them a name. The part
 of the grammar tree for G1 then gets the handling of the common clauses
 for free, and we only need to tack on the stuff that G0 doesn't have.
 Not only does this reduce coding and testing effort, but it ensures
 consistency across commands, where it should exist. i.e. Anything which
 is even moderately common in gcode should be specified only once in the
 grammar.
Whatever qualms I may have about the difficulty of interjecting 
meaningful error messages into an interpreter based on lex'ing and 
parsing is overcome by the benefits you point out here.

Regards,
Kent


--
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] question on gcode parsing


Am 29.01.2012 um 13:59 schrieb andy pugh:

 On 29 January 2012 12:29, Erik Christiansen dva...@internode.on.net wrote:
 
 While that could be 'de-hashed' without an alternative numbered
 parameter identifier, I don't see how you'd propose to handle:
 
 #43 = foo / #44
 
 I am puzzled how you would handle
 foo = 10
 oo = 1
 g1fooZ100
 
 Is it not a significant problem that every single letter of the
 alphabet is already a G-code command?

those can be disambiguated through the '=' which makes it an assignment 
statement wheres the last one is a block

the meaning of 'oo' or 'foo' need not be resolved until its clear whether the 
line is a block or an assignment statement

(I *think* ;)
-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

Re: [Emc-users] question on gcode parsing

On 1/29/2012 9:02 AM, Erik Christiansen wrote:
 On 29.01.12 12:59, andy pugh wrote:
 On 29 January 2012 12:29, Erik Christiansendva...@internode.on.net  wrote:

 While that could be 'de-hashed' without an alternative numbered
 parameter identifier, I don't see how you'd propose to handle:

 #43 = foo / #44
 I am puzzled how you would handle
 foo = 10
 If the concern is that it could be confused with F 10, then I'll
 cheerfully admit that F should be a keyword in the grammar, as it is
 to us, and so no variable may be named F. Thus, there is no problem.

 If we imagine a case where disambiguation were not so simple, then a
 quick way out is manually coded lookahead. That's not needed here.

 oo = 1
 OK, O Codes. They'll all go in a declutter, replaced by their naked
 keywords, sub, call, endsub, etc. Each is easily recognised by the
 lexer, and a unique token ID passed to the parser, so that it
 immediately knows which grammar subclauses apply.

 We won't be able to have a variable called call, or a function called
 endsub, but oo isn't a keyword, so here it's unambiguously a
 variable name, since it is preceded by neither sub nor call.

 g1fooZ100
 Is there an axis identifier missing here? If it's supposed to be:

 g1YfooZ100

 Then the gcode ends at the numeric - alpha transition. The grammar then
 demands some {axis_identifier,magnitude} pairs, optionally with embedded
 stuff like feedrate. Thus Y foo and Z 100 are easily picked out,
 whether spaced or not. Since there is no '#' in front of 100, it is a
 literal numeric.

 There is no parsing complexity in any of these cases.

 Is it not a significant problem that every single letter of the
 alphabet is already a G-code command?
 No, not of itself. So long as we have an unambiguous grammar, then the
 parser has no trouble. The grammar tells the parser when a
 [xXyYZzUuVvWw] is to be interpreted as an axis ID, rather than the first
 letter of a name. To avoid the constraint that a name could not begin
 with one of those letters, I would need to employ a stateful lexer, but
 that is easy. The parser then fine tunes the lexer's eyesight, token by
 token, as it walks along a line of gcode.

 Incidentally, spaces in the input are usually eliminated by one line in
 the lexer. The parser never sees spaces, so that one line is all the
 space handling there is. (Well, that's how I do it, 'cos it's easier.)

 The parser is automatically generated from the BNF grammar and its
 embedded output actions (coded in C), so it's only necessary to write
 the lexer, the grammar, and the leaf actions. The fun begins if the
 grammar is ambiguous, resulting in conflicts. Debugging that adds to the
 entertainment value.

 But I haven't seen a troublesome gcode example yet. :-)

 Erik

Remember that just because a computer can understand a grammar does not 
mean that a person can. (Consider the C++ grammar.)

Also, I'd like to add a requirement to have variables with string 
values (together with some added functions). That's so someone could 
write code that does engraving.

Someone commented about the comment syntax -- using parens to delimit 
comments -- in a somewhat deprecating manner. I'd suggest that it is 
certainly no worse than the /* */ comments in my favorite language. I do 
find it useful to be able to embed a comment in the middle of a line; 
not just at the end.

Ken

--
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] question on gcode parsing


Am 29.01.2012 um 15:20 schrieb andy pugh:
 
 g1YfooZ100
 
 And here is the question? What did I mean?
 
 I was actually meaning feed at the rate defined by the parameter oo,
 but how is the parser to know that is what I wanted rather than there
 being a missing S (for example) in G1 Sfoo Z100 (not a totally random
 case, my machine has a very reluctant S key, I very often type M31000
 in MDI)

that is what I mean with 'either retain bracketing letters' or go the 'make 
whitespace significant' route

g1YfooZ100 is ambiguous as to the end of the feed variable

g1Y Foo Z100 would mean G1Y f#oo Z100 under the 'make whitespace significant' 
rule


 I think we should keep the # for all variables. It is what humans
 reading G-code expect to see.

Fine - that's a decision item.

- 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

Re: [Emc-users] question on gcode parsing

On 1/29/2012 9:20 AM, andy pugh wrote:
 On 29 January 2012 14:02, Erik Christiansendva...@internode.on.net  wrote:

 oo = 1
 OK, O Codes. They'll all go in a declutter, replaced by their naked
 keywords,
 No, that is creating a second named parameter in order to be more
 ambiguous later:

 g1fooZ100
 Is there an axis identifier missing here? If it's supposed to be:

 g1YfooZ100
 And here is the question? What did I mean?

 I was actually meaning feed at the rate defined by the parameter oo,
 but how is the parser to know that is what I wanted rather than there
 being a missing S (for example) in G1 Sfoo Z100 (not a totally random
 case, my machine has a very reluctant S key, I very often type M31000
 in MDI)

 I think we should keep the # for all variables. It is what humans
 reading G-code expect to see.

 A linked point is that we seem to be discussing mainly human-generated
 G-code, whereas a large proportion of G-code executed by EMC2 machines
 is machine-generated. As well as discussing machine-parsing we also
 might need to consider machine-generation.


I like the point that you bring out. Not only does this have to be 
ambiguous, it has to be robust in the case of common errors. One could 
imagine a language where every utterance was grammatically legal. That 
would mean that you could never write an illegal program.

I don't think I would like that. Redundancy in language can be very useful.

Ken


--
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] question on gcode parsing

On 1/29/2012 10:55 AM, Erik Christiansen wrote:
 On 29.01.12 14:20, andy pugh wrote:
 On 29 January 2012 14:02, Erik Christiansendva...@internode.on.net  wrote:

 oo = 1
 OK, O Codes. They'll all go in a declutter, replaced by their naked
 keywords,
 No, that is creating a second named parameter in order to be more
 ambiguous later:
 Yes, the variable assignment is unmistakable, but the sneaky intent
 wasn't. :-)

 g1fooZ100
 Is there an axis identifier missing here? If it's supposed to be:

 g1YfooZ100
 And here is the question? What did I mean?

 I was actually meaning feed at the rate defined by the parameter oo,
 but how is the parser to know that is what I wanted rather than there
 being a missing S (for example) in G1 Sfoo Z100 (not a totally random
 case, my machine has a very reluctant S key, I very often type M31000
 in MDI)
 As it should, a parser slavishly applies its grammar to the input which
 we _do_ provide, not what we didn't. In the BNF grammar, we need to
 specify that a feedrate_clause may appear after a g1, as an alternative
 to an axis_motion. That causes the 'f' to be recognised as a keyword,
 which in turn causes oo to be detected as a variable name. It is
 equally straightforward to allow and optional 'S' clause to this part of
 the grammar.

 What further simplifies the task is that we can, for example, group the
 clauses which are common to G0, G1, etc., and give them a name. The part
 of the grammar tree for G1 then gets the handling of the common clauses
 for free, and we only need to tack on the stuff that G0 doesn't have.
 Not only does this reduce coding and testing effort, but it ensures
 consistency across commands, where it should exist. i.e. Anything which
 is even moderately common in gcode should be specified only once in the
 grammar.
I'd rather NOT have the details of what is mandatory and what is 
optional for various g-codes be part of the grammar. Right now, it is 
pretty straightforward to add a new g-code. I don't think we should 
require modifying the grammar to be necessary to add (or change) a g-code.

 To allow removal of the square brackets currently containing an
 axis_motion clause, we need alternative clause termination. Upthread I
 suggested ';', as is used between elements of a for loop in most
 languages. Your line then becomes:

 g1foo;Z100

 Or if we are in industry, and someone else might need to read it:

 g1 foo; z100   # Either GFZ or gfz is easier on humans.

 Now a LALR(1) parser can deal not only with that, but also with a
 variable named foo or Foo, so long as we configure a stateful lexer,
 which is able to look for only a keyword immediately after the G1, and
 resume seeing a variable name after the f keyword is consumed.

 I think we should keep the # for all variables. It is what humans
 reading G-code expect to see.
 That is admirably achieved by changing nothing, fully maintaining
 historical authenticity. I respect such a preference.

 The purpose of the proposed changes is expressly to eliminate such
 useless visual clutter. My expectation is that if we proceed to
 implementation, then users will choose to use one syntax or the other.
 The two need to be equivalent in function, but the old clutter need not
 adhere to the more readable alternative syntax.

I find it interesting that you consider removing (what you refer to as) 
the clutter makes the code more readable. I consider having the clutter 
more readable. Removing the clutter makes it easier to write (there are 
fewer keystrokes).

A typography analogy might be useful. My understanding is that fonts 
with serifs are easier to read than san-serif fonts. I'm sure that it 
has been suggested that serifs be removed to eliminate clutter.

Redundundancy is sometimes useful. :-)

 A linked point is that we seem to be discussing mainly human-generated
 G-code, whereas a large proportion of G-code executed by EMC2 machines
 is machine-generated. As well as discussing machine-parsing we also
 might need to consider machine-generation.
 Yes, it needs to be considered, but I don't quite see an impact.
 Compatible machine-generated gcode is currently in the historical
 format, and it is adequately handled by the existing parser.

 The purpose of the decluttered parser is to allow human-generated gcode
 to become human readable. If, in time, some machine-generated gcode should
 transition to the more readable format, then that's OK too.

 One thing with a lex/bison based interpreter is that the implementation
 itself contains a BNF specification of the legal grammar. Whether input
 is legit or not is easily looked up in one place. And if error messages
 are not sufficiently explicit, then it's fairly easy to see if steps can
 easily be taken to fix it.

 Erik


Regards,

Ken

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just

Re: [Emc-users] question on gcode parsing


Am 29.01.2012 um 16:55 schrieb Erik Christiansen:
 
 What further simplifies the task is that we can, for example, group the
 clauses which are common to G0, G1, etc., and give them a name. The part

By 'grouping common clauses' do you mean testing for required or permitted 
'words' pertaining to a particular code?

- 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

Re: [Emc-users] question on gcode parsing

2012-01-29 Thread Kirk Wallace

Regarding messing with the g-code interpreter, my vote is that g-code
should describe axis position, feedrate; and spindle speed and
direction, and little more. Everything else should be handled with CAM,
including canned cycles and such. Less is more.

If one insists on improving g-code, I would start over with a language
using keywords rather than letters. The need to to extract the most
context from single symbols is a throwback from when teletypes ran at
300 Baud.

Just my opinion based on very limited experience.
-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/index.html
California, USA


--
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] question on gcode parsing

2012-01-29 Thread andy pugh

On 29 January 2012 18:43, Kirk Wallace kwall...@wallacecompany.com wrote:
 Regarding messing with the g-code interpreter, my vote is that g-code
 should describe axis position, feedrate; and spindle speed and
 direction, and little more. Everything else should be handled with CAM,
 including canned cycles and such. Less is more.

Which FOSS, Linux, CAM system would you suggest?

-- 
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] question on gcode parsing

2012-01-29 Thread John figie

On Jan 29, 2012 12:44 PM, Kirk Wallace kwall...@wallacecompany.com
wrote:

 Regarding messing with the g-code interpreter, my vote is that g-code
 should describe axis position, feedrate; and spindle speed and
 direction, and little more. Everything else should be handled with CAM,
 including canned cycles and such. Less is more.


I would agree if  there were an open source CAM that was good.  I tried
pycam but it is lacking.  Given that I can't afford an expensive package I
find it pretty easy to just write gcode.  Especially for simple things.
--
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] question on gcode parsing

2012-01-29 Thread Dave Caroline

On Sun, Jan 29, 2012 at 6:43 PM, Kirk Wallace
kwall...@wallacecompany.com wrote:
 Regarding messing with the g-code interpreter, my vote is that g-code
 should describe axis position, feedrate; and spindle speed and
 direction, and little more. Everything else should be handled with CAM,
 including canned cycles and such. Less is more.

 If one insists on improving g-code, I would start over with a language
 using keywords rather than letters. The need to to extract the most
 context from single symbols is a throwback from when teletypes ran at
 300 Baud.

There is no open source cam for 5 axis
I know of no other way than hand coding for my machine
I NEED better syntax not less syntax

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] question on gcode parsing

2012-01-29 Thread Kirk Wallace

On Sun, 2012-01-29 at 19:08 +, andy pugh wrote:
 On 29 January 2012 18:43, Kirk Wallace kwall...@wallacecompany.com wrote:
  Regarding messing with the g-code interpreter, my vote is that g-code
  should describe axis position, feedrate; and spindle speed and
  direction, and little more. Everything else should be handled with CAM,
  including canned cycles and such. Less is more.
 
 Which FOSS, Linux, CAM system would you suggest?
 

What little code I've created so far is done by hand, Qcad/dxf2gcode or
Synergy, but it's not LinuxCNC's fault that there aren't more choices.
In my opinion, g-code should be a script for telling the machine how to
operate, not a utility for creating or bypassing code. I just want to
float the Spartan ideal to try to help keep the interpreter and LinuxCNC
from getting bloated.

Over the years I've seen good enough software become bloated to the
point of needing other programs to make them usable again. I like
jumpers instead of Plug-N-Play.
-- 
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/index.html
California, USA


--
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] question on gcode parsing

On 29.01.12 13:12, Kenneth Lerman wrote:
 On 1/29/2012 9:02 AM, Erik Christiansen wrote:
  But I haven't seen a troublesome gcode example yet. :-)

 Remember that just because a computer can understand a grammar does not 
 mean that a person can. (Consider the C++ grammar.)

Point taken. (And perl is C++ cubed, with even authors of perl books
admitting in print that it is execrable. See sig.) Andy's example with
foo and oo is also a prime example. I had no idea what the example
was supposed to mean, but a grammar of your choice would parse it
according to the specified rules even if neither of us correctly
anticipated the outcome.

Gcode should be explicit, and therefore readily understood. Obfuscated
examples, such as Andy's are demonstrably not human readable, but a
parser should not be confused by them, even if we are.

My point is that I believe that all legal gcode is eminently parsable,
and I have yet to see any supposedly pathological gcode example which is
very difficult to parse.

 Also, I'd like to add a requirement to have variables with string 
 values (together with some added functions). That's so someone could 
 write code that does engraving.

That sounds like fun, but I'm not sure how you'd get from ascii to the
G1 moves to produce any font at all. Isn't ascii to gcode a cam
function? The interpreter doesn't generate gcode. is more or less our
primary maxim, AIUI.

 Someone commented about the comment syntax -- using parens to delimit 
 comments -- in a somewhat deprecating manner. I'd suggest that it is 
 certainly no worse than the /* */ comments in my favorite language. I do 
 find it useful to be able to embed a comment in the middle of a line; 
 not just at the end.

Ah, yes, shouldn't exclude embedded comments I suppose.
How about [This is a comment], or This comment style frees up () too.
It's the conflict with the greater utility of () in functions and
expressions, which complicates a parser. Replacing the square brackets
with the more conventional parentheses reduces gcode,s weirdness, making
it human readable with less mind-twisting when moving from all the other
scripting languages an integrator is exposed to.

The embryonic human_readable_syntax to gcode translator which I started
in july last year, using lex/bison, does use the # as comment delimiter,
but I could easily add This comment style as well, allowing use of
either. It's not an attempt at an alternative interpreter, but would
simply be run as a filter.

It would need quite some work before being ready for prime time, since
the current input syntax is made highly readable by using English words
which state what is to happen, rather than cryptic gcode non-mnemonic
cryptic numbers. Gcode veterans would hate it with a vengeance.

For any chance of broader appeal, I'd have to make it also accept
conventional gcode with only decluttering added, I see. I'll have a look
at what it'll take to do that. (Just a suite of alternative grammar
clauses, one up from the leaf level, I expect.)

Erik

-- 
Yes, sometimes Perl looks like line-noise to the uninitiated, but to the  
seasoned Perl programmer, it looks like checksummed line-noise with a 
mission in life.  - The Llama Book

--
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] question on gcode parsing

2012-01-29 Thread Steve Blackmore

On Sun, 29 Jan 2012 10:43:18 -0800, you wrote:

Regarding messing with the g-code interpreter, my vote is that g-code
should describe axis position, feedrate; and spindle speed and
direction, and little more. Everything else should be handled with CAM,
including canned cycles and such. Less is more.

If one insists on improving g-code, I would start over with a language
using keywords rather than letters. The need to to extract the most
context from single symbols is a throwback from when teletypes ran at
300 Baud.

Just my opinion based on very limited experience.

Your limited experience is good, IMO.

My experience comes from working in the commercial world for 40 yrs.

The simpler the code, the better. It doesn't matter these days how long
the code is, but it has to be simple. The guys running CNC machines in
factories are not rocket scientists. They don't have to be.  

Subroutines are a big NO. They are rarely understandable to anyone else
other than the geek who wrote them, and they are impossible to recover
from if anything goes wrong. Canned cycles aren't much better!

None of the modern commercial code I see contains either. Fanuc
controls, in the main, can't feed hold in a canned cycle or subroutine
and recover. They can with plain Gcode.

One of the companies I do a bit for make hydraulic manifolds. They start
with a steel forging. It has over 40 holes drilled and reamed in it and
ALL are threaded for plugs or hose connectors. The rough forgings are
over £1000 each. There are four of these in each machine on a tombstone
mount, one of the risky actions is drilling through end to end, (600mm)
then reaming with a scissor action floating reamer. The whole process is
done with G1 and G0 moves. Not a peck or deep hole cycle in sight.
Simple reason is the ops can hear if it goes wrong, stop the machine,
jog out, rewind a few lines, change tools and carry on.

Some may think it's clever writing fancy subs and others may marvel at
how clever you are reducing 100 to 4 lines of code. Those who actually
work in the real Engineering world often laugh/curse and think - what a


Steve Blackmore
--

--
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] question on gcode parsing

On 29.01.12 11:14, Kent A. Reed wrote:
 On 1/29/2012 10:55 AM, Erik Christiansen wrote:
 
  ...
 
  What further simplifies the task is that we can, for example, group the
  clauses which are common to G0, G1, etc., and give them a name. The part
  of the grammar tree for G1 then gets the handling of the common clauses
  for free, and we only need to tack on the stuff that G0 doesn't have.
  Not only does this reduce coding and testing effort, but it ensures
  consistency across commands, where it should exist. i.e. Anything which
  is even moderately common in gcode should be specified only once in the
  grammar.

 Whatever qualms I may have about the difficulty of interjecting 
 meaningful error messages into an interpreter based on lex'ing and 
 parsing is overcome by the benefits you point out here.

It's good to talk this stuff over then, because we then all have a
better understanding of where we can get to from here, with manageable
effort and useful improvement. (I.e. The perfect is the enemy of the
good.) I just don't know how to generate enthusiasm for a decluttered
amateur-readable syntax which helps us dilettantes up the gcode learning
curve. (As a 30-year programming veteran, I can't hack going back to the
days when we didn't even have an assembler to convert human-readable
mnemonics to the meaningless machine code. There's no difference between
0x01 and G01 in terms of human-readability.)

Error messages can be made meaningful to an experienced user of a tool.
They cannot remove the learning curve which a newcomer to the discipline
must climb, I find. I've seen some unreasonable expectations expressed
by new users, when the primary problem was that they did not understand
that they need to understand the language they're using, and make some
inferences from the hints provided by a translation tool which is not a
tutor. (Well, especially not when it's in beta.)

When developing language translators, I usually have implemented basic
translation, followed by low-hanging (i.e. easy to implement) error
messages, then trickier translation, and finally less obvious error
messages. The latter may continue to be added throughout the life of the
product.

Erik

-- 
Note that this is Perl code and I'm well-aware of the general unparseable
nature of Perl. A most works solution would be fine.
  - Ovid, on Vim Users ML.


--
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] question on gcode parsing

On 29.01.12 13:30, Kenneth Lerman wrote:
 On 1/29/2012 10:55 AM, Erik Christiansen wrote:
  What further simplifies the task is that we can, for example, group the
  clauses which are common to G0, G1, etc., and give them a name. The part
  of the grammar tree for G1 then gets the handling of the common clauses
  for free, and we only need to tack on the stuff that G0 doesn't have.
  Not only does this reduce coding and testing effort, but it ensures
  consistency across commands, where it should exist. i.e. Anything which
  is even moderately common in gcode should be specified only once in the
  grammar.

 I'd rather NOT have the details of what is mandatory and what is 
 optional for various g-codes be part of the grammar. Right now, it is 
 pretty straightforward to add a new g-code. I don't think we should 
 require modifying the grammar to be necessary to add (or change) a g-code.

Oh Deeearr, that's a bit of a problem.
You see, having a BNF grammar specification to eliminate any confusion
over what is legal syntax, is a major purpose of the improvement.
(I believe it is broadly considered a defect in the current parser.)

It is worth understanding that it is not possible to intelligently
generate error messages if the grammar fails to specify what is
mandatory and what is optional for various g-codes. Clearly, that is
the explicit _purpose_ of the grammar.

Having that BNF grammar specification embedded in the new parser means
that it abides by the language specification. A coder cannot diddle the
parsing significantly in a corner of the code.

Changing the BNF specification, and filling in the blanks in the leaf
code, _is_ adding or changing the legal gcode. Nothing else needs to be
done, other than update the documentation, since the parser is
auto-generated from the few keystrokes we have added.

The process is disciplined, highly structured, and minimises hand coding
to the nth degree. There's not a lot of code to wade through.
(Some people will hate it. ;-)
...

  The purpose of the proposed changes is expressly to eliminate such
  useless visual clutter. My expectation is that if we proceed to
  implementation, then users will choose to use one syntax or the other.
  The two need to be equivalent in function, but the old clutter need not
  adhere to the more readable alternative syntax.
 
 I find it interesting that you consider removing (what you refer to as) 
 the clutter makes the code more readable. I consider having the clutter 
 more readable. Removing the clutter makes it easier to write (there are 
 fewer keystrokes).

The change nothing preference is admirably handled by the existing
parser. The alternative syntax can be expected to be alternative. ;-)

My interest in this was reawakened by others expressing distaste at the
obfuscating clutter in the current gcode syntax, yet again. When there's
enough interest, we'll do something about it.

 A typography analogy might be useful. My understanding is that fonts 
 with serifs are easier to read than san-serif fonts. I'm sure that it 
 has been suggested that serifs be removed to eliminate clutter.

I prefer to avoid that clutter too, and don't use serif fonts.

If syntax highlighting is used to impose different colours on different
parts of some code within a line, then I have trouble reading it.

 Redundundancy is sometimes useful. :-)

Hmmm, I don't think it exists in mathematical or programming
expressions, and I abhor it in gcode. To my mind, it only introduces
potential conflict between the parts of the unnecessary duplication.
However, what we have in gcode is not redundancy, but clutter lacking in
any information content of any kind. The variable and function names, as
well as keywords, contain _all_ of the information in their alphanum
names. The surrounding crutches for low capability parsers give nothing to
the user.

Erik

-- 
 Am I correct that perl5-porters is the proper forum for submitting
 my ideas?
I think you didn't get a reply because you used the terms correct and
proper, neither of which has much meaning in Perl culture. :-)
   -Larry Wall


--
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] question on gcode parsing

On 01/29/2012 10:40 PM, Erik Christiansen wrote:
 On 29.01.12 13:30, Kenneth Lerman wrote:
 On 1/29/2012 10:55 AM, Erik Christiansen wrote:
 What further simplifies the task is that we can, for example, group the
 clauses which are common to G0, G1, etc., and give them a name. The part
 of the grammar tree for G1 then gets the handling of the common clauses
 for free, and we only need to tack on the stuff that G0 doesn't have.
 Not only does this reduce coding and testing effort, but it ensures
 consistency across commands, where it should exist. i.e. Anything which
 is even moderately common in gcode should be specified only once in the
 grammar.
 I'd rather NOT have the details of what is mandatory and what is
 optional for various g-codes be part of the grammar. Right now, it is
 pretty straightforward to add a new g-code. I don't think we should
 require modifying the grammar to be necessary to add (or change) a g-code.
 Oh Deeearr, that's a bit of a problem.
 You see, having a BNF grammar specification to eliminate any confusion
 over what is legal syntax, is a major purpose of the improvement.
 (I believe it is broadly considered a defect in the current parser.)
I would put the details of what letter codes are valid for which gcodes 
in the semantics of the implementation of the particular code (the way 
it is  now). Are you suggesting that a three axis machine where there is 
no A axis should have a different grammar than a four axis machine that 
does have an A axis.

I don't believe it would be reasonable to specify the total grammar the 
way you suggest using BNF. How would you specify that G1 can have X Y Z 
values in any order, but only one of each? And that in some cases the X 
Y or Z values are optional if they use the same value as a previous 
line? Remember, of course, that when we have subroutines, a previous 
line means a previously executed line.

Ken
 It is worth understanding that it is not possible to intelligently
 generate error messages if the grammar fails to specify what is
 mandatory and what is optional for various g-codes. Clearly, that is
 the explicit _purpose_ of the grammar.

 Having that BNF grammar specification embedded in the new parser means
 that it abides by the language specification. A coder cannot diddle the
 parsing significantly in a corner of the code.

 Changing the BNF specification, and filling in the blanks in the leaf
 code, _is_ adding or changing the legal gcode. Nothing else needs to be
 done, other than update the documentation, since the parser is
 auto-generated from the few keystrokes we have added.

 The process is disciplined, highly structured, and minimises hand coding
 to the nth degree. There's not a lot of code to wade through.
 (Some people will hate it. ;-)
 ...

 The purpose of the proposed changes is expressly to eliminate such
 useless visual clutter. My expectation is that if we proceed to
 implementation, then users will choose to use one syntax or the other.
 The two need to be equivalent in function, but the old clutter need not
 adhere to the more readable alternative syntax.
 I find it interesting that you consider removing (what you refer to as)
 the clutter makes the code more readable. I consider having the clutter
 more readable. Removing the clutter makes it easier to write (there are
 fewer keystrokes).
 The change nothing preference is admirably handled by the existing
 parser. The alternative syntax can be expected to be alternative. ;-)

 My interest in this was reawakened by others expressing distaste at the
 obfuscating clutter in the current gcode syntax, yet again. When there's
 enough interest, we'll do something about it.

 A typography analogy might be useful. My understanding is that fonts
 with serifs are easier to read than san-serif fonts. I'm sure that it
 has been suggested that serifs be removed to eliminate clutter.
 I prefer to avoid that clutter too, and don't use serif fonts.

 If syntax highlighting is used to impose different colours on different
 parts of some code within a line, then I have trouble reading it.

 Redundundancy is sometimes useful. :-)
 Hmmm, I don't think it exists in mathematical or programming
 expressions, and I abhor it in gcode. To my mind, it only introduces
 potential conflict between the parts of the unnecessary duplication.
 However, what we have in gcode is not redundancy, but clutter lacking in
 any information content of any kind. The variable and function names, as
 well as keywords, contain _all_ of the information in their alphanum
 names. The surrounding crutches for low capability parsers give nothing to
 the user.

 Erik


--
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

Re: [Emc-users] question on gcode parsing

On 29.01.12 19:31, Michael Haberler wrote:
 
 Am 29.01.2012 um 16:55 schrieb Erik Christiansen:
  
  What further simplifies the task is that we can, for example, group the
  clauses which are common to G0, G1, etc., and give them a name. The part
 
 By 'grouping common clauses' do you mean testing for required or
 permitted 'words' pertaining to a particular code?

Not writing any testing code, no. It's just extracting and re-using some
BNF grammar clauses. You'll get that straight off, I'm sure, but for
casual readers, an example might help. Back in July, I only got as far
as handling a bunch of modal commands, and don't have the G0, G1 example
implemented at this instant, so hopefully some of what is already there
will serve to illustrate the principle of hiving off a group of leaf
clauses into a grammar clause which can be used repeatedly. (Even if the
example clause isn't one which we would re-use, it's probably clear
enough how easy it is to do the same with one we would.)

The following BNF defines a parser-internal modal_directive, for which
it will accept six alternative input clauses: 

modal_directive:  compensation_directive
   |  motion_directive
   |  plane_directive
   |  spindle_directive
   |  tool_directive
   |  workspace_directive
   ;

None of the six are raw input, so they all need to be defined by
lower level grammar clauses. Let's take plane_directive:

plane_directive:  PLANE XY{ plane = XY ; emit( G17) ; }
   |  PLANE ZX{ plane = ZX ; emit( G18) ; }
   |  PLANE YZ{ plane = YZ ; emit( G19) ; }
   |  PLANE UV{ plane = UV ; emit( G17.1) ; }
   |  PLANE WU{ plane = WU ; emit( G18.1) ; }
   |  PLANE VW{ plane = VW ; emit( G19.1) ; }
   ;

Here, PLANE and the following word are both tokens passed by the lexer
as it recognises input keywords. The C code in {} is the leaf action
needed to complete processing.¹

I'll try to put some time aside to implement G0 and G1 translation, but
if we accept that plane_directive: can be mimicked by e.g.
common_options:, then there could be a common set for G0 and G1. The
parameter clauses for G0 and G1 could then look something like:

g0_options: common_options
  ;

g1_options: common_options
  | feedrate_option
  | another_option_not_for_g0
  | yet_another_option_not_for_g0
  ;

In practice, common_options may be just axes words.
Any input on what G1 can take, and G0 can't, is gratefully accepted.
(I'm not finding http://www.linuxcnc.org/docs/html/gcode_main.html
particularly definitive. ;)

I'll take a look at the grammars mentioned upthread, to see if they
contain such information. If we have it, I don't know where.

Another way to proceed is for anyone interested in a decluttered syntax
to pass on what they know about the legal options for one command. After
that's implemented, we'll soon find out if any subsequent user
disagrees.

¹ Being only a translator from a human-readable input form to gcode, the
  actions are only translation and remembering the active modality, not
  least for generating meaningful error messages, such as in this other
  clause:

compensation_modality:  RADIUS ON LEFT  {  if (plane == YZ)
  error(Illegal plane selected.)
   emit( G41)
}
 |  RADIUS ON RIGHT { if (plane == YZ)
  error(Illegal plane selected.)
   emit( G42)
}
 |  RADIUS OFF  { emit( G40) ; }
 ;

Please don't panic about the input syntax. That is easily made more
cryptic and similar to gcode. ;-)

Erik

-- 
[Perl is] more like a tank than a mine field. It may be ugly, but it
shoots straight and gets you where you're going, if you don't mind a few
squashed daisies.- Larry Wall
But how much more?


--
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] question on gcode parsing

On 29.01.12 23:05, Kenneth Lerman wrote:
 Are you suggesting that a three axis machine where there is 
 no A axis should have a different grammar than a four axis machine that 
 does have an A axis.

No, there is no such constraint in the current parser, and there is no
reason to imagine that there might be in the new. A language like C does
not constrain whether the user can count by twos or threes, and nor is
there any connection between a gcode grammar and the peculiarities of a
specific machine. One grammar handles them all. I think most users
understand that the machine specifics are entirely dealt with by
run-time configuration and the gcode input.

It is worth understanding that the current parser _does_ have a fixed
grammar, just like the proposed alternative. The significant difference
is that in the current parser, it is not revealed in a concise
human-readable form.

As far as grammars go, the only structural change is transition from an
amorphous hand-coded parser to a structured auto-generated parser, using
a formal BNF grammar specification, instead of an undocumented one.

 How would you specify that G1 can have X Y Z values in any order, but
 only one of each? And that in some cases the X Y or Z values are
 optional if they use the same value as a previous line?

That is trivial, and is achieved without writing any program code to do
it. Multiple alternatives, independent of order, and optional
parameters, are the most basic meat of writing a BNF grammar.

A prior post today shows how a BNF grammar allows alternatives, in any
order. Here is an example of how to allow an optional parameter:

tool_options:  /* Empty */
|  ',' spindle_directive

As with the rest of the grammar, the code to implement our wishes is
auto-generated. We just have to get the grammar right. ;-)

If you read the early chapters in O'Reilly's Lex  Yacc book, you'll
see how completely straightforward these simple cases are. :-)

 Remember, of course, that when we have subroutines, a previous 
 line means a previously executed line.

An interpreter must retain the state of any modal directive. That's
rather simple. A translator benefits from doing the same, since it can
then generate better error messages. The grammar example posted earlier
today includes an example of this. It's also pretty simple.

What is being missed here is that the present parser does all that you
fear above, just without the maintainability and documentation benefits
conferred by a higher level implementation, using powerful tools.

Erik

-- 
In general, they do what you want, unless you want consistency.
- Larry Wall in the perl man page


--
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] question on gcode parsing

On 30.01.12 02:33, Steve Blackmore wrote:
 On Sun, 29 Jan 2012 10:43:18 -0800, [Kirk] wrote:
 
 Regarding messing with the g-code interpreter, my vote is that g-code
 should describe axis position, feedrate; and spindle speed and
 direction, and little more. Everything else should be handled with CAM,
 including canned cycles and such. Less is more.

+1

Despite being keen to work towards an optional human readable syntax, it
should perform _identically_ to the current one. (All I have implemented
so far is the beginnings of a filter, so it _can't_ do anything the
current one doesn't.)

 If one insists on improving g-code, I would start over with a language
 using keywords rather than letters. The need to to extract the most
 context from single symbols is a throwback from when teletypes ran at
 300 Baud.

That is what I have begun to do. The syntax might need to be whacked
with a 4lb hammer to displease the least number of users, but it has a
number of goals:

1) Be mnemonic. i.e. give some farnarckling clue as to what the command
   does. (Even MOV is orders of magnitude superior to 0x01 or g01.)

2) Compress the learning curve, by making more explicit what the program
   does. In industry, the benefit is measurable in dollars. It accrues
   from 1).

3) Reduce the number of ruined $2000 workpieces. It is infinitely easier
   to mistype G0 instead of G01, than it is make Rapid out of Move.

   No amount of error checking will pick up a destructive misprogramming
   in legal syntax. Someone else posted that redundancy can be useful.
   When it not only gives the commands explicit meaning, but also helps
   catch typos, then the extra keystrokes can be worth a great deal.

 Just my opinion based on very limited experience.
 
 Your limited experience is good, IMO.
 
 My experience comes from working in the commercial world for 40 yrs.
 
 The simpler the code, the better. It doesn't matter these days how long
 the code is, but it has to be simple. The guys running CNC machines in
 factories are not rocket scientists. They don't have to be.  

In a production environment I imagine that there is not always time to
cross-check a program edit with another employee. Does it ever happen
that G0 instead of G01 (or something even more exciting) goes in,
due to a momentary lapse in mentally converting what-should-happen to
those cryptic codes?

 Subroutines are a big NO. They are rarely understandable to anyone else
 other than the geek who wrote them, and they are impossible to recover
 from if anything goes wrong. Canned cycles aren't much better!

If we all had CAM, I don't think we'd labour over hand written
subroutines either. It's to cope with work which would otherwise need
CAM, that subroutines are a godsend to the amateur user.

Erik

-- 
Programs must be written for people to read, and only incidentally for
machines to execute.- Abelson and Sussman


--
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] question on gcode parsing

2012-01-28 Thread Michael Haberler

a bit of trawling yielded this:

http://fennetic.net/irc/emc3/src/emc/interpreter/

this has rs274 parsers done with ANTLR, and bison/flex

I have no idea what the status is

-m

Am 21.01.2012 um 16:31 schrieb Scott Hasse:

 All-
 
 I'm thinking about writing some gcode filters for EMC2 in python, and want
 to make these as robust and flexible as possible.  To that end, I'm
 wondering if there is a typical approach to parsing and validating
 arbitrary-format gcode into some sort of canonical form so that a
 text-based approach to transformation could be more generically written.  I
 see there is rs274 python bindings, but the API for that is not clear to
 me.  It seems it is for parsing gcode, but I don't see how I would use it
 to pretty print or normalize a gcode file for subsequent processing.
 
 In particular my first goal is a filter that would take XYZ input and with
 some parameters (radius, etc.) wrap the Y axis around an A axis.  Any
 advice on that particular problem or alternate approaches is certainly
 welcome.
 
 I've very much enjoying EMC2 and am working on my second machine conversion
 (an Anilam 3300) using Mesa 5i23 after finishing building and integrating a
 stepper-based rotary table:
 
 http://code.google.com/p/sector67-sandbox/wiki/FourthStepperAxis
 
 Thus my need for some software to generate A axis gcode :-)
 
 Thanks much!
 
 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


--
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] question on gcode parsing

2012-01-28 Thread Kent A. Reed

On 1/28/2012 9:20 AM, Michael Haberler wrote:
 a bit of trawling yielded this:

 http://fennetic.net/irc/emc3/src/emc/interpreter/

 this has rs274 parsers done with ANTLR, and bison/flex

 I have no idea what the status is

 -m


Michael:

Interesting...the directory bits irc/emc3 certainly suggests irc 
conversations on the subject took place some five years ago. Did you 
look at the stuff in the irc/emc3/docs directory? The file 
EMC3_Architecture.doc reads like the conversations on this list the past 
few days.

I suppose a first item of business with the rs274ngc parser code would 
be to examine the grammar. As a start, I just looked at the Parser and 
rs274ngcTokenTypes files. I don't see a case statement or token for the 
O word, so some work has been left to the interested student with 
regard to the flow-control codes. I don't have time to dig deeper.

That this parser work already exists is another proof of something my 
thesis adviser told me long ago: there are rarely new ideas, just new 
attempts to implement them.

Regards,
Kent


--
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] question on gcode parsing

2012-01-28 Thread Michael Haberler


Am 28.01.2012 um 16:20 schrieb Kent A. Reed:

 On 1/28/2012 9:20 AM, Michael Haberler wrote:
 
 http://fennetic.net/irc/emc3/src/emc/interpreter/
 
 
 I suppose a first item of business with the rs274ngc parser code would 
 be to examine the grammar. As a start, I just looked at the Parser and 
 rs274ngcTokenTypes files. I don't see a case statement or token for the 
 O word, so some work has been left to the interested student with 
 regard to the flow-control codes. I don't have time to dig deeper.

I'm having a look at bison parser, I'm more familiar with that.

The syntax clearly predates O-word control structure; UV missing too. It's 
pretty much from the EBNF in the RS274NGC_3 paper.

This obviously never reached production stage - there are numerous typos 
although it compiles. Looks ok to shorten the way though.

.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

Re: [Emc-users] question on gcode parsing

2012-01-25 Thread Michael Haberler

[this should move to emc-developers, which is why I'm cc'ing there]

it just occured to me that a decent parser would give us the opportunity for a 
significant language simplification while retaining backwards compatibility.

An example for the current RS274NGC language with variable references, 
expressions and control structures:

--
#var1 = [#foo + 1]
#var2 = 10

o#label1 if [#var1 lt #var2]
 
o#label1 else

o#label1 endif
--

Note the pathetic amount of syntactic noise - wouldnt it be more readable to 
write:

--
$var1 = $foo + 1
$var2 = 10

if $var1  $var 2
...
else
...
endif
--

We have several noise chars per variable (#), useless labels including noise 
(o#label1) which do not help in disambiguating, and useless brackets around 
expressions, plus, well, fortranesque operators

now the major reason why this is so is that the current scanner only does 
lookahead 1 character, and the parser is inadeaquate; if even Perl can do it, 
so should RS274NGC

A combination of a say flex scanner, bison parser should be able to parse both 
examples unambiguously. Moreover, it should tell during the bison run wether 
there are any ambiguities or conflicts when such a language simplification is 
introduced - it would give a reduce/reduce message. For instance, one could 
experiment wether the '$' as variable introducer is actually necessary (it 
probably is due to ambiguities with words in a block).

I understand this is quite different from you pretty printer/lint goal

If we were to go about this, I think the way to do this is:

- have both parsers as alternatives
- add a flag to sai/rs274 to parse a file with old and new parser
- compare outputs for regression tests
- when it is clear that no ambiguities are left, move it to mainline as the 
default parser

- Michael


--
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] question on gcode parsing

2012-01-23 Thread andy pugh

On 23 January 2012 06:03, Michael Haberler mai...@mah.priv.at wrote:

 A prettyprinter might use whitespace to improve output readability, that's all

Does anyone else indent their loops and subs in G-code?

-- 
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] question on gcode parsing

2012-01-23 Thread Michael Haberler

Am 23.01.2012 um 03:16 schrieb Scott Hasse:

I understand where you are coming from. Word order is not important as
long as you understand how things will be interpreted, and that
understanding matches what actually happens.

I think that point alone would make a pretty printer useful.

During work on the interpreter I added about half a dozen of distinct execution
phases to
http://www.linuxcnc.org/docs/devel/html/gcode/overview.html#sec:Order-of-Execution
by reading the code. It's now *26* phases for executing a block. There might
be a genius out there who looks at a block and divines the execution order
according to that list, and I'm not one of those.

re tools:

my past experience *) is mostly with yacc-type tools but looking around it
seems there are few options for parser generators which are a) usable from
c/c++ and Python and b) are maintained and widely used. ANTLR seems to support
both c and python.

sell me on it ;) is there a good non-Java, python and/or c++ parser example for
a simple language so I understand what we'd be getting into?

-Michael

*;-)
http://www.worldcat.org/title/task-sequencing-language-for-specifying-distributed-ada-systems-tsl-1/oclc/123326453
--
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] question on gcode parsing

2012-01-23 Thread Michael Haberler


Am 23.01.2012 um 11:17 schrieb andy pugh:

 On 23 January 2012 06:03, Michael Haberler mai...@mah.priv.at wrote:
 
 A prettyprinter might use whitespace to improve output readability, that's 
 all
 
 Does anyone else indent their loops and subs in G-code?

me 


--
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] question on gcode parsing

2012-01-23 Thread John Thornton

me

On 1/23/2012 4:17 AM, andy pugh wrote:
 On 23 January 2012 06:03, Michael Haberlermai...@mah.priv.at  wrote:

 A prettyprinter might use whitespace to improve output readability, that's 
 all
 Does anyone else indent their loops and subs in G-code?


--
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] question on gcode parsing

2012-01-23 Thread Martin Dobbins


Yes

Martin

 
 Does anyone else indent their loops and subs in G-code?


 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] question on gcode parsing

2012-01-23 Thread Erik Friesen

Yes, C style.

On Mon, Jan 23, 2012 at 9:47 AM, Martin Dobbins tu...@hotmail.com wrote:


 Yes

 Martin


  Does anyone else indent their loops and subs in G-code?


  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

--
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] question on gcode parsing

2012-01-23 Thread Alan Condit

On Jan 23, 2012, at 2:17 AM,  andy pugh bodge...@gmail.com wrote:

 Does anyone else indent their loops and subs in G-code?
me
---

Alan Condit
1085 Tierra Ct.
Woodburn, OR 97071

Email -- acon...@ipns.com
Home-Office (503) 982-0906

--
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] question on gcode parsing

2012-01-22 Thread Michael Haberler


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

Re: [Emc-users] question on gcode parsing

2012-01-22 Thread Andrea Montefusco

On 01/22/2012 10:46 AM, Michael Haberler wrote:
 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

Maybe you avoid the bnf-C++ step, using some spirit

http://www.boost.org/doc/libs/1_48_0/libs/spirit/doc/html/index.html

(no pun intended)

 *am*

-
Andrea Montefusco iw0hdvhttp://www.montefusco.com
tel: +393356992791 fax: +390623318709
-

--
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] question on gcode parsing

2012-01-22 Thread John Harris

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

Re: [Emc-users] question on gcode parsing

2012-01-22 Thread Kent A. Reed

On 1/22/2012 4:46 AM, Michael Haberler wrote:
 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.
Michael:

I think your list of requirements is a good one and the goal being 
discussed admirable. I just feel an urge to throw out a caution about 
your first requirement.

I never got past idly playing with the primordial Unix tools lex and 
yacc but I when I was actively engaged in the fledgling ISO/STEP 
activity I watched closely as one of NIST's best programmers constructed 
a reference implementation of a compiler for EXPRESS, the language the 
STEP  committee developed for expressing information models. He used all 
the classic compiler construction techniques of the late 1980s. You'd 
think he was working against your list of requirements---or the dragon 
book.

The result was a program that was excellent in a maddening way. If the 
input schema were correct, the compiler would run to completion and 
create lots of stuff that was needed in the creation of software tools 
to work with STEP data. It was widely used inside and outside NIST in 
the creation of production code. However, if the input schema were 
incorrect, the compiler would effectively roll over on its back and die. 
Sure, it emitted error messages but they were obtuse and seldom useful. 
The folks in the ISO/STEP committee writing EXPRESS schemas for their 
various application protocols went crazy trying to use his compiler as a 
diagnostic tool. Their mode of operation was, write a schema, submit, 
amend the schema, submit, looping as many times as needed to get the 
compiler to stop failing.

I had conversations with the author about the need for a student 
compiler---similar in concept to the Waterloo FORTRAN compilers of the 
1960s and 1970s [you youngsters can look them up]---that provided 
copious and useful error and warning messages. His response was that 1) 
it was much harder to say what is wrong than to say something is wrong 
and 2) there was no resource to do all the additional work required. 
(Actually there was also a 3---if I were so committed to the idea, why 
didn't I just do it?)

In particular, he convinced me it is generally difficult to implement 
meaningful error messages in an LALR parser. (Something I've since read 
in various books.)

OK, so EXPRESS is a much more complicated language but I think the 
situation may be similar with G-code. To develop 'industrial-strength 
error diagnosis and recovery requires great discipline. I suspect it 
might even be better not to use the lex/yacc (flex/bison) approach at 
all if one is trying to develop a stand-alone diagnostic tool similar to 
lint.

But, hey, this is just one man's opinion.

The first thing I would do if I were determined to go this route is to 
take the fledging grammar from Tom Kramer's paper, amend it as necessary 
to reflect the LinuxCNC additions to RS274/NGC (testing, of course, to 
see that the result is a valid BNF grammar), pass it through the 
toolchain of choice, and see what it gives me to work with.

I suppose the current LinuxCNC interpreter was heavily influenced by Tom 
Kramer's original RS274/NGC interpreter code. There's a late-model 
version of this code at http://code.google.com/p/rs274ngc/ (aside-This 
version has obviously been touched by others since it now bears a 
copyright statement by Mark Pictor, whom I do not know. The original 
NIST code was not subject to copyright.) I have no idea whether Tom 
passed his grammar through lex/yacc in the creation of his intepreter 
but you can ask him or Mark Pictor. Their email addresses are listed on 
the Google project page.

 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 absolutely agree. In the early days of LinuxCNC development, one 
critic in particular returned to this complaint again and again. I see 
it as the price one pays for open-source development in a widely 
distributed, sparsely populated community that changes over time. One 
never knows what will be the language preference of the person with the 
next great idea (of course this only matters if the person is 
sufficiently committed to the idea to implement it). We already have 
shell scripts, C, C++, tcl/tk, Python (what did I leave out?). Let's not 
add Java if we can help it. It's

Re: [Emc-users] question on gcode parsing

2012-01-22 Thread Scott Hasse

I understand where you are coming from.  Word order is not important as
long as you understand how things will be interpreted, and that
understanding matches what actually happens.  I think this discussion has
ranged across several useful applications for a formalized parser,
including:

1) My original intent, which is to clean up and normalize gcode input so
that subsequent filters can be much more naive yet still safe.  The parser
in this case would fail on malformed input, disambiguate lines to make
things as clear as possible and normalize output, including things like
white space.

I could probably achieve my original use case (wrapping a Y axis around an
A axis) for my specific input files in a very short python program, and it
would serve my purpose.  But that is something I wouldn't feel responsible
releasing to others (even with caveats) because ultimately the code would
be used to move machines, etc.  As a result my work would be a development
dead end and there would be no benefit to LinuxCNC.  I expect there are
one-off translation scripts like this all over the place that will never
see the light of day because of the lack of robustness.  I know I have
several.  Since I have some modest experience as a software developer
writing parsers, this is something (along with the Y-A wrapper filter) I
can work on and hopefully contribute back in exchange for all of the
benefits I have accrued from LinuxCNC.

2) If this parser/validator existed and was portable, it could be used to
verify gcode in general, serving what some developers call a lint
function against gcode (http://en.wikipedia.org/wiki/Lint_%28software%29).
 This might have a positive effect for gcode in the wild, as CAM and motion
control developers could check their output and those considering extending
the language might realize sooner that there are good and bad ways to
extend the language.

3) Further, if the parser/validator was sophisticated enough to understand
the LinuxCNC extensions and could be integrated via C/C++, it could be used
as a front-end to the LinucCNC gcode interpretation process, hopefully
providing more robust parsing and validation, more clear error messages,
and better ability for developers to understand and enhance the parsing
process.

That is the discussion so far at least as far as I understand it.  Michael
has done a nice job of providing some requirements for case #3, which is
probably the hardest case, but those requirements impact how we might go
about #1 and #2 as well, in that we would ideally want to pick a parser
generator that would let us re-use the grammar.

Hope that helps clarify, others please check me if I have this wrong.

Scott

On Sun, Jan 22, 2012 at 9:09 AM, John Harris jdhhar...@customstage.netwrote:

 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

Re: [Emc-users] question on gcode parsing

2012-01-22 Thread dave

On Sun, 22 Jan 2012 20:16:40 -0600
Scott Hasse scott.ha...@gmail.com wrote:

 I understand where you are coming from.  Word order is not important
 as long as you understand how things will be interpreted, and that
 understanding matches what actually happens.  I think this discussion
 has ranged across several useful applications for a formalized parser,
 including:
 
 1) My original intent, which is to clean up and normalize gcode input
 so that subsequent filters can be much more naive yet still safe.
 The parser in this case would fail on malformed input, disambiguate
 lines to make things as clear as possible and normalize output,
 including things like white space.

OUCH! I've become quite used to g-code with no white spaces and would
hate to see that forced on user. If it is an option I have no problem. 
Just my preference. 

Dave
 
 I could probably achieve my original use case (wrapping a Y axis
 around an A axis) for my specific input files in a very short python
 program, and it would serve my purpose.  But that is something I
 wouldn't feel responsible releasing to others (even with caveats)
 because ultimately the code would be used to move machines, etc.  As
 a result my work would be a development dead end and there would be
 no benefit to LinuxCNC.  I expect there are one-off translation
 scripts like this all over the place that will never see the light of
 day because of the lack of robustness.  I know I have several.  Since
 I have some modest experience as a software developer writing
 parsers, this is something (along with the Y-A wrapper filter) I can
 work on and hopefully contribute back in exchange for all of the
 benefits I have accrued from LinuxCNC.
 
 2) If this parser/validator existed and was portable, it could be
 used to verify gcode in general, serving what some developers call a
 lint function against gcode
 (http://en.wikipedia.org/wiki/Lint_%28software%29). This might have a
 positive effect for gcode in the wild, as CAM and motion control
 developers could check their output and those considering extending
 the language might realize sooner that there are good and bad ways to
 extend the language.
 
 3) Further, if the parser/validator was sophisticated enough to
 understand the LinuxCNC extensions and could be integrated via C/C++,
 it could be used as a front-end to the LinucCNC gcode interpretation
 process, hopefully providing more robust parsing and validation, more
 clear error messages, and better ability for developers to understand
 and enhance the parsing process.
 
 That is the discussion so far at least as far as I understand it.
 Michael has done a nice job of providing some requirements for case
 #3, which is probably the hardest case, but those requirements impact
 how we might go about #1 and #2 as well, in that we would ideally
 want to pick a parser generator that would let us re-use the grammar.
 
 Hope that helps clarify, others please check me if I have this wrong.
 
 Scott
 
 On Sun, Jan 22, 2012 at 9:09 AM, John Harris
 jdhhar...@customstage.netwrote:
 
  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
   -

Re: [Emc-users] question on gcode parsing

2012-01-22 Thread Michael Haberler


Am 23.01.2012 um 05:56 schrieb dave:

 On Sun, 22 Jan 2012 20:16:40 -0600
 Scott Hasse scott.ha...@gmail.com wrote:
 
 including things like white space.
 
 OUCH! I've become quite used to g-code with no white spaces and would
 hate to see that forced on user. If it is an option I have no problem. 
 Just my preference. 

A new parsing frontent will not change the *accepted* syntax, so there's 
nothing forced on users

A prettyprinter might use whitespace to improve output readability, that's all

-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

Re: [Emc-users] question on gcode parsing

2012-01-21 Thread Jon Elson

Scott Hasse wrote:
 All-

 I'm thinking about writing some gcode filters for EMC2 in python, and want
 to make these as robust and flexible as possible.  To that end, I'm
 wondering if there is a typical approach to parsing and validating
 arbitrary-format gcode into some sort of canonical form so that a
 text-based approach to transformation could be more generically written.
G-code is extremely easy to parse.  Every numeric value is preceded by a 
letter
telling what it is.  In EMC, there are some special cases like comments and
variables, introduced by ( and #.

Jon

--
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] question on gcode parsing

2012-01-21 Thread Ed Nisley

On Sat, 2012-01-21 at 12:44 -0600, Jon Elson wrote:
 Every numeric value is preceded by a letter telling what it is. 

Except in the wonderful world of RepRap, wherein they're now
(contemplating?) dual-extruder G-Code with multiple numeric values
after the E axis to mix / simultaneously extrude multiple materials:

http://reprap.org/wiki/G-code#M160:_Number_of_mixed_materials

The E axis must then absorb a linear distance of filament, plus the
mix fractions for each material.

The RepRap dialect seems to be diverging fairly rapidly from what the
LinuxCNC parser understands; in particular, their myriad M codes look
like a problem.

-- 
Ed
http://softsolder.com



--
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] question on gcode parsing

2012-01-21 Thread Scott Hasse

I understand the basic parsing for the majority of common cases can be done
fairly easily, but this seems rather error-prone for something that will
eventually be moving a machine.  I am hoping to build something that is
more robust for handling, e.g. inline comments and all of the other special
cases present in the specification.  I then want to expand it further to
perform validation and normalization of the gcode, splitting lines, etc.

There is seemingly a grammar for the language that could be used to

http://www.isd.mel.nist.gov/documents/kramer/RS274VGER_11.pdf  around page
60.

Unless something like this exists, my plan would be to use a parser
generator like antlr to build a parser using that grammar, and then
implement the validation on top of that, verifying using for instance the
modal group rules here:

http://www.linuxcnc.org/docview/html/gcode_overview.html

And ordering things per the actual order of execution rules.  My hope is
that then I will be able to safely use a simple text-based transformation
against the output of this process after the file has been parsed,
normalized and validated.  I am hoping someone at some point did most of
that work, though, in a way that can be used from python in EMC2.

Hope that helps clarify,

Scott

On Sat, Jan 21, 2012 at 1:10 PM, Ed Nisley ed.08.nis...@pobox.com wrote:

 On Sat, 2012-01-21 at 12:44 -0600, Jon Elson wrote:
  Every numeric value is preceded by a letter telling what it is.

 Except in the wonderful world of RepRap, wherein they're now
 (contemplating?) dual-extruder G-Code with multiple numeric values
 after the E axis to mix / simultaneously extrude multiple materials:

 http://reprap.org/wiki/G-code#M160:_Number_of_mixed_materials

 The E axis must then absorb a linear distance of filament, plus the
 mix fractions for each material.

 The RepRap dialect seems to be diverging fairly rapidly from what the
 LinuxCNC parser understands; in particular, their myriad M codes look
 like a problem.

 --
 Ed
 http://softsolder.com




 --
 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] question on gcode parsing


Am 21.01.2012 um 20:10 schrieb Ed Nisley:
 
 The RepRap dialect seems to be diverging fairly rapidly from what the
 LinuxCNC parser understands; in particular, their myriad M codes look
 like a problem.

new M-codes are really easy to introduce into the LinuxCNC G-code interpreter

here's an example where the semantics of the new code is defined by an O-word 
procedure; alternatively by Python: 
http://www.linuxcnc.org/docs/devel/html/remap/structure.html#_an_minimal_example_remapped_code

---

the issue IMO is only marginally technical - like the lack of extensibility or 
plugin capability at the language or UI layers.

I cannot discern any current plans of LinuxCNC project beyond the fabrication 
of next release, or any planning discussion for that matter. And outreach into 
fields like the reprap community doesnt happen by incidental interest alone. So 
there you have it: LinuxCNC in the chipmaking corner of the CNC universe.


- 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

Re: [Emc-users] question on gcode parsing

2012-01-21 Thread Ed Nisley

On Sat, 2012-01-21 at 21:27 +0100, Michael Haberler wrote:
 LinuxCNC in the chipmaking corner of the CNC universe.

Which it does exceedingly well!

For a number of reasons, I don't like the Arduino-based motion control
that's common to DIY 3D printers and would vastly prefer LinuxCNC for
the high-performance printer that's on my far back burner. The language
is close enough, right now, but it'd take some effort to make the answer
come out right; which is why I'm spring-loaded to notice discussions
about parsers.

Returning to my lurking niche...

-- 
Ed
http://softsolder.com



--
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] question on gcode parsing

2012-01-21 Thread Chris Radek

On Sat, Jan 21, 2012 at 12:44:14PM -0600, Jon Elson wrote:

 G-code is extremely easy to parse.  Every numeric value is preceded by a 
 letter telling what it is.  

It depends what variant.  There may be some this simple, for instance
variants that papertape-reading NC machines used are probably close.

But for a modern gcode or for the linuxcnc gcode in particular, this
is not the slightest bit true, and it is a disservice for those in the
know to say it, since inexperienced people hearing it will try to
write regexp-based gcode parsers or other foolishness, and then will
encounter something like

g20#1=0
g#1x#1y#1f100
o100 repeat[100]
g91g1x.01#1=[#1+.01]
g90ysin[#1*360]
o100 endrepeat
m2

where without trying too hard, the only line following that rule is
the last one.


 In EMC, there are some special cases like comments and
 variables, introduced by ( and #.

Yes, and many many other special cases.


--
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] question on gcode parsing


 On Sat, Jan 21, 2012 at 12:44:14PM -0600, Jon Elson wrote:
 
 G-code is extremely easy to parse.  Every numeric value is preceded by a 
 letter telling what it is.  

The LinuxCNC dialect is a context-free language at least with respect to 
expressions and control structures and as such cannot be parsed with regular 
expressions, or by looking at letters (which is equivalent to regexes in 
expressive power).

to build a parser, the best route IMO would be to use a flex/bison type tool 
combination for C/C++; for Python tools can be found here: 
http://wiki.python.org/moin/LanguageParsing (unsure what would be the tool of 
choice these days; Yapps is already used for comp in LinuxCNC)

It would be useful longer term to have such a grammer  scanner combination to 
serve both as a concise executable language definition, and as a basis for both 
LinuxCNC and other tools (like CAM programs) as well.

--

to just parse a program for backplot-type purposes, you might look into using 
the rs274ngc module which sports Python callbacks for machine primitives. An 
example can be found here: http://git.mah.priv.at/gitweb/rs274-python.git

- 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

Re: [Emc-users] question on gcode parsing

2012-01-21 Thread Scott Hasse

In the absence of an existing solution that is basically my plan as stated
above with antlr, which can generate a python parser.  Although once the
grammar is codified, there is no shortage of parser generators that could
be applied.  Some of the reasons Chris points out above lie at the heart of
my motivation as well.  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.

I can certainly say I didn't think there was actually a gcode specification
until long after I was exposed to various flavors of gcode in the wild.  I
think that is probably common, but perhaps not good for consistency of
extension.

The rs274 bindings seem interesting but from what I can tell are geared
toward generating motion type commands (and backplots), and as a native
binding don't really lend themselves well to being a portable
parser/verifier.

Appreciate the input from all so far!

Scott

On Sat, Jan 21, 2012 at 7:36 PM, Michael Haberler mai...@mah.priv.atwrote:


  On Sat, Jan 21, 2012 at 12:44:14PM -0600, Jon Elson wrote:
 
  G-code is extremely easy to parse.  Every numeric value is preceded by a
  letter telling what it is.

 The LinuxCNC dialect is a context-free language at least with respect to
 expressions and control structures and as such cannot be parsed with
 regular expressions, or by looking at letters (which is equivalent to
 regexes in expressive power).

 to build a parser, the best route IMO would be to use a flex/bison type
 tool combination for C/C++; for Python tools can be found here:
 http://wiki.python.org/moin/LanguageParsing (unsure what would be the
 tool of choice these days; Yapps is already used for comp in LinuxCNC)

 It would be useful longer term to have such a grammer  scanner
 combination to serve both as a concise executable language definition, and
 as a basis for both LinuxCNC and other tools (like CAM programs) as well.

 --

 to just parse a program for backplot-type purposes, you might look into
 using the rs274ngc module which sports Python callbacks for machine
 primitives. An example can be found here:
 http://git.mah.priv.at/gitweb/rs274-python.git

 - 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

Re: [Emc-users] question on gcode parsing

2012-01-21 Thread andy pugh

On 21 January 2012 15:31, Scott Hasse scott.ha...@gmail.com wrote:
 To that end, I'm
 wondering if there is a typical approach to parsing and validating
 arbitrary-format gcode into some sort of canonical form

There is a standalone interpreter in the LinuxCNC source, though I am
not sure what it is for, or how it works, or if it works any more. Nor
is it in Python. In fact, I don't know why I am bothering, but I guess
I got this far, and it's now only Ctrl-V
http://git.linuxcnc.org/gitweb?p=emc2.git;a=tree;f=src/emc/sai;h=c01f9e6223e3b713b68f9077c61cf27bdc34dadc;hb=HEAD


-- 
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] question on gcode parsing


Am 22.01.2012 um 03:31 schrieb andy pugh:

 There is a standalone interpreter in the LinuxCNC source, though I am
 not sure what it is for, or how it works, or if it works any more. Nor
 is it in Python. In fact, I don't know why I am bothering, but I guess
 I got this far, and it's now only Ctrl-V
 http://git.linuxcnc.org/gitweb?p=emc2.git;a=tree;f=src/emc/sai;h=c01f9e6223e3b713b68f9077c61cf27bdc34dadc;hb=HEAD

this is the linuxcnc interpreter, just linked with a 'text output only' canon 
(aka machine primitives) layer

to try it out:

$ ./rs274 -g
executing
1 N. USE_LENGTH_UNITS(CANON_UNITS_MM)
2 N. SET_G5X_OFFSET(1, 0., 0., 0., 0., 0., 0.)
3 N. SET_G92_OFFSET(0., 0., 0., 0., 0., 0.)
4 N. SET_XY_ROTATION(0.)
5 N. SET_FEED_REFERENCE(CANON_XYZ)
READ = g0x10y10
6 N. STRAIGHT_TRAVERSE(10., 10., 0., 0., 0., 0.)
READ = 

it is used extensively in automated tests when 'runtests' is executed (that's 
the stuff nobody likes to write, which is why rs274 is terra incognita ;)

-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

Re: [Emc-users] question on gcode parsing