03:46:51 [r_takaishi_'out] ; Ping timeout: 252 seconds
04:01:20 [r_takaishi_'in]
04:47:27 [r_takaishi_'out] ; Ping timeout: 276 seconds
05:01:27 [r_takaishi_'in]
17:52:25 [g000002'in]
17:55:04 [g000002'out] ; Remote host closed the connection
18:03:51 [g000031'in]
18:06:23 <g000031> 今日も
18:06:37 <g000031> successful lispぼっち読書会やります
18:07:03 <g000031> 今日は意味なくCL製のクライアントであるbeircを使ってみます
18:08:07 <g000031> コピペできないw
18:09:25 <g000031> コピペできないと辛いのでクライアント変えますw
18:09:38 [g000031'out] ; Quit: Client Quit
18:10:11 [g000031'in]
18:11:37 <g000031> http://common-lisp.net/project/beirc/
18:11:53 <g000031> mcclimの上にできてるのでコピペはできる筈ですが…
18:13:24 <g000031> (((Chapter 30 - Helpful Hints for Debugging and Bug-Proofing)))
18:13:39 <g000031> ということで今回はデバッグの話のようです
18:14:49 <g000031> ((((Finding the cause of an error))))
18:17:39 <g000031> 間違いには、大別すると二種類あって一つは、デバッガに落ちるようなエラー、こちらは型の違いだったりしてlispレベルでの間違い、
18:20:57 <g000031> もう一つは、lisp的にはおかしくないけれど、予想した結果にならないというもの、これは手続の順番が違っていたり、はたまた終了しなかったりというもの
18:21:51 <g000031> これらの問題に対しては、簡潔に短かく関数を書くというのが良いとのこと
18:22:31 <g000031> また、同じファイルに#| |#で囲んだテストを書いて置くのも有用だ、とのことです
18:22:56 <g000031> テストケースが付いてるとデバッグは非常に楽ですね
18:23:01 <g000031> ((((Reading backtraces, compiler settings for debugging))))
18:27:33 <g000031> エラーに遭遇した時に有用な情報に、エラーメッセージと、バックトレースという2つの情報があるとのこと
18:27:52 <g000031> エラーは何が起ったかの説明
18:28:25 <g000031> バックトレースは、どこでエラーが起きているかの情報
18:29:44 <g000031> バックトレースはスタックで、現在のエラーはトップある
18:29:52 <g000031> ということになります
18:30:59 <g000031> デバッグの情報がどれだけ詳しいかは、処理系によりますが、
18:32:23 <g000031> とりあえずのところ 最適化の設定で、speedは大きくすれば、情報は少なくなるのと、debugは大きくすれば情報は大くなる、というのは共通、とのこと
18:32:38 <g000031> s/大く/多く/
18:33:00 <g000031> デバッグ中にもこの設定は変更できるので、(declaim (optimize (speed 0) (space 0) (debug 3)))のようにするのが吉とのこと
18:33:22 <g000031> 詳しくは、処理系のドキュメントを良く読もうとのことです
18:33:32 <g000031> ((((Simple debugging tools))))
18:34:49 <g000031> プログラムはエラーに遭遇することなく動くけれど、意図した動作でなかったり停止しない場合に有用なツールの解説です
18:34:58 <g000031> (((((BREAK, PRINT)))))
18:44:36 <g000031> まずは、breakの解説で、プログラムの任意の位置に差し込んで実行することにより、breakの位置でデバッガに落ちます
18:45:32 <g000031> デバッガで色々確認することができて、再開もできます。再開の際に変数の値を変更することも可能です
18:46:05 <g000031> レキシカル変数だと処理系とセッティングによっては、捕まえられないことがあるんですよねー
18:46:48 <g000031> なんにしろ、処理系のデバッガの使い方を熟知すれば修正は早くできそうです
18:48:49 <g000031> 次は、printの説明です。所謂printデバッグですね
18:48:59 <g000031> formatも活用できるだろうとのことです
18:49:49 <g000031> 注意点としては、printで多値のフォームを囲むとprintは多値を返さないので二値目以降が捨てられてしまうというのがあります
18:50:21 <g000031> print自体は、フォーム自体の返り値をそのまま返すので、差し込みやすい感じではありますね
18:50:29 <g000031> (((Power tools for tough problems)))
18:50:48 <g000031> さらに強力なツールの解説です
18:50:55 <g000031> (((((TRACE, STEP, ADVISE, WATCH)))))
18:52:24 <g000031> まずは、traceの解説ですが、16章で大体のところは解説されました
18:52:55 <g000031> trace/untraceは一つだけでなく、まとめて指定もできることが解説されています
18:55:29 <g000031> 次にstepです
18:56:34 <g000031> ステップ実行できますが、直線的なプログラムならさておき、フォームがネストしていたり再帰していたりすると追うのがしんどいとのこと
18:59:19 <g000031> 次に標準機能ではないですが、adviceとwatchの説明
19:02:45 <g000031> adviceは、オリジナルの関数を差し替えたりすることが可能ですが、デバッグ時の利用方法としては、
19:05:35 <g000031> 条件によってbreakしたりtraceしたりするような機能を付けたり、デバッグしている部分をデバッグしやすくするため他の部分の動作を一時的に変更したり、につかえるとのこと
19:06:40 <g000031> watchは変数のモニターで大抵ウィンドウのインターフェイスで確認できるようなものが提供されているとのこと
19:07:03 <g000031> 16章で触れられていたので、mclも確認してみましたが、mclにも付いてないっぽいんですよねー
19:07:17 <g000031> サポートしてる処理系が知りたいです
19:07:33 <g000031> ((((Into the belly of the beast))))
19:07:59 <g000031> ((((INSPECT, DESCRIBE))))
19:09:32 <g000031> 更に込み入ったところということで、データそのものを確認するツールの紹介です
19:09:56 <g000031> describeは、データを詳細に表示してくれるもの、inspectは、その対話版というところです
19:10:12 <g000031> なんか16章と大分被ってますねこの章w
19:10:31 <g000031> ((((Continuing from an error))))
19:12:13 <g000031> errorは中断のみですが、cerrorは再開可能になります
19:12:42 <g000031> 再開するにあたって、再開の前にできることが説明されています
19:23:59 <g000031> alter variable values
19:24:09 <g000031> 変数の変更
19:24:11 <g000031> redefine the function that caused the error and run it again
19:24:17 <g000031> 関数定義を変更してリスタート
19:24:42 <g000031> skip the rest of the function that caused the error and specify values to be returned
19:25:51 <g000031> これはどうやるんですかね、いまいち分からないです
19:25:54 <g000031> restart any function further down the call stack
19:25:57 <g000031> これも同様
19:26:09 <g000031> skip the rest of any function further down the call stack and specify values to be returned
19:26:19 <g000031> これも分からない
19:27:12 <g000031> 元の文を解釈できてないってのもありますが、これら機能について調べてみないと分からない感じですね
19:29:53 <g000031> あ、「errorは中断のみですが、cerrorは再開可能になります」って書きましたが、仕様上はerrorのところでも処理系は、内部的にcerrorとして実装してるので、
19:30:11 <g000031> 継続可能→その際にできること、ってことですね
19:31:08 <g000031> それにしても、後三つは分からないですね
19:31:16 <g000031> ちょっと調べてみたいと思います
19:31:26 <g000031> ((((Problems with unwanted definitions))))
19:34:54 <g000031> 不要になった関数を削除する方法についてです
19:35:04 <g000031> fmakunboundと、uninternが紹介されています
19:36:38 <g000031> 総称関数の場合は、ちょっと事情が違って、メソッドが複合して総称関数を構成しているので、特定のメソッドを見付けて削除する必要があります
19:36:53 <g000031> これには、remove-methodを使いますが、これが面倒臭いんですよね
19:37:37 <g000031> 処理系によっては、メソッドブラウザ等によって簡単に任意のメソッドを削除することができるらしいです
19:38:31 <g000031> 自分は面倒なので場合によっては、fmakunboundしてしまって再定義ってのをやりますね。ツールが充実していれば特定のメソッドだけ削除するのは容易そうですが
19:38:39 <g000031> ((((Package problems; method definitions))))
19:40:39 <g000031> シンボルの競合についてです
19:42:54 <g000031> 定義を書き始める前に適切にin-packageしておかないと
19:44:50 <g000031> 意図しないパッケージで定義されてしまったりする
19:45:51 <g000031> ことがありますが、これを直そうとして、あれこれしていると競合したりします
19:46:45 <g000031> 適切な手順としては、まきちらしたシンボルは、uninternで回収することだそうです
19:47:17 <g000031> 確かに一旦競合が始まると面倒なことは多いです。自分の場合は、パッケージを破壊して、読み直しが多いですね
19:48:34 <g000031> あとは、パッケージとメソッドが絡んだ例の説明がありますが、具体的にどういうことなのか、ちょっと分からないですねー
19:49:03 <g000031> You can also get into trouble with packages by having unexported classes defined in two packages and specializing a method based on the wrong class.
19:49:25 <g000031> ですが、同じクラス名で、ってことでしょうか。それなら、厄介な気はします
19:51:28 <g000031> ((((The problem with macros))))
19:51:58 <g000031> マクロの変更についての問題です
19:52:24 <g000031> マクロを再定義したら、それに依存してるものはすべて再コンパイルする必要があるって話ですね
19:52:50 <g000031> ((((Runtime tests catch "can't happen cases" when they do...))))
19:54:55 <g000031> コメントに"can't happen cases"とあるのは、注意信号とのことですが、
19:55:19 <g000031> これをプログラムとして記述するには、assertが使えるとの話です
19:55:48 <g000031> 確かに明示的にプログラムとして記述して捕まえる方が良いですね
19:55:53 <g000031> ((((Use method dispatch rather than case dispatch))))
19:57:14 <g000031> 型での分岐について、typecaseか、総称関数かという話です
19:58:08 <g000031> 著者としては、総称関数を使うべし、とのこと。変更にも強いし、変更漏れのバグも少ないとのことです
19:59:57 <g000031> でも、typecaseも結構記述力があったりして使い勝手が良かったりするんですよねー
20:00:31 <g000031> というところで30章は終わりです。次回は、31章から再開です
20:00:35 [g000031'out] ; Quit: ERC Version 5.1.2 $Revision: 1.796.2.4 $ (IRC client for Emacs)