Conversation
goodboy
added
clearing
Contributor
Author
|
Marking this ready to get some eyes, but it's still super ib-specific and I want to still finesse a buncha stuff and make follow up issues for a more general solution / API for ledgers. |
Contributor
Author
|
Aight, as of right now [ib.algopaper."mnq.globex.20220916"]
size = 58.0
be_price = 11703.458965517251
bsuid = 497954580
expiry = "2022-09-16T00:00:00+00:00"
clears = [
{ tid = "0000e1a7.629f3c2d.01.01", cost = 0.57 },
{ tid = "0000e1a7.629fa5c0.01.01", cost = 0.57 },
{ tid = "0000e1a7.62a0a898.01.01", cost = 0.57 },
{ tid = "0000e1a7.62a0fb24.01.01", cost = 0.57 },
]includes a table of As further refinemen we could probably,
|
goodboy
force-pushed
the
lifo_pps_ib
branch
3 times, most recently
from
0311e24 to
800715e
Compare
…er>_<acct>.toml` files
Start a generic "position related" util mod and bring in the `Position` type from the allocator , convert it to a `msgspec.Struct` and add a `.lifo_update()` method. Implement a WIP pp parser from a trades ledger and use the new lifo method to gather position entries.
Since "flex reports" are only available for the current session's trades the day after, this adds support for also collecting trade execution records for the current session and writing them to the equivalent ledger file. Summary: - add `trades_to_records()` to handle parsing both flex and API event objects into a common record form. - add `norm_trade_records()` to handle converting ledger entries into `TradeRecord` types from the new `piker.pps` mod (coming in next commit).
Add a `TradeRecord` struct which holds the minimal field set to build out position entries. Add `.update_pps()` to convert a set of records into LIFO position entries, optionally allowing for an update to some existing pp input set. Add `load_pps_from_ledger()` which does a full ledger extraction to pp objects, ready for writing a `pps.toml`.
This makes it possible to refresh a single fqsn-position in one's `pps.toml` by simply deleting the file entry, in which case, if there is new trade records passed to `load_pps_from_toml()` via the new `reload_records` kwarg, then the backend ledger entries matching that symbol will be filtered and used to recompute a fresh position. This turns out to be super handy when you have crashes that prevent a `pps.toml` entry from being updated correctly but where the ledger does have all the data necessary to calculate a fresh correct entry.
- use `tomli` package for reading since it's the fastest pure python reader available apparently. - add new fields to each pp's clears table: price, size, dt - make `load_pps_from_toml()`'s `reload_records` a dict that can be passed in by the caller and is verbatim used to re-read a ledger and filter to the specified symbol set to build out fresh pp objects. - add a `update_from_ledger: bool` flag to `load_pps_from_toml()` to allow forcing a full backend ledger read. - if a set of trades records is passed into `update_pps_conf()` parse out the meta data required to cause a ledger reload as per 2 bullets above. - return active and closed pps in separate by-account maps from `update_pps_conf()`. - drop the `key_by` kwarg.
Before we weren't emitting pp msgs when a position went back to "net zero" (aka the size is zero) nor when a new one was opened (wasn't previously loaded from the `pps.toml`). This reworks a bunch of the incremental update logic as well as ports to the changes in the `piker.pp` module: - rename a few of the normalizing helpers to be more explicit. - drop calling `pp.get_pps()` in the trades dialog task and instead create msgs iteratively, per account, by iterating through collected position and API trade records and calling instead `pp.update_pps_conf()`. - always from-ledger-update both positions reported from ib's pp sys and session api trades detected on ems-trade-dialog startup. - `update_ledger_from_api_trades()` now does **just** that: only updates the trades ledger and returns the transaction set. - `update_and_audit_msgs()` now only the input list of msgs and properly generates new msgs for newly created positions that weren't previously loaded from the `pps.toml`.
Gah, was a remaining bug where if you tried to update the pps state with both new trades and from the ledger you'd do a double add of transactions that were cleared during a `update_pps()` loop. Instead now keep all clears in tact until ready to serialize to the `pps.toml` file in which cases we call a new method `Position.minimize_clears()` which does the work of only keep clears since the last net-zero size. Re-implement `update_pps_conf()` update logic as a single pass loop which does expiry and size checking for closed pps all in one pass thus allowing us to drop `dump_active()` which was kinda redundant anyway..
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proper attempt at #307 and a local "trades" ledger system using
.tomlfiles under<confdir>/ledgers/where files will be named something like:trades_<brokername>_<accountname>.tomlSo far ledger contents looking something like this:
Click to expand!
And, as of right now
pps.tomlentries lookin more or less like this (example only):REQUIREMENT:
TODO: (oustandings moved to #345)
pps.tomllocal position tracking/summary fileid,cost,(date-)timestamp, maybe something else?breakeven_pricelifo_price?Client.trades()methodPostionTrackerUX on chartsProbably as follow up PR(s): -> See #345 for all deferrals and detailed write up of all these
krakenledger parsing and generalize into a top level module?piker ledgersubcommand?piker ppssubcommand with openspps.tomlin editor/pager?tomlencoder?tomlencoder to output things sanely, i think it's just worth writing a super fast custom encoder that writes adhoc-ly in the format we want forpps.toml, the reader-writer separation is already whattomlidoes (the fastest pure py reader soon to land in the stdlib) and and then we can just droptomloutright and worry about getting a general encoder later.pps.tomlupdates ingit