Processing.js で 外部 pde コードにブレイクポイントをはる
今回も単発ネタで恐縮です
環境
- Processing.js (1.4.8)
- Google Chrome Developer Tools
やりたいこと
Processing.js では、processing 形式で書いているコードが、 Processing.js によって JavaScript に変換されたのち、ブラウザのJavaScript実行エンジンで処理されます。
メイン html に直接 Processingのコードを書いたり、js 形式で Processing.js コードを書いて読み込む場合は、それらのコードを Chrome の Developer Tools で補足できますが、
<canvas data-processing-sources="pcode.pde" id="processing_sketch"></canvas>
の形式で純粋な processing コードをキャンバスに読み込ませる作法の場合、pde ファイルはDeveloper Toolsに補足されません。
この図の左の "Sources" タブには、<canvas>
タグ中で参照している pde ファイルが表示されていません。これではブレイクポイントがはれません。
実際には、実行中は既にpdeからjavascriptに変換されているので、ブレイクポイントで止まるのは、変換後のjavascript中になります。とにかく、ブレイクポイントをはりたいです。
Chromeで debugger;
キーワードを使う
ecma-262 (HTML5のJavaScript) にはコードから能動的にブレイクさせるキーワード debugger
があります。これ自体はjavascriptの標準なので主要なブラウザで使えますが、基本的には「一般的なjavascript」に対して適用する物です
Chromeではこれを使うことで、「Processing.jsのコードをjsに変換した後のコード内で」能動的にブレイクさせ、コードを見ることが出来ます。
Breakpointについて一般的な説明
https://developer.chrome.com/devtools/docs/javascript-debugging#breakpointsdebugger; ステートメントの使い方
https://developer.chrome.com/devtools/docs/console#setting-breakpoints-in-javascript
Processing.js では、 pdeファイル内に Processing の記述と js の記述を混在させることが出来ます。 (jsの記述は、変換時にそのまま素通しになります) これを利用しmasu.
debugger;
を pdeファイルの setup()
関数なんかの冒頭に書いておくと、実行前にいったんブレイクされ、Developer Tools の Sources に VM*** というタブが開かれます。そこで下図のように、processing.js によって javascript に変換された後のコードを読むことが出来ます。そして、この状態からなら、任意の箇所にブレイクポイントをはったり外したり出来ます。
ちなみにこの手法、 Paper.js でも使えます。
Firefox だと
Firefox でも同様に debugger;
キーワードを利用できますが、ブレイクした際に変換後のjavascriptを良い感じに表示してくれません。これについてはあまり深く調べていないので、もしやり方ご存じの方がいらっしゃいましたら、教えていただきたいです。
(蛇足)コンパイル(コンバート時)にエラーがあった場合
pde ファイルにエラーがあった場合、Processing (not .js)の場合はコンパイルエラーになりますが、Chrome等ブラウザで実行した場合は、実行時(Processing.jsによるコンバート時)エラーとなります。
ここでは、存在しない hoge
という変数を println(hoge)
しようとしてエラーを起こさせています。
このときのChrome Developer Tools の様子はこんな感じ。
Processing.js によってコンバートされた結果の js コードが(ここでは) VM138 というタブとして表示され、その中の 132 行目でエラーが起きたことを示しています。
これでもデバッグは可能ですが、毎回「わざと」エラーを起こすのはイケてないですよね。
で、どうするか
Chromeを使えばdebugger; キーワードでブレイクポイントをはってデバッグが出来ることが分かりましたが、これも javascript 変換後のコードを見ることになるので、どうもサクサクとはデバッグ出来なそうです。どう言った「流れ」でコードを書いているかによって、デバッグの仕方は変わりそうです。
processing でスケッチを作り込んで、ウェブで表示する場合
この場合は、 processing のエディタでスケッチを作り込んでしまうのが良いかと思います。Java -> javascript 変換時のエラーについては、ある程度パタンがある気がするので、そういった物に対して頑張って対処します。
HTMLとの連携などをする場合
この場合は少し大変ですが、本記事で紹介したような手法でデバッグをすると良いかと思います。