Hi Alan, that is an interesting idea.
from the interpreter perspective there's in principle no issue why some other language couldnt emit canon calls just alike; possible (with a lot of work) note that other parts of linuxcnc have some assumptions about the language, for instance the UI's - not just from the input language, but also features like UI startup, and backend issues like run-from-line, and those assumptions arent spelled out in some spec - you're off to reading code that said, dropping rs274ngc as a language from the scene completely is going to break a lot of corners of linuxcnc, and IMV its not desirable to start with however, I think it possible with limited effort to have a second language basically besides rs274ngc; this would require some minor adaptation of a UI to understand that there's more than one language to execute (as a file, and 'MDI', if you will) and default would be rs274ngc. It is IMV the only realistic migration scenario because it can be done incrementally. flatly the more discussion I read about *designing* a new language, the less I see the point - it would be IMV useless work in building from scratch a new language with stepping, breakpoints, state model, introspection etc and arrive on something less that whats alreday out there in existing other interpreted languages. What I can image is taking an existing interpreter, say Python, and make it understand G-code in some shape or form, and that would call on the existing rs274ngc interpreter. Maybe as a subroutine to start with. You want g-code, well execute that. You want arbitrary data types, external packages, advanced control flow - use Python and fall back to rs274ngc where it makes sense. Given that, one can build arbitrary other languages ontop of Python - there's a lot of tools, packages and experience out there in doing that; training the rs274ngc pony to do the same trick isnt going anywhere. IMV this is all about vehicles, not language preferences. If you have a decent vehicle, you dont have to bother somebody else with your language preferences, just go build it and be done with it, instead of having yet another round of academic discussions in which-language-looks-better-today. Yes, plugins are the stuff which makes projects successful. HAL for instance is one very sucessful plugin mechanism. Comp is another one. We dont have anything of that ontop the language and task executor, and few on the UI side of things and *within* rs274ngc. To clarify: with "plugins" I mean end-user/integrator extensible, not C/TCL-developer extensible. That's just too much of a minority issue. Yes, filters are glorified macros with all the downsides, I dont count them as plugins. - Michael Am 12.02.2012 um 14:03 schrieb Alan: > Hi everyone, > > I have followed the discussion so far with interest. I personally view > gcodes as a very low level language. I guess the addition of owords goes > some way towards improving things. My ideal would be an object based > language for describing the geometry etc of path generation. But my real > reason for commenting is to ask a question. > > Is it possible (i.e could be done reasonably quickly and fairly > simply!!) to change emc so that motion processors became a plugin (in > the same way that eclipse has plugins)? In that way emc could come with > the standard plugin to transcribe current gcode text files into motion > commands but would allow others to write (if they felt inclined) python > plugins, sophisticated Gcode parsers or APT360 parsers etc. > > I suspect the quick answer is no as it would require some very radical > changes to emc's structure, but it would to me be an interesting > development but then again I am a retired hobbyist with a computing > background. > > So my question is really about allowing extensibility in the future. I > do not think that I am talking here about filters which to my limited > understanding are something like a macro facility. Have I got that right > or are they more than that? > > My visualization of a postprocessor plugin is that it would take a file > as input and would output a sequence of low level emc-library motion > commands, so would require that these basic motion commands be made > explicit and publicly accessible. > > I dont know how this would fit in with displays such as Axis and with > kinetics modules but suspect that these could work at the lower level > motion commands. > > If adding plugins is already possible please excuse my ignorance and > point me to how that is possible. > > Thanks > > Alan > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users ------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
