Debugging with Leo: getting started?

[Matt Wilkie]

Hi All,

I'm in the middle of trying to understand how a 3rd party python module and utility works (ref). The complications surpass my fledging debugging approach of liberally sprinkling print() statements everywhere, so I figured I'd buckle down and learn how to use a debugger properly like the Smart Kids Do. I hit a road block pretty quickly though: the "Debugging with Leo" chapter in the docs are out of step with outside world. One of the first things to do is grab winpdb, but that tool/project appears to be in a state of flux. The original project is unmaintained. It's been picked anew as winpdb reborn, but is currently straddling the divide of python 2 vs 3.

Winpdb Reborn: https://github.com/bluebird75/winpdb

Getting back to Leo debugging: the g.trace and g.pdb sections don't apply to my challenge (I think) because I'm not running Leo scripts, but trying to follow the program execution of the external code. Any suggestions of how I could get started?

Thanks!

Matt

[Edward K. Ream]

On Sun, Aug 11, 2019 at 7:29 PM Matt Wilkie <map...@gmail.com> wrote:

I figured I'd buckle down and learn how to use a debugger properly like the Smart Kids Do.

Insert calls to g.pdb().  This will start Python's pdb debugger. You must be running Leo from a console.

When you hit a breakpoint, hit "n" once to move out of the Leo code and into the code you want to see.

If "g" isn't available, then start the debugger using:

import pdb ; pdb.set_trace()

Imo, there is seldom a need for anything other than pdb.  Guido has said that's what he uses.

Edward

[Brian Theado]

As Edward says, adding a call to pdb.set_trace() works. This assumes you already know where to put the breakpoint. If you don't, then one way is just start pdb before any code executes and start stepping through the code. Usually this is tiresome because you end up stepping through a lot of code and you don't know which code you should step over vs. step into. The command for this is:

python -m pdb <thescript>

I find it is usually better to use the python trace module to get a feel for the flow of the code. From that output you may be able figure out where you want to set a breakpoint:

python -m trace --trace <thescript>

But this has way too much output so it is better to filter out all the standard python library calls. Do that by running this command to get this list of directories to ignore:

python -c 'import sys ; print(":".join(sys.path)[1:])'

And run your trace command like this:

python -m trace --trace --ignore-dir <output from above command> <thescript>

This requries <thescript> to be located outside your standard library paths (i.e. installed with pip), otherwise the execution trace of that code will be excluded as well.

--
You received this message because you are subscribed to the Google Groups "leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to leo-editor+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS0AvV5nUw3Q9-4iEW_c2tRaCVsvkRFRb8azO%3DOZ5cw%2BrQ%40mail.gmail.com.

[Matt Wilkie]

thank you both so much. (((learning hat on...)))

[Edward K. Ream]

On Mon, Aug 12, 2019 at 10:26 AM Matt Wilkie <map...@gmail.com> wrote:

thank you both so much. (((learning hat on...)))

You're welcome.  That's the spirit ;-)

Edward

[Matt Wilkie]

(I hit [post] by mistake. Some of you may get a partial message before this full one)

I needed to change some things to get working in Windows. For the ignore list of system directories: reverse the inner and outer quotes, capture to text file. Edit path to use Win path separator instead of unix (replace `:c:` with `;c:` -- colon-C-colon with semi-colon-C-colon).

python -c "import sys ; print(':'.join(sys.path)[1:])" > pdb-ignore.txt

-matt

[Matt Wilkie]

or, doh! use a different join() statement. Sheesh Matt!

[Edward K. Ream]

On Tue, Aug 13, 2019 at 12:41 AM Matt Wilkie <map...@gmail.com> wrote:

or, doh! use a different join() statement. Sheesh Matt!

python -c "import sys ; print(';'.join(sys.path)[1:])"

:-) As a general rule, newbies (in whatever area) should cut themselves a huge amount of slack.

Edward

[Edward K. Ream]

On Monday, August 12, 2019 at 6:13:29 AM UTC-5, btheado wrote:

As Edward says, adding a call to pdb.set_trace() works. This assumes you already know where to put the breakpoint. If you don't, then one way is just start pdb before any code executes and start stepping through the code.

I let this pass initially, but I can't recommend python -m pdb <script>.  Imo, knowing where to put traces and breakpoints is virtually the entire art of debugging.

I've been thinking of this for the last day or so because I'm deep into the debugging of #1289: singleton docks.  This has ramifications all over the startup code.  I insert traces (g.trace) to get a feel for what's going on.  The goal is to minimize the data, so as to maximize the effective content.

Inserting traces usually suffices.  When it doesn't, as at present, I use g.pdb to dig deeper.  But first, make sure to tailor your traces so as to maximize the signal/noise ratio for the project at hand.

Leo greatly simplifies discovering (and remembering!) where the sweet spots are.  Use clones to keep track of various likely-looking places.  I add comments to the headlines of nodes to remind me what nodes do, what nodes have been changed, and what nodes need more work.

Summary

It's your code. Use g.trace to discover what it does, with g.pdb reserved only for special needs. Use clones to keep track of complex issues.

Imo `python -m pdb <script>` is almost never needed, nor is it ever likely to be as effective as the method just described

Edward