開発イテレーション偏重 - 兼雑記
開発イテレーションを早くすれば、かなりの問題が勝手に解決される、と信じています。なんか最近、他の要素を軽視しすぎていたり、特にイテレーション速度に影響しなさそうなことすらしている気がしていて、信仰とかのレベルかもしれない、という気がしてきたので、ちょっと書いてみようかなと。主に C++ の話です。 仕事とかしてると良い判断力が求められたりしますが、判断というのは結構難しいですよね。アプローチ A と B で悩んだ時に、手が速ければ両方できたりします。開発イテレーションを無限に速くすると、必要とされる判断力はゼロに漸近していきます。やったね。 2手で変更の正当性を高速に確認できるようにする make (かその他のビルドコマンド)てやったらビルドができて、 make check (かその他のテストスクリプト)てやったら遅くないテストが全部走る、という体勢が好きです。試すためにはあっちのディレク
ELVM Compiler Infrastructure - 兼雑記
最近作ってたオモチャがだいたいまとまってきました。 https://github.com/shinh/elvm 第12回 kernel/vm 勉強会で発表した時のスライド: http://shinh.skr.jp/slide/elvm/000.html これは何かというと、前作った bflisp を改良したり整理したりしたもので、 C 言語をシンプルな中間言語 (EIR) に変換する改造 8cc と、その中間言語を Brainfuck をはじめとした他言語に変換するバックエンドから成り立っています。 bflisp との差分は、 Brainfuck 以外のバックエンドを追加しやすくしたり、バックエンドを C で書いて、完全に Brainfuck だけで 8cc.bf を再現することができるようにしたり、という感じです。 特に興味深いであろうバックエンドとしては、 Brainfuck, Unl
kati について - 兼雑記
https://github.com/google/kati kati について、ドキュメント書こう…と思っていたのですがなかなか進まないので、とりあえず日本語で書いてみることにしました。何書くかがあまり明確じゃないテーマなので、何書くか考えるのと英語考えるのを両方同時にやるのが少し大変で。 動機 kati は GNU make のクローンです。いずれ完全なコンパチになると嬉しいですが、なかなか難しいだろうと個人的には諦めています。用途に対して実用的ならば良いかなと。 動機としては、 Android platform のビルドシステムが、なかなかシュールな GNU make 黒魔術で構成されていて、 make が実際になんかしはじめるまでが遅かったので、そこを高速化したいというものでした。 ビルドシステムが遅いという時、まずだいたいヌルビルドとフルビルドの2点を考えます。ヌルビルドてのは生
ppencode2 - 兼雑記
Shibuya.pm で ppencode 2 についての話をしてきました。 http://shinh.skr.jp/slide/ppencode2/000.html つうてもしかしはてなんの話したらいいんだっけ感があって、なんの話をしたんだっけ。。 しっかしまあ、できたんだなーよかったねー感はありますね。 おまけというかなふたつ http://shinh.skr.jp/obf/yuine_kw.pl http://shinh.skr.jp/obf/yuine_sym.pl はまあなんかそれなりに面白い気がしないでもないが… これはまあ通常、通常てのが何かは知らんが通常、よりは少し大変で。 なんだか quote に足りない文字があったりすりがたいしたことでもなく まとめるとねむくてだるい
NaCl について - 2013-12-18 - 兼雑記
カーネル/VM Advent Calendar 2013 にさっき登録しました。需要の無さそうな NaCl について語ります。 https://qiita.com/advent-calendar/2013/kernelvm NaCl はグーグルが作ったものの中で一番好きくらいに好きなものです。理由は低レイヤコンポーネント集だから。概要としては安全に実行できる(ここでいう安全はブラウザが動いてる OS 上での任意コード実行ができない、という意味) Active X というか、 C/C++ でコードが書ける Java Applet というか、まぁそういう感じの。 NaCl はおおざっぱに言って、 検証可能なバイナリを出力するコンパイラツールチェイン (gcc, binutils, etc.) ユーザプログラムを検証して起動する service runtime service runtime と
TCC とか x86-64 とかの話 - 兼雑記
を会社でしたのでそのスライドを置いておきます。 http://shinh.skr.jp/slide/tcc64/000.html いつかこういうのまとめたいなあと思っていたのですが、特に後半とか色々グダグダになったり、記憶が消し飛んでて何に苦労したか忘れていたりと、まぁ色々適当になってしまって残念です。 脳なんて揮発メモリなんだから、なんかやったら記録残すってのは大事だなあという。
symmetric hello - 2010-05-26 - 兼雑記
見た目が対称ってのはどうかなぁと思って作ってみました。端末で見やすくしたくて、横幅を 80 文字以内におさえようとしてたら、何故か横幅ゴルフみたいな感じになってきて無駄に細くなりました。 ______={}//\\{}=______ _=+[]//\\[]+=_ ______.___=""+[][++_]//\\[_++][]+""=___.______ ____=""+{}//\\{}+""=____ ______._=""+!_//\\_!+""=_.______ __=""+!!_//\\_!!+""=__ ___=_+_+_+_+_//\\_+_+_+_+_=___ _______=____[___]//\\[___]____=_______ _________=____[_]//\\[_]____=_________ ___________=______.___[_]//\\[_
中二病と三大美徳とプロプログラマ - 2010-10-07 - 兼雑記
プログラマに取って重要な能力というか気質として、中二病というのがあるんじゃないかなーとかふと思ったのだった。 なんかちょっとしたことを達成した時に、「おおなんてこったオレすげー！！やばいオレ新世界の神だ！！！」みたいなことを思ったことがある人は結構いると思うわけです。まぁ数年、一年、一ヶ月、時には一日で実はそんなにたいしたことでもなかったことに気付いて、恥ずかしい思いをしたりするわけです。だから自分の過去の日記とか見るのは面白いわけです。 でまぁこの気質って、後で考えると恥ずかしいことだったりするんだけど、しかしこの喜びを味わった瞬間というのはなかなか快感なもんで、プログラマの人だと結構こういう経験がある人は多いんじゃないかと思います。プログラマじゃなくても研究職とかでも結構ありそうですね。 で、こういう気質が無い人って、「あっそう Hello, world! って出たね、あっそうテトリス
StringPiece というライブラリの話 - 兼雑記
例えばこう、ディレクトリの名前とその中のファイル名を / でくぎって結合する関数を書くとします。引数が std::string でも使いたいし const char* でも使いたい、ということで、たいていは void JoinFilePathStr(const string& dir, const string& base, string* out) { out->clear(); out->append(dir); out->push_back('/'); out->append(base); }なんてのを書くんじゃないかと思います。この関数で問題になるのは const char* を渡すと不要な string object が一度できることで、敬虔な C++ 屋さんだと、 void JoinFilePathStr(const string& dir, const char* base,
プログラミング言語 wake - 2010-07-09 - 兼雑記
Makefile と正規表現とパターンマッチを混ぜたような、トイ言語を作ってみました。 http://shinh.skr.jp/wake/wake.tgz Hello, world! all: "Hello, world!" wake のプログラムは Makefile のように書きます。つまり、 : で区切って左辺にターゲットを書いて、右辺にアクションを書く感じです。上記のように、 "" で修飾された文字列があると、その文字列を出力します。 Makefile のように、右辺には複数のターゲットを書けますし、文字列以外にも、他のターゲットを action として書くこともできます。 all: "Hello, " world world: "world!" 正規表現 左辺のターゲットは、正規表現で書けます。例えば、 all: hoge hige fuga .*: "yay!\n" とすれば y
fugatrace - 2010-03-28 - 兼雑記
なんか TCC だの WebKit だのを触っていると、ツリー構造を何度もなめてて同じコードを何度も通る感じになって、デバッガの breakpoint がイマイチ機能しない時があります。そういう時は printf を仕込んだり条件付き break を使ったりとかするわけですが、まぁそういうもののオルタナティブとして tracer を書いてみました。 http://github.com/shinh/fugatrace Mach-O と ELF 両方で動かにゃならんので適当に Ruby で GDB を使ういい加減な作りになっています。名前は hogetrace リスペクトで。 出力としてはこんな感じ。 http://shinh.skr.jp/dat_dir/trace.html.gz 重要なオプションは -g と -b と -R で、 -g は gdb の rbreak を使って正規表現で b
WebKit のまとめとぼくと - 2010-01-09 - 兼雑記
とまぁ当初の予定より長々と書いたのですがたぶんこれで最後。インフルエンザ的な何かでディレイが生じました。 なんとなく、「基本的にはよくできてるけどそこらこちらに欠点もあるんだなー」という私の感覚が伝わってくれてたら嬉しいです。一般的に自分が多少なりと関わってるものは欠点がだんだん見えてくるって効果もあるとは思うんですが、 Chrome や社内なんかと比べてもやはり、寛容というか大雑把というか適当というか、そういう面が多分にあるように思います。 しかしまぁこれは私にとってはいいことで、それだけ初心者でもそれなりに手伝うスキがあるってことでもあるからです。そのへんは 50% のものを 80% にする方が 80% のものを 100% にするより好みだという話で、まぁ人によって違うんではないかと思います。 コードが難しいとかも私としてはむしろ楽しく感じすらする部分で、ドキュメントが無いとかもドキュ
情報科学苦手の会 - 兼雑記
という素敵な会があったので行ってきた。 http://groups.google.co.jp/group/nigate 私もなんか発表とかしました。 C++ の吐く機械語ってどうなってるのとかいう話だったので、まぁそんなに違うんじゃないかなーとスライド作ってみたら、意外とたくさん違いがった。 http://shinh.skr.jp/dat_dir/cppbin/000.html 苦手ってことだし適当なスライドでいいだろーと思ってほぼ何も調べずに書いたら、例外とかで難しいツッコミが多くて困った。特に例外についてはもうちょい詳しく調べんといかん。 自分の苦手なものを書く時にも書いたのだけど、私にとって苦手なものっていうのは、興味なり必要性はあるけど勉強が足りてないものだなぁと思います。そもそも興味も必要性も無いものってわざわざ苦手とか思わないんですよね。5年前の私は英語が苦手でなかったと言える
ゴルフ場のなかみ (そのに) 08:03 2009-11-28 - 兼雑記
最近ゴルフ場を新しいマシンに引越したので、前回の記述より色々とよくなった部分もあるので、それについて書いてみます。といっても sandbox についてだけですが。 http://github.com/shinh/ags/blob/master/be/modules/sandbox.c 新しい sandbox は、 arcus-judge のシステムのやってることをまんまパクった部分が多いです。 kernel いじっちゃうとメンテ大変そうだなーと思ったので module でやってるのと、全体的に色々雑なのが大きな違いです。 http://code.google.com/p/arcus-judge/wiki/ArcusSandbox kernel module での system call のフックは、 /boot/System.map-2.6.26-2-xen-686 を見て sys_cal
ゴルフ場のなかみ - 兼雑記 (2009-09-29)
最近ゴルフ場を新しいマシンに引越そうとしていて、ついでなのでシステムをもうちょっと丁寧にパッケージ化しようとしてます。そのついでとして、現在のゴルフ場について内部がどうなってるか、ということを少しまとめてみようと思いました。 結構似たようなことをするサービスもあるんですが(codepadとかllevalとか)、そのへんのコードとかは全く参考にしてないので、そういうのを見た方がいいかもしれませんし、あとゴルフ場固有の事情も色々あったりするかもしれません。まぁでも日本語でそのへん書いてるのはあんまり見たことがないので、多少参考になる部分もあるかもしれません。 今作業中のコードは github に入れていっています。 apt で入らないパッケージの処理以外はだいたい入ってるはずですが、まだ足りないものとかあるかもしれません。 http://github.com/shinh/ags システム自体は
デバッガが使えないパターン - 兼雑記
http://practical-scheme.net/wiliki/wiliki.cgi?Shiro (2009/04/13) 面白いです。 shiro さんが書かれたものの亜種になるものも多いですが、少し私も書いてみようかと。スレッドやらイベントは下記とかぶる。 http://d.hatena.ne.jp/shinichiro_h/20081001#1222794259 多スレッド 少ないうちはいいんですが、多いとバグに関係があるスレッドを探すだけでかなり大変。 race condition 時は「明らかな症状が出る時点では既に痕跡が消えているケース」の亜種になるかなと。 あとタスクキューみたいなのがからむと次の問題とかぶる。 イベントモデル シングルスレッドで select をぶん回してる時なんかに、返事来たらこの callback 実行してねーと asynchronous な実行を
select の semantics - 兼雑記
なんか要は select で write 待ちしてる時に、帰ってきた file descriptor に何バイトまで書けるか、という話。 http://shinh.skr.jp/m/?date=20081008#p01 のへんに適当にはったりしたリンクによると、ポータビリティ考えるなら非同期使え、ってのが明らかに正しいぽい。 POSIX なんかを見てみると、 http://www.opengroup.org/onlinepubs/009695399/functions/select.html If a descriptor refers to a socket, the implied output function is the sendmsg() function supplying an amount of normal data equal to the current value
2008-05-25 - 兼雑記 - Yajit
ふと思い立って YARV からの JIT コンパイラを Xbyak で書き始めてみました。 x86 と x86_64 を両方サポートするつもりだったけど、とりあえず適当にやりすぎて x86_64 に依存しまくってしまったのでとりあえず現状そっちだけ。今度 x86 対応はちゃんとやる。あと Windows と MacOSX もたぶんまだだめ(調べられる環境すらない)。 http://shinh.skr.jp/tmp/yajit.tgz YA なのはなんか他にやってた人いるみたいだし、私の記憶が確かなら YARV にも昔そういう最適化フラグあったような。実装されてたかは知らんけど。 とりあえず動くコードもあれば動かんコードも…って感じです。速いかというと…遅い気がする。とりあえずブロック呼び出しごとに mprotect してるとかがあまりに問題外すぎる気がする。とりあえずこんなとても恣意的なベ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
1st prize in ICFP Programming Contest 2009 - 兼雑記