[IPython-dev] New ipythonqt console questions/feedback

[Fernando Perez]

Hey,

On Fri, Oct 8, 2010 at 4:09 PM, MinRK <benjaminrk at gmail.com> wrote:
>
>
> On Fri, Oct 8, 2010 at 15:52, Fernando Perez <fperez.net at gmail.com> wrote:
>>
>> On Fri, Oct 8, 2010 at 3:41 PM, MinRK <benjaminrk at gmail.com> wrote:
>> > It doesn't necessarily have to be done differently at startup, because
>> > you
>> > can 'destroy' a widget at any point, leaving the process alive.
>>
>> Sorry, do you mean leaving the client process or the kernel process alive?
>
> It leaves the parent process alive, but destroys the widget.  What would
> require some different behavior at the top level would be to allow the
> kernel to persist beyond its parent process.  The original KernelManager
> lives in that process. I haven't changed this behavior at all, I just
> destroy the window *without* ending the process.  Then, when another window
> issues a shutdown command, the original parent process gets shutdown as well
> as the kernel subprocess.

OK, thanks for the clarification.

That actually sounds like a reasonable approach to me.  No user will
do this by accident, and it's a very useful feature to have.  I'll go
over the code tomorrow to review it.

>> Great!  Do you want this for inclusion now?  Initially you meant it
>> purely as a proof of concept, but at this point it's getting to be
>> useful functionality :)
>
> It can be merged now. The main thing that's not solid is the close dialog.
>  It's not obvious to me how to present the options clearly and concisely.
> Any suggestions for prompt and button text?
> Cancel: do nothing (easy)
> Option 1: close only the console
> Option 2: shutdown the entire session, including the kernel and all other
> frontends.

How about the dialog:

#
"Close console and/or kernel?"

[Cancel] [Close console] [Close both]
#

>> :)  The key question in yours is whether it leaves the Qt client
>> process zombified or not, I'm not quite clear on that point yet.
>
> Nothing really gets zombified, because the original kernel does not get
> detached from its parent.  If you close all the consoles, you can still stop
> the kernel with ctrl-C in the original terminal window.
> However, if you start the original kernel with a GUI launch method (i.e. not
> attached to a terminal), you can close all of the consoles, leaving the
> kernel around waiting for frontends.  This is sort of like a zombie since
> there is little evidence that it's still around, but it's still fully
> functional and fully valid (you can connect frontends to it later). Note
> that you have to specifically choose to leave the kernel alive every time
> you close a console to do this, so I'm okay with that level of clarity.

I'm thinking each kernel should leave a file in ~/.ipython with its
pid and port info.  This would make it easy to have later a tool that
can read this info and either connect to existing kernels, or cleans
them up.  What do you think?

Cheers,

f

> There could be something wrong in my code, since this (and the fixes
> yesterday) is my first Qt code ever, but it seems pretty straightforward.