Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor simc engine to make it useable as a library #4383

Open
athei opened this issue Jul 24, 2018 · 0 comments
Open

Refactor simc engine to make it useable as a library #4383

athei opened this issue Jul 24, 2018 · 0 comments

Comments

@athei
Copy link
Contributor

athei commented Jul 24, 2018

Because of my effort to create a web assembly version of simc in #4341 I identified the following issues that need some work to make it useable as a library. The goal is to have a discussion about them and do the refactoring.

Progress reporting
The progress bar is outputted as formatted text to stdout. What an embedded application (like the browser) needs is a way to get notified about progress update with structured data. My proposal is to have a mode where I supply a functor (callback) that gets called after each iteration. When specifying the callback an update interval can be specified too.

I currently have the following workaround in progress_bar_t::update to get progress updates:

#ifdef SC_WASM
  {
    wasm_hooks::update_progress( progress, current_progress(),
                                 compute_total_phases(),
                                 base_str, phase_str );
    return false;
  }
#endif

This suppresses progress bar output and supplies my application with the information I need.

Result output
Currently the different report classes either output to a file or to stdout. What I need is a mode where I can just write the reports to a buffer. For example an overload of
report::print_json(simc, std::stringstream &out). I need this for the json case because that format is used to pass the information to javascript in the WebAssembly case. Text could be helpful, too. Currently I just write out the json file by setting json_file_str and read it back in after the sim as a workaround.

Setup Boilerplate
I found it difficult to find all the calls that I need to make before I can sim. After reading the qt gui and cli code I came up with that:

dbc::init();
module_t::init();
unique_gear::register_hotfixes();
unique_gear::register_special_effects();
unique_gear::sort_special_effects();
hotfix::apply();

I do not even know if that is all or how to track new things that need to be added. Maybe it can be integrated into the sim_t constructor which initializes this with something like std::call_once to not redo it again for each instance. And also make it callable ahead of time, optionally. For example a static sim_t::initialize() which can be called manually or is called by the first constructor call if not.

Also it is not obvious to me which functions I need to call after the sim. For example all the analyze() functions. Can that be integrated at the end of execute() ?

And maybe sim_t::setup() can be moved to the constructor so it is obvious that I need a control object. So we do don't have a standard constructor but one that takes the options.

All in all I think the goal should be that by constructing a sim_t we should have an instance that is ready to roll without having to call further init or setup functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant