はじめてのにき

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

そいや前ふと考えたのを スレッドうんぬんで思い出したんだけど、 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)

_ えるえる

あつかましく Larry のサインもらた！ もう俺はそれで全て良い。

何度か語ってると思うけど実はそんなに語ってないかもしれないけど、 僕はそんなに好きなプログラム書籍とかそんなに語れないんだけど、 いわゆるラクダ本は大好きな本で、 すっぽすっぽのプログラミング言語 C++ とかと 同じ程度には影響とかはある気がするんだ。 まぁ僕は本に影響されるとか今一つピンときてないのであやしいけど。

サインもらった記念に Perl をベタボメする。

Perl っていうのはこう、変態言語愛好会にとっての LISP と 考えても全く問題ないと思う。 ヤツらはこう10年先を行ってると考えてよく、 LL とか好きな子がこんなハッキーなことやったぜ!! っていうのは、 「あーそれ Perl が 3000年前に通った道」 みたいなこと言われてもおかしくない程度には すごいというのを認識してからの方が安心かもしれないのです。

例えば今日とか Perl Golf というのを Web ベースで… とかほげほげ司会のかたがおっしゃってたけど、 あれはたぶんウソで、当初は newsgroup で行なわれてたんだと思う。 newsgroup とかいう時代からゴルフやってた連中なわけですよ。 知らんけど。

まぁゴルフのこととか書くとまたそんな話か的な感があるけど、 Perl で実行できる詩を書く perl poem とか、 Acme::* とか、 JAPH とか、 ほげほげとか、ふがふがとか、

…と書きたかったんだけど、ぶっちゃけあんま Perl とか知らんな。 まぁそいう子はとにかく Perl を学ぶべきなんです。たぶん。

でまぁラクダ本も Larry がそいうの好きなんだなぁ という感じがすごくするのでこう良いのですよ。

用心しろよ、 emacs さん。言語を内蔵するのは、君だけの専売特許じゃないよ :-)

とか、まぁこうなんというかこいうのいいね。

だいぶ前に書いたこのへんの頭おかしい話とかも 別に秘奥義とかじゃなくて単にラクダ本に書いてあったわけだし

http://d.hatena.ne.jp/shinichiro_h/20071107#1194442793

(00:49)

_ title

http://d.hatena.ne.jp/takkaw/20080830/p2

ちなみに Python にも capitalize もあります。 (is)?(upper|lower|title) とさらに capitalize がある、というのが現状らしく、 Python は大文字小文字変換界の雄と言っても良いのではないかと思います。 iscapitalize が何故ないのか、それを考えて余生を過ごそうかと思います。

(00:55)

_ isakr

で、今日の呑み会で、 isakr みたいなのがあるといいんじゃないかということなので さっそく作ってみました!

class String
  def akr?
    # must not be capitalized
    return false unless self[/^[a-z]/]
    # there should be continuous upcases
    return false unless self[/[A-Z][A-Z]/]
    return true
  end
end

puts "defLATE: #{'defLATE'.akr?}"
puts "deflate: #{'deflate'.akr?}"
puts "Deflate: #{'Deflate'.akr?}"
puts "dEflate: #{'dEflate'.akr?}"
puts "DEFLATE: #{'DEFLATE'.akr?}"
puts "deFLate: #{'deFLate'.akr?}"

実行結果:

defLATE: true
deflate: false
Deflate: false
dEflate: false
DEFLATE: false
deFLate: true

とりあえず現実の例が一つしか無いので、 仕様策定が難しそうですね…!

(01:04)

_ String#akr

akr? があるなら実装はかんたん

class String
  def akr
    akrize = proc{|s|s.split('').map{|_|rand<0.5 ? _.upcase : _.downcase} * ''}
    until (s = akrize[self]).akr?
    end
    s
  end
end

10.times{puts 'deflate'.akr}

実行例

dEFlate
deFLaTe
dEFlaTE
dEFlAte
dEFLATE
dEFLatE
deflATE
dEFLATe
dEFlAtE
dEflATe

いかにもいやなかんじのものが

(01:09)

_ ぐ

昔見た時は deflate 違ったような気がするなぁ… とか思ってぐぐったらやはり別の事例を発見した。 うん僕が見た時は DeFLaTe だったような気がする。

というわけで先程のコードには重大なバグがあるので プロダクションでは使わないようにおねがいします

(02:01)

_ そういえば

ほげほげより C++ の方が中二病としてはほげほげな気が するというような気がする的指摘。

たしかにほげほげは中二病そのものだと思うけど、 C++ はこうやりたくなることはわかるなぁ うん実際にはそんなに書かないんだけどね、

というあなた

は中二病なので問題ないというような。 いやそういう話だったか

(23:44)