wait and resume execution on button press

[gszep]

suppose there are two sections in my notebook:

• First Section: Pre-processing and lightweight computation, lots of interactivity
• Second Section: Application of algorithm, only need to visualise results, heavyweight computation

Ideally I would have a "Run Algorithm" button in the second section, where Pluto does not execute any code below the button - which contains heavyweight computations - and waits until I press it to execute it. Would this be possible? It would be nice to be able to separate out execution spaces.. Sometimes I just want to execute the first section without executing the second one at all, for example if I've changed my mind about the dataset I've loaded.

[fonsp]

Can you split you issue in two: 1. Clearly state the problem, 2. Your suggestion. I have found that it is difficult to discuss direct suggestions, but discussing the underlying problem leads to creative solutions.

[gszep]

Sure :) Suppose I have a notebook that looks like the following

### A Pluto.jl notebook ###
# v0.12.18

using Markdown
using InteractiveUtils

# ╔═╡ c49493f2-4366-11eb-2969-b3fff0c37e7b
begin # load packages and other requirements
    using ...
end

# ╔═╡ ba294c1c-43ab-11eb-0695-1147232dc62a
begin

       # allow user to interactively change prepocessing params
        @bind preprocessingParams ... # or more complicated binding of observables using JSServe.jl
    data,labels = load(path)

    # apply preprocessing params to data; typically fast and plot should be reactive
    transform!(data, preprocessingParams...)
    plot(data) # show summary statistics of preprocessed data; updates on changes to observables
end

# ╔═╡ 9dbf3d0c-4432-11eb-1170-4f59655b7820
begin  # computationally expensive cell; updates every time preprocessing params are changed - not desirable!
    outputs = train(data,labels)
end

# ╔═╡ b80a14f4-4435-11eb-07bd-7fcc8ca10325
begin  # interactively explore outputs
     @bind plotParams ... 
     plot(outputs,plotParams...)
end

# ╔═╡ Cell order:
# ╠═c49493f2-4366-11eb-2969-b3fff0c37e7b
# ╟─ba294c1c-43ab-11eb-0695-1147232dc62a
# ╟─9dbf3d0c-4432-11eb-1170-4f59655b7820
# ╟─b80a14f4-4435-11eb-07bd-7fcc8ca10325

The issue in this example is that the computationally expensive cell 9dbf3d0c-4432-11eb-1170-4f59655b7820 re-evaluates every time the user updates any of the observables in preprocessingParams. The user would usually tinker with those parameters, then once happy would execute cell 9dbf3d0c-4432-11eb-1170-4f59655b7820, grab a cup of tea, then come back and then explore the results in an interactive plot in cell b80a14f4-4435-11eb-07bd-7fcc8ca10325

Proposed Solution: Create a "pagebreak" style functionality. For example inserting a pagebreak like so

# ╔═╡ Cell order:
# ╠═c49493f2-4366-11eb-2969-b3fff0c37e7b
# ╟─ba294c1c-43ab-11eb-0695-1147232dc62a
# pagebreak
# ╟─9dbf3d0c-4432-11eb-1170-4f59655b7820
# ╟─b80a14f4-4435-11eb-07bd-7fcc8ca10325

Would treat the first two cells and the last two cells essentially as separate notebooks, with separate execution spaces. However when cell 9dbf3d0c-4432-11eb-1170-4f59655b7820 is executed, the current state of the preceding notebook is imported, including all values of observables.

Not sure how this could be done in practice. One could use an include statement but this would merely import the state with default values for all observables. Using include also re-evaluates the whole previous notebook which is not needed as the results are already available.. maybe this can be done by two different workers that pass messages between each other? Hope this helps explain the feature request.

[gszep]

I think this would also allow users to create larger notebooks - the size of a book for example - where each chapter or section in the book is treated as a separate execution space that (optionally) inherits the state from the previous section. This way when the user loads the notebook they don't have to wait until all cells in the book are executed before being able to interact with the first section of the book

[fonsp]

Can you take a close look at https://github.com/fonsp/Pluto.jl/discussions/298 ? It is a proposed solution to the same problem, so try to narrow down on how your suggestion is different and better.

It sounds very similar to https://github.com/fonsp/Pluto.jl/discussions/298#discussioncomment-182529 my response to this suggestion is https://github.com/fonsp/Pluto.jl/discussions/298#discussioncomment-182530 , you can comment on that message if you want to discuss that message further

[gszep]

will continue discussion on relevant thread :)