はじめてのにき

_ 矛盾したライセンス

http://d.hatena.ne.jp/nazodane/20080918/1221748642

ふと矛盾したライセンスをかかげると全く使えなくなるのかな… とか思ったけど、別にそんなことない気がした。 要は全部守ればたぶんいいんだよな単に。 ライセンス変更可能で特許取得禁止だと、 えーと特許取得禁止なライセンスに変更するなら別にOKみたいなそういう。 ホントかな。

で、

• 男性のみ使用可能です。
• 男性は使用してはいけません。

とかだと完璧な矛盾ライセンス。

まぁそういう問題からフリーな GBL で 10 おくえんください

http://shinh.skr.jp/m/?date=20060817#p06

(00:08)

_ 僕の考えたあーきてくちゃ

そいや前ふと考えたのを スレッドうんぬんで思い出したんだけど、 jmp と call の直後だけコンテキストスイッチする可能性がある アーキテクチャとかどうなのかな。 あとコンテキストスイッチしないバージョンの jmp とかあると 色々ラクで良い。 あと jmp とか call 無しで10万命令とか走らせると SIGILL 。

(00:12)

_ これ

ホントにすばらしいのかな

http://www.kt.rim.or.jp/%7ekbk/zakkicho/08/zakkicho0809b.html#D20080915-2

call $

じゃいかんのか。

(01:28)

_ イベントvsスレッド

http://morihyphen.hp.infoseek.co.jp/log2/200809.html#091530

あー説得されるなぁ。 このへんは考えるたびに違う結論になる気がするんだよな。 今はスレッド派。 woさんと想定してる例が全然違う感じがして、 結局適材適所的なんじゃないかと思ったりとか。 一度イベント派vsスレッド派の宗教闘争とかするべきだな。

とりあえず前教えてもらった正反対の主張をはっておく。

http://www.spa.is.uec.ac.jp/~kinuko/survey/body/events-are-bad.html

で、この話で僕がとりあえず最初に想定するのは webサーバ的なサーバで、 サーバの main thread が accept した fd を 別スレッド以下 slave とでも呼ぶに渡すとかそういう。 で、そいうモデルだと slave から main の方に 送るデータってほとんど無いあたりで、 違いが出てくるのかなぁ。 データが密接に絡めが絡むほど スレッドの方が不利になってくるのは真だと思うし。

で少なくともこいうモデル考えてる時は、 状態遷移表とかきちんとやらんでも うやむやにしきれちゃうケースが多いんじゃないかなぁ…と思う。

とりあえずこっち系モデルで ぱっと思いつくイベントうざい例として、

void handleRequestSimple(int fd) {
  read(fd);
  // hogehoge
  write(fd);
}

とかいう関数をリクエストが来るたびに呼ぶとする。 スレッドの方は

threadLibrary.create(&handleRequest);

とかしてて(もちろん現実的には thread pool なんだろうけど)、イベントの方は

eventLibrary.register(&handleRequest);

とかしてる感じだとする。

hogehoge が簡単な処理なら良いんだけど、 例えば proxy みたいに他のサーバからデータ 取ってくるようなケースだとすると、 スレッドなら

void handleRequest(int fd) {
  read(fd);
  foo();
  requestAnotherServer();
  bar();
  write(fd);
}

とかそのまま書きゃいいわけだけど、 イベントの方だと、

void handleRequestDone(int fd) {
  bar();
  write(fd);
}

void handleRequest(int fd) {
  read(fd);
  foo();
  requestAnotherServerAsync(bind(handleRequestDone, fd));
}

とかになるのかな。 まずこの関数増やすとかうざいんだけど、 それはまぁ問題ないとして、 例えば bar がバグってた時に本当にうざいんだよな。 スタックトレースとか見ると、 スレッドの方は、

bar
handleRequest
thread_main

とかになるのかな。 で、イベントの方は、

bar
handleRequestDone
EventLibrary::loop
...
main

とかになって、これだと何がイヤだって言うと 誰が handleRequestDone を呼んだのかわかんなくなってるっていう点。 手続き的な思考に慣れてる身としては、 気持ち的には handleRequestDone は handleRequest が 呼んでるつもりだったんだけど、 それがスタックトレースに無くて、 バグを追跡しにくい、っていうような。

何かしら callback というのは書く方もイマイチだと思うけど、 少なくとも第三者によるコードの可読性を損ねるというのは ほぼ間違いないんじゃないかと思う。

まぁでもこのへんは僕のわかる範囲でも偏った議論で、 デバッガがイベントモデルサポートみたいなのを入れてくれればいいんじゃね、 スレッドはほどほどのサポートあるんだから不公平な比較だ、 みたいな話と、 スレッドは無限に作るわけにはいかない、っていう話がある。

