'Because that's the way it is' isn't allowed here.
Why doesn't the debugger step backwards just like you can step forward, instead of having to loop back to a previous line? Joe Kuhn
Because when you're running code backwards, you're not debugging real production code? You can use the "Set Next Statement" menu option to backup while in the debugger, but I can't fathom why anyone would want to step through their code backwards. Do you have a use case for it? -- Mike Helland
Sure. As I step through code I watch variables change and sometimes I miss something. I want to go back to a prior state in a prior line and watch everything change a second time. As it is I've got to make sure I re-init my variables and then step through the code again. It gets quite messy at times. Joe Kuhn
Uh, FoxPro would then have to save the disk and memory state after each line - not very feasible. -- Peter Crabtree
Or reverse what each program line does. The answer may be more historical than practical. At some point early in the development of programming languages an assumption was made that forced us into one direction only? Joe Kuhn
But it can only reverse what the last line did IF we're dealing with procedureal, non-distributed, monolithic programs. You talk about the direction of programming, I'm a fan of the reasoning that programming is completely based on simple transformations. Some of those transformations are difficult to reverse unambigiouslly. I could be wrong, I'd like to hear what some of the wiser programming heads have to say on that claim. -- Mike Helland
Non-distrubuted yes. Difficult to reverse unambigiouslly? Do you have an example? Joe Kuhn
Ok, when it hits the suspend, and you start stepping backwards, what does it do:
myVar = .T.
myVar = .F.
Personally, I have no clue, and I woudlnt'n expect the debugger to figure it out either because its not something we deal with on a regular basis. -- Mike Helland
Wow. I never thought of it that way. Fun! Joe Kuhn
Actually, I've been campaigning for this feature for many years. There are ways to do it that would work in many but not all situations.
Snapshotting certain memory areas to disk, or a ram disk area, although slow, could be useful in situations where the developer is willing to pay the performance penalty for the opportunity to use this powerful debugging feature. For example, one might implement a new command SET SNAPSHOT ON that a developer could place in the code that would cause the above saves to occur. Then, further down in the code, a SET STEP ON or SUSPEND or, better yet, ASSERT .F. could be used to start the single stepping debugging session. If the developer needed to back up, each line executed after SET SNAPSHOT could be backed out, albeit slowly, one by one, with the option of going forward again at any point. With the latest generation of fast processors, this kind of capability is more practical than ever. As for the ambiguous IF, the backstepper could ask the developer to provide the original state of the variable, or it could simply look back at the previously executed lines and get the state of the variable from the save area. It would know what lines were executed and could infer the state from that information, or it could simply look back until it found the IF statement and then look at the variable store as it was at that moment. Storing the state of memory could be improved by saving deltas with each step. Only the variables that have changed would be saved. It is admittedly a bit complex, but certainly do-able and easily within the ability of the talented VFP development team.
This feature is one that would be seldom used, but when needed, would most valuable. Ray Kirk
Ok, so VFP would keep track of what? Variable changes are (fairly) easy, obviously. Program branching is fairly simple, too. But you can't do this for things external to VFP. ActiveX controls, FLLs, DLLs, etc (unless the FLL didn't do anything outside of VFP, say, it formatted a string). How about code like this:
oAgent = CREATE("msagent.agent")
oAgent.Connected = .T.
* Or what about this:
CREATE CURSOR myCursor(myField I)
FOR I = 1 TO 1000000 && 1,000,000
INSERT INTO myCursor(myField) VALUES(I)
LOCAL ARRAY A(1000)
SET SNAPSHOT ON
USE IN myCursor
* Does VFP now save the whole table, index and array?
Also, what if a user event occured at some point in the whole process? Does VFP also keep track of Windows events? The list isn't done there.
However, I think the fox team *could* do it. I just don't see a big enough gain, as a developer to warrant it, unless the Fox developers were running out of things to do (heh, yeah, that's not happening any time soon).
I think things like more informative error messages (which PART of my #$#%^@# 80 line SELECT has the *&^%& data type mismatch?!?!), changing
DoDefault() to only do "user" code, and not VFP native code (and add
DoVFPDefault()), et cetera would be significantly more helpful. -- Peter Crabtree
Laying down a tracer for branch points and doing deltas only - these sound like good ideas. Joe Kuhn "Deltas"? -- Peter Crabtree
( Topic last updated: 2003.03.17 04:05:41 PM )