- kernel_selector.set_kernel validates selection and triggers 'spec_changed.Kernel'. It does not start the session anymore.
- notebook calls kernel_selector.set_kernel when:
- kernelspec is in notebook metadata
- session is loaded (e.g. no kernelspec metadata)
- notebook starts session, loads metadata on spec_changed.kernel
The only case where starting the session is not triggered by spec_changed is on notebook load with no kernel metadata
Ensures kernel.js is always loaded.
It wasn't being loaded when creating a new notebook with a particular kernel because `change_kernel` wasn't being called. Only the `spec_changed` event is triggered by all the various ways a kernel can be loaded,
so load kernel stuff on that event.
As per discussion, each kernel can provide a file name kernel.js that
we try to load at kernel switching. If such a file exist we assume that
the kernel pathches the javasscript and that this javascript cannot be
unpatched, and further switching of the kernel cannot be undone without
reloading the page. (separate PR for UI)
if a kernel provide kernel.js, the it should consist into a AMD module
definition that uses require.js the module shoudl define a function name
`onload` that will be called at the appropriate moment before the kernel
starts.
javascript doesn't guarantee the order of AJAX requests,
so we give `Session.delete` and `Kernel.kill` a callback signature.
Changing the kernel type calls `Notebook.start_kernel`,
which terminates the previous session, if defined,
before starting the new one.
A flag is stored, to prevent multiple simultaneous attempts to start sessions, raising a SessionAlreadyStarting Error,
preventing the spec_changed event from firing.
Min RK
Matthias Bussonnier
Mathieu
Thomas Kluyver