-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Global output area for the notebook #75
Comments
As an addition to (1), anything that creates a child process that writes to stdout and stderr ends up not shown in the notebook (this is what @takluyver was hoping to address with the kernel nanny IIRC). I've been thinking about how I'd want general kernel output that didn't go over the normal messages to appear as a separate rolling log (like a side terminal). This would be useful for my current operations where a kernel runs on the JVM and generally has startup issues. If it can't even start then it doesn't even get ZMQ started and the user has no idea why the kernel is failing (and may not have quick access to the notebook server logs). |
On the scales of agreement, I'm not sure I believe in serializing a global output format. I am in agreement that there is a problem to solve here though. 👍 |
This would be a single output area on the notebook, for example: nb.global_outputs = [
...
] otherwise identical to the |
This is something that has come up a few times in the past in discussions on various topics such as connecting multiple clients to a kernel and interactive widgets.
There should be a global output for the notebook, not only in the UI but also in the document format. For the following reasons:
stdout
/stderr
messages are not uniquely bound to a cell of the notebook and are therefore lost to the user.If we do so, information such as the widget manager state could become global output instead of notebook-level metadata. Indeed such an output would be a more natural location for transient information than
metadata
, which conveys the idea of more static information.Not all front-ends need to implement a UI for that notebook-level output area, but I imagine that it could be displayed optionally, or simply accessible through convenience js fonctions for people who work in the front-end.
The text was updated successfully, but these errors were encountered: