scawful / premia

Risk Premia Trading Client

Major Projects

• Oracle of Secrets - Complete overhaul of The Legend of Zelda: A Link to the Past
• Yet Another Zelda3 Editor - The Legend of Zelda: A Link to the Past Editor, Emulator, Debugger
• Premia - Quantitative market analysis program and trading client.

Websites

• https://zeniea.com/ - message board based on ZEN3MP repo
• https://halext.org/ - personal blog and smaller projects

premia's Issues

Custom Watchlist for Guests

Currently, the WatchlistView is bound to the data provided by the WatchlistModel which only gets data from TDAmeritrade currently.

For guests, I'd like to create an alternative watchlist table that provides some GUI elements for adding multiple lists, adding new symbols, deleting symbols, and storing that data in a file to be used in the future by the application. Then in the future when my server endpoint with data is set up, users without an API linked will still be able to get price quotes from their own custom watchlist.

This can be implemented completely in the WatchlistView class and seamlessly added into the current implementation as it already handles when a user is not logged in and displays some placeholder text, so a function to display the custom watchlist pane would go there.

WebSocket streaming with thread pool/executor

This is an advanced task, so be prepared to do a lot of threading, networking, and reading Boost documentation.

To help with this feature you should be knowledgeable with Boost.Asio https://www.boost.org/doc/libs/1_77_0/doc/html/boost_asio.html and Boost.Beast https://www.boost.org/doc/libs/1_79_0/libs/beast/doc/html/index.html

Currently the WebSocket features of Premia are limited to the Socket class in the TDAmeritrade service, which simply polls the API and then prints the responses to the console. However, a single instance of the stream isn't very useful when you have a watchlist full of symbols and multiple charts to update, so I want to convert the WebSocket thread as its implemented into a thread pool with an active listener/callback for all the data updates so it can be efficiently used for the type of tasks I detailed above.

Once the streams have been organized into a thread pool, some way of communicating with them in a thread safe manner needs to be devised for updating the GUI as requests come in. We should also take extra care not to clog up the buffer with requests, which means having an intimate understanding of the exchange of data going on. Taking the time to read the TDA Streaming Guide https://developer.tdameritrade.com/content/streaming-data will be helpful in testing. This can also play into the design of the callbacks/event handlers for #3

Here's a stack overflow article https://stackoverflow.com/questions/69601043/boost-beast-websocket-how-to-make-a-pending-async-read-queue-work-for-io-con I found that may help in converting the current implementation to using a thread pool, but the design for the callbacks/events still needs to be formulated.

Handle GUI thread blocking during curl requests

To make requests from the various APIs, Premia uses curl and a callback function to store the json response as a string and pass it off to a parser class that interprets that data as an object. During the time the program is making those requests it naturally blocks the GUI thread and prevents it from updating or being interacted with. I know this needed to be addressed with threading, but I'm not sure how to go about displaying the GUI while that data is still loading. Here's some issues I've encountered when trying to do naive fixes for this.

If I just thread the Model class request that ends up calling the API interface, then there can be synchronization issues with the View requesting data from the Model that is stored inside of STL containers which are not thread safe. Many API objects have underlying hash maps and vectors that are very picky about the threads that touch them, so this issue needs to be addressed. This may require fundamentally rethinking how GUI data is handled via callbacks and templates. I'm just not sure exactly what the best way to go about it is.

The best example of this is in WatchlistView and WatchlistModel, if you want to look at some code that does in fact block the GUI during the requests made.

TDAmeritrade Order Protobuf Service/Handler

TDAmeritrade Watchlists Protobuf Service/Handler

TDAmeritrade OptionChain Protobuf Service/Handler

API Management/Authentication View

Design a View that shows the various APIs supported by the program and their necessary inputs (key, passphrase, etc) as well as logging the status of their authentication with the API (whether they have a special token). Include this View to be used in the ViewManager as an option for the primary column.

Add PriceHistory support to the LinePlotChart

Implement the ability to load a PriceHistory's candle object into a LinePlotChart and provide options for controlling that chart akin to the CandleChart. This is a fairly straightforward task and has a good example (CandleChart and LinePlotChart) and a decent amount of wiggle room in terms of implementation. Currently the line plot chart just attempts to load and plot a csv file from the assets folder that represents some asset over time (I've been using it with my TDA daily portfolio balance csv file) but it would be better suited as a price chart, and maybe repurposed as a balance/performance chart elsewhere.

TDAmeritrade PriceHistory Protobuf Service/Handler

Implement Coinbase API features

Currently, the CBP.hpp inside of include/Interface is blank after copying methods from the old implementation. The goal is for it to be more akin to the TDA.hpp in the same folder.

This means using a Client class that handles the API requests using curl and Boost.Beast for HTTP/TLS and WebSocket connections respectively, as well as using a Parser class that sorts the json data into an object the program can later use. This is a very general feature/issue so it can be expanded on based on the demands of the Coinbase API.

This feature would require editing the following files

• include/Interface/CBP.hpp
• src/Services/CoinbasePro/Client.cpp
• src/Services/CoinbasePro/Parser.cpp