後者の方はつまり、 thread pool に thread が えーとさっきの論文紹介によると10万スレッドあるとして、 いやそんだけあったら大丈夫だろ…って感じがするけど、 その10万全てがその全てが requestAnotherServer に使われてしまうと、 requestAnotherServer を伴わないような、 簡単な処理 handleRequestSimple とかをする余裕が あるのにできなくなってしまって、 結局イベントモデル的なものを併用しなくちゃいけなくなる、 っていう話。 いやまぁ10万スレッドあるなら大丈夫な気もするが…

あとまぁどうでもいいけど重要な話として、 10万スレッドもあるとデバッグが別の意味でムズいという話が。 つまりどれが重要なスレッドなのかさっぱりわからなくて、 デバッガなどでスタックトレース見る時にどのスレッド見ればいいのー的な。 まぁこれもデバッガおよびランタイムが賢くなればなんとかなるか。

あとまぁレースコンディションとかあると 再現しにくいバグが出うるっていう wo さんの指摘は その通りだと思うし、

あーうーんやっぱ適材適所的な感じなのかなぁ。 スレッドベースの GUI ライブラリとかあるのかな。 キーボードを待つスレッドとマウスを待つスレッドと… みたいなの。

ふーむ

(09:51)

_ イテレータとスレッド論争

http://twitter.com/kinaba/statuses/922906127

これ微妙に面白いなぁ本質的ではなさそうだけど 例えとしてはなんかよくわかる。

しかし考えるとすぐによくわからんくなるので、 一度俺はスレッドの明日を守る守護神であるという設定で wo さんととっくみあいが起きる程度の論争とかすべきなんだと思う。

まーでも適材適所くさい気がするなぁ。 僕がよく見るような、 単一の機能を提供してるようなサーバとか、 裏でなんかしつつユーザになんか見せる、とか その程度の単順なサーバだと たいていスレッドの方が良さげに思う。

あと上に書いたような、ユーザのリクエスト処理してる間に 時間かかる処理しなきゃなんないような、 つまるところプロキシサーバみたいな物体も 割とスレッドな物体じゃないかなぁと思う。 あとユーザが長時間セッションをはって コマンドを順々に叩いてくるような物体も、 手続き的に書けるって意味でまぁ嬉しいかな。

で、複雑に内部状態を変更しつつも 長時間かかる IO があるようなものはどうすればいいのだろうね…

あとそうだ。小さいものは貧乏症的な意味で thread 使いたくない。 sevilwm の ipc 部分は thread で書いた方がラクだったと思うけど、 そういう理由で select でやってる。

(23:56)

_ ここらで

• scheme の人が言及
• shiro さん降臨

というような流れがあると考えなくてすんで大変嬉しい。

(23:57)

_ 答え

そういえば書いてなかった。

du でやると 70MB もあるんだよな。

単順にファイルサイズ足してくと 3.4MB だそうで。 Text Compression 引くと 2.26MB 。 総投稿数は 17384

(02:30)

_ アトランチス

http://jp.youtube.com/watch?v=IjYZ7E7f5CM

via http://twitter.com/alohakun/statuses/920239733

これ星取るルートとしては最短なのかな。 もちょい短かった気もするんだけど。

(02:37)

_ 吉野家

http://mb101bold.cocolog-nifty.com/blog/2008/08/post_0539.html

via http://risky-safety.org/~zinnia/d/2008/08/#20080826-t0-h3-p0

そいやこれは店に入ってから飯にありつけるまでの最速を目指してるとか かと思ってた。

(02:40)

_ 数日

木曜早起きしたので chrome で弾幕はってみる。 結構動いたのでこれはこれはと思った。

で木曜から土曜まで会社の hackathon 的なものに。 だいぶ前から触ってみたかった部分に 触るいい機会になって非常によかった。

帰ってから土曜は寝てた。 夜中にちょっとだけシューティングの基本部分を。

日曜は libBulletML を JS で実装してた。 accel や horizontal を完成させる 根性が湧いてこないあたり、 当時には勝てないもんだなぁと思う。 ただ単順な単位時間あたりにコード書ける量みたいなのは 増えてる気がしてそれは少し嬉しかった。 ただ集中が続かないのでトータルとしては遅い。

本当は bulletSurf なり abagames.util.bulletml なりを 使うべきだったんだろうけど、 前者はソースコードが見当たらんくて、 後者は AS よりは C++ の方が似てるんじゃねえかコレとか思って挫折した。

あとまぁ BulletML => JS のコンバータを JS で書いて libBulletML for JS にしたいかなぁとか思ったのもあって自分でやった。

