なお昨日購入したSSDは開梱すらしていない。

21世紀にもなってgit-svnを生で叩かざるを得ない俺…普段は git-svn dcommit だけ使うよ。fetch, rebase は使わない。

近所のPCデポにIntel Toshiba Samsungしかなかったんだよ…RAID1組んでサイマル死という結末だけは迎えたくないよな?!

気が触れて Samsung SSD 840 EVO をふたつも買ってしまった。

PPTPクライアントになってMSサーバと喋れるルータって意外と少ない?

今回の LLVM Devmtg において、AMD(R600)のTomが"京都の会社のひとから名刺もらっちゃったんだけどなくしちゃった、心当たりある方はメールくれないか?"とのこと。 lists.cs.uiuc.edu/pipermail/llvm… …って俺のフォロワさんに伝えてどうにかなるか?

mingw32-g++-4.7のthiscallとかx86_64-cygwinのLP64とか、意識的に脳内先延ばししてる件が多くてアレ。

Windows==CL.EXE と思ってるヤツとは話は合いません

未だにMS処理系特有の件をWindows云々書くメールを無意識に無視してしまう俺。

大雑把に動いてるからいいやもうw

…ばぐった…今日も夜更かしか…

Python の twisted.(中略).deferred がなかなか理解できなくって苦労したのさ…

(せめて release_34 が final になるまでは自粛してくれたのむよ…)

もし、朝起きたときに LLVM trunk が C++11 専用になってたら、十中八九俺は暴れる。

なお AMD FX 8core で5分程度。

clang は1分以内にビルドできなければならない(目標)

そして長年(??)の野望である auto-bisecting, auto-reverting を実装する季節だ。

stable timer に上限を設ける "n時間変化がなかったらビルド開始、ただし前回のビルドからz時間経過してたら stable timer を無視してビルド開始"とかのロジック入れないとアレになりそう。

buildbot の stable timer を長く設定し過ぎるといまのLLVMツリーで永遠にビルドが始まらない可能性が微レ存

今回は(今回も?)、release_34 は手動 git-svn でフォローすっか…

むしろ clang.git release_34 がいまだに作られてない。サーバ側の不手際により、 release ブランチへの変更は trunk の変更がないと反映されなかったりする。

つーかまた llvm.git release_34 が根なしになってるンすけど…

つくったものが思い通りに動くのを見るのは楽しい。

@omasanori 深読みせず安直に取っていいとオモ。

急にカルピスの原液を瓶でラッパ飲みしたくなったんだが…誰のせいだ…

どうやら clang のミスコンパイル発見。テストケースつくるべきかあすに備えて寝るべきか…

目の前で再現してるだけマシかもしれん。

Heisenbug にぶちあたって発狂中…

busybox.exe の考え方はなかった…bash.exe を取り除こうとしてたので考えが及ばなかった…

CMake の target_link_libraries() の挙動が大嫌いだ…