Liking cljdoc? Tell your friends :D

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 ...

It's design documetns 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 ...

 It's design documetns 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
raw docstring

all-stopping-criteriasclj/s

(all-stopping-criterias state)

All stopping criterias that are possible

All stopping criterias that are possible
raw docstring

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
raw docstring

fast-forward!clj/s

(fast-forward! state)

Move to last possible iteration

Move to last possible iteration
raw docstring

fast-forward?clj/s

(fast-forward? state)

Is fast forward possible?

Is fast forward possible?
raw docstring

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
raw docstring

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)
raw docstring

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`
raw docstring

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`
raw docstring

rewind!clj/s

(rewind! state)

Move to first iteration

Move to first iteration
raw docstring

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
raw docstring

cljdoc is a website building & hosting documentation for Clojure/Script libraries

× close