Rubyを組み込む側から見たAPI/ABIの互換性
@kosaki55tea @nalsh なので冒頭に nalsh さんに言った通り、API 変更はしょうがないので、バージョンさえあげてもらえれば vim 側は大丈夫ですw
2013-02-26 15:29:12@nalsh @mattn_jp まあそうねえ。こまったなあ。でもnum2hoge あたりのインラインは効果があるかどうか疑わしい最適化に過ぎないと思っててやめられると思う
2013-02-26 15:33:24@mattn_jp @nalsh ところで別件ではあるが、いくらなんでも (DYNAMIC_RUBY_VER < 18) とかはもう捨ててもいいんじゃないの?
2013-02-26 15:34:02@kosaki55tea @mattn_jp CRubyとして正式に保証してるCAPIのリストはREADME.EXTにあるんだけど、あれはexportされてるかは保証してないので、別にコンベンションを提案するか @_ko1 に作ってもらわないとだめすな
2013-02-26 15:37:31@nalsh @mattn_jp うん、ダメだな。このヘッダを互換性保ったままdlsymセーフに出来る気がしない
2013-02-26 15:37:46@nalsh @kosaki55tea これがruby20のdllがエクスポート関数。rb_float_newが無くなっててinline(静的リンク時に必要)のrb_num2ulongが追加されてます。 https://t.co/KxZ7UDsCH9
2013-02-26 15:38:28@kosaki55tea @nalsh あと、vim 的には dll が無かった場合でも動きたいので動く時の為にinlineでコードを太らせられる、というのはif_ruby使わない人にはちょっと残念だったりします。
2013-02-26 15:40:52どうしてもdlopenしたいなら、公開ライブラリlibhoge.soを直接dlopenしようとするとハマるので、libhoge.soをリンクした自前のライブラリlibfoo.soを作って解決するとか、まあそういうstub的手法で回避しなさいってことである
2013-02-26 15:41:35@nalsh @kosaki55tea いえ、僕は保証してと言ってるのでなく、どんな風に互換性が無くなったかを説明しようと思っただけです。あくまで僕はAPI変更は許容派です。
2013-02-26 15:42:10libhogeのほうで何とかするなら、# define DYNAMIC # include "hoge.h" して hoge_init_dynamic() すると、自動で関数ポインタがセットされるような libhogestub.a を用意するとかなー
2013-02-26 15:43:46@mattn_jp @nalsh アダプタをruby側で提供して、vimはlib rubyのかわりにアダプタをdlopenするようにすればええんかな。アダプタはlibruby.soをふつうにリンクするので ruby.h のコンベンションは変えずにすむ。
2013-02-26 15:47:45