[IPython-dev] New ipythonqt console questions/feedback
Sat Oct 9 01:32:48 CDT 2010
On Fri, Oct 8, 2010 at 4:09 PM, MinRK <email@example.com> wrote:
> On Fri, Oct 8, 2010 at 15:52, Fernando Perez <firstname.lastname@example.org> wrote:
>> On Fri, Oct 8, 2010 at 3:41 PM, MinRK <email@example.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
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?
> 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.
More information about the IPython-dev