Pre-Issue: 不具合/要望未満のメモ書き

[vain0x]

不具合/要望 (Issue) にまとまったかたちで記述できていないこと

注意: 内容は不確かです。調査や検討をしていないことが書かれています

[vain0x]

• 古いパスが使用されるケースがある?
  • (WrapCall 有効状態で) 呼び出しフレーム数がゼロなのに /CallStack/CallFrame/Param/Int を文字列化しようとするケースがあった
  • ./dev (default.hsp) で set_stat からreturnした直後に発生。再現するかどうかはランダムかもしれない
  • (要調査。パスやスタックフレームに世代番号をつけてチェックしたほうがいいかもしれない。古いパスを使用してもなるべくアクセス違反などのエラーは発生しない設計だけど、WrapCall まわりはそのあたりの信頼性が低い)

[vain0x]

• 開発者向けのドキュメントの分かりにくさ
  • README から ARCHITECTURE と docs/dev にリンクがあるけど環境構築手順が後者であることが分かりづらい
    • (README は主に利用者向けだから、ごちゃごちゃさせたくない)
  • ソリューションを開いてビルドと書かれてるが、ソリューションやビルドなどの用語説明がひとことあってもいい
    • (想定読者の不明確さ。hsp は知ってるが C++ はやったことない人を想定したほうがいい)
  • ビルドの結果として何が起きるか、それをどう使うか書かれてない
    • (src/knowbug_dll/bin/{config}/{arch} ディレクトリにdllが出力されるのでそれを knowbug_install と同様の手順でhspのインストールディレクトリ内に配置すれば動く)
  • クライアント側 (knowbug_client) のビルド手順がビルドスクリプトしかない
    • ビルドスクリプトが通らないとかなり困りそう (実際hsp37だと通らない)
    • スクリプトが utf-8 だから非標準のビルド手順を踏む必要がある
      • サクラエディタ を使うとビルドできるらしい (試してない)
      • sample/misc/mkexe でもいけるはず

[vain0x]

• knowbugのウィンドウをHSPのウィンドウより背面に表示する #32
  • 起動時にメインウィンドウを gsel ,1 (show) しない案 (別のAPIとかで表示状態にすればフォーカスを奪わない?)
  • 起動後にスクリプト側のメインウィンドウ (あれば) にフォーカスを与える案
  • knowbug_client の初期化が完了するまでスクリプト側の実行をブロックする案

[vain0x]

• 次飛/脱出がうまく進行しないことがある (デバッギのウィンドウ上にマウスを動かすと動くのでメッセージ待ちになっているかも)
  • knowbug側の「更新」ボタンを連打すると進行することがある
  • デバッギのボタンを連打すると進行することがある
  • (hsp36/sample/game/battle.hsp で試した)
  • v1時代のイシュー: 条件つきステップ実行の挙動がおかしい #7
  • HSPの動作と協調したほうがいいかも (HSPから debug_notice が来ているタイミングのみ処理)

[vain0x]

• v2.2.2 リリース
  • HSP3.6 を使っているユーザーのために不具合修正だけいれておく (HSP3.7 への移行は除いた)
  • リスクを減らすため logmes の文字数制限をなくす #124 も含めなかった
  • knowbugのウィンドウをHSPのウィンドウより背面に表示する #32 や「次飛」が不安定な問題は直したかったけどまだよく分からない
• HSP3.7 対応の予定 (仮)
  • ginger 側と同様にビルドスクリプトを直す

[vain0x]

• 次飛(STEPOVER)
  • debug_notice ではなく msgfunc を差し替えてそこで再 step-in するほうが安定するかも (code_dbgtrace)

[vain0x]

• sample/misc/mkexe で knowbug_client と proxy 両方作れた、いちおう動いてそうだ
  • ビルドスクリプトもhspで書いたほうがいい説
    • hsp-er がどのくらいシェルに慣れてるのかによる

[vain0x]

• HSP3.7対応 #125
  • ビルド手順の説明を更新することになったが、依然として分かりづらい
  • knowbug_client_proxy の説明をIDE側のビルド手順に入れられなかった
  • Visual Studio のチートシートみたいなのがあってもいいかも (C++ガイドラインと似たような感じで、全体の機能数が多いので、knowbug開発に必要な部分に絞った説明を書く)
  • 図がほしい

[vain0x]

• ステップオーバー(次飛)・ステップアウト(脱出)ボタンのラベルをなんとかしたい
  • すっかり慣れてしまったけど、次飛・脱出表記はよく分からない。アイコン＋ツールチップにするとか

[vain0x]

• コーディングガイドラインも変えたくなってきた
  • キリがないので局所的にだけ直す (HspObjectList が knowbug_server ファイルに埋まってるのがよくないとか)
• パフォーマンス
  • リスト更新の際に時間がかかってる気がする
  • 簡単に測ったかぎりでは、複数件のウィンドウメッセージを送る部分で時間を消費してる

[vain0x]

• knowbug_app/knowbug_server に分かれていて、その分けかたが適切にみえないのがどうしても気になる
  • ファイルが2つある理由は、エントリーポイントと実装詳細を分けて、エントリーポイントを明確にするため
    • DllMain や debugini などのエントリーポイントである関数 (DLL 外部から直接呼び出される関数) と、それ以外を分けたい
    • その場合、クライアントからのメッセージ受け取りや WrapCall もエントリーポイントだから、そっち側にあったほうがよかった
    • (MVCアーキテクチャにおける C=controller のイメージ。これにMVCを適用にすべきかは不明)
  • knowbug_app の名前は、knowbug_dll や dllmain といった名前のほうがよかった
    • 逆にクライアントアプリは "main" がエントリーポイントで "app" はそうでない (一貫性がない)
  • DLL 内の状態 (変数) をまとめた1個のクラスは用意したい
    • static 変数を複数持つ方式は初期化や破棄がややこしいのでなるべく避けたい (ダメではないはず)
      • OOPらしくないという気持ちの問題もあるかもしれない
      • hInstance は問題ないから static に置けばいい
      • HSP3DEBUG *debug も static に置いてよかったかも
    • 現状は KnowbugApp/KnowbugServer の2つあるが、1つでいい気がする
      • もしかしたらDAP版を作る場合に KnowbugServer の部分を使用しないから分けたのかも
      • もしかしたら KnowbugServer はクライアントに対するコネクションの意味合いだったのかも (クライアントの起動と通信が責務)
        • (その場合、object_list_entity_ が含まれているのはおかしい)
        • (その場合、メッセージに対する処理が server 側に実装されているのもよくない。とはいえ client_did_* をすべて仮想メソッドやイベントにするのは実装上冗長だと思ったのかもしれない)
  • (もしかしたらDAP版を想定してこういう状況にしたのかも。通常版とDAP版という2つのユースケースがそれぞれ KnowbugApp クラスを使うという構図。そのうえで、エントリーポイント (DllMain) を KnowbugApp と同じファイルに書くことにしている)
    • dll → app → server(connection) という3段構造
    • DAP版だとクライアントアプリを起動しないから dap → app → server(connection) だとまずい、違いそう
    • いずれにせよDAP版を作るときにまた考えればいい (たぶん HspObjects と HspObjectWriter/HspObjectListEntity 以外はほとんど使わない、DAP版を作る予定はいまのところない)