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 -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/853c0770-92d9-4b92-b428-a5c9baf19ce3%40googlegroups.com.
