Nathan Huesken | 2 Dec 11:48

get stack from current pdb instance

Hi,

Is it possible to get the current call-stack from the current pdb
instance?

I noticed:
__IP.InteractiveTB.pdb.get_stack()

It takes 2 arguments, I found no documentation and have no idea what to
pass ...
--

-- 
 _________________________________________ 
/  The dame was hysterical. Dames Usually \
\ are. -- Calvin as Tracer Bullet         /
 ----------------------------------------- 
       \   ,__,
        \  (oo)____
           (__)    )\
              ||--|| *
Nathan Huesken | 2 Dec 12:22

Getting current list of breakpoints in "sync with editor"

Hi,

I want to syncronize breakpoints between my interactive ipdb in ipython
and gvim. For this, I do:

-------------------------------------------------
def write_breakpoints(ip,filename=""):
        ...
	breakpoints=ip.InteractiveTB.pdb.get_all_breaks()
        ...

#syncronize with the gvim editor
def sync(ip,filename,linenum,column):
        ...
	write_breakpoints(ip)
        ...

import IPython.ipapi
ip=IPython.ipapi.get()
ip.set_hook('synchronize_with_editor',sync)
--------------------------------------------------

This seemed to work before. But now (I have not touched it for some
time) it does not work anymore. The list of breakpoints is simply empty.

How can I get the current pdb instance? How can I get its breakpoints
within the sync-with-editor function?

Thanks!
Nathan
(Continue reading)

Jon Olav Vik | 3 Dec 03:44
Picon

Re: get stack from current pdb instance

Nathan Huesken <ipython <at> lonely-star.org> writes:

> Is it possible to get the current call-stack from the current pdb
> instance?
> 
> I noticed:
> __IP.InteractiveTB.pdb.get_stack()
> 
> It takes 2 arguments, I found no documentation and have no idea what to
> pass ...

(After writing the post below, it struck me that your question might be better 
asked at 
http://news.gmane.org/gmane.comp.python.ipython.devel
because you seem to be delving quite deeply into IPython internals.)

The source code isn't very long. If you know what you're doing (I don't), you 
can probably figure it out yourself. Specifically,

>>> ??__IP.InteractiveTB.pdb.get_stack()
    def get_stack(self, f, t):
        stack = []
        if t and t.tb_frame is f:
...

Just from the sound of it, I'd guess t is a traceback 
http://docs.python.org/library/traceback.html
and f is a (stack) frame. Searching the plain Python docs for tb_frame:
http://www.google.com/search?
q=tb_frame&domains=docs.python.org&sitesearch=docs.python.org
(Continue reading)

Neal Becker | 4 Dec 17:24
Picon

[newb] remote engine usage

On my local machine
I started:
ipcluster ssh --clusterfile=clusterfile

(all looks good, started 8 engines).

Again locally:

from IPython.kernel import client
mec = client.MultiEngineClient()

mec.execute ('import os')
res = mec.execute ('print os.getcwd()')

NoEnginesRegistered: There are no engines registered.
                     Check the logs in ~/.ipython/log if you think there 
should have been.

What did I do wrong here?
Danny Jacobs | 4 Dec 19:03
Favicon
Gravatar

KeyboardInterrupt ignored until flush is complete!

Hello Everyone,

My ipython usage experience is almost perfect and I am close to
achieving research nirvana but lately I have been having a strange
issue that really affects the workflow.  After working for a little
while, doing plotting and numpy stuff the keyboard interrupt (^c) at
the command line (eg to cancel a half-written command) stops working
and responds with

KeyboardInterrupt ignored until flush is complete!

before continuing on to (or attempt to) run whatever is on the command
line.  A google search for this error only brings up svn commits to
ipython from a couple years ago. As far as I can tell this has to do
with the pylab threading environment and perhaps some unfinished
thread process.  Is there a way to clear this (by giving it the flush
it desires) besides restarting the interpreter?  I haven't been able
to pin down when exactly interrupts stop working but I will keep
trying. Its definitely after doing some pylab plotting.

My basic science command line is:
ipython -pylab -p sh

IPython 0.10   [on Py 2.5.1]
matplotlib 0.99.1.1
OS X (10.5)

Thanks,
~Danny

(Continue reading)

Picon

Do you really, truly, cross-your-heart-and-hope-to-die want to quit?


When I want to quit from IPython, I really hate the prompt "Do you really
want to exit ([y]/n)? y". I
feel as though my judgment is being called into question. How do other
people feel about this?
--

-- 
View this message in context: http://old.nabble.com/Do-you-really%2C-truly%2C-cross-your-heart-and-hope-to-die-want-to-quit--tp26662668p26662668.html
Sent from the IPython - User mailing list archive at Nabble.com.
Ville M. Vainio | 6 Dec 10:51
Picon
Gravatar

Re: Do you really, truly, cross-your-heart-and-hope-to-die want to quit?

On Sun, Dec 6, 2009 at 8:45 AM, Dr. Phillip M. Feldman
<pfeldman <at> verizon.net> wrote:

> When I want to quit from IPython, I really hate the prompt "Do you really
> want to exit ([y]/n)? y". I
> feel as though my judgment is being called into question. How do other
> people feel about this?

The purpose of this is to annoy users enough to start using 'Exit'
with capital E ;-).

