debugging breakpoints

[Doug Bonar]

Can I set the graphically?

In spyderlib/plugins/editor.py  I see breakpoint related actions being set up, but I can't find the breakpoint_menu anywhere as an actual UI widget.  That said, F12 does put a dot in the edge of the file -- looks like it should be a breakpoint.   Unfortunately, it I start the debugger, then create a breakpoint, the debugger doesn't seem to see it. 

So, a 2-part question.
1)  Is there some way other than F12 to set breakpoints?
2)  Is there a way to add a breakpoint while the debugger is running?

Thanks

[Jed Ludlow]

On Wed, Mar 6, 2013 at 3:41 PM, Doug Bonar <dbo...@gmail.com> wrote:

Can I set the graphically?

In spyderlib/plugins/editor.py  I see breakpoint related actions being set up, but I can't find the breakpoint_menu anywhere as an actual UI widget.  That said, F12 does put a dot in the edge of the file -- looks like it should be a breakpoint.   Unfortunately, it I start the debugger, then create a breakpoint, the debugger doesn't seem to see it. 

So, a 2-part question.
1)  Is there some way other than F12 to set breakpoints?

Yes. The easiest way is to double-click to the left of the line numbers in the editor. Shift+double-click sets a conditional breakpoint. A second double-click on any breakpoint will remove it. There is an open request to add a breakpoint toolbar [1], so please star the issue if you feel like that's an important feature.

2)  Is there a way to add a breakpoint while the debugger is running?

Yes, but you have to use command-line pdb commands to do it. The inability to set a new breakpoint through the editor after a debugging session has already launched is a known limitation right now that will likely be addressed in a future release [2].

Hope that helps,

Jed 

[1] https://code.google.com/p/spyderlib/issues/detail?id=1265

[2] https://code.google.com/p/spyderlib/issues/detail?id=609

[Doug Bonar]

Thanks Jed.  Not the answers I wanted to hear, but glad to know I wasn't missing anything.

[Doug Bonar]

I ended up just adding a bit to my local version.

I added a new signal, 'reload_spyder_breakpoints(filename)' to plugins/editor.py and caught it in externalconsole.py.  That then looks at the current tab widget and asks its monitor to run a new function I patched into SpyderPdb in sitecustomize.py.  It touches 4 files, but it didn't seem too hideous.

For now, my patched in function is just clearing all breakpoints for the file using Pdb's clear_all_file_breaks( filename ) and then loading the ones from CONF as the existing set_spyder_breakpoints does.  If I get ambitious, I might change that to leave the ones that are unchanged in place (matching of file, line & condition string) since right now the numbering of all breakpoints in the file changes when you adjust any one.  But it is a start.

Doug

[Sylvain Corlay]

Great, could you share your patch? I would be interested to test it.

S. 

[Doug Bonar]

My local version has some other changes as well, plus in only on 2.1.11.  I'll try doing the same thing in a clean, newer version over the weekend.

[Doug Bonar]

In case it might be useful to someone in a more informal form than a diff, here are the extracted changes as lines of code. 

---------------------------------------

#
#  Two pieces which allow the monitor to trigger reloading breakpoints.
#
    
In monitor.py

    In Monitor add a function
   
    def reload_breakpoints(self, file):
        if not self.pdb_obj:
            return
        # command defined and patched into place in sitecustomize.py
        self.pdb_obj.reload_spyder_breakpoints( file )

    and, in Monitor.__init__ register it
   
            "reload_breakpoints":self.reload_breakpoints,


sitecustomize.py

    In SpyderPdb, add in the function for the monitor to use.
   
    def reload_spyder_breakpoints(self, filename):
        # TODO, fix this so that it just adds/removes the diffs, not all bps
        from spyderlib.config import CONF
        filename = self.canonic(filename)
       
        self.clear_all_file_breaks( filename )
               
        # load in new ones
        CONF.load_from_ini()
        if CONF.get('run', 'breakpoints/enabled', True):
            breakpoints = CONF.get('run','breakpoints', {})
            for fname, data in breakpoints.iteritems():
                fname = self.canonic(fname)
                if filename == fname:  # add it
                    for linenumber, condition in data:
                        self.set_break(fname, linenumber, cond=condition)  
    
    
#
#  And three pieces which set it up so that the editor will trigger the loading
#
                        
plugins/editor.py

    In Editor.save_breakpoints, add a final line
   
        self.emit(SIGNAL("reload_spyder_breakpoints(QString)"), filename)
 

externalconsole.py

    In ExternalConsole.register_plugin, add a new registration
   
            self.connect(self.main.editor,
                         SIGNAL("reload_spyder_breakpoints(QString)"),
                         self.reload_spyder_breakpoints)

    and in ExternalConsole add the appropriate function

    def reload_spyder_breakpoints(self, filename):
        # ? Basically, works when the debugger is the top external console
        # BTW, could do shellwidget.shell.ask_monitor(...)
        # but the style seems to be to let the shell take care off
        # asking the monitor.
        shellwidget = self.tabwidget.currentWidget()   
        if shellwidget is not None:
            shellwidget.shell.reload_breakpoints( filename )

  
