Support {"msg_type":"shutdown_request"} and “quit()” for “ipython console”

[flying-sheep]

start a R console with IPython frontend via ipython console --kernel=ir

pressing C-d will apparently send a {"msg_type":"shutdown_request"} message to the kernel. we should support those.

other methods to cleanly exit R like calling quit() should also work, but instead yield “kernel died, restart ([y]/n)?”

[takluyver]

There is code to support shutdown_request - https://github.com/IRkernel/IRkernel/blob/0.4/R/kernel.r#L209

We should do the right thing when quit() is called, though. It's a bit convoluted: the kernel doesn't shut itself down, but the execute_reply it sends to the frontend includes an ask_exit payload. That will cause the frontend to issue a shutdown_request, and shut itself down as well.

[flying-sheep]

@shutdown_request: apparently it needs to be handled in handle_shell:

$ ipython console --kernel=ir
IPython Console 3.1.0

In [1]: <C-d>
Do you really want to exit ([y]/n)? y
[1] "Got unhandled msg_type:" "shutdown_request"    

[takluyver]

Ah, I bet the shutdown_request is coming over the shell channel instead of the control channel. Technically, the same set of messages can go over either channel. I guess I was testing it on the Qt console, and there shutdown_request actually goes over the control channel.

[flying-sheep]

jup, if it can come via both, we need to handle it in both.

[flying-sheep]

ah, quit() is still not there

[jankatins]

Yep, also just found out that quit() is not the way to exit a kernel...

Maybe overwrite the default quit function to call whatever the kernel needs tell the kernel manager to quit?

[flying-sheep]

yes, but i think this is getting chaotic.

we need to structure everything to make clear how it works

• options we set
• functions and variables we insert into the namespace
• functions we override/replace

@takluyver what do we do apart from those?

[takluyver]

I don't think we currently inject anything into the user namespace. We inject one function of the IRdisplay namespace so that that can send data using the kernel.

In time we probably want to override quit() and readline() to use the kernel.

[flying-sheep]

we are shading quit already.

but that breaks when clearing the global/user namespace, so maybe we should put it somewhere else. because yeah, it’s the user namespace, not ours.

[takluyver]

Aha, I missed that ;-).

What namespace is quit() normally in? Can we replace it there? Or can we shadow it from the package's namespace?

[flying-sheep]

What namespace is quit() normally in?

you can easily check that by doing

> environment(quit)
<environment: namespace:base>

Can we replace it there? Or can we shadow it from the package's namespace?

i think both. all packages are between .GlobalEnv and package:base, so wherever we put it it will work.

> search()
[1] ".GlobalEnv"        "package:stats"     "package:graphics" 
[4] "package:grDevices" "package:utils"     "package:datasets" 
[7] "package:methods"   "Autoloads"         "package:base" 

but we actually don’t attach any package, so we either

1. need to attach IRkernel (which would expose its public functions),
2. create and attach a IRoverrides package that contains just the functions we want to shade, or
3. replace quit() in package:base

[flying-sheep]

fixed ages ago in #196