Rubyを組み込む側から見たAPI/ABIの互換性

Rubyを動的にロードしているVimから見るとAPI/ABIが頻繁に変更されているという話。
6
成瀬 @nalsh

@kosaki55tea @mattn_jp それを言い出すとマクロ置くのがおかしいとかABI互換性派手に壊さないと正常化できないよ

2013-02-26 15:28:57
mattn @mattn_jp

@kosaki55tea @nalsh なので冒頭に nalsh さんに言った通り、API 変更はしょうがないので、バージョンさえあげてもらえれば vim 側は大丈夫ですw

2013-02-26 15:29:12
AoiMoe a.k.aしお兄P @AoiMoe

だいたい自前でdlsymとかするなよって話のような気もしなくもない

2013-02-26 15:29:17
AoiMoe a.k.aしお兄P @AoiMoe

dlopen/dlsym/dlcloseなんてstub用意して隠蔽化しませう

2013-02-26 15:29:51
mattn @mattn_jp

@kosaki55tea @nalsh 答え:「API の変更」なのでしょうがないです

2013-02-26 15:31:03
成瀬 @nalsh

@mattn_jp @kosaki55tea 今後はリリースごとにRUBY_API_VERSION変えるのでご安心ください(ゎ

2013-02-26 15:31:10
小崎 資広 (KOSAKI Motohiro) @kosaki55tea

@nalsh @mattn_jp まあそうねえ。こまったなあ。でもnum2hoge あたりのインラインは効果があるかどうか疑わしい最適化に過ぎないと思っててやめられると思う

2013-02-26 15:33:24
AoiMoe a.k.aしお兄P @AoiMoe

dlopenがどんな共有ライブラリに対しても動くと思ったら大間違いなので、罪作りなAPIだよな。

2013-02-26 15:33:42
小崎 資広 (KOSAKI Motohiro) @kosaki55tea

@mattn_jp @nalsh ところで別件ではあるが、いくらなんでも (DYNAMIC_RUBY_VER < 18) とかはもう捨ててもいいんじゃないの?

2013-02-26 15:34:02
AoiMoe a.k.aしお兄P @AoiMoe

libpthread.soに明示的ないしは暗示的に依存してるライブラリをdlopenするとか悪夢やで

2013-02-26 15:34:43
成瀬 @nalsh

@kosaki55tea @mattn_jp 継続的に保証しないと意味がないので小手先の話をしてもあんまり

2013-02-26 15:35:50
AoiMoe a.k.aしお兄P @AoiMoe

dlopenしたくなったらそれは何か良くない兆候くらいに思っておいても間違いない

2013-02-26 15:37:23
成瀬 @nalsh

@kosaki55tea @mattn_jp CRubyとして正式に保証してるCAPIのリストはREADME.EXTにあるんだけど、あれはexportされてるかは保証してないので、別にコンベンションを提案するか @_ko1 に作ってもらわないとだめすな

2013-02-26 15:37:31
小崎 資広 (KOSAKI Motohiro) @kosaki55tea

@nalsh @mattn_jp うん、ダメだな。このヘッダを互換性保ったままdlsymセーフに出来る気がしない

2013-02-26 15:37:46
成瀬 @nalsh

そもそも dll とは邪悪なものである

2013-02-26 15:38:14
成瀬 @nalsh

そもそも Unix とは邪悪なものであって

2013-02-26 15:38:28
mattn @mattn_jp

@nalsh @kosaki55tea これがruby20のdllがエクスポート関数。rb_float_newが無くなっててinline(静的リンク時に必要)のrb_num2ulongが追加されてます。 https://t.co/KxZ7UDsCH9

2013-02-26 15:38:28
成瀬 @nalsh

@mattn_jp @kosaki55tea 全部保証する気はないですよ

2013-02-26 15:40:07
mattn @mattn_jp

@kosaki55tea @nalsh あと、vim 的には dll が無かった場合でも動きたいので動く時の為にinlineでコードを太らせられる、というのはif_ruby使わない人にはちょっと残念だったりします。

2013-02-26 15:40:52
AoiMoe a.k.aしお兄P @AoiMoe

どうしてもdlopenしたいなら、公開ライブラリlibhoge.soを直接dlopenしようとするとハマるので、libhoge.soをリンクした自前のライブラリlibfoo.soを作って解決するとか、まあそういうstub的手法で回避しなさいってことである

2013-02-26 15:41:35
mattn @mattn_jp

@nalsh @kosaki55tea いえ、僕は保証してと言ってるのでなく、どんな風に互換性が無くなったかを説明しようと思っただけです。あくまで僕はAPI変更は許容派です。

2013-02-26 15:42:10
MURAOKA Taro @kaoriya

@n_soda なるほど。まぁdeprecatedなのなら納得はしますけど…今回は増えたケースですからねぇw

2013-02-26 15:43:17
AoiMoe a.k.aしお兄P @AoiMoe

libhogeのほうで何とかするなら、# define DYNAMIC # include "hoge.h" して hoge_init_dynamic() すると、自動で関数ポインタがセットされるような libhogestub.a を用意するとかなー

2013-02-26 15:43:46
小崎 資広 (KOSAKI Motohiro) @kosaki55tea

@mattn_jp @nalsh アダプタをruby側で提供して、vimはlib rubyのかわりにアダプタをdlopenするようにすればええんかな。アダプタはlibruby.soをふつうにリンクするので ruby.h のコンベンションは変えずにすむ。

2013-02-26 15:47:45