Agreed on all accounts. It is also possible that options 1 and/or 2 could be structure in such a way to support option 3 (simula gdb).
I was serious about the intern thing. If one was interested I would be glad to try to help with mentioning, but I have roughly a petabyte of data to process at work (seriously), and it will be months before I have enough time to pick anything else up, and the couple of side projects I have not already swept under the rug are not getting much love. I cannot take this one on. EBo -- On Nov 9 2015 11:15 AM, Kenneth Lerman wrote: > 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 <[email protected]> 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 >> >> >> <[email protected]> >> >> > >> >> > 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 >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/emc-developers >> ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
