Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Splitting debugger in two - specific debugger and common GUI
dmoore:
On this:
--- Quote from: dmoore on February 08, 2011, 11:13:36 pm ---1. which is responsible for setting and moving the code position marker in the editor: the plugin or the framework? Assuming the framework, which methods need to be implemented in the plugin (and what other calls need to be made or events signalled) to get this to happen?
--- End quote ---
It appears that correctly implementing IsStopped/IsRunning and then calling SyncEditor from the plugin is enough.
cbexaminr:
--- Quote from: MortenMacFly on February 08, 2011, 08:30:05 pm ---Please guys, calm down. I believe oBFusCATed is truly willing to accept changes / patches that address the functionalities you have in mind. It is the same for me but I guess all that's missing for now is some more time. I for myself would be willing to try but simply don't have enough time, but I can understand your frustration coming out of this situation.
--- End quote ---
oBFus is probably quite calm, unless I upset him, I probably am the one most needing to calm down, but...
The actual depths of my frustration you have no idea of. Its roots date back prior to my join date of this forum.
--- Quote ---However, as a compromise how about applying it for a nightly to give a chance to other users to try. <snip> from it we can polish out the ToDo's. But this should clearly be done in a continuous work.
--- End quote ---
If you wish to apply certainly.
TBD: ToBeDone, ToBeDetermined,ToBeDeleted, ToBeDiscussed
Of the TBD's still present (at least two I should have removed), I don't believe any of them currently require any action, they are more ToBeDiscussed, if anyone has anything to offer regarding them.
--- Quote ---If the community benefits from it ...
--- End quote ---
There may be an external community that could benefit if I can meet GPL compliance requirements for mingw built gdb mods I have. If the scrolling, leveled/layered, tipwindow can be completed and incorporated(by someone), I think that would be of great benefit to that potential community as well.
dmoore:
I made a little progress tonight on the Python Debugger. For anyone interested in following along, the code is here
--- Code: ---svn checkout svn://svn.berlios.de/cbilplugin/trunk/PythonDebugger
--- End code ---
It's still a mess and has quite a few bugs. But you can sort of step through a python program and add/remove breakpoints.
oBFusCATed:
--- Quote from: dmoore on February 09, 2011, 02:46:56 am ---It appears that correctly implementing IsStopped/IsRunning and then calling SyncEditor from the plugin is enough.
--- End quote ---
You need to implement GetCurrentPosition too, it is called when an editor is opened.
--- Quote from: dmoore on February 08, 2011, 11:13:36 pm ---I have plenty questions about the Debugging API. As a general comment, the cbDebuggerPlugin class definition could definitely use some more documentation, as I'm not always sure what the framework is providing and what the plugin needs to do (lack of time on your part, I know). A couple of specific questions (there will be more):
--- End quote ---
The main classes you should look at are:
DebuggerManager, the data classes in DebuggerManager.h, the classes for the debug windows and the cbDebuggerPlugin
--- Quote ---2. I noticed the the GDB_MI plugin was using some sort of smart pointer to store the breakpoint class instances (with the breakpoint class itself defined in the SDK). I would have thought the framework would provide the container classes...
--- End quote ---
Most of the time the plugin is the owner of the data and then the GUI classes query the debugger for this data, so they can display it in some way.
Probably this is not the best design, but I wanted to change as little as possible and also to minimize the copying of data.
cbexaminr:
--- Quote from: oBFusCATed on February 08, 2011, 03:19:06 pm ---... that can be used only in remote debugging mode... My idea is to move the calling code inside the debugger, so you have the option to implement it or not.
--- Quote from: cbexaminr on February 08, 2011, 02:13:25 pm ---Awaiting advice on what to do differently than IsExternalProcess()...
--- End quote ---
This one requires major refactoring...
--- End quote ---
oBFus,
As mentioned in a caveat of the original (Debug external program) patch submission inclusion requested further above, I desire to support remote debugging access within the Debug external process functionality. As also mentioned there, it appears some (possibly significant) study of the remote debugging info handling will be necessary for me to achieve that additional functionality.
Is it likely that your changes relative to remote debugging, and any associated major refactoring are going to affect the current structure and/or use of remote debugging info, such that any work I complete toward that functionality against the current state of the source plus my current changes, will require major rework to bring forward after your changes are completed?
While I would like to move forward in implementing that functionality now, I also do not wish to have to do the work twice, so your feedback on this appreciated...
*** i.e. should I wait to proceed with exploring how to, and subsequently implementing remote debugging within the Debug external program functionality for which I've already requested inclusion, until after you've completed, or report deciding not to, your planned changes in this area?
(somewhat aisde -
Regarding your suggestion elsewhere of using dummy or makefile projects to support these functionalities, they are "clunky" in regard to my anticipated usage patterns, a)either by cluttering my environment with otherwise useless projects, or b) requiring additional keystrokes to regularly access/change (remote) debugging info in a project configuration that may be opened multiple times simultaneously (with multiple codeblock instances) to explore issues that could occur on multiple nodes each running one/more identical concurrent application instance(s) of that (currently non-)codeblocks project in a multi-node test environment.
Perhaps also worth mentioning, supporting multiple debug instances of the same application/project, with both/either remote and local instances, would support this use case as well, but I'm guessing, without trying [since there seems to be possibility of only one remote debugging info instance per project] that this is not currently supported.)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version