--

-- 
Ville M. Vainio
http://tinyurl.com/vainio
Fernando Perez | 6 Dec 11:32
Picon
Gravatar

Re: Do you really, truly, cross-your-heart-and-hope-to-die want to quit?

2009/12/6 Ville M. Vainio <vivainio <at> gmail.com>:
> On Sun, Dec 6, 2009 at 8:45 AM, Dr. Phillip M. Feldman
> <pfeldman <at> verizon.net> wrote:
>
>> When I want to quit from IPython, I really hate the prompt "Do you really
>> want to exit ([y]/n)? y". I
>> feel as though my judgment is being called into question. How do other
>> people feel about this?
>
> The purpose of this is to annoy users enough to start using 'Exit'
> with capital E ;-).

The real bug is that when you type exit() or quit(), we should always
exit unconditionally, like we do with %Exit.  But there's a valid use
case for a safety check: when an EOF exception is triggered, which on
*nix happens via a simple C-d keystroke.  That is very easy to touch
by accident, especially if you have emacs readline bindings, where C-d
on a non-empty line deletes characters, but C-d on an empty line
produces EOF.  So the difference of a single character on the current
line changes the behavior from deletion to ending the program, and it
might cost you a lot of state you took a long time to compute.

So the behavior should be:

- exit, quit, %Exit, etc: stop bothering people with questions and just quit.

- EOF exception: ask users by default, this can be configured to not
ask anymore if they want (but then, they can't complain if a single
misplaced C-d kills their hours-long session).

(Continue reading)

Phillip M. Feldman | 6 Dec 21:17
Picon

Re: Do you really, truly, cross-your-heart-and-hope-to-die want to quit?

I didn't know about this option.  This is a good workaround until the 
bug fix suggested by Fernando is implemented.

Thanks!

Philllip

This is a good interim lukshuntim <at> gmail.com wrote:
> Dr. Phillip M. Feldman wrote:
>   
>> When I want to quit from IPython, I really hate the prompt "Do you really
>> want to exit ([y]/n)? y". I
>> feel as though my judgment is being called into question. How do other
>> people feel about this?
>>     
>
> Hi,
>
> Maybe be you like "ipython -noconfirm_exit". :-)
>
> Regards,
> ST
> --
>
>
>
>
>   
Ville M. Vainio | 6 Dec 22:43
Picon
Gravatar

Re: Do you really, truly, cross-your-heart-and-hope-to-die want to quit?

On Sun, Dec 6, 2009 at 10:17 PM, Phillip M. Feldman
<pfeldman <at> verizon.net> wrote:

> I didn't know about this option.  This is a good workaround until the
> bug fix suggested by Fernando is implemented.

I find calling "Exit" with capital E really quite unobstructive (been
doing that right after picking up ipython).

--

-- 
Ville M. Vainio
http://tinyurl.com/vainio

Gmane