Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Refactor simc engine to make it useable as a library

オープン
  • 何か問題がありますか？
#4,383 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
cpp, wasm
領域
backend

調査の方向性

Start by reading the listed progress_bar_t::update workaround in engine/sim/sc_progress_bar.cpp, then compare the Qt GUI and CLI setup and report paths mentioned in the issue. The work spans progress callbacks, writing reports to buffers, and sim_t initialization and execution, so first clarify the desired API and scope with maintainers. Done means the agreed library use cases no longer require the workarounds described here.

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
C++
スター
1.6k
フォーク
789
平均マージ
9時間 44分
マージ済み PR（30日）
56

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

simulationcraft/simc のほかの issue

simulationcraft/simc の issue をすべて見る

似ている issue

C++ の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。