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