Is there some way to do this?

Or preventing the debugger from zeroing out it's state after pushing the stop button?

As it's currently implemented (executing files are tagged as R/O), one has to remember the program's state in detail while attempting to fix a bug. I'd much rather just simply look at it while coding a revised (or even new) implementation.

Andrew

currently it is marked RO because when a breakpoint is hit, the line is highlighted and variable information is dumped (globals & locals)
what if you have modified the code and that part doesn't exist anymore?

this can be solved:
if interactive debugging (step/breakpoint etc so that debugging information is needed to display in the file tab) is started, check if the file has been modified. if yes, display the debugging in a new tab, using the code that was saved to a temp file at the beginning of preparing for debugging. and the lines will be highlighted in that new tab

however, i don't think this is neccessary. it is ok as it is at the moment

It will be usefull to let programmer edit the file while debugging, even if the code change is not considered for that debugging session.
I may get to a point where I notice wrong code, and want to fix without stopping the debugging and launch again. I dont care if the code is not considered until next debug.

thanks
Cristian

Amen. I would love it if I didn't have to stop the debugger to edit a mistake. Having to click stop or press CTRL-F2 really slows me down and breaks my train of thought.

Just so you know, I've built debuggers & VM's before, so I understand why it works the way it does now.

Netgert - your solution is too complicated. Mine solves the problem (which you don't think is one anyway) without a new UI element (which is expensive) or new workflow process (which requires learning to know how to use.)

Given the nature of the applications that I'm developing, PhpEd's debugger makes PHP coding possible, but this one simple thing would double the debugger's usefulness.

Andrew

ok. Seems it's too improtant to all of us. So let's try to discuss the problem.
Suppose you have just two lines in your code echo "a" and echo "b".
You have set a breakpoint on echo "b". While in the debug session you insert just one line between those two, say echo "ab". Now echo "b" becomes 3rd line and echo "ab" becomes 2nd. Debugger still executes old code and it means that it tells the IDE it is say on the line 2. While the line two is just added and is not run by the debugger. So Current Executed Line will be shown on wrong position and breakpoint will trigger on a wrong position too. The same way if you have a function call on the line and press F7 it may or may not let you step in depending if actual (being debugged) functoin call is there on the debugger side.
Any ideas? Solutions?

yes, my "solution" was bad, just a quick example
but still there is no logical way (atleast i cant see one) to display UP-TO-DATE debugging state in MODIFIED code... they just exclude each other.. the only, and indeed resource-costy, solution is to duplicate the code, one for debugging and other for modifying.
maybe you could explain your ideas a bit better

There are two approaches to improve the use of the debugger in PhpEd. One is a superset of the other.

Approach one, the programmer sets a break point that the application hits. The source file is display & highlights the correct line in read-only mode. The programmer hits the stop debugger tool tip. The source file status is changed to editable and the cursor is positioned on the break point line. The various step/run debugger buttons are set to inactive and the debugger exits - without clearing it's displays (until the start of another debugger run.)

Key difference from the current behavior: The Globals, Locals, Call Stack, Watch, Breakpoints and Immediate tabs are not cleared out when the programmer hits the stop button.

Approach two, the programmer proceeds as before, but is able to edit in place without stopping the debugger.

Key difference from approach one: The source file doesn't track with the actually executing source & therefore the debugger display can get out of sync.

I don't have a detailed suggestion at the moment to solve approach two, but frankly that's a 'nice to have.' Not clearing the debugger state after stopping is a 'have to have' and a lot less work than approach two. At the moment, I'm litteraly cutting & pasting values so I can keep track of state after I exit the debugger so I can review it while bug fixing. This is slow slow slow.

Make sense?

Andrew

1) thats practically the same as stopping debugging when you have found a bug, with only exception not to clear debugging information known so far

2) thats the problem we've tried to tell you about debugging info going out of sync

you should have told it in the first place: dont clear locals/globals/etc after debugging stop

I haven't really seen any good reason against editing a temporary copy of the file while the debugger is running. Is it really so expensive?

That is, when the debugger is running, you could "clone" the file in the editor. The one showing the debugger progress is readonly, but you can make changes to the temporary copy. Of course, these won't show up in the running debugger session and won't affect debugger state.

If that makes a difference - you need not be able to save the temporary file while the debugger is running (to prevent overwriting the file currently being processed).

After the debugger is finished, drop the file tab which has been used for running the debugger, and make the temporary copy the new version.

mp: the cost depends on the file. on big files, duplicating mean getting more memory (the same amount as for original) / disk space. also, if there are big systems (included files etc) there would be a duplicate for every edited file

if there is no better way, this method should _not_ be ignored to make editing available when debugging

no no no... we have a copy on the server that's running. Not necessary to have another more, because debugger anyway works with server side copy of the file that is actually parsed (in other words even changing the copy on the server disk won't affect the debugger). The problem is how to display "running line" and "breakpoint lines" in the editor on the client site if the file allowed for editing and suppose you have deleted some lines have typed some new ones and have moved some others to another place... In other words, if server side lines does not correspond 1:1 to the client side. Even if I make a copy on the client side and be able to locate source lines in it and they are 100% guaranteed true lines, how would it help me to find corresponding lines in the edited file?