はじめてのにき

_ swap

http://d.hatena.ne.jp/nishiohirokazu/20100622/1277208908

http://d.hatena.ne.jp/nuc/20100716/p17

via http://twitter.com/gusmachine/status/18840198768

@gusmachine さんいいこと言うなあ…ってのはいいとして。

id:nuc さんは空間使用量が O(N**2) で増えていく、 と書いてあるけど、そうなん? と思ってしまった。 fibonacci の多倍長整数のオーダーが O(N) になるのか。

で…

2.77618e-13*x^2.55 の方が 2.10854e-10*x^2 よりどう見てもマッチしてるな。 特異的って感じもないと思う。

まぁ Haskell とか不思議の塊なので、深く考えるのはやめ。

で、メモリ。

うーん O(N)。

まぁ Haskell とか不思議の塊なので、深く考えるのはやめ…

(02:10)

_ ちなみに

二つ目のグラフの a == 0.668326 だそうです。 そしてメモリの縦軸は kB 。 つまりメモリ使用量が 668 Bytes ずつ増えていく計算になるわけですが…謎。

もう少し上まで

a               = 3.16989e-10      +/- 1.038e-11    (3.274%)
b               = 2.63344          +/- 0.007344     (0.2789%)
c               = 1.01622e-13      +/- 9.684e-15    (9.53%)

a               = 0.642804         +/- 0.007101     (1.105%)

ソースコード

http://github.com/shinh/test/commit/79d93f47d025f841ee9a7639bf3b493d918b86b0

(02:27)

_ wake

名前は

• kati はやっちゃったから hikiwake かなぁ
• てか wake って m ひっくりかえした make っぽいね
• 作りはじめた時に眠かったのに作りたくなって無理矢理起きて作ってた

のでちょうどいいと思った

あと一日中雌豚先生の作業用 BGM 聞いてた結果、 たしかに違うかなーと思った。

(02:42)

_ bf.bef

書いた記憶があるのにどこにもないなぁと探しまわった。

見つかった…

http://d.hatena.ne.jp/shinichiro_h/20100121#1264012341

検索用: befunge brainfuck bfint.bef brainfuck.bef

(02:51)

_ WebKit

たいしたことじゃないけど

http://ss-o.net/webkit/extension/browser.html#Page5

個人的な感覚ではあの switch case は必要悪かなぁ。 分離されてるとかえって不便な気がする。

グローバル変数も過去の遺産っていうか省メモリやら キャッシュしたいやらでしょうがない面も強い、かな。 ただ省メモリ用のハッシュとキャッシュ用の static 変数でのハッシュは、 それぞれ class 作って抽象化しておけば、 いざ thread safe にしたいとか思った時にやりやすかったかもー という意味ではまぁ過去の遺産と言われてもしゃーないか。

http://ss-o.net/webkit/extension/browser.html#Page10

WebKit2 の説明はちょっと意味がわからなかった。 どっちの説明も「なので、」までは正しいと思うんだけど、 後半はどっちもそうなんじゃないか。 WebKit2 もたぶんタスクマネージャ見たら たくさん起動してるだろうし、 どっちも1つのアプリケーションの中でプロセスを分割してるし…？

Chrome は ... なので、使いまわせない。 WebKit2 は ... なので、使いまわせる。 とかがこの文脈で言える唯一のことじゃないかなぁ。

出てきたころは、 WebKit2 はまだ新しいので、 セキュリティうんぬんとか詳しいこと考えてるのかなーとかいうのは 言えたっぽいんだけど、 まぁ今はさっぱり動きとか見てないのでわからない。

(12:56)

_ SSE 命令

http://msirocoder.blog35.fc2.com/blog-entry-58.html

これは大変便利げな

(13:06)

_ wake の page

As of September 18, 2010 とか書いてあった。 未来に生きてるなー。

正解は July でした。

さっき昨日ビルドしたはずのファイルに ls -l して、 July とかでてきて、 えーと July って 5 月じゃないかにゃー ヘンだにゃーと思ったところで、 そもそも July は今月だと気付いた。

英語の月名は難しいよなあ…

(13:19)

_ ものはついでと申します

