Right now, you get an error together with a line number. A good fix would be to do a stack backtrace. If it is in a subroutine, show the line that it was called from including the values of all of the arguments. Then, if that line is in a subroutine, show where it was called from with its arguments. Recursively.
A second aid that would be handy is to have tracing. As each line is interpreted, output the raw line (and file:linenumber) to a file. Also output the expanded values of any arguments. (So: X[#21+#44] would be output with as X[4.3333] if that's the sum.) When an error is detected, the trace file would be flushed so that the user could look at it. A third aid would be like gdb. It would have the ability to set a breakpoint on a line. It would also cause a "break" when there was an error. Within this tool, one could look at the current subroutine stack, look at local and global named parameters, etc. The first two tools would be pretty easy. The third would be somewhat harder. Ken On Fri, Nov 6, 2015 at 11:11 PM, EBo <e...@sandien.com> wrote: > 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 > -- Kenneth Lerman 55 Main Street Newtown, CT 06470 ------------------------------------------------------------------------------ Presto, an open source distributed SQL query engine for big data, initially developed by Facebook, enables you to easily query your data on Hadoop in a more interactive manner. Teradata is also now providing full enterprise support for Presto. Download a free open source copy now. http://pubads.g.doubleclick.net/gampad/clk?id=250295911&iu=/4140 _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
