はじめてのにき

_ TCO マラソン Round 1 終了

こういう画像があるので、 頑張ってどこが黒い点でどこが白い点かを推測しなさい、という問題。 プログラムは見たい行の答えを聞くことができて、 聞いた行は当然得点にならないので、 なるべく見る行数を少なくしつつたくさん正しい情報を推測できると良い。 フォントデータは与えられてるから、そのへんから推測する感じ。

僕は 4.5 行に一行ずつ開いてみて そこからそれっぽいアルファベットを適当に推測するとかそんな感じでやった。

当たり前だけど、 アルファベット一つに確定させる感じでやってたのはとりあえず良くなかったぽい。 @colun さんの twitter を読むに、 複数のアルファベットを使える可能性がある場合は、 ピクセルごとにそこが黒くなる確率を調べて そこが 50% 越えると黒とするとかが良かったようだ。 当たり前だ…

あと @colun さんがやったという、 前の行の情報から次開くべき行を確率的に調べる、 みたいなのはやった方がいいんだろうなーとは思ったけど、 どのくらい効くもんかなーというのが予想できなかったのと、 まあどうせ round 1 は通過できるだろうよ…と めんどくさくなって全然手をつけなかった。

いい問題だったと思う。 ただ解答のバリエーションが出にくい感じではあったかなぁ。 あんまりマジメにやってないのにそういうこと言うのも申し訳ない感じだけど。

まぁ round 2 行けると思うんで次から頑張ろうかと思う。 ていうか頑張らんと round 3 行けないよね…

(23:27)

_ cocotron

linux x86-64 向けに作れないかなあと適当にごにょってみた。メモ

InstallCDT は x86-64 を target にするとうまいこといかんので、 install.sh の

CFLAGS="-m32" $sourceFolder/gcc-$gccVersion/configure

を

CC="gcc -m32" $sourceFolder/gcc-$gccVersion/configure

とかに変えたらとりあえずうまくいった。

Foundation, CoreFoundation, CoreServices, objc の xcodeproj に対して、 Linux-i386 な target を複製して Linux-x86_64 を作る。 で、 i386 になってる部分を全部 x86_64 に変える。 依存関係も作りなおす。出力先ディレクトリとかも変える。 Foundation に関しては march=i686 とかも消す。

これでたいていのファイルはコンパイル通るんだけど、 objc_msgSend 系の色々がアセンブリで書いてあるんだよな… 一見してやってることは簡単そうだからなんとでもなりそうではあるけど、 めんどくさい…

(21:53)

_ LLVM の謎

http://pumpkinsugar.posterous.com/llvm-coding-standards

LLVM/Clang はあんまり読むとかはしてないけど、 なんか追ったりはした… 主に ld-mac が起こす謎のクラッシュの追跡だったわけだけど。

なんか LLVM とか新しいプロジェクトだからコードが綺麗に違いない! と思ってみたら意外なことに色々よくわからんみたいなのがあって 余計がっかりみたいなのはある気がする。

それと LLVM が損してるのはやはりこう 変数名が大文字スタート関数は小文字スタートってのは 慣れてなさすぎるというのも。 普段はプロジェクト内でそろっていれば OK とか嘘ぶいてるクセに 結局そいうもんかなーとか。

にしてもなあ…

なんか普通に Tmp とか Str とかいう変数がそれなりに 長いスコープで使われてたりするし、 あとそもそも小文字大文字はルールが場所によって変わってるよね。 ループ変数だけは小文字とか、 ぱっと探して見つけたのでは include/llvm/ADT/APFloat.h なんかは構造体の名前、 enum 、 変数名と全て小文字スタート、 と思ったらたまに大文字スタートの変数もあるな…

それとファイルの場所特定しにくいのもすごい。

include/llvm/FooBar と lib/FooBar はだいたい対応するようになってるんだけど、 include/llvm/ADT はあるけど lib/ADT は無くて lib/Support に実装入ってるとか、 まあユーザのためにヘッダだけはとりあえず場所変えたけど 実装の場所いじる気力が無かったのかな…とか思うわけだけどひどいとおもう。

他には include/llvm/Attributes.h と lib/VMCore/Attributes.cpp が対応してるとかですね…

(23:19)

_ そして

上のどれでも無いことをとりあえずやった…

https://github.com/shinh/w3m/commit/7eb2984ce3a61ceb7ec17b37a943c6c9ae3cbc7c

(09:29)

_ 変ゼミ

http://kc.kodansha.co.jp/hensemi/

こんなもんアニメ化するんかって感じだな… はじめてニコニコポイント買ってしまった。

(21:15)

_ 0x is not that bad