ruby1.9 (git-svn-id: http://svn.ruby-lang.org/repos/ruby/trunk@28675)

a               = 1.02084e-10      +/- 2.187e-12    (2.143%)
b               = 2.47454          +/- 0.0404       (1.633%)
c               = 3.26532e-13      +/- 1.625e-13    (49.76%)

a               = 0.642804         +/- 0.007101     (1.105%)

コード

n = ARGV[0].to_i
fib = [1,1]
n.times{|i|
  fib << fib[i+1] + fib[i]
}

時間は O(N**2.47454) 。

なにか正直言って、 memory allocator がこんだけ order をいじるんだなぁということを知らなかった。

あと、 Haskell が線型のメモリしか使わないのは、 よく考えたら僕の脳内 Haskell はそいう動きしそうに思ったので、 さして不思議じゃないかなぁと。

java version "1.6.0_18"

a               = 1.81687e-10      +/- 3.693e-12    (2.033%)
b               = 2.16295          +/- 0.1003       (4.636%)
c               = 2.73763e-11      +/- 3.232e-11    (118.1%)

a               = 0.000237798      +/- 5.535e-06    (2.328%)

時間は O(N**2.16295) とのことで、 オーダーのオーバヘッドは少ない。 ただそもそもなんか遅いんだけどな…

import java.math.BigInteger;
import java.util.ArrayList;

public class fib {
    public static void main(String[] args) {
        ArrayList<BigInteger> l = new ArrayList<BigInteger>();
        l.add(BigInteger.ONE);
        l.add(BigInteger.ONE);
        int e = new Integer(args[0]).intValue();
        for (int i = 0; i < e; i++) {
            l.add(l.get(i).add(l.get(i+1)));
        }
    }
}

Java 書いたの超ひさしぶりだー

(13:57)

_ C++

完璧言語 C++ ではどうか。

a               = 5.4409e-11       +/- 1.265e-12    (2.325%)
b               = 1.84416          +/- 0.09885      (5.36%)
c               = 3.58202e-10      +/- 4.327e-10    (120.8%)

O(N**1.84416)! O(N**2) のアルゴリズムのオーダーを減らしてくれる memory allocator! すごいです!!

a               = 0.000188953      +/- 7.58e-06     (4.011%)

まぁ途中で memory allocator は サイズの大きい小さいで挙動を変えてるだろうし、 gmp もそいうのあるかもしれないし、 まぁ N**a とかでの fit はあまり意味ないんだろうと思う。

ソースコード。 gmpxx ってえらいですね。 GNU とは思えない。知らんかった。

#include <stdio.h>
#include <stdlib.h>

#include <iostream>
#include <vector>

#include <gmp.h>
#include <gmpxx.h>

using namespace std;

int main(int argc, char* argv[]) {
    vector<mpz_class> v;
    v.push_back(1);
    v.push_back(1);
    int e = atoi(argv[1]);
    for (int i = 0; i < e; i++) {
        v.push_back(v[i] + v[i+1]);
    }
    //cout << v[e] << endl;
}

これまでのあらすじ:

Ruby すごくね

(14:57)

_ あとそうだ

これは GC のある言語に大変厳しいベンチマークなので、 公平性には欠けまくりだと思う。

なんでかっていうとメモリ使用量が増えるばっかりで、 全然 collection されないから。

聞いた話によると、コンパイラとかはこいう挙動をする、 GC 泣かせなアプリの一つらしい。 つまりソースコードを読んでがーとデータ構造作るんだけど、 作るばっかであんま解放する物は無い、というような。

(15:01)

_ ↑

適当に D も足しておいた。

時間は O(N**2.5833) ですって。

(16:21)

_ niconico

http://twitter.com/lyrical_logical/status/18776878242

芸風的に雌豚先生復活とかだと嬉しいなー。 動画丁寧すぎるのがそれっぽくないけど。

(10:09)

_ wake

C++ で書いたらだいぶ速くなった。 20-30倍くらいか。

基本正規表現だけだからこんなに速くなると思ってなかったんだけど、 まぁ Ruby の方のコードは色々適当なのが悪いんじゃないかと思う。

で

all: "$(loop0)"

loop3000000: "DONE\n"
loop(\d+): loop$(add($1,100))

#include "std/num.wake"

とかが 2 秒とかかかってて、 ちょっとまだ遅すぎるよなーという感がある。 16kHz とかくらいか。

ターゲットが増えると遅くなるってのはいけてないので、 なんかそのへんなんとかなるといい。

二つほど方法はあって

• 正規表現を合成する
• 各正規表現の先頭部分に関して trie を作る

とかかなぁ。

正規表現の合成って特に後方参照的な意味で 難しそうな気がするけどどうなんだろうな。 普通に \1 とかの番号を振りなおすだけでいいのかな。 とりあえず \10 とかは使えるんだなーと確認した。

うーんでも trie かな

(13:59)

_ なるほど!

http://twitter.com/lyrical_logical/status/18816579845

(14:15)

_ ↑

うざい遊びをしててすいません

単にこのエロ動画の話 http://www.nicovideo.jp/watch/sm11381844

(14:18)

_ memset

http://twitter.com/hamano/status/18818137867

https://review.source.android.com/#patch,sidebyside,14699,1,libc/memset.c

ありそうすぎて笑った。

/bin/grep -r --include='*.cc' --include='*.h' --include='*.cpp' --include='*.c' memset *

とかしてみたところ、

SDL_command/SDL_command.c:    memset(cmd->input_queue, -1, sizeof(int)*input_queue_size);
marathon/SequenceAlignment/sa2.cc:    memset (F, -1, sizeof (F));

ごく稀にはあることがわかった。

(14:32)

_ dc.sed

簡単だと思っていた引き算が意外とめどい

dc.sed は何故 add と sub を同時にできてるんだ…

: addsub1
	s/\(.\{0,1\}\)\(~[^,]*\)\([0-9]\)\(\.*\),\([^;]*\)\(;\([^;]*\(\3[^;]*\)\).*X*\1\(.*\)\)/\2,\4\5\9\8\7\6/
	s/,\([^~]*~\).\{10\}\(.\)[^;]\{0,9\}\([^;]\{0,1\}\)[^;]*/,\2\1\3/
#	  could be done in one s/// if we could have >9 back-refs...
/^~.*~;/!b addsub1

ええ理解不能です

(15:43)

_ ああそうか

引き方を先にマッチさせればいいのか。 やはり簡単だった…

(15:45)

_ ぼとるねっく

perftools でプロファイル取ってみたところ、 正規表現とかでは全然なくて、 malloc 多すぎとかだった。 とりあえず string::reserve 呼ぶとだいぶ速くなった。

あと tcmalloc 使うとだいぶ速くなる。

ベンチマークは大事だなぁと思った。

で、前回の話から考えると、 std::string じゃなくて自分で string 作った方が速くなるんないか…

(18:02)

_ perftools

libpcre の symbol 取れねーなーと悩んでいた。 profile の末尾についてる /lib/libpcre... とかを /usr/lib/debug 以下のものに置換すればとりあえず取れるみたいだ。

inline 展開のせいでよくわからんのだけど、 たぶん、

• 少なくとも 31.8% は pcre_compile
• 20% くらいが pcre_get_substring_list ?

って感じっぽい気がする。 とりあえず後者は簡単に減らせるはずだ。 pcre_exec の返す ovector のフォーマットが わかるといいんだけどな。

      The  first  two-thirds of the vector is used to pass back captured sub-
      strings, each substring using a pair of integers. The  remaining  third
      of  the  vector is used as workspace by pcre_exec() while matching cap-
      turing subpatterns, and is not available for passing back  information.
      The  number passed in ovecsize should always be a multiple of three. If
      it is not, it is rounded down.

3倍ってなんだと思ってたんだけど、そういうことか…

(20:09)

_ pcre_get_substring_list を取り除いた

全然速くならない。 普通に pcre_exec が遅かったみたいだった。

RE2 はどうかなーと思ったんだけど、 backreference が無いみたいなので論外だった…

Irregexp とか YARR とか使ってみるという手もあるんかな。

ぱっと見では YARR の方が切り出しやすそうな雰囲気かなぁ… と思ったけど wtf とかに依存してやがるな。

Irregexp にするか… とか思ったあたりで何やってるんだろうと思いはじめてきた。

(20:59)

_ 散歩

なんで駒場に行かにゃならんの… ということで雨もふるし大変うざい選挙になってしまった。 どうも期日前投票するべきだったみたいだ。

好きでない共産党にわざわざ投票しに行ったのに 落選してしまったのでかなしかった。 タリーズめ…

しょうがないのでついでになんかしようとマンガを 読んだり買ったり。

読んだ:

ドリフターズは普通に面白そうだなーと思った。 ローマとカルタゴの人を知らんかったのでちょっと歴史の勉強した。

眠れる惑星。 あいかわらずストレートに都合のいいエロマンガかく人だなぁとか思った。

打撃天使ルリ。 3巻で終わってたのかー。 1巻あったら買ったんだけどな。

殺しや1の人とのぞき屋は同じ作者だったようだった。

罪と罰はなんか時代ずらしただけじゃなくて、 ソーニャの立ち位置とか全然違うっぽい。 なんかラスコーリニコフ役から信念が感じられないのがいけてないなぁとおもった

カイジ。つまり福本先生この話実体験ってことすか…的な

あと忘れたけどもろもろ。 燃えよペンってもっとぶっとんでた気がしたんだけど、 今見るとなんかそうでもない気がしてしまった。

買った:

地雷震1。最初の方はどうしようもなく救われなくていいよね。 そういえばウシジマ君もなんか少しいい人になってて そのへん地雷震ぽい気がちょっとした。

ジャぱん18 はですよがついてる話を読んでおこうかなぁとか思って買った

初期のURASAWA 。激しく読んだことあった。

劇画自民党総裁。勉強になった。

まるごと西原理恵子。 西原理恵子のマンガの読み方としては これはすごくいい売り方な気がするなぁ。

恐怖新聞。 うしろの百太郎の方が事実として押しつけてくる感が強い感じなのかな。

そんなことよりやりたかったことはあるはずなんだけど無駄な日曜になった

(23:53)

_ アルファベット only perl

http://shinh.skr.jp/dat_dir/mederu/041.html

ここで「たぶんできそうげ」と書いた、 アルファベットだけの Perl で任意コード実行だけど、 今考えると比較的簡単にできるのであった。

同じく quine も書けると思う

今度なんか書く

(02:35)

_ らくてん

あの英語は失笑を招くほどひどいらしい。

みんな英語うまくていいなぁとしか思えない。

や、日本ぽい発音てのはそだけど、 どう考えても通じると思われるので別にいいじゃんね…

あれがダメだっていう人はこう、 インド英語とかもダメってことになると思うんだよな。

なんか楽天に関しては色々思うことが混じっていると思う。

• 英語のクオリティは普通に必要十分じゃね
• 記者会見英語でやるのは意味ない感強いけど、まぁパフォーマンスみたいなもんなら別にいいんじゃないかな。今後もずっと続くとかならよく知らんけど
• 国際競争力つけようと努力すること自体は一般的に言うといいことなんじゃないかね
• 普段「日本から世界に通用するサービスが出てないのは何故か！」とか論じてる人は素直に応援してあげたらいいんじゃ
• ところで英語自体はこわいので自分の会社とかであんなことが起きたら悲しいと思う
• 特に多少なりとも愛社精神があったりすると悲しいと思う

最後の意味でこいう意見はとてもこわい。

http://d.hatena.ne.jp/nishiohirokazu/20100707/1278509600

僕個人はさっさと転職を選択すると思うけど、 しかし仮にうっかり愛社精神が強くあったりしたら悩むと思うので、 英語ができないくらいで仕事できないとか言われることになって、こわい。

ところで、よく TeX とか C とか人を長期に渡って 苦しめててひどいとか言うけど、 英語の方がよっぽどひどい言語と

(00:59)

_ C の代替

なんか C はいいものだけど、 ハードウェアってそれなりに変わったらしいし、 C の守備範囲でもちょいなんか無いもんかねみたいな話を よくしたり聞いたりするんだけど、 なんか機能で考えるより何が実装できればいいかを考えればいいんかな。

アセンブラや言語拡張無しで、

• バックトレース書ける
• JIT 書ける
• closure 書ける
• GC 書ける
• 高速な画像/動画処理できる

このあたりかなぁ。

(02:05)

_ 1.5倍とか

http://www.kmonos.net/wlog/111.html#_2334100705

なんかこの話は gus さんと何度かしたのでなんか書く。

結論としてはなんか C++ が残念な気がするという話なんだけど、 メモリアロケータの実際とか自信無い面があるので少しあやしい。 全く測定とかはしてないし。

まず、要素数が少ない時。

この時はどうせメモリアロケータ的に 穴もへったくれもなくてサイズごとのプール使ってるんじゃないのか。 そしてキリのいい数字の方がサイズごとのプールにちょっきり入りそうだし、 倍々でいいんじゃないの。

次に要素数多い時。

なんか mmap しはじめるはず。 ということで使い捨てたメモリは munmap されるだろうし やはり依然として穴とか関係ない感がある。

ただやはり瞬間的に要素数 * 3 のメモリが必要になるわけだし、 このへんになると直感的に 1.5 倍とか少なめな方が良さげな気もする。

そもそも要素数が大きくなってくると realloc が mremap になっていって、 mremap ならそもそも アドレスが移動しようがコピーいらなくなるんじゃね？ ならし計算量どころか毎回 O(1) なんじゃね？ という話を gus さんにした。

すると C++ の allocator は realloc しないと教えてもらった。 kinaba さんが引用している comp.lang.c++ の 議論にもあるけど、 C++ の vector は、 必ず、次の領域の allocate => コピー => free って感じでやる、らしい。

さて、仮に C++ の allocator に realloc があったらいいのかっていうと、 どうも realloc ではうまくいかない気がする。 というのは non-POD な型の場合、 アドレスの移動が起きた場合、 適切にコピーコンストラクタ呼んでやらないといけなくて、 しかし realloc でアドレスが変わった時って、 前の pointer は既に free されているのよね。

なんか話としては

• is_pod とかを駆使して pod が vector に入ってる時くらいは realloc にする
• あるいは user がアドレス移動 OK だよ、と vector に policy として伝える
• デフォルトでは何もしない move_address とかいう関数を全てのクラスに暗黙で定義されるようにしておいて、アドレスの変化が重要な子はそれを定義
• そもそも realloc がアドレス変える時に古い address が free されてるのが悪くて、 address が変わる時は user が free しなければならない realloc があればいい
• あるいは、アドレスが変わる時は失敗する realloc があればいい
• mremap ならそれはできるはずなので、サイズが大きくなった時用の allocator だけは自分で…

などなど。なんか C++ ダメなんじゃないかと思った。 0x とかで解決されてるよ! とかだったらすいません。

(02:22)

_ コピーコンストラクタ

でその議論の結論としては

#include <stdio.h>

struct S {
    S(const S& s) {
    }
};

int main() {
    // copy コンストラクタを定義たせいでデフォルトコンストラクタが無い時は
    //S s;

    // こうすればいいよ!
    S s(s);
}

(02:32)

_ RIP相対

http://twitter.com/kazuho/status/17851784436

x86-64 の場合、無いと大変なことになる系かなと

何故でしょうか!!!

とかいうのはめんどいので書く。

x86-64 さんは、こうアドレス空間が広いです。 64bit 。 x86 と同じ 32bit 絶対でデータを mov とかしようとすると、 届かないことがあったりします。 つまりどういうことかというと、

void foo() {
    puts("foo");
}

をコンパイルして objdump する。

> gcc -c -g rip.c
> objdump -Sr rip.o

rip.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <foo>:
void foo() {
   0:   55                    push   %rbp
   1:   48 89 e5              mov    %rsp,%rbp
    puts("foo");
   4:   bf 00 00 00 00        mov    $0x0,%edi
        5: R_X86_64_32 .rodata
   9:   e8 00 00 00 00        callq  e <foo+0xe>
        a: R_X86_64_PC32 puts+0xfffffffffffffffc
}
   e:   c9                    leaveq
   f:   c3                    retq

とかすると、まぁ callq の引数部分が 32bit 相対になっていて、 ここがその、 so とかになった時に loader が解決できない可能性があるわけ。

で、それが理由で普通に -shared とかすると、

> gcc -g rip.c -shared -o rip.so
/usr/bin/ld: /tmp/ccbHkebh.o: relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC
/tmp/ccbHkebh.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
zsh: exit 1     gcc -g rip.c -shared -o rip.so

とまぁ怒られるわけです。つまりどこにでも置けるように PIC (position independent code) にしやがれ、と。

で言われた通りに -fPIC とかつけるとどうなるかっつーと、

0000000000000000 <foo>:
void foo() {
   0:   55                    push   %rbp
   1:   48 89 e5              mov    %rsp,%rbp
    puts("foo");
   4:   48 8d 3d 00 00 00 00  lea    0x0(%rip),%rdi        # b <foo+0xb>
        7: R_X86_64_PC32 .rodata+0xfffffffffffffffc
   b:   e8 00 00 00 00        callq  10 <foo+0x10>
        c: R_X86_64_PLT32  puts+0xfffffffffffffffc
}
  10:   c9                    leaveq
  11:   c3                    retq

こうなる。 ここに rip 相対が登場して、 .text と .rodata の相対的な位置は変わらんようにしてある (っていうかまとめて mmap するって話だと思う) のでちゃんと relocation できますめでたしめでたしというような。

ちなみに x86 だとどうなるかというと、

00000000 <foo>:
void foo() {
   0:   55                    push   %ebp
   1:   89 e5                 mov    %esp,%ebp
   3:   53                    push   %ebx
   4:   83 ec 14              sub    $0x14,%esp
   7:   e8 fc ff ff ff        call   8 <foo+0x8>
        8: R_386_PC32 __i686.get_pc_thunk.bx
   c:   81 c3 02 00 00 00     add    $0x2,%ebx
        e: R_386_GOTPC _GLOBAL_OFFSET_TABLE_
    puts("foo");
  12:   8d 83 00 00 00 00     lea    0x0(%ebx),%eax
        14: R_386_GOTOFF .rodata
  18:   89 04 24              mov    %eax,(%esp)
  1b:   e8 fc ff ff ff        call   1c <foo+0x1c>
        1c: R_386_PLT32 puts
}
  20:   83 c4 14              add    $0x14,%esp
  23:   5b                    pop    %ebx
  24:   5d                    pop    %ebp
  25:   c3                    ret

なんか call が増えて大変なことになる。 __i686.get_pc_thunk.bx の定義は

08048416 <__i686.get_pc_thunk.bx>:
 8048416:       8b 1c 24                mov    (%esp),%ebx
 8048419:       c3                      ret

という感じで、まぁ要は call で eip 取ってくるテクニック。

ところで、 なんで call pop じゃダメなのかは知らない。 intel さんが call があると ret やーというような解析を もりっとしていて、 call したのに ret しないと遅くなるとか そいうことだったりとかかなーとか妄想するが知らない。

あと、たしか、 x86-64 は 64bit 絶対 call とか、 64bit 絶対参照とかあったと思う。 このへん使えばどこにでも届くわけだけど、 やらないのは、どうせ PIC の方がいいじゃん (リロケーションのコストとか的に) ってことなのかなぁ。知らない。

(23:33)

_ ↑

こいう話は TCC の時に色々 考えたりしたので、 どっかで話したりする機会ないかなぁとか思いつつ今に至ってる気がする。

謎のメモが出てきた。

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

(23:36)

_ w3m

http://d.hatena.ne.jp/yshl/20100704#1278255925

おおありがたや、ということで適当に

http://github.com/shinh/w3m/commits/master

(00:45)

_ $

そうか $ をいじるという手があったかー

http://gist.github.com/462815

僕は fromInteger いじれるといいのかなぁとか思ったけど、 instance Num すると + を再定義せざるを得ないっぽいので どうしたもんかーという程度でとまってしまった

(06:39)

_ :

pm の man はあったものの w3mman で見れなかったので修正

http://github.com/shinh/w3m/commit/b9ad76673b43feba10f4d968948c8e44588f8334

(06:44)

_ キャラジェネ

スプライトみたいなもんだと思ってたけど 正確にどいうもんなのかわかってないなーと思ったのでぐぐった。

グリフだったのか…

(07:00)

_ こわいはなし

http://atnd.org/events/5073

すっかり忘れてた… 今からでもなんか書こう。

バイトしてた時の最初のプロジェクトは 大変社会勉強になるコードだった。

less とかで読んでいると、 どうも 2 行に 1 行空行が入っていて、 ヘンな style だなぁと思ったのだけど、 実は 20 段くらいネストしてるから 空白だけで 80 column 越えしてたのだった。

そのネストした中身はコピペな感じなコードなのだけど、 なかなか内容もためになった。

どういうものかということで一つ覚えているものを。 直線がたくさんあって、 その直線群、つまり

struct Line {
  float start_x, start_y, end_x, end_y;
}
vector<Line> lines;

とかいう lines があったとして、 その lines がループを形成しているかを判定したいらしい。

どうやってやってやるかというと、

• まず、 lines を構成する全ての頂点の平均を求めて中心を求めます
• その中心からランダムな直線を 100 本引きます
• 100 本全ての直線が lines のどれかと交わっているようなら、つまりループになっているでしょう

複雑なコードの管理能力と、問題解決のための独創的な発想の2点で、 そのコードを書いた人は頭いいと思った。 つまりこう、頭は悪い方がいいのだなぁと勉強になった。

(07:22)

_ lenovo

今度は 17 万以上のマシン買ったら 5 万引かー。 うまいことやれば 30% 引きってことだなぁ。 どんどんエスカレートしていく気がするんだが レノボ大丈夫すか

(00:48)

_ オールインワンPC

っていうジャンルがあるんだなぁ。 よく考えるとメインなノートPCのキーボードとかいらんわけだし、 もうこういうのでいい気がしてきた。

要求としては

• フルHD
• なんかグラボ
• i[3-7]

この条件を満たしてなるべく安いものならいいと思った

(12:30)

_ よくわからんし

暇だか秋葉でも行くかのう…

(12:33)

_ Haskell Quiz

http://blog.hackers-cafe.net/2010/06/haskell-quiz.html

むうむつかしい

(13:58)

_ paged media

dev channel 出てるなーということで入れてみた。

とりあえず linux は paged media 入ってるなぁ。

Win と Mac は間に合ってないっぽいな。 ちゃんとテストせんとなぁ…

(15:22)

_ myrurema

http://route477.net/d/?date=20100702#p01

便利そうなので refe から離れるべく入れてみた。

rurema とか長いよってことで rure にした

(15:40)

_ つか

man と apropos で良くねーと思った。

どうも Perl module と OCaml は man が入ってるみたいだ。 C++ の STL とかはあるわけだし、 Ruby とか Python も man にしておいてもいいんじゃないかな。 あと JavaScript も欲しいな

(15:51)

_ polipo

http://www.pps.jussieu.fr/~jch/software/polipo/

という cache する http proxy があるらしい。

filtering もできるっぽいから、 mod_python_filter とか使うのやめてこっちでいいかなぁ。

(16:13)

_ 歯医者さん

しばらく通院していたのだけど 2週間前にすっぽかして、 そのまますっぽかしたということにすら気付かないまま、 今に至っていると、気付きました

(23:26)

_ RIP CGI

http://d.hatena.ne.jp/nurse/20100702#1278054508

CGI 好きなんだけどなぁ。

Process isolation というのは本当にいいもので、 つまりこう Ruby がクラッシュしようが メモリバカ喰いしようが、 そのプロセスさえ死んでくれればいいわけで、ねえ。

ゴルフ場はなんとなく FastCGI だけど、 正直 CGI の方がいいんちゃうかなーとかたまに思う。 なんかたまにメモリ大量消費してて、 よくわからん。

しかしまぁ、僕とかは ruby で web のなんか作る人間としては、 それこそ CGI.rb にそれなりに我慢ができる程度に 圧倒的にライトユーザなので、 まぁ意見としてはどうでもいい層なんだと思う

(23:56)