来年また応募したいですね。今年も応募したけど、かすりもしなかった。受賞した近永さんとかラスボス度が高すぎて。楽になってるから好きですね。何が嬉しいのっていう。外に向かってスレッド間通信の代わりに使えるんですよね。タイミングが選べないから、スレッドを殺したいときにしか有用じゃないんじゃないかなと。させるっていうのは巻き戻しとは違うセマンティクスなので、あんまり使い道がない。使うしかなかったと聞きますね。してもあまり問題がなかったので。タイムアウトもあれはあれで、もうちょっとなんとかならんのかと思うけど。以降でスレッドの仕様が大きく違うので、いろんな矛盾がね。仕様はまあありかなと。するのもある意味アリだよね。スレッドを最初に読んだときは、ここまで割り切るのもアリなんだ、と、その時はプラスの評価だったんですよ。変えたけど、全然苦情来てない。だれもそこまで真面目に使っていない。したらロック取らずに抜けてくるとか。したときには例外があがってこない。嫌いな所はスレッド、と。クラスがなかったら俺コミッターになれなかった気がする。そんなに読んでない、得意分野だけ。システムコールから遡って読んでいくだけだから。挫折する人結構いますよ。笹田さんと一緒に学生向けのプログラミングキャンプをやったことがあるんだけれど、学生さんは文法拡張したがるから、あそこは避けられない。その魔窟を選ぶのかと。文法もなんとかしたいですけどね。「文法をなんとかしたい」と「スレッドと割り込みをなんとかしたい」というのを比べると、割り込みの方をなんとかした方が、と思っちゃう。文法はそこまで困らない。申告があると確認する。リリースのときに非互換が出ないようにする仕組みを機械的に作ったりとか。機械的チェックはやっぱり必要ですよね。非互換はありませんとか。言っちゃった以上やる他ないので結構大変でした。カーネルを直したときに、デバッグのテストツールで出力したログに対して、おかしな組み合わせを検出したり、というのはやってますね。さっきも言った文字列操作や正規表現がありがたいっていうのは、このあたりかな。成功した事例ってほどでもないけど、さっき言ったテストツールかな。日々の検証で地道に使っています。テストツールはバグ発見というよりも修正できたかの確認。自分はバグを発見するタイプではないので。田中さんは自分でバグを発見するタイプですよね。やったらその発想ができるのか。正解を知って逆算してるのでは、と思ってしまったり。ソースコードを追って怪しそうな所を見つけてから狙い撃ちしたり。大きい文字列を作るといろんなメソッドが落ちてたんです。使っていたので、スタックがあふれるという単純なものだった。使っている所を狙ってテストケースを作り報告しましたね。使うように修正してくれたり。配列はまだ大きいと落ちちゃうんですよね。大きい配列をスプラットに渡そうとするとスタックがあふれて落ちる。スタックの話なので、別ですが。引数に外から来た任意の引数を渡してしまうとまずいという話で、固定長はまだ残ってたかな。渡していて、一掃作戦をかけています。使いたい気持ちも分かるけど、前後にチェックを挟むとそこまで速くならないし。速度違うと思うけどな。ロック競合を考えないといけない。関係ないのかもしれないけど。出来ないときにどうするのか考える必要があるのが手間かなと。スタック足りなかったりとか。僕の人生を変えかねない位のインパクトが。