[Viewer] Add native support of Jupyter and Google Colab #187
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 9 commits
August 29, 2020 11:42
…nding reload request to the client.
duburcqa
changed the title
Merged
duburcqa
added a commit
that referenced
this pull request
Aug 31, 2020
* [Viewer] Native and full support of Jupyter and Google Colab, using directly kernel communication * [Viewer] Remove the support of port forwarding, since it is not longer relevant * [Viewer] Create display cell in notebook mode when instantiating a viewer while no display cell is already available * [Viewer] Check for browser availability when calling 'open_gui', and wait for the client to be ready * [Viewer] Avoid timeout on low-hand machine while starting video recording * [Viewer] Improve the reliability of running Meshcat server detection. * [Viewer] Remove heartbeat check since it is impossible to estimate appropriate response time Co-authored-by: Alexis Duburcq <alexis.duburcq@wandercraft.eu>
duburcqa
added a commit
that referenced
this pull request
Aug 31, 2020
* [Viewer] Native and full support of Jupyter and Google Colab, using directly kernel communication * [Viewer] Remove the support of port forwarding, since it is not longer relevant * [Viewer] Create display cell in notebook mode when instantiating a viewer while no display cell is already available * [Viewer] Check for browser availability when calling 'open_gui', and wait for the client to be ready * [Viewer] Avoid timeout on low-hand machine while starting video recording * [Viewer] Improve the reliability of running Meshcat server detection. * [Viewer] Remove heartbeat check since it is impossible to estimate appropriate response time Co-authored-by: Alexis Duburcq <alexis.duburcq@wandercraft.eu>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New features and improvements:
Bug fixes and improvements:
Various other minor fixes.
Side notes:
Bi-directional communication between frontend javascript and backend zmq is a bit tricky to achieve. It comes from the fact that the handling of incoming communications (including connection requests) are handled by the main thread, so it is not impossible to wait for a message through zmq socket, while waiting for an incoming reply from the kernel communications. More generally, it is impossible to do any multitasking, ie starting to monitor an new jupyter display while a replay loop is already running. Moreover, since the callback cannot interrupt the main thread, if the reply of a simulation has already started then a new display cell will stay empty since the opening notification will be received by the server only at the end. #stackoverflow #ipykernel
To circumvent those limitations, 'kernel.do_one_iteration' is interleaved 'zmq_socket.recv', so that incoming messages can be processed on the spot. The only issue doing this is that every request from the kernel will also be processed, including that queued cell evaluation. If there is any, it will corrupt the stack and Jupyter will throw an error (recoverable). It would be possible to avoid it by analysing the messages in the stack, only process 'comm_*', and put back in the stack the other ones. This is out of the scope of the PR. (UPDATE: Fixed by #190)