会社のホワイトボードに

[](){}();

とか書いてあって、 C++0x のラムダキモいとかいう話をしてたのかなぁと思った。 でもなんか思い出してみると記号だけで似たようなもん書ける言語ってのは いくつかあって、

->{}[]
->{}()
(\()->())()

とかも書いておいた。 他もありそうだなぁと思ったけど思い出せなかった。

この手の syntax って最初に見た時はびっくりするけど、 慣れるとまぁなんでもないんじゃないかな。 むしろ

(funciton(){
  // ...
})();

みたいなコードがイディオム化している JS なんかだと、 これもうちょい短かった方が良かったんじゃないかな…とか思う。

(02:03)

_ id:hirosegolf さん

http://d.hatena.ne.jp/hirosegolf/

この人が FizzBuzz 54B かつ今 TCO マラソンで僕の一個上にいる人かな…

(11:28)

_ そのマラソンは

これ難しいなぁ…と思いつつ 適当に書いたら意外と上の方に来た。 もうほっといても予戦は通れるかな… とも思うけどまぁみんなまだ様子見だろうしな…

うーんでも結構ここから大きく得点良くするのもむつかしそうではあるなあ

(11:32)

_ 式を dump したい

よく式を途中のローカル変数の情報つきで dump したくなる。

例えば

a = 42
b = 90
c = 20
dump{(a + b).to_f / c}

とかしたら

6.6 = ((a=42) + (b=90)).to_f / (c=20)

とか出る、というような。

Ruby なら書けるかなあ…ということで書いてみた。

https://github.com/shinh/test/blob/master/dump.rb

呼び出し方が

 binding.dump "(a + b).to_f / c"

とかいう感じで文字列で呼ぶ感じになってしまったのが残念。 なんか構文木オブジェクトとか取れるといいんだろうね… あとインスタンス変数とかグローバル変数とかも対処した方がいいし、 途中のメソッド呼び出しとかも対応するといい気もするけど、 まぁこんなもんでもそれなりに良い気もする。

C++ ってか Boost::lambda ならこういうのできていい気がするな…

http://blog.livedoor.jp/sasata299/archives/51382345.html

を参考にさせてもらった

(16:51)

_ FizzBuzz conference

http://partake.in/events/8c2cd95b-b6d4-4d9f-917e-a98ba9aafd25

万が一 ksk さんが消えると人類は二度と 50B FizzBuzz に到達できないのではないか… とか意味わからんことを話してたりしたんですが、 まぁどっかで区切りをつけてどんなコードか見せてもらいたいもんですね… ということでページを作ってみました。 日程は特に反対が無ければ6月あたりかなぁと思ってます。

まぁ興味ある人は適当に参加表明していただければと思います。

しかし kinaba さんのせいで次の参加者の発言が規制されているな…

(21:55)

_ でー言語

http://partake.in/events/feac18f7-0b78-4129-92c5-ad0cce8feafb

に行ってきた。 SC2 の MVP vs MKP が気になりつつ遅刻しつつだけど… 後で見たがいい試合だった。

でー言語は久々に見てもこう、 楽しそうというか見るからに TODO がたくさんある感じで、 正直これだけ放置してても僕的にはあんま実用的になってないなあ…という感じというか。 これは褒め言葉で、つまりなんかあれこれ工夫するスキがありまくりっていうか。 maloader 飽きたらやってみたいなぁとか思ったことが色々あった気がする。

見てたのはデバッグしやすくなっただろうか…ということ。

• 例外飛んだ時の backtrace はあるだけマシになったけど、イマイチ。
• x64 の ABI 守ってるか、トレース用の DWARF 吐いてるか気になるので見るべき。あれ守ると backtrace が出しにくくなる的な意味で。僕のカンではたぶん守ってないので良い。
• 適当にクラッシュするコード書いて GDB に喰わせると GDB が死んだ。 DWARF4 の DW_TAG_* と D の独自 DW_TAG_* がかぶってるのが良くない。これはどう考えても D が DW_TAG_lo_user 以降の数値を使うべきである…とりあえず簡単な変更でなおることは確認した。
• -g じゃなくて -gc をつけるとクラッシュしない、が、これは string[] の内容見るのが大変になるので実用性が極めて落ちる。
• たぶん、 DWARF 拡張するとかじゃなくて、 go とかみたいに C の構造体として見せるべきだと思うね…
• this の EAX 渡しと GDB って整合性取れるんだっけ。これも調べるべき。
• Mac ではそもそもデバッグ情報が全く見れないらしい。たぶん dSYM になってないから…と思って Apple GDB ながめたけど時間切れ。

他のメモ

