Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Python Debugger
oBFusCATed:
I read this http://www.flameeyes.eu/autotools-mythbuster/ it is modern docs for autotools, most of the info in the internet is hard to read and this is the major reason for autotools been not well understood by people.
Alpha:
--- Quote from: dmoore on July 25, 2012, 03:55:40 am ---(I may add python project support later)
--- End quote ---
When/if this occurs, know that you have an interested user :).
dmoore:
--- Quote from: Alpha on July 26, 2012, 06:14:04 pm ---
--- Quote from: dmoore on July 25, 2012, 03:55:40 am ---(I may add python project support later)
--- End quote ---
When/if this occurs, know that you have an interested user :).
--- End quote ---
Cool. Are you already developing Python projects in C::B? If so, how are you setting them up? (In the past I have simply used the file manager plugin to browse my python sources instead of setting up dedicated projects, but recently started creating projects with a target specifying the main script. I assume you would want the debugger to be able to start a debug session on this target? Anything else?)
Btw, this looks like an easy way to get python autocompletion into C::B: http://code.google.com/p/pysmell/
Hasn't been updated in a long time (2008), but the sources aren't terribly complicated
Re the Debugger (for obfuscated): Still stuck implementing watches. I get a crash every time I try to expand any watch that isn't the first watch item. This could be just something stupid on my part, but I suspect I may not be using cb::shared_ptr correctly. (my watch is derived from cbWatch, and there are lots of cb::shared_ptr<cbWatch> instances passed around that point to instances of my derived class)
oBFusCATed:
--- Quote from: dmoore on July 27, 2012, 04:45:31 pm ---Re the Debugger (for obfuscated): Still stuck implementing watches. I get a crash every time I try to expand any watch that isn't the first watch item. This could be just something stupid on my part, but I suspect I may not be using cb::shared_ptr correctly. (my watch is derived from cbWatch, and there are lots of cb::shared_ptr<cbWatch> instances passed around that point to instances of my derived class)
--- End quote ---
I have to check it, but I have no time at the moment, unfortunately.
But cb::shared_ptr<Base> supports managing Derived objects, but you have to have a virtual destructor.
Alpha:
--- Quote from: dmoore on July 27, 2012, 04:45:31 pm ---Are you already developing Python projects in C::B?
--- End quote ---
Not exactly; I more use Code::Blocks as an editor for individual Python files if it happens to already be open (which is most of the time). For more significant Python work, I often use Eclipse, however, it is never fun trying to make an elephant dance, and I would like to transition my work to Code::Blocks as soon as it appears to have a minimum subset of features.
I have not had the chance to explore your plugin's capabilities yet, but yes, target aware debug sessions, and (essentially) the same other features of the current gdb debugger interface (I did not check to see how many of these you have created yet).
Other features that would be nice (though do not necessarily belong in this plugin) are a build target type of "MIME" (or "Other" or "Script") that will poll all applicable plugins to see if any of them support this target (probably by scanning file extensions) - the plugin would then take over building/running related operations (this would give a more seamless use than the workarounds currently required for languages that do not follow compile-link-run and allow users to remove any that were unnecessary), and code completion. I will probably try my hand at working on these when I have enough time. (These are just ideas, I am not expecting you to work on any of them, unless, of course, you want to.)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version