Am 05.02.2012 um 19:07 schrieb Scott Hasse: > I must admit I've I've watched this thread unfold with a bit > of apprehension. Certainly the current direction has evolved to the point > where the result will likely not be usable for my purposes. I don't see a > way of using a flex/bison-based parser from python apart from native
There is no decision on a language change, or any tools to use at it, at least I dont see one. I dont even see a proposal. Btw my post was about a property of the current language, not a tool. That property poses certain restrictions wrt to the current language on the kind and way any tool would be used. I've thought myself a bit of Antlr since, and so far I believe these restrictions apply here as well. I would love to be proven wrong on that. > bindings, so in terms of having a portable parser or lint-type tool this > would not result in one AFAIK. The grammar might provide a good starting > point for me, though. > > Secondly, although gcode is certainly not a great language, I'm not sure I > fully understand the motivation behind yet another custom gcode syntax > extension. I have always thought decoupling was a good basic idea, and IMO > the practical interface between LinuxCNC is a gcode file. As long as this > interface is stable, and ideally as concise and standard as possible, it > allows myriad CAM tools to reliably generate input files. Keeping it dumb > IMO has great benefits. It allows CNC educational programs and those who > learned basic gcode a long while back to continue to be productive. > Whatever happens, I think that the basic concept of a G-code block must be retained - there is too much knowledge and experience and code out there. This is why a similar idea like the author package never caught on (see http://wiki.linuxcnc.org/cgi-bin/wiki.pl?PythonBindings). Note also the current interpreter has a fairly complete set of Canon Python bindings at the G-code remapping level, I'm not sure anybody except me used them so far - too low level, just a building block. The control structure work added by Ken is very useful. I've worked on flow control, fixed several issues, and added a feature here and there. However, there are limitations given the current design. For instance, your lint-type tool will not be able to decide in the general case whether a given program *flow* will run or error (just think of subroutine names derived from parameters - whether that works depends on the parameter value). Another issue is that the current language drives a machine nicely, but severely lacks in introspective capabilities. Predefined named parameters helped a bit, HAL pin access helps a bit, but overall it's not thrilling. I think I fixed the some aspect of the extensibility deficit with the remapping work which *embeds* Python, but that works 100% under the hood. Run-from-line needs work. Conditional breakpoints and the ability to change values during a breakpoint would be nice. -- That said, I concur with you that cooking up yet another scripting language is not necessarily a good idea. Inventing one is fun, but then there's building, documenting, teaching and maintaining a language with yet another set of control structures, execution model and syntax, plus the not-so-fun aspect of backwards compatibility. Fact is, this project has scarce manpower to work on that. I would thing this community would be better off reusing other work to the maximum extent possible, in particular in areas which are not terribly relevant to improve the actual machine control part of the system, which is the core asset. It's positively not 'scripting'. And the question remains whether the result will be worth the effort compared to other alternatives. If the end result doesnt look all that different from another scripting language, I dont see the rationale for a build, or extend decision in the first place. I think using Python would be a terrific and stable base for control structures and execution model, and would bring the rest of the language for free, including its documentation, tuorials for humans, an outsourced stream of fixes and upgrades, IDE's, an active community, other data types, a better Run-from-Line, conditional breakpoints, you name it. For instance, the recent proposal to add a string datatype - well, thats in place, and in a better shape than we ever could. Again, G-code blocks must be there, there is no point in forcing everybody to dissolve blocks into a series of function calls. One option is to retain rs274ngc as a 'domain specific language' in Python. As an example for what the end user impact would be: 0100 if [#4711 GT 23] G1 x10 y20 0100 endif would mutate into something like if param[4711] > 23: g('G1 x10 y20...') For linear code old style scripts, and MDI in GUI's, the g('') noise can be made to disappear if so desired. Flow control would move exclusively to the Python level. Parameter arithmethic can, but need not move, as can assignments. Automatic translation seems viable. It is a language break - thats the a bit of a price, but it has large upside. That approach is quite doable within the limits of this project since much of it is in place, and a known variable; it just needs to come to the forefront. - Michael > > For the relatively smaller edge case of those wanting to > hand-code sophisticated machine control, gcode (even the LinuxCNC flavor) > is already a terrible starting point. Wouldn't it make more sense to just > develop something like a simple python API that corresponds to > (results in) machine motion operations (it could ultimately generate > gcode), and modify the LinuxCNC interface to interpret those files > line-by-line (the code displayed and stepped through would be the e.g. > python, not gcode). Then you would have as much looping, conditional, file > inclusion, etc. as you could hope for. Language design is fun, and there > certainly is a trend toward domain-specific languages, but we already have > many good choices for scripting languages that could be employed to be much > more capable than any sort of gcode extension could ever be. > > Of course, I typically use low-end CAM or write gcode generators, and I am > a relative LinuxCNC newbie, so perhaps I am not understanding the use case > for an incrementally "better" custom gcode vs. using a mature scripting > language. > > My two cents, > > Scott > > ------------------------------------------------------------------------------ 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