Since I started this project, Coinbase actually merged their API into one for Exchange/Cloud so the specification of "Pro" isn't super necessary but I believe there's still a distinction in which account you access based on the endpoint URL (though I could be wrong as this code hasn't been ran/tested in months)

To test your code you can go to tests/ServiceTestSuite/CBP.cpp and invoke any of the objects besides the actual static interface header. That should be used merely as a means of calling client/parser/socket code.

You can find information about the https://docs.cloud.coinbase.com/exchange/docs

TDAmeritrade Quote Protobuf Service/Handler

Cleanup leftover demo code in View components

This is good if you're just trying to familiarize yourself with the code, but throughout the View components I'm sporadically experimenting with the ImGui library using the demo window and source as a reference, so often times I will directly copy code from the demo and retool it to my needs based on the feature I'm trying to lay out. As you can imagine, this leaves behind a lot of unsavory code and copy pastes. So I figured I'd make it a task to go through any View layouts and make sure of the following.

• Variables that can be declared in the View class header should (e.g. static flags for a table,child,etc)
• Variables that cannot be declared in the header (e.g. arrays being passed to a gui element that takes as argument) should be overloaded to support an STL structure that will make it possible to declare the element as a class variable. Only use static scoped variables in extreme circumstances.
• Elements without unique identifiers/labels should be given a unique name (use ## before the name to negate a text display of the string)
• Reproducible code should be moved into a simple void function to leave the update function clean and straightforward

You can look at the imgui_demo.cpp for examples of what I mean and then compare against the View components themselves. Also, it's good to have that demo source file handy when you're learning ImGui anyway.

TDAmeritrade Account Protobuf Service/Handler

The Workspaces Feature

Workspaces is the true wild west of Premia. The final frontier. The open road.

Completely customizable open window space where a user can place as many "Views" as they want and arrange them in any order they want. ImGui provides a very easy method of adding "child windows" that float inside the main program window and I've designed each View class in such a way that they can easy be fit inside one of those floating child windows. So the task is to design the Workspace manager to the do the following:

• Support for adding floating Views such as charts, graphs, orders, portfolios, console, etc
• Additional menus enabled for views exclusively in workspace mode (for customization)
• Grid based layout that user can enable to snap, sort, and resize views
• Save and load workspace configurations and layouts

This will probably require some real though and maybe even some design patterns to really get right and do properly (this is C++) so I made it its own separate branch at features/workspaces and I wrote the basics of a header file for it. You can look at ViewManager for reference of how Views are handled if you want to experiment with the workspaces feature.

Some other details: the current ViewManager design sets the size of the (ImGui) viewport to the full size of the (SDL) window, but if you don't set that ImGui size, then you can have any number of ImGui windows floating around inside the SDL viewport.
So, it's fairly simple to get the idea of a workspace up, but adding all these features that make it feel like an "editor" are going to be the real challenge.

TDAmeritrade WebSocket Streamer Callback Implementation

The current WebSocket streamer implementation has a callback for the buffer that feeds into the console widget within the main program view manager, but it should be fitted with a more detailed callback or logging method that'll allow for live streaming to a chart or watchlist view. This may have some intersection with the protobuf upgrades proposed in other issues.

OAuth refresh token generation for TDAmeritrade users

TDAmeritrade users may find it difficult to get started with Premia given that it required following a very complicated and outdated setup procedure to receive the refresh token for the service. To make up for this, I'd like to add a native means of authenticating ones account with the application into the account. I've included some resources about how this process works and a short chat log where I discussed my general vision for the feature. Will need to explore how to open a browser instance with the correct parameters as detailed in the guides as well as setting up a server in Premia that acts as a callback from the webpage once the user has logged into TDAmeritrade successfully.

https://developer.tdameritrade.com/content/simple-auth-local-apps
https://www.reddit.com/r/algotrading/comments/c81vzq/td_ameritrade_api_access_2019_guide/

cmake conflict

Ubuntu 22.04

CMake Error at build/_deps/googletest-src/googlemock/CMakeLists.txt:98 (target_link_libraries):
  Attempt to add link library "gtest" to target "gmock" which is not built in
  this directory.

  This is allowed only when policy CMP0079 is set to NEW.


CMake Error at build/_deps/googletest-src/googletest/cmake/internal_utils.cmake:152 (add_library):
  add_library cannot create target "gmock_main" because another target with
  the same name already exists.  The existing target is a static library
  created in source directory "/home/dev/code/premia/src/lib/protobuf".  See
  documentation for policy CMP0002 for more details.
Call Stack (most recent call first):
  build/_deps/googletest-src/googletest/cmake/internal_utils.cmake:205 (cxx_library_with_type)
  build/_deps/googletest-src/googlemock/CMakeLists.txt:100 (cxx_library)


CMake Error at build/_deps/googletest-src/googlemock/CMakeLists.txt:101 (target_link_libraries):
  The plain signature for target_link_libraries has already been used with
  the target "gmock_main".  All uses of target_link_libraries with a target
  must be either all-keyword or all-plain.

I think the submodules grpc's own cmake files is fighting with the project's own cmake files.

TDAmeritrade UserPrincipals Protobuf Service/Handler