> Benoît Minisini ha scritto: > >> If one puts in a breakpoint, and is stepping through the code one line > >> at a time to check values of variables etc, is there any way or > >> re-setting to a line in the same subroutine prior to the current line > >> you have stopped on. > >> > >> I've found sometimes I'm trying to find a bug, and I put in multiple > >> break points so that I can skip from one to another, and then want to > >> check something in the middle that I've gone past, but have to stop the > >> entire program and start again. > > > > Alas you cannot go back in time in debuggers yet. I've heard about people > > thinking about it, but I don't think you will never see it in Gambas! > > This is a serious problem, tough. There are programs which, for one > reason or another, are a little difficult to debug using the internal > gambas debugger. For example, think at a data-entry form, with a lot of > controls, each having validation (perhaps, put on top of a database). If > you want to debug the final action of the form (the Apply button, may > be), then you have to fill in all the values. Every time you discover a > bug, even a stupid one, you must restart the program from the beginning; > and, may be, that form is nested deep in the program logic - you have to > step through many menus and dialogs to arrive at the point of interest. > Other times, you don't have a clear idea of the algorithm you have to > write, so you try again and again. In these situations, the more you can > do through the debugger, the more time you save. > > There could be some improvements to the debugger: > > - the possibility to assign new values to variables (perhaps not the > structured, but only the simplest ones)
This is planned, but some function is yet missing in the gb.eval command to implement ot. > - the possibility to modify the program text and continue debugging > (perhaps without adding/deleting lines) I think I can't do that. This is too much work for something that is not really useful. > - the possibility to change the program counter (perhaps with > constraints) I don't find that useful at all, but I think it may be possible to implement. > - the possibility to add "debug" code, which is compiled in only > when a special "debug run" is invoked This is planned. > - conditional breakpoints / break on the "Nth occurence" > This is not planned, but it is possible to implement. I will note that. > ...and may be other which does'nt come to my mind at the moment. > > We already discussed a little about this: I know this is somehow hard to > implement, but having the gambas virtual machine ready in memory should > help... I mean: if the debugger "knows" how to obtain the value of a > variable, and how to display it, then perhaps it is possible to > [relatively] easily assign a new value. Or, the possibility to modify > the source and continue debugging, seems to me not very hard to do (but > I could be wrong, of course). > > I know that I am biased, because for my work I go deep to the processor > hardware, and the debugger lets me do nearly everything I want, but you > could consider whether any improvement could be done to the gambas > debugger. > > Hope I did'nt annoyed you, they were simply ideas. You didn't annoyed me. :-) Regards, -- Benoît ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
