ToDo:
しるばーになった。
だいたい
って感じにやってる気がする。
負けるパターンとしては
このあたりか。 6,7 pool はたぶん適切に入口ふさげれば大丈夫なんだと思うんだけど、どうもうまくふさげないことが多いのがダメぽ
序盤と序盤後の戦闘負けはまぁヘタなので納得できる。
ひきこもりっ子はどうすればいいんだろうなぁ。 偵察するしかないと思うんだけど、 しかしどう偵察すればいいのか難しい。 observer で missile turret とか photon cannon を 頑張って避けつつ近付く感じですかね… あと observer とか出してると中盤の戦力増強が ちょっと遅れるので、突然ひきこもりっ子が兵出してきたりしたら恐いなー とか思ってしまうのがまた良くない。
(00:09)
最初 AS みたいな感じなのかなと思ったんだけど、
Java を Ruby syntax ぽくした物体と言うべきっぽい。 つまり速いっぽい。 なんか Ruby のつもりで使うとガッカリ感があるかもだけど、 まぁマクロあるんで Java の冗長な繰り返しはそれで防いでねー的な感じっぽい。
コンセプトはあまりに正しいなーと思った。 Eclipse 無くても Java が書ける時代が。
App Engine とかでもいい感じで動いてるっぽい。 あとは GWT あたりとうまいこと連携してくれると 嬉しいんかなーとかなんとか
しかし別に web アプリとか作りたい用事が無いんだよな。
(03:03)
http://slashdot.jp/it/article.pl?sid=10/08/31/1148237
とおもった。
あとコメント見てわらった。 「はてなのCTO」で十分じゃないのか…
しかしこれではよしき先生が目立たないdesune
http://www.sodan.org/~penny/blosxom.cgi/2010/08/31#xoogler
(03:14)
やっとこさ勝ちと負けの数が釣り合ったり。 今6連勝してるらしいのでそろそろ しるばーとかになれたりするとはっぴーかもなんだけど、 昇格条件謎らしいしなー
アカウントはもう一度ロックされたので、 パスポートとかスキャンして送ったら秘密の質問の答えを教えてもらえた。
好みの展開は rush びびりつつ兵出したり photon cannon 置いたりしつつ、 偵察に行った probe が適当にどっかわけわけわからんところに 飛行場作って VoidRay 2,3 台でなんか相手をいちびって、 あとは適当に相手の出方見つつ対空とかしてきそうなら VoidRay でいちびってる間に研究した warpgate で 地上の子をたくさん作って相手の 2nd を妨害しつつ、 こっちも作って…みたいな感じだけど、 なんか VoidRay だけで決まってしまうことも多い。 物足りない気がするけど、まぁ勝率稼ぎという意味では良い気がする
最初の守りかたがむつかしいなぁと思う。 一個目の pylon は近くで、 二個目くらいから入口封鎖に向かう感じがいいのかなぁ。 cannon も入口とミネラルとこに置いとくのがいい気がする
(03:32)
Lots of requests to publish Tetsu Soh's memory profiler on Github. I agree! #rubykaigi
どっかにコード無いんかなーと探してたらこれを見つけた。
(01:49)
というのを漠然と考えた。新しい語の導入を許すと
puts sh = "Hello, world!"
とかで一瞬で解決して、許さないとすぐに無理ゲー感がただよってくる。
ていうか hello だけなら
"Hello, world! ".display
とかでたまたま解決したりするし、ゲームとして色々成立しない。
改行を出すのにムダに苦労してみるとか…
"Hello, world!".display
yield Dir rescue eval "loop { puts ; STDERR; raise exit }"
たぶんルールは
とかか。 eval もなんか取ってつけたような感じだから禁止してもいいかも
"Hello, world!".display
yield Dir rescue END { DATA; ARGF; fail loop { puts; STDERR; raise exit } }
true
__END__
偶然だけど、 END fail raise exit と登場して、 true __END__ でシメててなんかかっこいい。
(02:40)
続き
その後
(23:57)
名古屋っぽいもの食いたい。 USB ケーブル無いから GPS 無いのが痛いかな
それはそうといろいろためになったとおもう。なんか忘れそうなんでなにか書いておく。
なんかまだあった気がするけどまぁ
あとは何度も定義読んだであろう Sort モジュールなー
これを読んだ。面白かった。
- 最初の方の暗号ってその時代に生まれてたら解けたんじゃねと思ってしまうけど解けないんだろうね。なんというか基礎教養的なものってのは案外強いんだよなーたぶん - まだ解けてない宝の地図とかあるのかーロマン - ディフィーさんとヘルマンさん (以下 DH) は別人 - DH より RSA の方が良いようだ…今一つメリットにどうもピンと来ないけど - RSA も DH も発見者は彼らじゃないそうだすげえ
(00:45)
http://golf.shinh.org/p.rb?Sort+by+Length+for+OCaml+Golf+Competition
これなんかうちに short coding とか二冊あるから 賞品とかにしたらどうでしょーとか 自分で言っておきながら持ってかえってくるの忘れて 帰省してた。
僕が優勝すればいいのではないか!
(01:07)
MacOSX のバイナリを無理矢理 linux で動かして遊ぼうとしている。 で、なんか、それなりには動くんだけど たいていのプログラムはどっかで crash する感じで、 どうも glibc の初期化ルーチン走ってないのが良くないかぁ という感じのものが多い気がする。 たとえば setlocale とかそういう。
で、 glibc を初期化したいわけだけど、 どうしたらいいかなーというのがあまりいい案がない。
とかになるのかなーと思うんだけど、 libc の初期化ルーチンを自前でリンクするとかめどい…
なんもしない main を書いて、 それを実行バイナリに落として、 必要な部分を自分の ELF binary にコピってくる… みたいな感じで動くんかなぁ。
リンカじゃなくてローダにすべきだった気がしてきた。
今からやるとするとどっちがラクかなー
(23:54)
ややこしいよなぁ…
http://www.x86-64.org/documentation/abi.pdf
これによると struct 返り値は hidden parameter でいいのかなー と思ってたんだけど、 なんか GCC の挙動違うぞ… と思って調べてみたところ、 どうも RAX と RDX に入るならそっち使う、 って感じかなー。
http://agner.org./optimize/calling_conventions.pdf
によるとややこしいなぁ…
(14:29)
devquiz の pacman とかやってみる。 ダメぽ。
おそらく熱暴走で reverse proxy の役目を果たしてた マシンが止まるという事件が 2 度ほどあったので、 OCaml meeting 前にこれは不安だろうということで、 ゴルフ場のマシンの方に reverse proxy の役割をうつした。 これでたぶん大丈夫かな…
(21:56)
http://d.hatena.ne.jp/lyrical_logical/20100819/1282232382
そういう話なんかなコレ。 pimpl 死ね死ね派として。
元の話は
// header
class C {
public:
C();
void f();
private:
class CImpl;
CImpl* pimpl_;
};
// source
class C::CImpl {
public:
CImpl() {}
void f() {
// ...
}
};
C::C() {}
void C::f() { pimpl_->f(); }
と
// header
class C {
public:
C();
virtual void f();
static C* create();
};
// source
class CImpl : public C {
public:
CImpl() {
}
virtual void f() {
// ...
}
};
C* C::create() {
return new CImpl();
}
の比較ってことなんじゃないのかな知らんけど。 pimpl とファクトリの比較って言ってるから pimpl とファクトリは組み合わせれるとかじゃなくて、 pimpl 的なことをファクトリでやる、っていう話かと想像した。 まぁいずれにせよ元の話が違っても 僕は後者の方が好きだという主張したいという話をしたい。
pimpl って何がダメってめんどくさすぎることで、 ただでさえヘッダのせいで二カ所に関数名書かにゃならんので DRY から遠ざかってるのに、 pimpl とかしたらに三カ所なってありえんというだけ。 まぁそれだけなんだけど、しかし三カ所に書くってホントありえんと思うんですよ。 単に引数一個増やすだけであちこち書き直していくとか完全におかしい。
たぶん後者の話の弱点は仮想関数呼び出しとか ヒープアロケーションのオーバヘッドくらいなわけだけど、 たぶん pimpl 使いたいと思うようなクラスを思い出してみると、 たぶんたいした個数作らないオブジェクトがほとんどなんじゃないかなぁと思う。 NantokaMgr とか NantokaController とか名前つけたくなるクラスが多いんじゃないかと。
(02:16)
| 前 | 2025年 9月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 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 | ||||
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。
_ もわ [むしろここ見て知ったよ！ < よしーき先生のべんちゃー]