あとは Lua をなんとかして JS で動かすべきだよね。

(03:04)

_ ちょうほしい

http://twitter.com/hajimehoshi/statuses/921820648

というかよみたい

(16:53)

_ マルチスレッドわかりにくい

ってホントかな的なことをよく思うのだけど。

http://morihyphen.hp.infoseek.co.jp/log2/200809.html#2008-09-14

イベントの検証漏れってのがえーと何指してるのかよくわからなかった。

(20:52)

_ おこられた

ttp://shinh.skr.jp/t/gugurenai.gif

(21:50)

_ ゴルフ場カルトクイズ

ゴルフ場に投稿され、溜まっているコードの量はどのくらいでしょうか

1. 70kB 2. 700kB 3. 7MB 4. 70MB

(22:25)

_ そいや

http://blog.tarotaro.org/archives/216

の

発表者は寝巻きにサンダルで来ていた(ように見えたが違うらしい)。

にわらった。 確かに寝てる時も着てるので間違ってはいないし。

(22:29)

_ RealLib

http://d.hatena.ne.jp/hzkr/20080909#p1

ふえー。 数式の形で覚えとくとかなのかなぁ。 ある程度の normalize みたいなのは途中でやるのかな

(09:03)

_ そいや

http://idm.s9.xrea.com/ratio/2008/09/03/000797.html

での yugui さんのゴルフについての記述は良いなぁ。 探索空間がムダに広いからパズルや リファレンスをひくきっかけとしてうんぬんというような。

あとなんか最近主張してるゴルフというか キモいコード家で書く利点として、 キモいコードというか ちょっとかっこつけたような表現を ちょっと使ってみたくなるような 気持ちが発散されて、 会社では普通のコードを生産できるというような。

GoF 読んだばかりの人がやたらデザパタとか使ってみたくなるとかいうような話。

条件演算子とかも仕事では使いたくないんだよな。

int* p;
p ? *p : 0

とかならいいけど、

char* p;
p && *p ? p : ""

あたりからあやしくなってきて、 どのあたりが読み手がいらつき始める境界かよくわからんので、 最初っから全く使わんでもいいんじゃねとか思っちゃうんだよな。

そいやあとは || も微妙な時があって、

assert(!strict_check_mode || ptr != NULL);

みたいなヤツ。

if (strict_check_mode) {
  assert(ptr != NULL);
}

の方がわかりやすい、と主観的には感じる。 カバレージ測定しやすいという副次効果もあるかも。

まぁそのへんが主観でしかないってのはそうなんだけど、 ただまぁ後者を積極的に読みにくい、 って感じる人はそんなに多くないだろうなぁとか思うと、 読みにくいと感じる人がそれなりにいるであろう前者は 避けたくなるよなぁとか。

一方、家で書いてるコードは普通のコードでも

while (*rp) --**rp++;

とか平然とあって、まぁ発散できてるなー的な

(00:35)

_ BAMBOO麻雀

http://risky-safety.org/~zinnia/d/2008/09/#20080906-t0-h1-p0

を見てやってみた。 面白いなぁ。

こんなルールでも九連ってなかなか出ないんだなぁ… とだらだらやってたら出た。うれしい

(01:40)

_ Perlの功績

http://www.kt.rim.or.jp/~kbk/zakkicho/08/zakkicho0809a.html#D20080903-4

正規表現まわりだと =~ とかはちゃうのかな。 自信まったくなし。

あと s///ge はゴルフ的な観点から神

あれ、あと $` $' $& $+ $1 $2 ... も Perl 出身とか? これもまったく自信なし

(05:22)

_ hello.grass 493B

http://golf.shinh.org/p.rb?hello+world#Grass

うし。 ちなみにまめさんのは見ないで頑張った

(14:39)

_ はやいな

http://shinh.skr.jp/llvmbench/023.html

(10:56)

_ そいや

mircbot っていうアカウント取ろうとしたら、 既にいて驚いたんだけど、 どんなヤツかと見てみたら 取ったのは俺で、まぁおどろいた

http://twitter.com/mircbot

(11:18)

_ したら負け

http://d.hatena.ne.jp/ku-ma-me/20080901/p2

• Perl: use strict したら負け
• OCaml: for や while を使ったら負け
• C++: friend は負けっぽい(使うけど)
• XXX: 使ったら負け(お好きな言語をどうぞ)

あとは C を吐くコンパイラは負けた気分とか、 色々あるなぁ

(01:11)

_ make

http://twitter.com/emasaka/statuses/906494269

すばらしい指摘だとおもった。

ああそうそう kati はとうぜんそいう意味

http://shinh.skr.jp/koneta/#kati

(18:55)