The watch-mode loop. Shell only: it polls modification times and the
keyboard, feeds what it finds to the pure volley.watch state machine, and
carries out the effects: build a plan, drive volley.engine for one run in
fresh workers, cancel a run, print, show the prompt.
Both inputs sit beside the one event queue instead of in a second one: the
queue holds only worker events, and the loop that reads it with a timeout
also checks the keyboard and, every volley.watch/poll-ms, the files. The
queue is the one mutable object; everything else is threaded through the
loop as a value: the worker handles and the live frame height (:world,
as volley.main threads them for a one-shot run) and the next worker id:
ids keep counting up
across runs, so a late event from a cancelled run's worker belongs to no
worker of the next run, and the engine drops it.
env (from volley.main):
:ctx {:queue :command}:run-effects! (fn [ctx world effects]) carries out engine effects,
returns [world exit-code-or-nil]:step! (fn [ctx world state input]) feeds the engine one
input and carries out its effects, [world state code]:print! (fn [{:lines :stream}]):reload-config (fn []) returning {:config c} or {:error msg}:worker-command (fn [config refresh?]) returning {:command argv}
or {:error msg}, for a reloaded config; with
refresh? the classpath is computed again:add-hook-paths! (fn [config]) puts a reloaded config's test paths
on the parent's classpath when its hooks run there:ctx's :command is only the first run's worker command; the session
keeps the current one:config, :config-file, :cli-suites:engine-opts options for volley.engine/init, without clock or timings:keys? read the keyboard (stdin is a terminal):live? the live reporter is in useThe watch-mode loop. Shell only: it polls modification times and the
keyboard, feeds what it finds to the pure `volley.watch` state machine, and
carries out the effects: build a plan, drive `volley.engine` for one run in
fresh workers, cancel a run, print, show the prompt.
Both inputs sit beside the one event queue instead of in a second one: the
queue holds only worker events, and the loop that reads it with a timeout
also checks the keyboard and, every `volley.watch/poll-ms`, the files. The
queue is the one mutable object; everything else is threaded through the
loop as a value: the worker handles and the live frame height (`:world`,
as `volley.main` threads them for a one-shot run) and the next worker id:
ids keep counting up
across runs, so a late event from a cancelled run's worker belongs to no
worker of the next run, and the engine drops it.
`env` (from `volley.main`):
* `:ctx` `{:queue :command}`
* `:run-effects!` `(fn [ctx world effects])` carries out engine effects,
returns `[world exit-code-or-nil]`
* `:step!` `(fn [ctx world state input])` feeds the engine one
input and carries out its effects, `[world state code]`
* `:print!` `(fn [{:lines :stream}])`
* `:reload-config` `(fn [])` returning `{:config c}` or `{:error msg}`
* `:worker-command` `(fn [config refresh?])` returning `{:command argv}`
or `{:error msg}`, for a reloaded config; with
`refresh?` the classpath is computed again
* `:add-hook-paths!` `(fn [config])` puts a reloaded config's test paths
on the parent's classpath when its hooks run there
* `:ctx`'s `:command` is only the first run's worker command; the session
keeps the current one
* `:config`, `:config-file`, `:cli-suites`
* `:engine-opts` options for `volley.engine/init`, without clock or timings
* `:keys?` read the keyboard (stdin is a terminal)
* `:live?` the live reporter is in use(watch! {:keys [ctx keys? live? config config-file] :as env})Run watch mode until the user quits. Returns the exit code.
Run watch mode until the user quits. Returns the exit code.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |