f348cbcd52
An async exit stack around the new `@tractor.context` is problematic since a pushed context can't bubble errors unless the exit stack has been closed. But in that case why do you need the exit stack if you're going to push it and wait it right away; it seems more correct to use a nursery and spawn a task in `pikerd` that waits on the both the target context completion first (thus being able to bubble up any errors from the remote, and top level service task) and the sub-actor portal. (Sub)service Daemons are spawned with `.start_actor()` and thus will block forever until cancelled so, add a way to cancel them explicitly which we'll need eventually for restarts and dynamic feed management. The big lesson here is that async exit stacks are not conducive to spawning and monitoring service tasks, and especially so if a `@tractor.context` is used since if the `.open_context()` call isn't exited (only possible by the stack being closed), then there will be no way for `trio` to cancel the task that pushed that context (since it can't run a checkpoint while yielded inside the stack) without also cancelling all other contexts pushed on that stack. Presuming one `pikerd` task is used to do the original pushing (which it was) then any error would have to kill all service daemon tasks which obviously won't work. I see this mostly as the painz of tinkering out an SC service manager with `tractor` / `trio` for the first time, so try to go easy on the process ;P |
||
|---|---|---|
| .github/workflows | ||
| data | ||
| piker | ||
| snippets | ||
| tests | ||
| .gitignore | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| requirements-test.txt | ||
| requirements.txt | ||
| setup.py | ||
README.rst
piker
trading gear for hackers.
piker is a broker agnostic, next-gen FOSS toolset for real-time computational trading targeted at hardcore Linux users .
we use as much bleeding edge tech as possible including (but not limited to):
- latest python for glue
- trio for structured concurrency
- tractor for distributed, multi-core, real-time streaming
- marketstore for historical and real-time tick data persistence and sharing
- techtonicdb for L2 book storage
- Qt for pristine high performance UIs
- pyqtgraph for real-time charting
numpyandnumbafor fast numerics
focus and features:
- 100% federated: your code, your hardware, your data feeds, your broker fills.
- zero web: low latency, native software that doesn't try to re-invent the OS
- maximal privacy: prevent brokers and mms from knowing your planz; smack their spreads with dark volume.
- zero clutter: modal, context oriented UIs that echew minimalism, reduce thought noise and encourage un-emotion.
- first class parallelism: built from the ground up on next-gen structured concurrency primitives.
- traders first: broker/exchange/asset-class agnostic
- systems grounded: real-time financial signal processing that will make any queuing or DSP eng juice their shorts.
- non-tina UX: sleek, powerful keyboard driven interaction with expected use in tiling wms
- data collaboration: every process and protocol is multi-host scalable.
- fight club ready: zero interest in adoption by suits; no corporate friendly license, ever.
fitting with these tenets, we're always open to new framework suggestions and ideas.
building the best looking, most reliable, keyboard friendly trading platform is the dream; join the cause.
install
piker is currently under heavy pre-alpha development and as such should be cloned from this repo and hacked on directly.
for a development install:
git clone git@github.com:pikers/piker.git
cd piker
virtualenv env
source ./env/bin/activate
pip install -r requirements.txt -e .broker Support
for live data feeds the in-progress set of supported brokers is:
- IB via
ib_insync - questrade which comes with effectively free L1
- kraken for crypto over their public websocket API
coming soon...
- webull via the reverse engineered public API
- yahoo via yliveticker
- coinbase through websocket feed
if you want your broker supported and they have an API let us know.
check out our charts
bet you weren't expecting this from the foss bby:
piker -b kraken chart XBTUSDrun in distributed mode
start the service daemon:
pikerd -l infoconnect yourt chart:
piker -b kraken chart XMRXBTenjoy persistent real-time data feeds tied to daemon lifetime.
if anyone asks you what this project is about
you don't talk about it.
how do i get involved?
enter the matrix.
how come there ain't that many docs
suck it up, learn the code; no one is trying to sell you on anything.
who is piker0?
who do you think?