3 ms·

Does anybody knows if with JupyterLab I will be able to keep some code running, close the browser, and still get the output of the code afterwards? For what I k

Does anybody knows if with JupyterLab I will be able to keep some code running, close the browser, and still get the output of the code afterwards? For what I know, currently I have to keep the browser open if I want to capture the output of a cell.

carreau 9y ago
If you update the `notebook` package there should be a workaround. Messages will be buffered on server-side until a client reconnect. It is still not perfect, but get part of the way. One long term plan is to have server-side model (not sure if it will be by default, or an extension), and have the browser just be a vue on this. It is quite hard to design as many visualisation libraries assume to be in a browser context, and have access to DOM.
- simsla 9y ago
  Would it be possible to buffer it in a way that survives interruption of jupyter/the kernel? (Maybe a stupid question. This lies outside of my expertise.) Thanks for building jupyter by the way. It's an essential part of my workflow.
  - carreau 9y ago
    Probably, though that might lead to inconsistent state. There are a lot that could be done, like actually recording the messages and replaying them, or broadcast to have for example a live "static view" when peer programming. But for this feature to be pushed forward you either need Volunteer time, or Donation to the project to hire devs/managers/designers,... (Donation to NumFOCUS https://www.numfocus.org/ https://www.numfocus.org/ are TaxDeductible)
- bguberfain 9y ago
  Buffering is indeed helpful, but will not solve the problem. I always thought that a proxy server holding the current state and sending diffs to clients would be enough, but it would still have issues with visualization libs. Is there somewhere were this issue can be discussed and addressed? GitHub?
  - carreau 9y ago
    There are a couple of issues about that, a bit scattered around. And many moving pieces. I agree that a proxy would be a nice thing, and IIRC someone made a prototype. This also hook into the JupyterLab "StateDB"/"modeldb" work and making it CRDT (Conflict-free Replicated Data Types) which is WIP somewhere; but I'm not sure where the best place is to discuss this. Work may happen on jupyter/notebook , jupyterlab/jupyterlab or maybe even https://github.com/phosphorjs/phosphor https://github.com/phosphorjs/phosphor I would take my chance on the main mailing list/google group.

carreau 9y ago

If you update the `notebook` package there should be a workaround. Messages will be buffered on server-side until a client reconnect. It is still not perfect, but get part of the way. One long term plan is to have server-side model (not sure if it will be by default, or an extension), and have the browser just be a vue on this. It is quite hard to design as many visualisation libraries assume to be in a browser context, and have access to DOM.

simsla 9y ago
Would it be possible to buffer it in a way that survives interruption of jupyter/the kernel? (Maybe a stupid question. This lies outside of my expertise.) Thanks for building jupyter by the way. It's an essential part of my workflow.
- carreau 9y ago
  Probably, though that might lead to inconsistent state. There are a lot that could be done, like actually recording the messages and replaying them, or broadcast to have for example a live "static view" when peer programming. But for this feature to be pushed forward you either need Volunteer time, or Donation to the project to hire devs/managers/designers,... (Donation to NumFOCUS https://www.numfocus.org/ https://www.numfocus.org/ are TaxDeductible)
bguberfain 9y ago
Buffering is indeed helpful, but will not solve the problem. I always thought that a proxy server holding the current state and sending diffs to clients would be enough, but it would still have issues with visualization libs. Is there somewhere were this issue can be discussed and addressed? GitHub?
- carreau 9y ago
  There are a couple of issues about that, a bit scattered around. And many moving pieces. I agree that a proxy would be a nice thing, and IIRC someone made a prototype. This also hook into the JupyterLab "StateDB"/"modeldb" work and making it CRDT (Conflict-free Replicated Data Types) which is WIP somewhere; but I'm not sure where the best place is to discuss this. Work may happen on jupyter/notebook , jupyterlab/jupyterlab or maybe even https://github.com/phosphorjs/phosphor https://github.com/phosphorjs/phosphor I would take my chance on the main mailing list/google group.