• 相変わらずコンパイルが速いのはいい。
• GC はあんま良くなってないらしい。パッチはあるけど…みたいな状態らしい。 fork する concurrent GC とはいかに。
• closure とか作る時に backtrace つけたいから言語ランタイム自体が backtrace 取れるサポートして欲しいとかなんとか言った
• かぶってるシンボルが weak symbol になってなくて plugin がやりにくくて困るとのこと
• walter たんもプログラマが知るべきなんちゃらに書いてるらしい。それは読まないと…
• GDC がいつのまにか他の人の手によって追いついてるらしい。
• D の例外ってどうなってるんですか setjmp/longjmp ですかと聞いたら windows は SEH 使ってるとのこと。そして僕はそのことを知っていたはずなのである… http://www.dsource.org/projects/tango/changeset/2569
• ライブラリの混乱っぷりはマシになったけど相変わらず色々スキがある感じなのかな…
• さすがに tango は死につつある…らしい? しかし日本は phobos ラブに偏ってるからな…
• D on Rails があれば流行るのではないか、という話に、 Rails は Java のアレっぷりにみんな辟易としてる時に颯爽と出てきたから流行ったのであって、今 D で作っても別にキラーアプリにならんのじゃないかなぁとか言った。今みんなが困ってること…ということで、
  • JS …が最初に思いついたけど、 coffee script とか GWT とかまぁ色々あるからイマイチかなと
  • iPhone と Android 両方サポートとかめんどいから D で書いたらどっちのアプリもできますみたいな不思議な仕組みがあれば…とか
  • まぁなんか地震とか停電を解決しますとか彼女ができますとかそいうソフトウェア作れれば流行るんじゃないかな
• DMD 読みやすいと主張したら反論され気味だった。贅沢を言いすぎではないか
• evalu8.c というファイルを見てちょっと面白いなと思った
• 個人的には D で書きたいものがなんもないのがあれだなぁ…最近 C/C++ じゃないと書けないものと Ruby で書けるものばかり家で書いてあるから。またゲーム書けって話なんだろう…
• そもそも一般的な話としても、なかなか適した用途というのが思い当たらないんだよな
  • ずっと動かし続ける系アプリは GC つきの言語だとこわいという妄想によりサーバは却下
  • それなりにパフォーマンス出た方がいいという考えあたりから、 GUI アプリとかモバイルとかかなぁ
  • ある程度デカいデータ処理やる自然言語屋さんとかには向いてる気がするな。書き捨てに近いコードだけどパフォーマンスが出た方がよくて、文字列処理が得意だと嬉しい。うーんなんかすごい mapreduce 向きだったりしないだろうか…

なんか僕はいつも backtrace backtrace とわめくと言われたのだけど、 そうだと思う。 実用性って観点で見ると、 backtrace と printf デバッグって プログラム言語に本当に重要な機能だと思うんだよな。 いつも言ってるけど。 printf デバッグっていうか Ruby の p がコンパイル言語にもあるべき。 後者は D は静的リフレクションでそれなりにできるんだろうなと思ってたけど、 まぁできるとのこと。 よく考えると書いたことある記憶もあるな…

(18:01)

_ 理解した

RTLD_GLOBAL と RTLD_LAZY を実装する必要がある。 前者は簡単だけど、後者はどうしよう… あれって正しくやると全コード遅延ロードできるようにする必要あるしな… 次の dlsym の時に eager bind するとかでいいだろうか…

そして lazy bind の反対語は eager bind でいいんだろうか…

(04:07)

_ まろーだー

なんか hacker news と reddit に載ったらしくて まぁなんか github の watch 数とかがちょっと にぎやかな感じになった…が特に何もない。

そのへんで見る意見をぱっと見るに…

• ライセンスとか大丈夫? => 大丈夫なんじゃね
  • こいうメディアではお決まりの会話なんだなぁと
• Cocotron と組み合わせて Cocoa アプリが!
  • 今でもそれなりに大変だから、そこまでやれるとは思ってないんだよなー意義も見出しにくいし
• クロスコンパイラでいいのに
  • クロスコンパイラには色々問題あるし、何よりセルフコンパイラってラクなんだよね… GDC のクロス作るより wine dmd.exe の方がラクだし、 i586-mingw32msvc-gcc で SDL ビルドしなおすより SDL.dll から wine implib.exe して取り出した SDL.lib を wine bcc32.exe する方がラクなんですよね…
• 名前がひどい
  • SC2 の marauder さんに(日本人的発音感覚で)近い名前つけただけなんだけど、 malodor で悪臭なのね。まぁ marauder 嫌いだからいいか…

(22:41)