You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In some applications, the computational cost of evaluating some cells can be so high that using Pluto instead of Jupyter is currently not an option (for example cells that do expensive statistical inference, run a simulation for minutes, etc.). However, the number of such cells in a notebook is typically (very) small.
Would it be possible to allow the user to disable auto-update for selected cells? The cells could be color coded or so to make this obvious. And if the output of the cell becomes out-of-date, the output could simply be "greyed-out" or so (same for all cells depending on it). Then the user could choose when to manually trigger re-evaluation of the cell (which would, of course, then also trigger evaluation of all "normal" cells depending on it).
I feel this would not break the philosophy of Pluto, since things would still be auto-updated for the most part, while it would open up Pluto for an entire class of applications (those involving heavier computing). It would also be quite natural to use, I think: While the user is playing around with some cells that (e.g.) define the input of a calculation, and to some initial check and plots, they typically will not want their (maybe chain of) expensive "main calculation" cells to be re-run all the time. However, when they're happy with their (e.g.) input stage, they will want to trigger their (maybe chain of) main calculation cells, and of course they will also want all their follow-up analysis and plotting code to run.
In some contexts, e.g. where cluster or clould job submissions are involved, running certain cells might actually consume limited computation budgets (or money, in the case of cloud). Even if not, it might load a system heavily, affecting other users. So allowing for optional control of the update-mechanism would also be resource-friendly.
My apologies if this has already been discussed.
The text was updated successfully, but these errors were encountered:
In some applications, the computational cost of evaluating some cells can be so high that using Pluto instead of Jupyter is currently not an option (for example cells that do expensive statistical inference, run a simulation for minutes, etc.). However, the number of such cells in a notebook is typically (very) small.
Would it be possible to allow the user to disable auto-update for selected cells? The cells could be color coded or so to make this obvious. And if the output of the cell becomes out-of-date, the output could simply be "greyed-out" or so (same for all cells depending on it). Then the user could choose when to manually trigger re-evaluation of the cell (which would, of course, then also trigger evaluation of all "normal" cells depending on it).
I feel this would not break the philosophy of Pluto, since things would still be auto-updated for the most part, while it would open up Pluto for an entire class of applications (those involving heavier computing). It would also be quite natural to use, I think: While the user is playing around with some cells that (e.g.) define the input of a calculation, and to some initial check and plots, they typically will not want their (maybe chain of) expensive "main calculation" cells to be re-run all the time. However, when they're happy with their (e.g.) input stage, they will want to trigger their (maybe chain of) main calculation cells, and of course they will also want all their follow-up analysis and plotting code to run.
In some contexts, e.g. where cluster or clould job submissions are involved, running certain cells might actually consume limited computation budgets (or money, in the case of cloud). Even if not, it might load a system heavily, affecting other users. So allowing for optional control of the update-mechanism would also be resource-friendly.
My apologies if this has already been discussed.
The text was updated successfully, but these errors were encountered: