Compare commits

..

1 Commits

Author SHA1 Message Date
Tyler Goodlet 455f10a655 Further root readme bump, factor `.clearing` content
In line with our move to `uv` and recent `nix` support update a bunch of
the summary content and factor out the order-control section to a new
`.piker.clearing` readme file with embedded todos therein.
2025-02-12 15:00:44 -05:00
1 changed files with 11 additions and 11 deletions

View File

@ -121,34 +121,34 @@ various sub-readmes:
spawn a daemon standalone
*************************
we call the root actor-process the `pikerd`. it can be (and is
recommended normally to be) started separately from the `piker chart`
program::
we call the root actor-process the ``pikerd``. it can be (and is
recommended normally to be) started separately from the ``piker
chart`` program::
pikerd -l info --pdb
the daemon does nothing until a `piker`-client (like `piker chart`) connects
the daemon does nothing until a ``pikers`-client (like `piker chart`) connects
and requests some particular sub-system. for a chart connection
`pikerd` will spawn and manage at least,
``pikerd`` will spawn and manage at least,
- a data-feed daemon: `datad` which does all the work of comms with
the backend provider (in this case the `binance` cex).
- a paper-trading engine instance, `paperboi.binance`, (if no live
- a data-feed daemon: ``datad`` which does all the work of comms with
the backend provider (in this case the ``binance`` cex).
- a paper-trading engine instance, ``paperboi.binance``, (if no live
account has been configured) which allows for auto/manual order
control against the live quote stream.
*using* an actor-service (aka micro-daemon) manager which dynamically
supervises various sub-subsystems-as-services throughout the `piker`
supervises various sub-subsystems-as-services throughout the ``piker``
runtime-stack.
now you can (implicitly) connect your chart::
piker chart btcusdt.spot.binance
since `pikerd` was started separately you can now enjoy a persistent
since ``pikerd`` was started separately you can now enjoy a persistent
real-time data stream tied to the daemon-tree's lifetime. i.e. the next
time you spawn a chart it will obviously not only load much faster
(since the underlying `datad.binance` is left running with its
(since the underlying ``datad.binance`` is left running with its
in-memory IPC data structures) but also the data-feed and any order
mgmt states should be persistent until you finally cancel ``pikerd``.