Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Snakes in the Blocks: A python plugin

<< < (2/3) > >>

dmoore:
I agree that both are only short term hacks.


--- Quote from: mandrav on November 22, 2006, 02:42:54 pm ---What's the use of this?
The point of having breakpoint events in the first place is to alert the debugger that a breakpoint has been set/unset. The debugger then can use whatever internal struct is appropriate to keep this info around. The editors don't keep this information around (other than marking the affected lines).

--- End quote ---

it seems to me that 1. breakpoints are being needlessly stored and processed repeatedly in the editor and in plugins (extra work) 2. it is too easy to lose synch with where the editor breakpoints are as someone edits and renames files, so why not have a means to validate them? (I have experienced repeated problems with the gdbdebugger). In my code, i retrieve the full list each time the debugger starts, and use the add/remove events to respond to commands while debugging. But ultimately, it's up to you. I can work around it.

Some of the gdbdebugger code also needs to change sometime in the future to make it share (for instance gdbdebugger responds affirmatively to all breakpoint requests, even if the file is not on the list of known file types)

EDIT: my ideal would be for editor manager / some other manager (say "debugger manager") to do more of the work.

mandrav:

--- Quote ---it seems to me that 1. breakpoints are being needlessly stored and processed repeatedly in the editor and in plugins (extra work) 2. it is too easy to lose synch with where the editor breakpoints are as someone edits and renames files, so why not have a means to validate them? (I have experienced repeated problems with the gdbdebugger). In my code, i retrieve the full list each time the debugger starts, and use the add/remove events to respond to commands while debugging. But ultimately, it's up to you. I can work around it.
--- End quote ---

Although I can agree with your arguments, I have to tell you that at first the editor was keeping the breakpoints. The debugger just asked for them before starting and responded to events while running. Pretty much what you described that your plugin does.
There's one major gotcha with this approach though, which was the reason to change the design to what it is now: it only kept a list of breakpoints for open editors. So if you put a breakpoint, closed the editor and then started debugging, the breakpoint was never set. It was actually "lost" the moment the editor was closed.

I 'm not saying that the current approach is the best possible but it does have the fewest problems. Let me think it through again, now that a second debugger plugin (this one) is available...

dmoore:

--- Quote ---it only kept a list of breakpoints for open editors. So if you put a breakpoint, closed the editor and then started debugging, the breakpoint was never set. It was actually "lost" the moment the editor was closed.
--- End quote ---

yeah, i figured this would be a problem, but it is a low priority issue for me at this point. sounds like a job for "debuggermanager".

if not, i agree i would also need to keep track of breakpoints in the plugin, but it would still be useful for the plugin to request the editors breakpoints and resolve any conflicts before starting a session.

for what it's worth, the hacks I wrote should be invisible to anyone who doesn't use the python plugin and avoid *most* conflicts with gdbdebugger for anyone who does use it.

EDIT: and one more thing. under the current system there is also an onus on the plugin to check when files are reopened to reinstate the breakpoint markings (again, more duplicated work)

dmoore:
I've created a C::B binary from the latest source with plugin installed. (see the first post)

dmoore:
I've fixed a few more bugs and enabled the subversion repository for my Interpreted Languages and Python Plugins at the berlios site. You can also download a Code::Blocks binary containing both plugins. See the first post for links.

Navigation

[0] Message Index

[#] Next page

[*] Previous page