Start with clock in stopped state (was ClockChecker)

[j-fu]

• Allow to check if the clock is running
• Do bookkeeping of the number of checks

See fonsp/Pluto.jl#476

[fonsp]

The Clock already returns the number of ticks:

@bind num_ticks Clock()

collect(1:num_ticks)

(I don't think I really understand what ClockChecker does or what problem it solves)

[j-fu]

I agree that this needs to be described better (or renamed or its structure improved). My use case is plotting of time dependent processes without resorting to creating gifs.

Let us assume I have a transient problem to solve, and a method to advance the time which does one or more timesteps:

solution=advance_time(old_solution, tstart, tend)

and I would like to plot the solution after each advancing step. Outside of Pluto I just would do:

t=collect(0:stepsize:tend)
for i=1:length(t)-1
     solution=advance_time(old_solution, t[i], t[i+1])
     plot(solution)
    old_solution.=solution
end

with the ClockChecker I can do in two Pluto cells

if running(checker, num_ticks)
     i=checks(checker)
     solution=advance_time(old_solution, t[i], t[i+1])
    old_solution.=solution
end

plot(solution)

and I can control running of the process using the clock. When I restart the clock, the process restarts with i=0. The point here is that I cannot know how long advance_time would take, so it is not possible to synchronize this with an independently ticking clock. I just want to repeat advance_time as long as the clock is ticking and restart from t[1] if I restart the clock.

With a hypothetical @emit I could just emit the solution in each step of the above for loop and trigger plotting, but I understand that this may be harder to implement or even against the reactivity concept.

[fonsp]

There are lots of these kinds of reactive mutability problems, and each requires a different creative solution. (observablehq.com notebooks demonstrate this.) I think that ClockChecker is too specific (and complicated) to include in PlutoUI. It would be more useful to write documentation to explain how to use Ref and reactive links to solve these puzzles yourself.

Another thing is that this promotes non-declarative programming. A declarative solution would be to use a precomputed animation (#26) or a GIF - this is a much simpler concept. You can also use memoization to write it as a function of (interactive) time. It sounds like you want to optimize the speed or memory usage, but is that really necessary?

[j-fu]

I accept that you see this as too complicated, after all it's a matter of taste... May be I'll find an simpler way which doesn't need such a struct.

As for declarative programming: It is all about the way time dependent results which can take some time for being computed are visualized. What I described is essentially a kind of iterator which produces time dependent results from an initial state. Whether they have been stored or are actually computed IMHO does not matter that much. However, storing may be expensive (3D PDEs), and waiting for a gif being produced for a longer calculation without any information (graphical or not) about the evolving state feels awkward like a windows boot after a system update... But I also grew up imperaratively, so I will check my mindset here...

Ultimately I want to use GPU accelerated graphics as in Makie or MeshCat for showing produced or stored results. Admittedly both seem to have concepts of updating a scene from within the for loop (need to check if this really works). In the moment both lack some visualization options, so PyPlot is in the list, too.

... what do you think about the clock state stopped by default after load ?

[fonsp]

... what do you think about the clock state stopped by default after load ?

Yes! We should add this property, and let's actually make it the default.

Ultimately I want to use GPU accelerated graphics as in Makie or MeshCat for showing produced or stored results.

This is definitely on my mind, I also want this to be possible. The MeshCat demo you sent is promising, and also the simon danisch ecosystem, but (currently) they both run their own HTTP server on a separate port, which means that it does not work over SSH, binder or GitHub codespaces (without forwarding the extra port), and I think/hope that these are "the future". Ideally they could both use Pluto as a proxy.

I am collaborating with Shashi Gowda and Sebastian Pfitzner on this problem - we hope to create a new Abstract* package that anyone can use to describe how their types can be visualized, and some other things. It will include this proxy idea.

Our design document is here:
https://docs.google.com/document/d/1_KJtlB0EyM8ytRzqngQBTArQLfNLPj70mDTywSVbghA/edit?usp=sharing
Feel free to join the discussion and write a paragraph about 3D viz!

I moved part of my comment here: fonsp/Pluto.jl#476 (comment)

[j-fu]

This is definitely on my mind, I also want this to be possible. The MeshCat demo you sent is promising, and also the simon danisch ecosystem, but (currently) they both run their own HTTP server on a separate port, which means that it does not work over SSH, binder or GitHub codespaces (without forwarding the extra port), and I think/hope that these are "the future". Ideally they could both use Pluto as a proxy.

Great that you see this in a similar way!

They both use three.js in the background. From the first tests I have the impression that MeshCat has much better performance, and each WGLMakie plot eats up one CPU core. When I'll find time I'll test this more and tell Simon... May be it is due to different ways to communicate data to three.js.

I am collaborating with Shashi Gowda and Sebastian Pfitzner on this problem - we hope to create a new Abstract* package that anyone can use to describe how their types can be visualized, and some other things. It will include this proxy idea.

Our design document is here:
https://docs.google.com/document/d/1_KJtlB0EyM8ytRzqngQBTArQLfNLPj70mDTywSVbghA/edit?usp=sharing
Feel free to join the discussion and write a paragraph about 3D viz!
I had a look - I am not that much in this javascript technology stuff (dabbled with three.js some time ago), so I am not sure if can contribute that much. However I will prepare a gist on my viewpoint, and provide the link.

[j-fu]

Ok accept the design decision to go without additonal methods around the clock, Would be nice thoug to allow initial state stopped (may be as an option).