NuSphere Forums Forum Index
NuSphere Forums
Reply to topic
Editing while debugging...


Joined: 15 Sep 2004
Posts: 9
Reply with quote
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
View user's profileFind all posts by amagrudeSend private message


Joined: 21 Nov 2003
Posts: 39
Reply with quote
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

_________________
-/ NetGert /-
View user's profileFind all posts by netgertSend private messageVisit poster's websiteMSN Messenger


Joined: 04 Feb 2005
Posts: 26
Reply with quote
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
View user's profileFind all posts by CrirusSend private message


Joined: 03 Apr 2004
Posts: 78
Reply with quote
Crirus wrote:
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.
View user's profileFind all posts by Rick ChristySend private messageYahoo Messenger


Joined: 15 Sep 2004
Posts: 9
Reply with quote
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
View user's profileFind all posts by amagrudeSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 7901
Reply with quote
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?
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 21 Nov 2003
Posts: 39
Reply with quote
amagrude wrote:
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

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

_________________
-/ NetGert /-
View user's profileFind all posts by netgertSend private messageVisit poster's websiteMSN Messenger


Joined: 15 Sep 2004
Posts: 9
Reply with quote
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
View user's profileFind all posts by amagrudeSend private message


Joined: 21 Nov 2003
Posts: 39
Reply with quote
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

_________________
-/ NetGert /-
View user's profileFind all posts by netgertSend private messageVisit poster's websiteMSN Messenger


Joined: 09 Dec 2003
Posts: 92
Reply with quote
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.
View user's profileFind all posts by mpSend private message


Joined: 21 Nov 2003
Posts: 39
Reply with quote
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

_________________
-/ NetGert /-
View user's profileFind all posts by netgertSend private messageVisit poster's websiteMSN Messenger
Site Admin

Joined: 13 Jul 2003
Posts: 7901
Reply with quote
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?
View user's profileFind all posts by dmitriSend private messageVisit poster's website
Editing while debugging...
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 5 Hours  
Page 1 of 2  

  
  
 Reply to topic