This throws "Reactor failure: Error: Unsupported operation." not sure why

(defn ticker "tick randomly at intervals up to n ms wide" [n]
  (m/cp
    (loop [r 0]
      (m/amb
        r
        (recur (m/? (m/sleep r (rand-int n))))))))

amb and ? are illegal in cp

use ap

thanks, yeah m/ap works. I want this continuous so the sleeps will be started on sample, because i am doing this in an inner loop of 10k dom elements

i have exceeded the browser's ability to keep up with the eagerness, trying to figure out how to make it lazier

i'm good, will ask on monday

use a shared raf-based continuous clock and make each element's color a random function of time

Struggling to mathematically model each cell in a grid getting a separate random timer, I guess it is an incoherent requirement as the timers become coupled to the consumer's ability to keep up

If the cell is a function of [t x y] it's easy

First time see m/cp here, is it in b27 ? Whats difference with ap ?

https://github.com/leonoel/missionary/issues/26 compared to ap, cp is fully lazy but more restricted (only ?< is allowed, not ? and ?>)

Why is m/? not allowed in m/cp?

Is this correct: m/?> (concat) is not sensible in m/cp because concatenating two continuous flows doesn't make sense: a continuous flow models a "current/latest state" which doesn't terminate under normal conditions, and continuous flows are always defined from t=0 with an initial value, so stacking two simultaneous continuous flows doesn't make sense

As to m/? in m/cp, if this println makes sense (def !x (atom 0)) (m/cp (println (m/?< (m/watch !x)))) then why not an async println backed by a task?

The root lesson seems to be "side effects don't make sense in continuous time"

the mismatch is async vs laziness

cp must be defined at every point in time, an asynchronous computation is not defined until it terminates, therefore an asynchronous computation is essentially eager

i agree with that – and the natural conclusion of that argument seems to be that the println in m/cp should be illegal as well?

setting aside philosophy; implementation wise could (m/cp (m/amb 0 (m/? (m/sleep (m/?< (m/watch !x)) ::x))) either model a pending value, or leave the 0 in place until ::x is available? is there a technical reason i've missed

understanding that the sleep does not begin until sampled, and the ::x is not seen until sampled, which may not even be an issue depending on the nature of your effects

What triggers the sleep in this example ?

(comment
  "Thought experiment: can m/amb and m/? be defined sensibly in m/cp?"
  (def !x (atom 0))
  (def <y (m/cp (m/amb 0 (m/? (m/sleep (m/?< (m/watch !x)) ::x)))))
  (def !it (<y #(! ::notify) #(! ::terminate)))
  % := ::notify
  @!it := 0
  ;% := ::notify -- sleep cannot begin until sampled, nothing to notify
  ;@!it := ::x
  )

you could model pending though and notify pending