Show More
@@ -195,7 +195,7 b' The ``user_`` fields deserve a detailed explanation. In the past, IPython had' | |||
|
195 | 195 | the notion of a prompt string that allowed arbitrary code to be evaluated, and |
|
196 | 196 | this was put to good use by many in creating prompts that displayed system |
|
197 | 197 | status, path information, and even more esoteric uses like remote instrument |
|
198 |
status a |
|
|
198 | status acquired over the network. But now that IPython has a clean separation | |
|
199 | 199 | between the kernel and the clients, the kernel has no prompt knowledge; prompts |
|
200 | 200 | are a frontend-side feature, and it should be even possible for different |
|
201 | 201 | frontends to display different prompts while interacting with the same kernel. |
@@ -934,7 +934,8 b' Message type: ``status``::' | |||
|
934 | 934 | content = { |
|
935 | 935 | # When the kernel starts to execute code, it will enter the 'busy' |
|
936 | 936 | # state and when it finishes, it will enter the 'idle' state. |
|
937 | execution_state : ('busy', 'idle') | |
|
937 | # The kernel will publish state 'starting' exactly once at process startup. | |
|
938 | execution_state : ('busy', 'idle', 'starting') | |
|
938 | 939 | } |
|
939 | 940 | |
|
940 | 941 | Kernel crashes |
General Comments 0
You need to be logged in to leave comments.
Login now