pythonshell.py

    In ExtPythonShellWidget, add the function to ask the Monitor
   
    def reload_breakpoints(self, file):
        return self.ask_monitor("reload_breakpoints(r'%s')" % file)

[Sylvain Corlay]

Awesome! 

It works for me. 

The only limitation is that it does update the breakpoint list only in the console that has the focus. If another console has a debugging session ongoing, its breakpoints will not be updated.

A way to solve this is to replace 

        shellwidget = self.tabwidget.currentWidget()   

        if shellwidget is not None:

            shellwidget.shell.reload_breakpoints( filename )

by

        for shellwidget in self.shellwidgets:

            shellwidget.shell.reload_breakpoints( filename )

in your patch. 

Sylvain

[Doug Bonar]

Cool, I'll make the change in my copy.  Personally, I can't really imagine having more than one debugger session active at a time, but better to keep them in sync.

Doug

[Sylvain Corlay]

Jed, do you think this patch is an acceptable solution to issues 849 and 609 ? Cheers, 

S. 

[Jed Ludlow]

On Tue, Apr 2, 2013 at 12:59 PM, Sylvain Corlay <sylvain...@gmail.com> wrote:

Jed, do you think this patch is an acceptable solution to issues 849 and 609 ? Cheers, 

S. 

Sorry for the long delay in responding on this thread. I've now got all the files patched, and I'm looking at it in more detail now. I hope to have some more results tomorrow.

Jed 

[Jed Ludlow]

On Friday, April 5, 2013 10:32:58 PM UTC-6, Jed Ludlow wrote:

On Tue, Apr 2, 2013 at 12:59 PM, Sylvain Corlay wrote:

Jed, do you think this patch is an acceptable solution to issues 849 and 609 ? Cheers, 

S. 

Sorry for the long delay in responding on this thread. I've now got all the files patched, and I'm looking at it in more detail now. I hope to have some more results tomorrow.

Jed 

I've completed a more thorough review. This is an excellent approach. I ultimately want to make breakpoint setting bi-directional (a change in Spyder gets reflected in pdb sessions *and* command line breakpoint changes in pdb sessions get reflected in Spyder), but the first direction is far more critical than the second.

I made a few modifications to make the solution a bit more general. It turns out that the previous approach didn't quite cover the "Clear all breakpoints" case, and it also wasn't working for the right-click context menu commands in the breakpoint plugin. To make that work, I had to use a slightly bigger hammer, basically eliminating all breakpoints and resetting them again every time a breakpoint change was made. I agree that it would be better in the long run to be less aggressive, but to get that working right for all possible use cases will take bigger changes.

Rather than push the changes directly to the default repo I have pushed them to my clone at bookmark jedludlow-issue-609 :

https://code.google.com/r/jedludlow-spyderlib-default/source/detail?r=60d63ffc8b5d68111f73f023305366b5dcc69361

I have also asked for review to decide if this should go into 2.2 or wait for 2.3. Feel free to chime in either by direct code review comments inline with the code or by commenting on the code review request here:

https://code.google.com/p/spyderlib/issues/detail?id=1345

Jed

[Carlos Córdoba]

Great work Jed and Doug! I already reviewed Jed's changes and I'm favor to add them to 2.2 because they are not so disruptive.

I think this was the last missing piece to make our debugging support really shine!

Cheers,
Carlos

El 06/04/13 11:01, Jed Ludlow escribió:

--
You received this message because you are subscribed to the Google Groups "spyder" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spyderlib+...@googlegroups.com.
To post to this group, send email to spyd...@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jed Ludlow]

On Saturday, April 6, 2013 10:23:47 AM UTC-6, Carlos Córdoba wrote:

Great work Jed and Doug! I already reviewed Jed's changes and I'm favor to add them to 2.2 because they are not so disruptive.

I think this was the last missing piece to make our debugging support really shine!

Cheers,
Carlos

Ok, the relevant changes have now been pushed to the default repository at this merge:

https://code.google.com/p/spyderlib/source/detail?r=c4597613ba21211a89945e38bc60c7f4eea7f1b1

The majority of the work was shouldered by Doug and Sylvain, so a big thanks to them for seeing a simple solution that I had not realized previously. I simply did the final cleanup.

Jed 

[Doug Bonar]

Glad to see it go in.  Having to set breakpoints on the command line was probably the biggest problem I was having with getting people to use Spyder rather than Eclipse+PyDev.  So this is a two-way win for me because the feature will exist, and I can point to being able to get changes made both locally and "officially".  

Doug

Doug: 

Jed 

--

You received this message because you are subscribed to a topic in the Google Groups "spyder" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/spyderlib/6gSNKVfQnlM/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to spyderlib+...@googlegroups.com.

[Sylvain Corlay]

Thanks for the attention but Doug did everything and should get credit for it. Thank you guys for correcting this bug and integrating it in the main branch. It makes a big difference!

S.