Pluto.jl: See results during calculation

[j-fu]

Just an idea - I am thinking about possibilities to present results of time dependent calculations within Pluto. The possibility to do this via animated @gif in Plots is there, but this is quite restricted and a bit far away with other packages.

I was thinking about the following: Currently, cell1 like
for i=1:10 global a a=i end
with the dependent cell2
a
results in the value 10.

Now I imagine a macro, let's name it @emit which allows the following
for i=1:10 global a a=i @emit a end
@emit would trigger the recalculation in cell2 each time it is called, and we would see the development
of it's results. It could be restricted to work only in places where the cell value would be returned if it would not be there.

[karlwessel]

If this is possible to do it could be really cool, for example for a live display of statistics collected with OnlineStats.jl.
And of course for debugging purposes.

[Pocket-titan]

Though not as comprehensive as the potential @emit macro you're describing, there is already a way to do time-dependent computations in Pluto using the Clock function from PlutoUI:

As of right now there are no ways to programmatically stop or start the Clock (which might be desirable - note that in the gif, the third cell keeps rerunning even though its value doesn't change, since the clock keeps ticking), but if there were, I think you'd be pretty close to achieving the behaviour you're describing.

[j-fu]

Yeah it could be done via a kind of iterator over an collection which spits out the next value only if i has changed. Something like this
mutable struct ClockChecker last_i count ClockChecker()=new(1,0) end
checker=ClockChecker()

if running(checker,i) # just check if i has changed since last call, and if so increase counter j=count(checker) algorithmic_step(j) end
This hinges at the situation that Pluto doesn't detect mutations in structs (and array elements).
With the right naming (tried so here) this might be explainable to students, so may be this is good enough if @emit doesn't get a go. The it might also got into PlutoUI. Thinking about a PR...

[j-fu]

But it would be good it the clock would not start on loading, but only after the first push of "start".

[GiggleLiu]

+1 for adding a kwarg to allow not start on loading.

[fonsp]

(continuing a discussion from https://github.com/fonsp/PlutoUI.jl/pull/47)

updating a scene from within the for loop

This is a problem, because it breaks the all important goal: _"At any instant, the program state is completely described by the code you see."_

I think that the solution could be lazy lists. The basic use case:

Animation([expensive_result(t) for t in 1:100])

Could be made runtime/memory efficient by describing the frames using a lazy map:

Animation(map(expensive_result, @lazy 1:100))

Here, Animation is called immediately, and can generate frames lazily, when the UI requests one.

In your example, the simulation depends on the previous step, which makes it a trickier accumulate/reduce problem:

Animation(accumulate(advance, @lazy 1:100, init=x0))

with

function advance(old_solution::Array, t::Number)::Array
    ...
    return new_solution
end

[GiggleLiu]

At any instant, the program state is completely described by the code you see.

Interesting. But I am wondering if Pluto can have more possibility as a stateful machine.
A typical using case is GUI, it have to be a state machine in most cases. Currently, we can use mutable structs as the state of the machine to simulate it.

I think the key point is how to make this robust. I am quite interested in thinking more into this direction. An example is given here.
https://gist.github.com/GiggleLiu/7ab57094475d0a496112807d3235b8f5