scawful / premia Goto Github PK
View Code? Open in Web Editor NEWRisk Premia Trading Client
License: GNU General Public License v3.0
Risk Premia Trading Client
License: GNU General Public License v3.0
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.
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.
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.
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:
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.
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.
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/
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.
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
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
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.
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.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.