On Nov 6 2015 4:44 PM, Gene Heskett wrote: > On Friday 06 November 2015 09:09:26 EBo wrote: > >> On Nov 6 2015 6:39 AM, Gene Heskett wrote: >> > On Friday 06 November 2015 04:53:15 andy pugh wrote: >> >> On 6 November 2015 at 04:29, Fernand Veilleux >> >> <fernveill...@gmail.com> >> > >> > wrote: >> >> > gcode is terrible IMHO. >> >> >> >> It's a terrible programming language, but then it was never >> >> intended to be one. >> > >> > I wouldn't condem it quite that vociferously. It has the basic >> trig >> > functions, all the basic control loop stuff, and several ways to >> do >> > a subroutine. My biggest and loudest bitch is the inability to >> > troubleshoot an errant arc move in a subroutine that may have 10 >> of >> > them >> > in it, it gets blamed on the line that calls the sub. I have had >> > to convert my blanket-chest code from 3 subroutines, to multiple >> > copies of >> > the subroutine but inline. In the process, I probably have 300 >> LOC >> > out >> > of 650 or so that are never executed. Its a horrible mess, but it >> > works. >> >> So then the question is "how do we develop better debugging tools?" >> or at least analytic tools of the results? For example, I can see >> generating a little more output to go from the motion planner to the >> tool path display. If those lines and arcs had the program line >> number somehow associated with it, then you would be able to >> possible >> zoom in and ask a question about a specific line segment displayed. >> It would then tell you which line of code generated it. There might >> also be other metadata you want to associate with it (like depth of >> recursion or stack depth, ... hmmm... I do not know off the top of >> my >> head). If we did not provide analytics, then it would be good to be >> able to step into a subroutine to execute it as well as run a call. >> Last version of LCNC I used had *something* like this, but I do >> remember that it did not play well with subroutines. Not sure about >> the latest and greatest. What I am envisioning here is the GDB >> equivalent of motion control -- full variable querying and setting >> capabilities, and the ability to set break points and other useful >> functionality. >> >> Just a thought... now back to my normal programming... >> >> EBo -- >> > Well, such thoughts would find me encouraging the effort for sure.
I will add this to the end of a 50 level project queue... Seriously though, it might not be that bad to implement. A bit noisy though (but that is what dubug switches are for). Hmmm... maybe if Google Summer of Code sponsored it, this would be a useful idea and suitable for an intern project... EBo -- ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
