ToDo:
enrage のせいでこのままじゃ無理じゃねーと思ってたけど、 belial たおせた。 belial 第二を倒した段階で zoltun 同様 DPS 上げる装備に変えた。今回は LoH もいらんだろうと amulet も変えた。ただそれだと盾無しだと腕で即死で、腕全部よけてると enrage に入るので、 passive で Resolve 入れたらなんとか耐えれるくらいになった。あと primary 二つはいらんかな…と DPS と spirit 回復兼ねて sweeping wind を入れた。他はそのままで良いと感じたのでそのまま。
戦闘は、3連打じゃない腕は cooldown と付近の health globe 次第であえて受けて、回復しつつそのまま殴り続けた。ブレスは ranged の時と立ってる位置が違うからか、当たるけど威力減ってる? という感じだったので、これも受けてそのタイミングで breath of heaven の時間を延長する感じにした。あと毒沼最後の方で無敵使えるならもったいながらず発動してその時間殴った。
そろそろ enrage だなーて時間だったけど入る前に倒せたので、時間的には少し余裕があった気がする。似たような立ち回りしてるつもりなのにあんま減ってない時もあったのは、 sweeping wind と ally 使い忘れてるタイミングがあったってことかな…と思う。あと毒沼でたまたま ally が長生きしてる時とかあったりするだろうし、運ゲー感も。
そのへんの運ゲーと理想的な立ち回り (毒沼中も ally 見て死んでたら生き返す、受けれる腕は全部正しく受ける、 near death experience も使って殴る、毒沼をなるべく前で避ける) あたりをやれば DPS 12k くらいでもいけるんじゃないかな…その根性はないが。
第三の成功率は WD で倒した時と似たようなもんだったと思うんだけど、第二が安定してるんで色々ためせるし、ずいぶんラクだった。修理費は 200k くらいとかかなたぶん…
http://us.battle.net/d3/en/calculator/monk#aiXQgj!ZUT!aYbZYc
DPS16k armor2824 res357 life32719
(04:27)
ラスボスになったいうウワサの ghom 。実際なんかビビるくらい強い。ちょっとずつダメージ当たる系はゴミ装甲が目立って enrage どころの騒ぎじゃない感じ。
AH 無しで複数箇所の装備のアップデートを farm でゲットするのはしんどいんで、 AH 解禁するか nerf とかで弱くなるの待つ感じかな…だんだんやる気減ってるから待ってもいいんだけど、そうするとよりやる気がなくなるだろうな
(23:35)
ねぼけて zip に使ってしまい、展開できてしまったことに驚く。
man によると
https://developer.apple.com/library/mac/#documentation/Darwin/Reference/Manpages/man1/tar.1.html
This implementation can extract from tar, pax, cpio, zip, jar, ar, and ISO 9660 cdrom images and can create tar, pax, cpio, ar, and shar archives.
とのこと。なんともはやだなー
で、 opensource.apple.com から gnutar をダウンロードしてみるも、どう見てもそんなパッチは入ってない。あーこれ BSD 由来なんかなーと --version してみると、 libarchive というものを使ってるとのこと。
なんか windows/mac フリーソフトウェア界が有史以前に通った道を21世紀にもなってやってる感じな気もしないでもないけど、しかし linux でもこれ使えるのは普通に嬉しい気がする…
とはいえ見てみると結構歴史の長いプロジェクトのようだった
(00:29)
ghom たおした。
nerf とか入らんかったから farm だけで倒せる装備が入るの待つのがだるかったので、あっさり AH 無ししばりをヤメて安物を買いあさった。
最初は盾装備 15k くらいで戦ってて、あと1割くらいかなーてとこで enrage しちゃったので、1割くらいなら余計に殴れるかな…と思ったけど、また enrage すると悲しいので、盾やめて両手持ちにした。
DPS20k armor5482(3857+1625) res732(all:474) life28101 LoH600
http://us.battle.net/d3/en/calculator/monk#biXkgY!XUY!cYbaYc
買ったものは
ざっくり 1M くらいか。それでずいぶん強くなるなっていうか正直もうこれでクリアできる装備なんじゃないかな…
変わらなかったのは胸腰腕肩。
(00:47)
ついでに siegebreaker 倒した。 reflect damage ついてようが普段から LoH ついてるモンクからすればザコもいいとこだな…
act3 のこの部分元々簡単だったけど、それにしても簡単だった。どうもいい装備買いすぎた疑惑がありますね…目についたものを転売してたせいで金減るどころか増えてるんだけど…
そういえばウワサの vault てやつを回ってみた時に NV5 のまま belial ラクに殺せたりしたし(まあこの子は enrage さえしなければたいして問題じゃない)。
(01:36)
cydaea はなんか強かった。 FoT 的に細かい敵たくさんは案外めんどい。 NV 捨てて、 sweeping wind 入れて何度かやったら勝てた。倒した時はもういけるかとゴリ押ししたらかなりギリギリ感があった感じだった…
http://us.battle.net/d3/en/calculator/monk#abXkgi!XUY!acbaYY
azmodan は初見普段ビルドで余裕。 melee 的にはザコだな…まあ血の池弱くなってるんだよねたぶん…
iskatu もなんか強かった。細かい敵たくさんはやはりきつい。 FoT がきついので、 cripping wave とかを久々に入れてみる。あとはザコ多い戦闘では恒例の sweeping wind
http://us.battle.net/d3/en/calculator/monk#WbXkgi!XUT!YcbaYY
(14:19)
rakanoth 。結構強い。 sweeping wind 足したり防御重視にしたり。 sweeping wind はどうも普段からあると良いと思うんだけど、 primary 二つないとザコ戦しんどいんだよな… enchantress のスキル変えてみたりも。
http://us.battle.net/d3/en/calculator/monk#aiXhgj!XUT!aYbaYc
MoE と ally 頼りで殴り続けて、喰らいはじめたら breath of heaven 使って逃げるか、 serenity で殴り続ける。両方 CD の時は逃げ続ける
(16:07)
http://shinh.skr.jp/m/?date=20120703#p01
で書いた libarchive の tar は zip 内の symbolic link をちゃんと溶かしてくれないのであった…
(16:27)
モンク終了。
izual は WD の時はあれだけ苦労したのにザコだった。普段のスキルのまま倒せた。
diablo もまぁ長いだけでザコ…なんか第三形態って攻撃かなり激しくなってるんだな WD の時は常に離れてるから気付かなかった…スキルは rakanoth と同じ。
装備とかは ghom からなんも変わってないと思う…本当に ghom さんラスボスだった…
DPS16k armor6779(5339+1340) res708(all:450) life27961 LoH691
ghom の時と違う理由は単に二刀流か盾かってだけ。装備は全体的に spirit regen 無くてキツいな…という感じだった。
(22:53)
の話を聞いて、 GCC でコンパイルしたコンパイラは大丈夫で、そのコンパイラでコンパイルしたやつはまだ大丈夫だけど、次でクラッシュするバグがあった、みたいな話をしていた。
で、 TCC であそんでたとき似たようなのがふたつあったなーと思ってたんだけど、片方しか思い出せない。そっちの片方はまだ2世代目が3世代目をビルドする時のやつで、こんな感じだったと思う。
INT_MIN 以下の値のリテラルの扱いがバグってて、なんかデカい値になっちゃう。 GCC はそんなバグ持ってないから1世代目は大丈夫。2世代目はそのバグを持った1世代目コンパイラでコンパイルされているので、コード中に一箇所だけある INT_MIN 以下の値が出てくるぶぶんがおかしくなってる。そのデカい数字が何でできてるかっていうと、 32bit 相対 call で届くかをチェックする部分で、届かないから trampoline 作らんといかんのに作らないから届かなくて SEGV する、っていうような感じだった。
このクラッシュは記憶がたしかなら3世代目を tcc -run で実行してる時、つまり
tcc -run tcc.c -run tcc.c -c hello.c
的なことしてる時しか当時は再現しなくて、小さいプログラムだと件のチェックに漏れるような種類の長距離 call が出てこなかった、とかなんとか。このへん記憶あやしくて最後に走らせるコードは tcctest.c でも再現してたかもしれない。
このバグ再現させるには JIT 生成されたプログラムから負方向の 32bit を越える距離の関数 call をする必要があって、これが小さいプログラムだと起きない。なんでかっていうと、プログラムは malloc された空間に置かれてて、 glibc の malloc は小さい malloc に対して最初のうちは 32bit におさまるアドレスを返すから。でも、デカいプログラムだとデカい malloc をする必要があって、となると 64bit なアドレスがかえってきてやっと問題が再現する…とかいう感じだったと思う。
うーんでも詳細イマイチ覚えてない…
それをゴマかした時の変更はこれだったんだと思うんだけど、ただこれは上記の話をきちんと説明しきれてない気がするんだよな…
http://repo.or.cz/w/tinycc.git/commitdiff/51a7f163ad4a363953ae744afbc12cd7bd381097
あともう一個はよくある 32bit 命令を 64bit アドレスに対して使っちゃってた、っていう系だと思う。この手のバグは頻繁に起こりすぎてて、世代を経ると発生するみたいなヘンなヤツでもイマイチ詳細を覚えてないんだよな…
(00:04)
http://shinh.skr.jp/m/?date=20090416
微妙な記録を見つけた。
tcc -run tcc.c -run tcc.c は tcc -run tcc.c -run tcctest.c より先に動いたらしい。で、前者の方動かすのに最後に必要だった変更はそのデカい int literal だった、っていうのは、時期的にも正しい記憶だったようだ。
(00:11)
http://blog.64p.org/entry/2012/07/11/224008
via https://plus.google.com/102550604876259086885/posts/AnEoGQexUcG
scons なんて始まってもいねえよ! ってのが僕の感覚だなあ、たいしてしらないけど、必要じゃない機能ばっか充実しているという mukai さんのイメージに賛成する感じ。
scons に関していつも言ってる悪口に、ファイルが本当に変更された時にだけ依存関係をビルドしなおしてくれるという便利な機能がある。
これはどういうことかというと、 hello.c から hello.o と hello を作ったあと、 hello.c を touch してもビルドしなおしてくれないと。 stdio.h とか書きかえた時とか、そういう特殊なことしてるからわざわざ touch してるわけで、なんか余計なお世話としか言えない。で、しょうがないなと hello.c の末尾に空行を一行足したりすると、 hello.o はリビルドされるけど hello はされない。何故なら hello.o のチェックサムは変わってないから。
そしてその余計なお節介にしか思えない機能が自慢気に書いてあるあたり、なんかすくなくとも僕の感覚とはずれてるなあ…としか思えない。
http://www.scons.org/doc/0.98.5/HTML/scons-user/c779.html
で、まーそういう余計なお節介があると知ると、あの遅さがそういう余計なお節介のせいではないか…とか思われて、どうしたもんかと思ってしまう。
ただ、一応今ぐぐってみると、色々速くする方法はあるみたいだ…ただ make 系ツールのデフォルトの挙動を遅いものにするセンスからして、このへん頑張っても make 程度にも速くならないんじゃないかな…とか思ってしまうよね…
http://www.scons.org/wiki/GoFastButton
あといつも言ってることだけど、ビルドシステムってのは、こうなんか、人々に再生産させたくなるようなオーラがただよってるらしく、なんか許しがたい数既にあるので、 make にムカついて僕の考えた無敵のビルドシステムを作ろうとしてる人はコレを見て考えなおしてほしい…
http://en.wikipedia.org/wiki/List_of_build_automation_software
mukai さんも書いてる通り、 automake/cmake/gyp あたりは一つ上のレイヤにいるので、そのへんはまぁ OK 。 autoconf のレイヤは特に代替があまり作られてない気がするけど、まぁ Unix 乱立がおさまりすぎて、ああいうのの時代は終わりつつあるのかもな…
ところで autotools はひとくくりにして、嫌ってる人が多い気がするけど、僕的には autoconf は必要で automake は死んでもいい派。 autoconf 無しだと、わりと色々詰んでると思うんだけどな… cmake は autoconf 的なことを少しだけしてくれた気がしたけど、どうだっけ…
libtool は実際問題正しくライブラリ用の make 書ける気がしないから、本質的じゃないけどあれも必要かな…とか言ってると automake 無しで libtool 使うの大変とかで必要になってきて、こまるわけだ…一度 automake 抜きで autoconf/libtoolize 使うとか練習してみるのも良いかもしれない…
(00:57)
sucks シリーズ、 JS はあまりよく知らないのにすごいのがいっぱいあるから書いてなかったけど、ちょっと書いてみた。
http://shinh.skr.jp/h/?JSSucks
(01:23)
i@u6 0:46 [master]
> cat non_static_data_init.cc
struct S {
int i = 42;
};
i@u6 0:46 [master]
> g++ -std=c++0x non_static_data_init.cc
non_static_data_init.cc:2:11: 残念ですが未実装です: non-static data member initializers
non_static_data_init.cc:2:11: エラー: ISO C++ forbids in-class initialization of non-const static member ‘i’
zsh: exit 1 g++ -std=c++0x non_static_data_init.cc
そ、そうですか…
(00:47)
最近思うことは飽和連鎖量が足りないなっていう。で、ぐぐってたら最初に出てきたやつ
http://www.geocities.co.jp/Playtown-Domino/6390/Bulletin/lecture/lecture6.html
これが、モロにGTR系なのに
C B CC BAA BAC
とかいうキツい形が最初に思いついてダメだなぁとか思った。ちょっとゆっくり一手一手考えるみたいなことした方がいいのかな…
あと初手で
BA BBA AAC
とかできた後に AB AC AD どれが来てもわりと悩むことが多い気がするなぁと思った。ネクスト考えないと、どの場合も A を5個消ししちゃうのが良いのかな… AC AD は2列目に立てるのもいいと思うんだけど。
(01:02)
A BC CCA BACD BBACDC AACCDC
の ABAB が
A AB BCB CCA BACD BBACDC AACCDC
とかになりがち。
BAB CAB CCA BACD BBACDC AACCDC
なら全然よいということを考えると、左端のフタが一つってのがイマイチ系なのかな…
(01:07)
いつもメモり忘れるけど、このモードを使うと Befunge のコードが書きやすくなる。
しかし自分ではっつけた結果をよく見ると、 contest2.map で C++ コードが befunge のコードに負けてやがってうける。
(21:56)
kinaba さんの動画ぼんやり見ててソルバというかシミュレータのバグに気付いた。
トランポリンの入口入った時に同じ出口に向かうやつ全部消えるってやつ、消さなくても次入ったら消える感じでいいかなーと思ってたけど、上に乗ってた石は動きだすべきなんだね…くそう完全に正しいの作れたかなーと思ってたのにがっかりだ。
これくらいはまぁ大変だけど実装できた気がするな。つっても1時間くらいはかかるだろうから、きわどいところだなー。
C++ より次元が多くてすばらしく見える Befunge 欠点は変更がしづらいことで、基本一度書いたコードの位置を移動させようとすると、多大な苦労を強いられることになる。特にメモリレイアウトとか変えようとすると死ぬので、最初にだいたいこういう感じで書こう…と決めた通りになるべく進めたい。
読みにくいのも問題といえば問題で、あーあそこバグってるなーと思っても、実際バグってるコードを探すのが結構大変。たった100行程度のコードなのに! 普通はそういうのをふせぐためにコメントを書いたりすると良いわけだけど、コメントがこれまた書きづらい。というのは、コメントに副作用があるのが問題で、ここは絶対に実行されてない、と確信を持つのに時間がかかるし、将来的にここを通したくなることは無い、って言える場所が少ない。例えば、
> このへんからメインループがはじまる
>
| ゴール判定のためにラムダの残り数を数えるコードがこのへんにある
goal->@
^ 1ターンが終わると端を通って戻る
みたいなコードがあって、上の例だと親切のつもりで書いた goal ってコメントが、 g は Befunge では実行できる命令なので、特にエラーも出ず、スタックの長さが突然変わることになる。この例みたいな重要なコードパスならまーすぐ気付くだろうけど、あんまり通らないとことか、あるいは今トランポリンを集中工事してるんだ、って時に洪水のとこがバグったりすると、すごい遅れて気付くことになる。というわけで今集中してるとこ以外はいじらないのが得策で、コメントもほとんど書けない感じだった。一応、未実装のとこは付近に空間ができがちなんで、 @ で潰して近くに文字列置いたりはしてたけど。
うーむ残念だ。他にもバグあったりするかなぁ…
(00:43)
README が文章も typo も無茶苦茶ですがな。英語がうんぬん以前に論理的につながって無い系。
こう疲れてるんで、 README は後から提出できる感じにしてほしいよね…
(01:21)
3日間聞いてたのは、ウテナ→ミク→ぷよm@s という感じだった。基本的になんかやかましいのが鳴ってると集中できるんだけど、ウテナとかミクずっとはさすがにうざい。ていうかミクはわりとすぐにつらくなってやめた。
ぷよm@s は色んな音が流れつつ、たまにやかましいのが流れるのが僕的には作業向けなんだけど、丈が短いからすぐループしはじめる。別な part に移動したらいいんだけど、今回は細心の注意が必要すぎる作業をしてたので、結果としてなんかずっと同じ曲聞いてた気がする…
それで思い出したんだけど、 part27 のあずささんの連鎖がいつ見てもすごいと思い出した。コレの11手目。
http://ips.karou.jp/simu/pv.html?_0uk8iiSkCukaiucgkwkIcgcKMKW-S1
via http://unknown72.seesaa.net/article/235037702.html
フツーに考えるとこういう12手発火5連になる気がする。作中で指摘されてたのは4+5の4ダブで、初代だとそっちの方がいいんだろうけど。
http://ips.karou.jp/simu/pe.html?_0uk8iiSkCukaiucgkwkIcIcaMKW-S1
(01:50)
こういうマップを妄想してた。
###L### # \\\ # # # # # # # #* # # * * # # * # # # # # #* # # # # # # *# # * * # # * # # # # R # #######
僕の AI に解かせてみたところ、なるほどこのロボット頭で岩止めれるのか…と気付いた。
(01:56)
2時に寝て8時に起きてしんどすぎると二度寝して、11時くらいと12時くらいと1時くらいと2時くらいでそれを繰り返して、明日からアメリカだから休もう…とメール書いた。で、また3時くらいでそれをやって、その時飯を喰って、あと2回そういう繰り返しをして今に至るがまだ体だるい…
とりあえずそろそろ準備しないとな…
(19:41)
http://herpolhode.com/rob/utah2000.pdf
読んだ。まーそうなんだろなっていう。よくわかってないけど CS とか半分くらいはそろそろ大学でやることじゃないんじゃないかな…てのは割とずっと思ってることだけど。
計算量とか数学系は続けりゃいいと思うし、科学技術計算のための大型計算機とかもやりゃいいと思う。ただシステムプログラミングとかは、もう企業にやらせりゃいいんじゃないかな…ていう感はある。12年前の rob pike の苦言を見て、そんな感じなんだろうなあと今思うてことは、たぶんあんま良くなってないんだろうな…
(21:43)
http://www.cs.dartmouth.edu/~doug/mdmspe.pdf
via http://research.swtch.com/qsort
「quicksort の最悪計算量は O(n^2) ですよ、でも pivot のとりかたとかでだいたい大丈夫にすることはできますよ」、ってのはよく言われる話だけど、実際 quicksort が n^2 になるようなデータを作る方法を考えてみた、っていう話。
作りかたがちょっと面白くて、 qsort を実際に呼んで、 callback で呼ばれる比較関数で小さい数字から少しずつデータを確定させていく、みたいな。
このコード、 mac とか linux で実行してみると n^2 にならない。 russ cox によると glibc の qsort は実際は merge sort らしいからそういうもんらしい。 mac もそういう感じなのかな。 N が小さい時はわりと n^2 ぽい挙動してるけど…
ぱっとコード見た感じ、 2*(log(N)-1) 回越えて再帰する時は heapsort する、みたいなコードに見えるかな。まーなんとなくわからんでもないし、あとまぁそれならそういう挙動するかな的な。
自分で適当に qsort 書いてみて antiqsort に渡してみたら、モロに O(n^2) になった。おもしろい。 qsort は C だとっていうか余計なメモリ使わない実装は結構むずかしいと思ってて、昔書いた時はすっと書けなかった気がするけど、今回はそんなに苦労しなかった。全然テストしてないからあってるかは知らんけど。
void myqsort(void* base, size_t nel, size_t width,
int (*compar)(const void*, const void*)) {
char* pivot = (char*)base;
char* b = pivot + width;
char* e = (char*)base + nel * width;
char* buf = (char*)malloc(width);
size_t lc = 0;
while (b < e) {
int r = compar(pivot, b);
if (r >= 0) {
b += width;
lc++;
} else {
e -= width;
memcpy(buf, b, width);
memcpy(b, e, width);
memcpy(e, buf, width);
}
}
if (lc) {
memcpy(buf, b - width, width);
memcpy(b - width, pivot, width);
memcpy(pivot, buf, width);
myqsort(pivot, lc, width, compar);
}
free(buf);
if (nel - 1 - lc)
myqsort(b, nel - 1 - lc, width, compar);
}
(16:59)
アンタのコードは大きいマップで大丈夫なの? と聞かれた。いい質問だなぁと思ったので、 tanakh さんとこのチームのリポジトリにランダム生成されたマップがあったなーと思い出したので、適当にやってみた。
https://github.com/tanakh/ICFP2012
結果としては、 128 と 256 くらいはまー一応 positive なスコア返す結果を出してるみたいだ。 1024 は10秒くらいで切り上げるとなんか 1byte とかの結果出してて、つまりとなりの lambda 取っただけ、って感じですかね…もうちょい待つとまぁそれなりに長い答えが出たり出なかったり。まぁでも正直動いてることに感心、ってだけの話ですね…
一応画面の更新は Growth のタイミング以外では全体をなめないようにしてあるんで、 befunge とはいえ、まぁまぁな速度で動いてるはずなんで、まーそんなもんかなー的な感じ…
(15:43)
4人席で2人で昼飯喰ってて、外人が寄ってきて、なんか聞く。文脈的に、「この椅子持っていっていい? 」か「この椅子誰か使ってるわけじゃないよね?」とかそんな質問である。実際僕の漠然としたリスニング能力も特にこの仮説を否定しない。
でこのへんで僕は投機的に yes と言ってしまう。質問がどっちだとしても、日本語だと、「うん」が正しい答えだから。で、言ってしまってから、ああ否定質問に、日本語で言う「うん」と言うには No という必要がある、っていう超基本的なことが頭によぎって、しまった No と言いなおさなきゃ、でもそれ以前にそもそも大本の質問は後者なんだっけ…とか、そのあたりでこう脳は全力で考えてるもののなにか言わなけりゃ、ということでタイムアウトした時の処理が走ることになる。タイムアウトの処理は比較的単純で、前回発話した単語からハッシュをひいて、その後にマルコフ連鎖的な意味で一番頻度が高い単語が出てくる。 "Yes" と既に言ってしまってるから、そのあとの単語は人工無能的には当然 please である。
この yes please というのは論外だってのは最初からわかってるし、そもそも sure とか go ahead とか言っときゃ無難だったのはすぐわかるんだけど、しかしこう既に愚かな発言をした後であって、はてどうしたもんかと思ってる間に相手は椅子を持ち去ってくれて、特に問題は起きない。いやあ相手が適当にこっちの意図を組んでくれる人で良かったなーと思うんだけど、 google ではたらいてる人とかはこういう意図を組んでくれる確率が非常に高くて、まあなんだかんだで頭いい人達だってことなのかなぁとかよく思う。あんまそれに頼って意思疎通するのよくないよね…
(15:19)
あと、なんかこう、 I always uses とかよく言ってしまう、って話をした。 uses は当然 use が正解。こういうミスをする理由もまたマルコフ連鎖で、僕の中では I or you なら動詞は use で、「それ以外」なら uses 、ってのが結びつけられてる。この時なんでまちがうかっていうと、 always がはさまってて、それは「それ以外」だから uses だろう、みたいな、ここまではほとんど考えてないレベルでの脳の反応だと思う。
でまあ、これはべつにひとつ前の話と違って、まぁぶっちゃけ間違っても問題なく通じるから、単純にほっとくと良い。言いなおしたりするとかえって混乱を招くから、言いなおすべきじゃない。そのへんはわかってるんだけど、しかし頭の中では「あー今 s/uses/use/ だなー」とか考えちゃう。それはまぁ日本語とかだとそんな問題なくて、多少ヘンな喋りかたしてしまって(こいうのは敬語がからむと結構あるころで、敬語で言うべき動詞を丁寧語で言っちゃった時とかに一瞬考えると思う)もまぁそこまで会話の流れに影響を及ぼさないんだけど、英語でこの手のミスをすると、「あーしくった!」「今のusesはuseと言うべきだった」「あーalwaysがはさまったせいだな!」とか、そいう思考が脳をかけめぐってしまう。でも、英語喋ってる時とかは少ない脳のCPUリソースが全部英会話に行ってるわけで、かつ全ての思考を英語に使わないとキツいわけで、比較的重要でないs/uses/use/問題とかにCPU時間を使ってる場合ではない。でもなんかあれこれ考えてしまって…みたいな感じで、よく詰む。
(15:33)
LLVM に投げてた趣味パッチが submit されたぽい。
http://llvm.org/viewvc/llvm-project/?view=rev&revision=160899
こっち見るとわかるのはこれのせいで ICFPC に 15 分ほど出遅れたということですね…
http://llvm.org/bugs/show_bug.cgi?id=13351
内容はしょうもなくて、 GCC だと入ってるけど LLVM は入れない dwarf の情報をひとつ入れただけ。 binutils がそれ使って読まなくていいとこの読み飛ばしをやってるんで、できたバイナリを addr2line するのが10倍くらいはやくなったりする。
テスト結果変わるから修正したりテスト増やしたりしてて気付いたんだけど、 lit とかいうテストツール使ってるんだなと。ぱっと見 dejagnu みたいなもんなんだけど、こういうテストツールみたいなのはプロジェクトごとに再生産した方がいいのかもね…とか。
(12:43)
leonid 先生と会う機会があったので4時間とか喋ってた。印象はなんかこの人なんでもよく覚えてるな…っていう。色々興味深い話を聞いた。覚えてるので面白かったのは、
http://golf.shinh.org/p.rb?Verhoeff+Algorithm
の問題。これ python が異様に短いんだけど、これにはタネがあるっていう話。これ出題した SeeNoEvil さんは短いコードを submit してあったんだけど、他の誰もタネに気付かないからヒント、ってことで SeeEvilRedBalloon って名前で投稿したと、で red balloon は base128 のデコーダ書けって話で、こっちの問題のテストケースを base128 で溶かすと python コードが出てくるからそれを exec するだけ…て話らしい。おもろい。
で、なんか coding session みたいなのすると楽しいんじゃないかってことだったので、いいねってことで、今度の月曜のたぶん19時くらいに問題投稿して1,2時間程度の勝負をしようみたいな話になった。日本時間だと火曜11時? 参加しにくそうですが暇な人は競ってくれればな…と思います。
あと言ってたのは、ペアプロでやるとかも面白そうだね、とか。チーム戦とか楽しそうではある…
(14:13)
についてなんか書こうかと思いつつ、特に何も書くことがないっていうか、どう書くとまともな説明になるのかよくわからない。「libc は strip されてるからバックトレースにシンボルが出ないんじゃ」みたいな頭痛が痛くなる発言をちょくちょく聞く気がするんだけど、何をどう説明すりゃそのへん系統だてた説明になるのかよくわかってない。
まー素直に最近僕が学んだことみたいなのをだらだら書いてくと良いのかもしれないんだけど、今ひとつ基本が浸透してないジャンルなので、それはそれでこう全く関係ない反応とかあるとしんどかったりも。
(13:18)
Seed というのが優勝した。この人は GSL 的には今年入ってから Code A/S の下の方に一瞬あらわれては死んでる感じだったのが、なんか突然優勝した。まぁ正直相手の運も良かったんだと思う。
この人は半年だか1年くらい前の GSTL でかなり衝撃的な感じの4人抜きだか5人抜きだかをやったので、はやく Code S 来ないかなぁと思ってたけど、すごく時間がかかってしまった。俺はアイツだいぶ前から知ってるぜ…みたいなことを言いたいわけだけど、しかし SC2 とか今でも見てる人の半分くらいは優勝する前から知ってる気がするし、そして韓国的にはこの人 SC1 の時からやってたらしいし…
決勝も P やってる身としては面白かった。 PvP は他の race の人からするとつまらんらしく、相手側の MC の方が人気あることもあるのか、結構イマイチだったーと言ってる人多かったけど…
思うに PvP だけ "greedy" の定義が違うんだと思う。 tech を進めのが他のマッチアップにおける expo くらいで、 fast expo とかは double expo くらいの感覚な気がする。昔は 4gw 以外の戦略は全て tech が進めるという意味で greedy で、本当に 4gw しか無いのはつまらなかったと思う。でも今はラッシュ多いとはいえ、色んな種類の rush が増えて、少し tech が進めつつやる rush が多いので、 allin 要素が少し少ない…と思う。
最近の新しい人だと Symbol ってのが良いようだ。なんかまぁ普通に強いし、いろいろスタンダードに正しい感じのことしてる気がする。 muta より infestor 多用ってのも今風なんだと思う。
でもそんなのより Freaky というのが良い。 infestor が好きでしょうがないらしくて、何に対しても mass infestor で対抗する。当然弱いので Code A/S には来ない…でも GSTL では NSHoSeo の選手層の薄さのおかげか、結構出てるぽい。
あとはこの MKP の CC first vs 6pool に感心しましたね…
http://www.gomtv.net/2012gsls3/vod/67627
(11:03)
http://shinh.skr.jp/m/?date=20120728#p02
の続き。
今日日本時間朝11時から2時間ほど、Rubyスピードゴルフ勝負をしようということになりました。普通に2週間問題として出題しますが、参加する人は自主的に (2hrs) という suffix を名前の後ろにつけて参加する感じで。その後は suffix を勝手にはずして縮めていけば良いです。 Ruby 以外も大歓迎ですが、競争する相手がいるかは残念ながら謎です。とりあえず3人は参加者が確保できてます。
ゴルフとか久しぶりっていう人僕もそうなのでぜひ。
問題はたぶん perlgolf にもあったマインスイーパ。サイズは違うけど。でもはじまるまで考えないでください。
(08:40)
| 前 | 2012年 7月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | 3 | 4 | 5 | 6 | 7 |
| 8 | 9 | 10 | 11 | 12 | 13 | 14 |
| 15 | 16 | 17 | 18 | 19 | 20 | 21 |
| 22 | 23 | 24 | 25 | 26 | 27 | 28 |
| 29 | 30 | 31 | ||||
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ lrlj [ghom ほんとに強いですよね…まだ倒せてないです…]