automaton-simulation-de.control
Control is a higher level API for simulation scheduler. With a control state you have a pointer to one iteration that you can control with play!, next!, move-x ...
Its design documents are in docs/archi/control/...
Design decision: Control state as an atom containing all information about rendering
Pros:
- With atom state can be managed during long-lasting operations e.g. during play! we can modify the speed of it, modify pause easily
- We can reuse atom state to modify the flow from multiple places
- Atom handles well multithreading
- Atom can be used both on clj and cljs Cons:
- Not known
Design decision: Split between control and computation
Pros:
- Split allows to easier manage responsibility between controling what's current response to render and how to move between them
- Computation being separated allows for flexibility in how to manage execution of scheduler. This allows for adding later on optimisation, split between backend/frontend rendering, offline/online usag... Cons:
- User of rendering needs to have more knowledge about how rendering is working
Design decision: Control based on computation (vs e.g. control based on state and separated from computation) Pros:
- Code is easier to manage and understand (decrease complexity)
- We are in rendering context so it allows for better solutions for rendering Cons:
- Control knows about computation so code is more entangled
Control is a higher level API for simulation scheduler. With a control state you have a pointer to one iteration that you can control with play!, next!, move-x ... Its design documents are in docs/archi/control/... Design decision: Control state as an atom containing all information about rendering Pros: - With atom state can be managed during long-lasting operations e.g. during play! we can modify the speed of it, modify pause easily - We can reuse atom state to modify the flow from multiple places - Atom handles well multithreading - Atom can be used both on clj and cljs Cons: - Not known Design decision: Split between control and computation Pros: - Split allows to easier manage responsibility between controling what's current response to render and how to move between them - Computation being separated allows for flexibility in how to manage execution of scheduler. This allows for adding later on optimisation, split between backend/frontend rendering, offline/online usag... Cons: - User of rendering needs to have more knowledge about how rendering is working Design decision: Control based on computation (vs e.g. control based on state and separated from computation) Pros: - Code is easier to manage and understand (decrease complexity) - We are in rendering context so it allows for better solutions for rendering Cons: - Control knows about computation so code is more entangled
all-stopping-criteriasclj/s
(all-stopping-criterias state)All stopping criterias that are possible
All stopping criterias that are possible
build-rendering-stateclj/s
(build-rendering-state initial-state)Builds state atom that is required to use controls
Builds state atom that is required to use controls
fast-forward!clj/s
(fast-forward! state)Move to last possible iteration
Move to last possible iteration
fast-forward?clj/s
(fast-forward? state)Is fast forward possible?
Is fast forward possible?
make-computationclj/s
(make-computation model computation-type & comp-data)Creates computation object for rendering state to manage computation of scheduler responses
Creates computation object for rendering state to manage computation of scheduler responses
move-x!clj/s
(move-x! state x)Move x number of iterations from the point of state current-iteration
Params:
x - integer (both negative and positive numbers)
Move `x` number of iterations from the point of state `current-iteration` Params: `x` - integer (both negative and positive numbers)
pause!clj/s
(pause! state)(pause! state val)Set :pause? in state to val boolean
Default value for val is opposite of current value
Especially useful for stopping play! fn`
Set :pause? in `state` to `val` boolean Default value for `val` is opposite of current value Especially useful for stopping `play!` fn`
play!clj/s
(play! state on-iteration-fn)Render simulation until rendering is paused or impossible to go further.
On each iteration executes on-iteration-fn with scheduler response.
Speed of going to next iteration can be adjusted with :play-delay in state
Render simulation until rendering is paused or impossible to go further. On each iteration executes `on-iteration-fn` with scheduler response. Speed of going to next iteration can be adjusted with `:play-delay` in `state`
wrap-registryclj/s
(wrap-registry registry)Wraps a model to add necessary behavior to model rendering. Adds stopping-criteria that are usefull to manage state
Wraps a model to add necessary behavior to model rendering. Adds stopping-criteria that are usefull to manage state
cljdoc is a website building & hosting documentation for Clojure/Script libraries
× close