Was running 0de971c2b32dcffbcef1465d612c365b3027838b. Going back to the tagged v2.2.0beta2 works fine. The merge of the ipython improvements (e6ff60e4db575a0625388d6cb0b8daa7e70ef632) causes the breakage .
On Thursday, February 14, 2013 3:24:31 PM UTC-6, Steve wrote: > > Hmm.. This conversation may be relevant to my situation. Debugging > integration is broken for me. I use a console window on my second monitor > (regular python, not ipython). Clicking the icons on the toolbar does > nothing as well as my hotkey bindings. I'm going to try and go back and > time and see when it broke. > > On Tuesday, February 12, 2013 5:20:15 PM UTC-6, Jed Ludlow wrote: >> >> On Tue, Feb 12, 2013 at 2:50 PM, Carlos Córdoba <[email protected]>wrote: >> >>> Today, all decisions about run commands and debugging control commands >>> are based upon console visibility. So, if two consoles are visible and you >>> change focus to the editor, commands will always go to the IPython console >>> regardless of widget focus today. To get them to enter the other console >>> you have to hide the IPython console. >>> >>> >>> My bad, it was the easiest thing for me to do at first. Perhaps after >>> solving the previous point, it should fix this one too. >>> >>> >> I don't think it's bad at all. It's actually quite convenient for the >> large majority of use cases. It only becomes a bit tricky when two consoles >> are visible. That's a fairly rare situation. >> >> >>> Incidentally, one longer-term solution would be to make it impossible >>> for more than one console to be showing by housing all consoles, both >>> standard Python interpreters and IPython clients, as tabs of the same >>> plugin. Old Spyder was this way. That would eliminate all ambiguity about >>> command direction and require no manual focus setting. I know issue 1053 >>> argues for putting IPython kernels and clients in the same plugin [1], but >>> the more I think about it the kernels are the things that really belong in >>> their own plugin by themselves. Standard Python interpreters and IPython >>> clients seem to be more natural cousins to be housed in the same tab widget >>> given the type of input they receive from the user. >>> >>> >>> Work for 2.3, right? :-) The two consoles are wildly different right now >>> and joining them won't be easy (if feasible at all). >>> >> >> Yes, I mean for 2.3 or beyond. I'm not recommending it lightly since I >> recognize it would be a fair amount of work. Rather, I'm suggesting that >> it's worth considering since it seems more intuitive than forcing kernels >> and clients into the same plugin (which sounds like a lot of work, too). If >> we are to adopt a problem that involves a lot of work, we should make sure >> we adopt the right one. >> >> >>> This will likely require a monkey patch to pdb since it's possible to >>> put a console into debug mode from the command line, and the only way for >>> Spyder to find out about that would be if pdb itself did the notifying. >>> That's not really a good option for external kernels since we can't monkey >>> patch pdb in those. I think we can come to a rational console selection >>> method without having to go there. >>> >>> >>> I think it could be far more easier: add a signal to the Debug action >>> and button that changes the state of a new console attribute called >>> "debugging". >>> >>> >> It is possible to catch it there for many use cases, but what happens >> when, say, you use IPython magic from the command line and manually issue >> "%run -d script.py". Now Spyder has no idea that debugging is going on in >> that console. >> > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/spyderlib?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
