Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Splitting debugger in two - specific debugger and common GUI
cbexaminr:
[deleted - misplaced due to timeouts]
[oBFus post and mine 'delete' request changes crossed on the wires]
[Readded content to be in correct order (Jens) :]
--- Quote from: oBFusCATed on February 07, 2011, 09:57:49 am ---1. Why do you need such feature? C::B is not intended as a gdb/cdb-only wrapper. It is an IDE with debugging support.
--- End quote ---
personal need - I am debugging items that cannot currently be built with C::B (borland/codegear/EMBT VCL-based applications), and C::B and GDB are the tools that I have currently chosen to invest in to make this possible (vendor tool usage has "issues".)
general justification - if C::B is the tool one has at hand, and, is familiar with, one should not be be forced to obtain-or-create/install/learn a different tool, when there is no particularly rational reason C::B can't provide that functionality.
question - What _is_ an IntegratedDevelopmentEnvironment?
answer - A set of tools that work well together to support development of applications. In order of anticipated common usage, most to least, that would likely generally include editor/build support/debugger/analysis-documentation tools.
observation - The organization of an IDE should not arbitrarily impose any requirement that tools which (can) work well alone, be unnecessarily structured to require working only with each other, when such "separate" usage architecture does not impose any significant penalty on that combined entity nor the effort involved in implementing it. (If you disagree with this, then perhaps you should consider disabling the ability to use the editor without having a project/workspace open :) .) If, the continued separate usage architecture of such tools imposes some significant penalty/requirement that no-one is willing to pay, then perhaps such implementation might be best avoided - but, I have already made the initial investment here, and I don't think the maintenance requirements will be significant.
I do not seek a gdb/cdb-wrapper only :) - I seek a tool that will serve me reasonably in various situations.
oBFusCATed:
--- Quote from: cbexaminr on February 07, 2011, 10:52:56 am ---personal need - I am debugging items that cannot currently be built with C::B (borland/codegear/EMBT VCL-based applications), and C::B and GDB are the tools that I have currently chosen to invest in to make this possible (vendor tool usage has "issues".)
--- End quote ---
You can use a dummy project for this or a Makefile project...
--- Quote ---general justification - if C::B is the tool one has at hand, and, is familiar with, one should not be be forced to obtain-or-create/install/learn a different tool, when there is no particularly rational reason C::B can't provide that functionality.
...
observation - The organization of an IDE should not arbitrarily impose any requirement that tools which (can) work well alone, be unnecessarily structured to require working only with each other, when such "separate" usage architecture does not impose any significant penalty on that combined entity nor the effort involved in implementing it. (If you disagree with this, then perhaps you should consider disabling the ability to use the editor without having a project/workspace open :) .) If, the continued separate usage architecture of such tools imposes some significant penalty/requirement that no-one is willing to pay, then perhaps such implementation might be best avoided - but, I have already made the initial investment here, and I don't think the maintenance requirements will be significant.
--- End quote ---
What about integrating your cooker in C::B? :P
An IDE imposes some style of work...
I'll look at the patch, but there is a chance that it won't be applied/approved...
--- Quote ---I do not seek a gdb/cdb-wrapper only :) - I seek a tool that will serve me reasonably in various situations.
--- End quote ---
Combining several tools sometimes is way powerful then using single tool for everything.
p.s. can someone move these two posts to the thread?
cbexaminr:
[content removed, see two posts above (Jens)]
dmoore:
--- Quote from: oBFusCATed on February 07, 2011, 09:57:49 am ---dmoore:
You should have "debug->start", "debug->run to cursor" and "debug->step into" active. Is this the case?
--- End quote ---
After playing around some more, yes, but only when a project is active. I often edit python scripts in C::B without using projects (hence the existence of File Manager and Tools+ plugins). Is there an easy way to handle this case? (I'd actually like to offer the user the option to debug the active editor or the active target (if the target is a python file). So maybe I just need to add another menu option?)
oBFusCATed:
Can you try to return true in IsAttachedToProcess(), for now, later we could fix it correctly.
Please write down every problem you encounter, then give me the list, so I can try to fix them.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version