Nelson Torres
3118d0f140
- To calculate the `max_pain` first we need an expiration date, get_expiration_dates()` retrieves them and the user then enters one of the shown, then using the select expiry_date on `get_instruments()` we are good to build the `oi_by_strikes` important! - Add `update_oi_by_strikes()`. - Add `check_if_complete()`. - `get_max_pain()`: here's where all the action takes place, the `oi_by_strikes` must be complete to start the calculations, - Use `maybe_open_oi_feed` for open a oi_feed. - Add `max_pain_readme.rst` |
||
|---|---|---|
| .github/workflows | ||
| config | ||
| dockering | ||
| docs | ||
| examples | ||
| piker | ||
| scripts | ||
| snippets | ||
| tests | ||
| .gitignore | ||
| LICENSE | ||
| MANIFEST.in | ||
| README.rst | ||
| default.nix | ||
| develop.nix | ||
| flake.lock | ||
| flake.nix | ||
| notes_to_self.rst | ||
| poetry.lock | ||
| pyproject.toml | ||
| pytest.ini | ||
| ruff.toml | ||
| uv.lock | ||
README.rst
piker
trading gear for hackers
piker is a broker agnostic, next-gen FOSS toolset and runtime for real-time computational trading targeted at hardcore Linux users .
we use much bleeding edge tech including (but not limited to):
- latest python for glue
- uv for packaging and distribution
- trio & tractor for our distributed structured concurrency runtime
- Qt for pristine low latency UIs
- pyqtgraph (which we've extended) for real-time charting and graphics
polarsnumpyandnumbafor redic fast numerics- apache arrow and parquet for time-series storage
potential projects we might integrate with soon,
- (already prototyped in ) techtonicdb for L2 book storage
focus and feats:
fitting with these tenets, we're always open to new framework/lib/service interop suggestions and ideas!
- 100% federated: your code, your hardware, your data feeds, your broker fills.
- zero web: low latency as a prime objective, native UIs and modern IPC protocols without trying to re-invent the "OS-as-an-app"..
- maximal privacy: prevent brokers and mms from knowing your planz; smack their spreads with dark volume from a VPN tunnel.
- 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 a next-gen structured concurrency supervision sys.
- traders first: broker/exchange/venue/asset-class/money-sys agnostic
- systems grounded: real-time financial signal processing (fsp) 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 (or maybe even a DDE).
- data collab at scale: every actor-process and protocol is multi-host aware.
- fight club ready: zero interest in adoption by suits; no corporate friendly license, ever.
building the hottest looking, fastest, most reliable, keyboard friendly FOSS trading platform is the dream; join the cause.
a sane install with uv
bc why install with python when you can faster with rust :
uv lockhacky install on nixos
NixOS is our core devs' distro of choice for which we offer a stringently defined development shell envoirment that can be loaded with:
nix-shell default.nixstart a chart
run a realtime OHLCV chart stand-alone:
piker -l info chart btcusdt.spot.binance xmrusdt.spot.krakenthis runs a chart UI (with 1m sampled OHLCV) and shows 2 spot markets from 2 diff cexes overlayed on the same graph. Use of piker without first starting a daemon (pikerd - see below) means there is an implicit spawning of the multi-actor-runtime (implemented as a tractor app).
For additional subsystem feats available through our chart UI see the various sub-readmes:
- order control using a mouse-n-keyboard UX B)
- cross venue market-pair (what most call "symbol") search, select, overlay Bo
- financial-signal-processing (piker.fsp) write-n-reload to sub-chart BO
- src-asset derivatives scan for anal, like the infamous "max pain" XO
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:
pikerd -l info --pdbthe daemon does nothing until a piker-client (like piker chart) connects and requests some particular sub-system. for a connecting chart pikerd will spawn and manage at least,
- a data-feed daemon:
datadwhich does all the work of comms with the backend provider (in this case thebinancecex). - 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 runtime-stack.
now you can (implicitly) connect your chart:
piker chart btcusdt.spot.binancesince 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 in-memory IPC data structures) but also the data-feed and any order mgmt states should be persistent until you finally cancel pikerd.
if anyone asks you what this project is about
you don't talk about it; just use it.
how do i get involved?
enter the matrix.
how come there ain't that many docs
i mean we want/need them but building the core right has been higher prio then marketting (and likely will stay that way Bp).
soo, suck it up bc,
- no one is trying to sell you on anything
- learning the code base is prolly way more valuable
- the UI/UXs are intended to be "intuitive" for any hacker..
we obviously need tonz help so if you want to start somewhere and can't necessarily write "advanced" concurrent python/rust code, this helping document literally anything might be the place for you!