Cの構造体や関数が定義された位置を表示するnadoka用bot、crubybotつくった

なにをつくったか

表題のとおり crubybot.nb ですが、その名の通りCRubyのソースを解釈して、与えた構造体や関数の定義位置を返します。返す時はGitHubのURLなんですが、まぁそこは枝葉ですな。

libclang

Cコンパイラにはプリプロセッサや構文解析、構文木の構築などが含まれています。ですので、Cソースで何かをしたい場合、Cコンパイラのモジュールを使えると便利です。clang由来の便利なやつがlibclangです。

なにをしているか

find_def のあたりを見ればわかるでしょ。

まとめ

というわけで、libclangを使うと簡単にCソースで遊べるので便利です。

付録

きつねさんとおぼえる！Clang おかわり を読んだらもっと楽にできた気もするけれど、わたしは読めていません。

最近のFreeBSDのsignal trampolineの場所

しばらく悩んでしまったので、後世の人が悩まないように。

プロセスにシグナルが送られると、カーネルはsignal frameをスタック（またはsigaltstack）に積み、「signal handlerを呼び、戻ってきたら後片付けをして元々のプログラムの位置に戻る関数(=sigreturn)を呼ぶコード」を実行します。詳しくは「インタプリタとシグナル - 微酔半壊」で。
で、このコードが signal trampoline なわけですが、backtrace で得られるアドレスにもこの signal trampoline 内を指すアドレスがあります。具体的には signal handler を呼んだ直後のアドレスです（理由はDEBUG HACKSのHACK #27あたりで）。なので、FreeBSD amd64 の場合 sys/amd64/amd64/sigtramp.S がどこに置かれたか探すわけですが、sys/kern/kern_exec.c だけを見ていると実際の値といまいちずれることがあります。
理由は r217151 にて shared page なるものが導入されたからです。酷いのは、実際に確保される場所が場合によって違うっぽいことで……、[http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046773.html:title=ある報告では0x00007ffffffff003だと言っているけれど」、手元では0x00007ffffffff193なんですよね……。
この問題は、r258661で実際に signal trampoline が置かれた場所を sysctl で取れるようになるようなので、それを待てば良いということになります。work around が必要ならば、shared pageの始まる0x00007ffffffff000以降のどこか、ということになりますが、まぁいいよね。

C backtrace

5. Backtrace系ライブラリについて。

> シグナルトランポリンとかよくわからないので教えてほしい。

わたしは黒のBSD本 (4.7 Signals) で勉強しました。日本語訳は入手困難だけど、英語版ならKindleで買えます。
が、第2版が8月にでるそうです！（3月14日追記）

BSDカーネルの設計と実装―FreeBSD詳解

Design and Implementation of the FreeBSD Operating System, The

The Design and Implementation of the FreeBSD Operating System (2nd Edition)

> CRubyにもどっかから持ってきたのかaddr2line.cってやつがあって、さっきのexecinfo.hで得た情報をもとにして、更にDWARFのデバッグ情報をつかって情報を拾い集めている。

経緯は %ruby観察日記 2010-11-25 や #4089 にありますが shinh さんによる独自実装ですね。

なお、Rubyの場合、rb_print_backtrace() という C API が（非公開APIとして）存在します。
ので、デバッグ用ではご自由にお使いください。

公開するgemでは使うなよ！ゼッタイだぞ！！

さくらのBASE Storage について

待望のs3っぽいやつがさくらに来たので、chkbuildのログ上げてみたら、CentOS系だけで70GB近くあった。 http://logfiles.b.storage.sakura.ad.jp/

content-typeとHTTPヘッダ (Content-Encoding) の設定ができないので、html.gzやtxt.gzをブラウザに自動展開してもらえないのが困っている。

GitHub で Web だけで Pull Request を投げるには

あらすじ

1. typo の修正とかでいちいちローカルにリポジトリ取ってくるのだるいよね。
2. GitHub って Web でファイル編集できて便利だね。
3. 油断してると master で編集しちゃうけど、master ブランチから Pull Request とか小学生でも許されないよね
4. どうやってブランチを作ればいいんだろう?

A: ブランチ選択画面から作れます

まとめ

結論としては、以下の様な手順になります。

1. fork する
2. ブランチ選択画面で、修正の元となるブランチに移動する
3. 再びブランチ選択画面で、入力欄におもむろに新しいブランチ名を入れて Enter おす
4. 新しいブランチができるので、Web から編集してコミット
5. Pull Request 投げる

まとめ2

ヘルプがあったらしい

Rubyのバージョンについて

前提

Ruby 開発陣がブランチのメンテナンスに割けるリソースは限界がある。具体的には2本 (+trunk) が限界。

現状

1.9.3 と 2.0.0 がメンテナンスされている。年末に 2.1.0 が増える。

利用者のニーズ

1. セキュリティ修正のみのブランチが欲しい (debian や heroku など)
2. バグ修正のみのブランチが欲しい (普通の開発者)
3. バグ修正と軽微な機能追加のみのブランチが欲しい (ちょっと進んだ開発者)
4. そこそこ互換性を保ったブランチが欲しい (先進的な開発者)
5. 互換性なんてどうでもいいぜﾋｬｯﾊｰ (Rubyコミッタ)

現在は、安定版ブランチが 2.、trunk が 5. である。

よくある要望

1. や 3. なブランチが欲しい

想定される返答

金を出すか自分でやってくれ（ただし、一度始めたら数年程度は継続して頂きたい）

はてぶへの返信

gfx: 2 (バグ修正のみのブランチ) をやめて 1（セキュリティ修正のみのブランチ）にするというのはありな気がする

https://www.ruby-lang.org/ja/news/2013/06/27/ruby-2-0-0-p247-is-released/ あたりを参照しつつ考えていただきたいのですが、経験上直らないと一部の人が生きるのがつらいレベルのバグはちらほらあるような記憶があるんですよねぇ。なので、1.+5.はいろいろとつらいんじゃないかなぁ。

アイディアレベルでは1.+3.+5.にしつつ、LTS導入みたいな話もあるんですが、このレベルの議論は皆様もにもお知恵を出していただいて、じっくり考えたいところですね。

Ruby開発者会議20130727

というわけで、Ruby 2.1 に向けて DevelopersMeeting20130727Japan をしたのです。
開発者会議で何をするかというと、RubyKaigi での見世物の通り、みんなが集まって色んなトピックに対してああでもないこうでもないと言い合うわけです。するとあら不思議、チケットで議論していた時はなかなか進まなかった話が、あっという間に reject されます。
また、三人寄れば文殊の知恵とはよく言ったもので、集まって議論していると保留間違いなしな雰囲気漂うラディカルな提案が、ブレイクスルー的な発想によって合意を得られることがたまにあります。今回で言えば分数リテラルがそうで、1/2r という表記の発想と虚数リテラルへのコンボは会議のハイライトでした。
次回は DevelopersMeeting20130831Japan なので、また大きな進展があるといいなぁ。
まとめ: Ruby 2.1 は電卓がはかどる

追記

ko1: 個人的にはキーワード引数の別名を蹴って binding.local_variable_get(:if) でいける、としたことがハイライト

議事録にも片鱗がありますが、コレに至るまでに色々な案が出ては却下されていき、収束していくスピード感がよかったですね。