or does doing it this way not get the optimization? not sure what "if an input emits the same value twice" means actually...

i mean it seems to stop printing "ERROR:" when it hits the threshold but I have no idea why it works 😛

this seems pretty usable https://gist.github.com/nivekuil/ed032e1b889444631e2beb101333f836

@U09K620SG another benefit of doing it in missionary is you can pre-compile animations to waapi keyframes to offload them for dom

don't think you can parameterize electric as easily

continuous operators that fmap clojure fns, like m/latest and m/cp, will “work skip” if the input flows notify but with unchanged values, and decline to run the clojure fn, instead reusing and propagating the cached prior value forward

ah, so my implementation still wastes cycles on the clock. back to the drawing board

I guess I could sample setpoint , that only triggers on a clock in practice or just debounce it

yes looks so, though if the cpu is idle it may not be a big deal

I don't like it, I want basically every value to be animated. just need to get setpoint to open some kind of gate that gets closed when the controller stabilizes

makes sense to me

ended up with https://gist.github.com/nivekuil/ed032e1b889444631e2beb101333f836

?< + reset!+ watch is basically a goto right? feels weird

that feels imperative and wrong, there must be a better way

sadly it still used up my last brain cell

https://gist.github.com/leonoel/05d46a2fabda0de49063b6faba69866d

I think this pattern is correct, I added another animation example with an easing function

how long did that take to write? I think I still don't understand when signal is needed

signal is for creating dataflow diamond topology, it allocates a memo buffer so that the signal (flow) value can be shared across multiple consumers. It’s a DAG builder primitive, without it you have supervision trees not DAGs. Without signal, the flow, eg <time, will be booted N times for N consumers. So you’d have N clock instances. Missionary flows are deliberately RT so that you can reuse them and boot them many times if you want to. This is a feature not a bug, it gives you the ability to opt in to sharing and do so at explicit points, thereby allowing you to express either topology. That means without m.signal a flow’s computation and effects will recompute and rerun for each instance of the flow. m/signal ensures that a continuous flow is booted once and the result is saved and shared across all consumers. (implying allocation of the memo buffer.) each Electric let compiles to m/signal. Leo please tell me if I have made a mistake

> how long did that take to write? It took me a while to grok the idea of cyclic reaction but now I'm used to it and I find it rather straightforward. It is relatively close to EE, you just need to make sure the system is stable

certainly prettier than verilog. I wonder if the overhead of missionary here is small enough that this is a viable signal processing dsl

good question indeed

we are using electric to author a robotics control system in a client engagement (highly experimental, the compile time DAG structure with cycles appears to be exactly right but the runtime execution model probably ought to be discrete)

things like how to compile the simulation model to gpu optimized math array operators is an open question as well (unclear at what point this is actually needed as we are not, like, training LLMs or anything like that)

& yes, reset! is basically reactive goto though note there is still the key structure- the process supervision tracks through it

i've used nextjournal, make sure to use RCF for async examples https://nextjournal.com/dustingetz/missionary-relieve-backpressure . Can you say more about how clerk is different? I did use it once last year

I’m not sure it is any different since you last used it, I guess I was being hopeful.

I think I’m going to stick with the repl until I have a better understanding of the missionary primatives

Ok, even still i highly recommend RCF for learning missionary at the repl. Here are more examples https://github.com/hyperfiddle/electric/blob/master/src-docs/user/missionary/missionary_tutorial_object.cljc (siblings to this file)

they dont run in CI so let us know of any failures

That’s really helpful, thanks.

RCF looks like exactly what I’m looking for

Quick question, do I have to do anything different to see the test output of RCF in a clerk notebook?

Right now I’m just seeing the return value

the green check is printing to stdout and in the console. I don't know what Clerk does with stdout. NextJournal captures the stdout and prints it in the notebook as you can see in my notebook linked above

ok, that explains the difference. thanks

surely you are not the first to want Clerk to do this, I would ask

Surely, but I’m not in a position to wait for an answer right now. Once I have more free time I’ll go back and get some answers 😁

I’m thankful for your fast responses, you’ve got me unstuck a few times now

this is just liveview right?

I'm not familiar with liveview so I can't say

But the count here is server side https://github-production-user-asset-6210df.s3.amazonaws.com/108688/271960973-94265d9e-a6cd-4d2f-8345-100901efe3df.gif

no