Am 05.02.2012 um 19:07 schrieb Scott Hasse:
> I must admit I've I've watched this thread unfold with a bit
> of apprehension. Certainly the current direction has evolved to the point
> where the result will likely not be usable for my purposes. I don't see a
> way of using a flex/bison-based pa
>
> I see no need for anything pythonesk in machine control. This just
> adds an obscure level of abstraction from the real machine.
>
> I too wrote a gcode generator for some of my standard shapes but found
> it was more elegant to do it in gcode
> as I could use sensible(ish) variable names. why
>For the relatively smaller edge case of those wanting to
>hand-code sophisticated machine control, gcode (even the LinuxCNC flavor)
For a lot of us hand coding is not an edge case, the available free
open source cam tools simply do not cater for anything over 3 axis
milling. which is just a subse
I must admit I've I've watched this thread unfold with a bit
of apprehension. Certainly the current direction has evolved to the point
where the result will likely not be usable for my purposes. I don't see a
way of using a flex/bison-based parser from python apart from native
bindings, so in ter
On 04.02.12 16:25, Michael Haberler wrote:
> This is different from the original language: the pre-oword syntax was
> context-free, which is why there's a meaningful EBNF in the Tom Kramer
> report, and working context-free parsers based on ANTLR and bison like
> here: http://fennetic.net/irc/emc3/
{this is a bit of language/compiler theory, but then the thread started here;
sorry;)}
One of ideas floating around was to to document the current language as an
EBNF, or an equivalent railroad diagram. An EBNF is a notation for a
context-free languages.
That will not work, because the current
