Hello:<br>One of the feature of the next  Fedora 11 release there is an improvement in the debugger using archer (<a href="https://fedoraproject.org/wiki/Features/Archer">https://fedoraproject.org/wiki/Features/Archer</a>), Is this improvements going to be reflected in the kdevelop4?<br>
<br>Thank you..<br>masch...<br>Salu2...<br><br><div class="gmail_quote">On Mon, Mar 23, 2009 at 6:29 PM, Andreas Pakulat <span dir="ltr"><<a href="mailto:apaku@gmx.de">apaku@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 23.03.09 21:03:39, Niko Sams wrote:<br>
> Hi,<br>
><br>
> To support more debuggers than just gdb we need a generic debugger<br>
> framework with<br>
> a common UI. I started this with a first patch<br>
> (<a href="http://reviewboard.kde.org/r/379/" target="_blank">http://reviewboard.kde.org/r/379/</a>) - you can't<br>
> call it framework :D it's just a bunch of common actions - as this is<br>
> the most annoying if<br>
> you have those actions for every debugger duplicated in the gui.<br>
> I'm currently also working on a XDebug (<a href="http://xdebug.org" target="_blank">http://xdebug.org</a> a php<br>
> debugger) debugger implementation<br>
> that uses the dbgp protocol - a generic protocol.<br>
><br>
> So a few things have to be cleared:<br>
> - what debugger will get ported to that framework?<br>
<br>
</div>Time will tell, currently both gdb-plugins have deficiencies.<br>
<div class="im"><br>
> - is this planned after the first kdevelop release?<br>
<br>
</div>kdevplatform doesn't guarantee BC or SC until we feel like it (i.e. 2.0<br>
release at most). So even if we start for 1.0 its fine if we completely<br>
scratch everything and redo it for the next release.<br>
<div class="im"><br>
> - general direction of the debugger framework<br>
>    apaku proposed the debugger plugin should not have access to<br>
>    any gui components. That would mean we have to think about models<br>
>    for stack/variable-view/breakpoints and so on. Advantage is a common UI<br>
>    that just has to be implemented once.<br>
>    However not all debuggers have the same features (gdb can show memory stuff<br>
>    where xdebug won't do that)<br>
<br>
</div>I have to admit that I may be a bit biased by Eclipse debugger framework<br>
(as thats the only one I ever got involved with). I'm not sure how they do<br>
things like memory-debugging (if thats supported at all), but thats<br>
something that maybe can still be supplied by the debugger plugin on its<br>
own.<br>
<br>
The part that the debugger plugin really should only deliver data for<br>
(IMHO) is for the "normal" stuff:<br>
<br>
- variables (local+global)<br>
- watches<br>
- threads<br>
- frames (and framestack)<br>
- position information for the current frame<br>
- hooks to tell the debugger plugin to do things like<br>
  step,pause,continue,step-return etc.<br>
- API to tell the plugin where breakpoints are set (or the plugin fetches<br>
  that list from the debugger controller)<br>
<br>
If we have that it would be a good start and we can think about extending<br>
it to more specialized things like memory-debugging and stepping individual<br>
assembler instructions later on.<br>
<br>
Andreas<br>
<font color="#888888"><br>
--<br>
You will have domestic happiness and faithful friends.<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
KDevelop-devel mailing list<br>
<a href="mailto:KDevelop-devel@kdevelop.org">KDevelop-devel@kdevelop.org</a><br>
<a href="https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel" target="_blank">https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel</a><br>
</div></div></blockquote></div><br>