<br><br><div class="gmail_quote">On Tue, Mar 10, 2009 at 4:26 PM, Ville M. Vainio <span dir="ltr">&lt;<a href="mailto:vivainio@gmail.com" target="_blank">vivainio@gmail.com</a>&gt;</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>On Tue, Mar 10, 2009 at 9:23 PM, Rocky Bernstein &lt;<a href="mailto:rocky@gnu.org" target="_blank">rocky@gnu.org</a>&gt; wrote:<br>
<br>
&gt; Gdb uses the protocol called GDB/MI, but outside of gdb I don&#39;t think any<br>
&gt; other debugger has adopted it. ActiveState uses DBGp, and not just for their<br>
&gt; Python IDE and debugger but also I believe for Tcl, Ruby and Python. And I&#39;m<br>
&gt; given to believe that there are other Python debuggers that use DBGp as<br>
&gt; well. So right now that&#39;s what I&#39;m contemplating in pydbgr.<br>
<br>
</div>So is pydbgr meant to sit on server side of DBGp, client side, or both?</blockquote><div><br>Both. One could use the pydbgr client side as a &quot;back-end&quot; like <a href="http://www.gnu.org/software/ddd/" target="_blank">ddd</a> or gnu emacs do for <a href="http://bashdb.sourceforge.net/pydb/" target="_blank">pydb</a>. <br>

<br>But most of the emphasis is and will on the debugging support side, followed by protocol support.<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br>
<br>
DBGp does look like an exhaustive protocol; and admittedly more<br>
documented than rpdb2 protocol. Can you reuse an existing DBGp server<br>
module?</blockquote><div><br>Shane Caraveo in private email wrote  (I hope this is okay to cite):<br><div> </div><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">

<br>

While our UI code is proprietary and only part of Komodo IDE, several
of our dbgp implementations are open source, and available from <a href="http://svn.openkomodo.com/openkomodo/browse/" target="_blank">http://svn.openkomodo.com/openkomodo/browse/</a><br></blockquote> 
<br>It would be nice to have skeletal DBGp client/server implementations for testing. As best as I can tell though this doesn&#39;t exist yet or I am not aware of it.<br><br>But we&#39;ve strayed from the original thought which was adding a set of domain-specific (or debugger-specific) commands to ipython to use that as a debugger command-line + ipython.<br>

<br>Here&#39;s an additional thought along that vein. The way pydbgr gets its commands for the command-line command processor is to import all files in a directory, introspect and look for classes that end in &quot;Command&quot; and instantiate each of those. (Now that I write this, better might be to check that they are instances of some Command superclass) .  Given this, it&#39;s possible to add a feature where users can write their own customized debugging commands and put them in a directory and when you start the debugger point to the directory and have the debugger add those additional debugger commands.<br>

<br>I throw this idea out as an alternative to ipython way to add &quot;magic&quot; commands. I&#39;m not that familiar with ipython magic commands, but probably that&#39;s the way one would add debugger-specific commands in ipython.<br>
 
<br></div><div><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<font color="#888888"><br>
--<br>
</font><div><div></div><div>Ville M. Vainio<br>
<a href="http://tinyurl.com/vainio" target="_blank">http://tinyurl.com/vainio</a><br>
</div></div></blockquote></div><br>