Breakpoints in debugger do not move correctly when editing code

[spyder-bot]

From DavidAnt...@gmail.com on 2012-02-29T02:16:45Z

What steps will reproduce the problem?

1. Set a breakpoint in the GUI by double-clicking next to the line number
   1. Debug the code, stops at the breakpoint as expected
   2. Type 'exit' to quit debugger'
   3. Add a few extra lines of code before the line with the breakpoint
   4. Debug the code again What is the expected output? What do you see instead? In the GUI, the green symbol has correctly stayed on the same piece of code, thus moving to a new line number.

However, the debugger stops at the line number where the breakpoint was originally set - which no longer corresponds to the piece of code where I set the breakpoint.

Original issue: http://code.google.com/p/spyderlib/issues/detail?id=955

[spyder-bot]

From jed.lud...@gmail.com on 2012-03-11T06:56:28Z

Labels: Milestone-Release2.2

[spyder-bot]

From pierre.raybaut on 2012-03-18T09:07:32Z

How to "debug the code again" (step #5)?
(shortcut? clicking on the green button at the top right of the existing console?)

[spyder-bot]

From pierre.raybaut on 2012-03-18T13:46:41Z

Labels: -Milestone-Release2.2 Milestone-v2.2

[spyder-bot]

From pierre.raybaut on 2012-03-18T13:56:03Z

Labels: -Milestone-v2.2 MS-v2.2

[spyder-bot]

From DavidAnt...@gmail.com on 2012-05-17T19:13:28Z

@-Pierre: Sorry, just noticed your question. It happens either when pressing ctrl-f5, selecting debug from the run menu, or the debug button from the toolbar.

[spyder-bot]

From DavidAnt...@gmail.com on 2012-05-29T01:36:23Z

The solution to this problem which occurred to me was that instead of storing breakpoints internally as line numbers, the editor widget should store a reference to the line within the editor - presumably there is some part of the qt interface which tracks lines in a more object-oriented fashion, which does not depend on the line number.

However, I just had a bit of a look through the code, and this seems to be a bit difficult. The breakpoints are actually stored in a persistent configuration file, where it clearly only makes sense to use line numbers.

So it appears that the solution would be to update the breakpoint line numbers every time the user adds or deletes a line. I'm not sure if this will hurt performance at all - I'll have a closer look some time.

[spyder-bot]

From jed.lud...@gmail.com on 2012-05-30T07:10:23Z

@-David: I ran into some of the same issues you did when I started implementing a breakpoint list plugin to start addressing issue #318 . I had the same concern about updating the line numbers of each breakpoint each time the edit text changes, so I instead implemented a periodic refresh of all the breakpoint locations that fires on a timer. The commits to my clone are referenced in issue #318 .

I thought it might be useful to start a wiki page about the current breakpoint design and possible future changes. I have made a brief first draft here: https://code.google.com/p/spyderlib/wiki/BreakpointDesign Feel free to edit or discuss further. I have several open questions in my mind about the right way to handle breakpoints in general, and rather than start in with making broad changes in the code I thought it more prudent to get some review first.

[spyder-bot]

From jed.lud...@gmail.com on 2012-12-19T08:17:24Z

I believe this issue was fixed as a result of work on issue #318 . In particular, rd5df2c73ca05 refreshes the breakpoint list every time the number of lines in the file changes. This revision has been out in the wild for some time now, and I have not noticed any performance hits.

I can no longer reproduce the problem by using the steps in the original report. I'm going to mark this as fixed and Verified.

Status: Verified