
プログラムを開発するとき(たとえば、CやPythonを使用して)、プログラムが期待どおりに実行されていることを確認するためにデバッグメッセージを書くことがよくあります。 Linuxでは、、、grep
などsed
のツールを使用して、さまざまなwc
柔軟な方法でこれらのテキストメッセージを処理できます。
ただし、テキストメッセージの代わりにグラフィックを表示しようとすると、通常はいくつかの問題が解決されます。一部のグラフィックライブラリを自分のプログラムにリンクする必要があります(この作業自体はインストール後にしばしば困難になります)、特定のライブラリに必要な定型句の初期化が何であるかを調べる必要があります。
次のようなものがあるかどうか疑問に思います。グラフィックライブラリをプログラムに接続する代わりに、「テキストデバッグメッセージ」を標準出力に出力するのと同様に、「グラフィックデバッグメッセージ」をパイプに出力します。次に、このパイプ(stdout-graphics?)をスタンドアロンプログラムとして実行されているいくつかのグラフィックビューアにリダイレクトします(たとえば、sedをスタンドアロンプログラムとして実行するのと似ています)。
私の理想的な世界ではこのようなことができます
gcc foo.c
./a.out 5>graphics_viewer
そして、プログラムで生成された「デバッグメッセージ」を見てください(おそらく2Dで動くいくつかの円と点)。
いくつかの注意:
- グラフィックライブラリを直接呼び出す代わりにパイプを使用すると、どのくらいのオーバーヘッドが発生するかわかりません。また、stdoutgraphicsエンコーディングによってオーバーヘッドがどれだけ発生するかわかりません(例: "draw_ectangle(30,20,100,100); putpixel(3,7); Flip();"などのテキストストリームを使用できますか?それとも使用する必要がありますか?)圧縮形式を使用してください。)理想的には、できるだけ一般的でなければなりません。パイプの使用がデフォルトのライブラリを使用するよりも最大で10%遅い場合はお勧めします。
- この文脈では、「グラフィックガイドライン」の標準形式(SDLライブラリのすべての機能を含む)が既に存在するかどうかはわかりません。もちろん、PostScript、TikZなどの小規模な分野に特化した言語もたくさんあります。
- stdoutgraphicsがあればstdingraphicsも役に立ちます。
答え1
私は終わった。生のグラフィックコマンドを出力するのではなく、ステータスメッセージを出力します。次に、これらのメッセージを理解し、正しいコンテンツを表示するディスプレイを作成します。
完全にカスタマイズされたディスプレイを選択したり、再利用可能なより一般的な言語を作成したりできます。
また考慮
また、使用を検討することができますユニットテストフレームワーク。単体テストは、特にコードをテストする最良の方法です。テスト中心設計。 (私が書いた標準出力プログラムの最初のグラフィック出力は、テストハーネスとテスト結果の可視化ツールでした。
また、見ることができます
dockviz
dot
形式(有向グラフ、無方向グラフ(グラフはチャートではない))で出力可能(参照)https://graphviz.org/doc/info/command.html)