Kent A. Reed wrote:
> I see that I last participated on the first of February. I was diagnosed
> with pneumonia the next day and have been out of it since.
Whew! Been there, done that a few years ago. Hope you are doing better!
Jon
--
On 2/7/2012 5:48 PM, Steve Blackmore wrote:
>> However, fun though that might be, I doubt it would reach completion,
>> >or gain any sort of market acceptance outside a very small subset of
>> >LinuxCNC users, and almost certainly wouldn't expand outside our
>> >project.
> Agreed - May be interesti
On Mon, 6 Feb 2012 10:03:20 +0200, you wrote:
>However, fun though that might be, I doubt it would reach completion,
>or gain any sort of market acceptance outside a very small subset of
>LinuxCNC users, and almost certainly wouldn't expand outside our
>project.
Agreed - May be interesting as an
From: "andy pugh"
To:
Sent: Monday, February 06, 2012 8:03 AM
> However I see no reason why we shouldn't consider starting from
> scratch with a new machine-control language, possibly based on Python
> syntax. I would prefer to see that translated directly into motion
> commands in LinuxCNC ra
On 6 February 2012 04:35, Erik Christiansen wrote:
> Granted, if I had them ingrained in my brain, after decades of use, I
> would not change either. There is no reason to. An optional input filter
> only provides flexibility to anyone wanting more. The filter I'm playing
> with will offer declutt
On 05.02.12 18:35, Dave Caroline wrote:
> >For the relatively smaller edge case of those wanting to
> >hand-code sophisticated machine control, gcode (even the LinuxCNC flavor)
>
> For a lot of us hand coding is not an edge case, the available free
> open source cam tools simply do not cater for a
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
sure, but either way you look at it: if there's a language change, there still
be a need for recognizing the old syntax, either for in-place compatibility or
external automatic conversion
-m
Am 04.02.2012 um 22:25 schrieb Kenneth Lerman:
> The use of matching labels to resolve ambiguity was j
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/
The use of matching labels to resolve ambiguity was just a cheap trick
to lower the cost of implementation. There is no reason that we should
keep the labels on control structures. We should then follow the same
rules that C uses.
Ken
On 2/4/2012 10:25 AM, Michael Haberler wrote:
> {this is a
{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
14 matches
Mail list logo
