ruby-gnome2-devel-ja — Ruby-GNOME2 developer's Mailing list. in Japanese.

[ruby-gnome2-devel-ja] gtk3のdrawシグナルについて

[Masaaki A. <mas...@gm...>]

青柳です。

[ruby-gnome2-devel-en] Gtk3: how to use Gtk::DrawingArea Windows
にて指摘されてしまったので、drawシグナルの対応をしてみました。
一応、以下のようにすれば動くのですが、正しい対応かどうかははっきりしません。
これで、いいでしょうか？

static VALUE
cairo_context_gvalue2rvalue(const GValue *value)
{
    return CRCONTEXT2RVAL(g_value_get_boxed(value));
}

void
Init_conversions(void)
{
    rbgobj_register_g2r_func(g_type_from_name("CairoContext"),
cairo_context_gvalue2rvalue);
}

[ruby-gnome2-devel-ja] [ANN] Ruby-GNOME2 1.1.0

[Kouhei S. <ko...@co...>]

須藤です。

Ruby-GNOME2プロジェクトはRuby-GNOME2 1.1.0をリリースしまし
た。

今回のリリースは今後のGTK+ 3対応前の最後のリリースです。（たぶん）
1.0.X系をお使いの方はアップデートをオススメします。

GTK+ 3対応のためにソースコードがだいぶキレイになりました。
そしｓて、その過程で見つかった問題も多数修正されています。
（メモリリークや引数の順番を間違えていてちゃんと動かない問題
など）

また、Ruby 1.9系でのみ発生するGC時のクラッシュも修正していま
す。Ruby 1.9で利用している方もアップデートをオススメします。

また、また、今回からRuby/GStreamerのWindows用バイナリ入りgem
も配布します。WindowsでRubyでマルチメディアデータを扱いたい
方は試してみてください。

== インストール方法

  % gem install gtk2

== Ruby-GNOME2 1.1.0: 2012-01-05

このリリースではソースコードがキレイになりました。

=== このリリースの概要

==== Ruby/GLib2

  * 改良
    * [GitHub#65] GLib 2.31対応。 [mtasakaさんが報告]
    * GLib::Enum/GLib::FlagsとSymbolの比較に対応。
  * 修正
    * [GitHub#1] GLib::Spawnの後退バグを修正。
      [Geoff Youngsさんがパッチ作成]
    * メモリリークを修正。
    * Ruby 1.9でGC中にクラッシュする問題を修正。
  * 変更
    * Ruby-GetText-Packageを使わないようにした。

==== Ruby/GTK2

  * 改良
    * [ruby-gnome2-devel-en] FileChooserDialog raising warnings on Windows:
      Windows用のgemにhicolor-icon-themeを追加した。
      [Nikolai Weibullさんが提案]
  * 修正
    * GC時にクラッシュする問題を修正。
    * メモリリークを修正。
    * Gdk::GC#colormap=が間違った値を使っているのを修正。
    * Gtk::TextBuffer#serializeが間違った値を使っているのを修正。

==== Ruby/Pango

  * 修正
    * メモリリークを修正。

==== Ruby/GdkPixbuf

  * 改良
    * Gdk::Pixbuf.newがHash引数に対応。
  * 修正
    * メモリリークを修正。

==== Ruby/GStreamer

  * 改良
    * Windows用のgemに対応。
    * メモリ管理を改良。
  * 修正
    * [GitHub#86] Gstreamer: test_caps test fails. [mtasakaさんが報告]
    * [GitHub#87] GStreamer: test_span test fails. [mtasakaさんが報告]
    * [GitHub#87] GStreamer: test_create_clock test fails.
      [mtasakaさんが報告]
    * [GitHub#89] GStreamer: test_fraction_range_new test fails.
      [mtasakaさんが報告]
    * [GitHub#91] GStreamer: test_state "sometimes" fails.
      [mtasakaさんが報告]

==== Ruby/Poppler

  * 修正
    * Poppler::Document#find_destが間違った変換をしているの
      を修正。
      [Chloe Desoutterさんが報告]（最初のeはアクセントが付きます。）

=== 感謝

  * Geoff Youngsさん
  * mtasakaさん
  * Chloe Desoutterさん（最初のeはアクセントが付きます。）
  * Nikolai Weibullさん

Re: [ruby-gnome2-devel-ja] Gdk::Pixbuf.newのhash引数化

[Kouhei S. <ko...@co...>]

須藤です。

In <CAMyNdeXhCSBB485RM+k6BnbC439nX_df=PAQ...@ma...>
  "Re: [ruby-gnome2-devel-ja] Gdk::Pixbuf.newのhash引数化" on Wed, 28 Dec 2011 07:26:08 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

>> ただ、Ruby/GTK3は新しいリリースなのでガンガンwarningでいいと
>> 思いますが、Ruby/GdkPixbuf2は既存のものなので、次のリリース
>> がでてからにしてもらえますか？次の次のリリースは1.1.0にして、
>> そこからwarningを出すことにしましょう。で、1.2.0あたりに廃止
>> という感じで。
> 
> わかりました。
> ただ、添付のリファクタリング（リトライコードの外部化）だけ先につっこんでも
> よろしいでしょうか？

はい、いいです。
（rb_gc()の次にg_error_free()が必要そうな気がします。）

あ、warningを出さなければ今のうちからHashのみの引数と既存の
実装を両立するコードは入れてもいいです。

Re: [ruby-gnome2-devel-ja] Gdk::Pixbuf.newのhash引数化

[Masaaki A. <mas...@gm...>]

青柳です。

> ただ、Ruby/GTK3は新しいリリースなのでガンガンwarningでいいと
> 思いますが、Ruby/GdkPixbuf2は既存のものなので、次のリリース
> がでてからにしてもらえますか？次の次のリリースは1.1.0にして、
> そこからwarningを出すことにしましょう。で、1.2.0あたりに廃止
> という感じで。

わかりました。
ただ、添付のリファクタリング（リトライコードの外部化）だけ先につっこんでも
よろしいでしょうか？

Re: [ruby-gnome2-devel-ja] Gdk::Pixbuf.newのhash引数化

[Kouhei S. <ko...@co...>]

須藤です。

In <CAM...@ma...>
  "Re: [ruby-gnome2-devel-ja] Gdk::Pixbuf.newのhash引数化" on Mon, 26 Dec 2011 23:23:59 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

> 引数はHashのみ受け付けるようにして、互換性についてはGLib::Depcatableでwarningを
> 出しつつ維持して、移行してもらうというのを考えています。

わかりました。では、よいと思います。
ただ、Ruby/GTK3は新しいリリースなのでガンガンwarningでいいと
思いますが、Ruby/GdkPixbuf2は既存のものなので、次のリリース
がでてからにしてもらえますか？次の次のリリースは1.1.0にして、
そこからwarningを出すことにしましょう。で、1.2.0あたりに廃止
という感じで。

（年明けにはリリースしたいです。。。）

> 現在、実装されていないgdk_pixbuf_new_from_stream、gdk_pixbuf_new_from_stream_at_scale
> を実装することになると思うのですが、現在の方式で進めていくのは使う側のソースの可読性の意味でも
> 問題があると思っています。

これらは、Hash引数のときだけサポートでOKです。

Re: [ruby-gnome2-devel-ja] Gdk::Pixbuf.newのhash引数化

[Masaaki A. <mas...@gm...>]

青柳です。

>> Gdk::Pixbuf.newのソースがちょっと混沌としているのと使い勝手が悪いので
>> hash引数に変更したいのですが、いかがでしょうか？
>
> これは互換性を捨てるという事ですか？
> それとも、1引数のHashも受け付けるようにするということですか？
>
> 後者なら反対する理由はありませんが、前者ならこの情報だけだと
> 反対すると思います。もっとそれっぽい理由付きなら反対しなくな
> るかもしれませんが。。。

すみません、端折り過ぎましたね。
引数はHashのみ受け付けるようにして、互換性についてはGLib::Depcatableでwarningを
出しつつ維持して、移行してもらうというのを考えています。
現在、実装されていないgdk_pixbuf_new_from_stream、gdk_pixbuf_new_from_stream_at_scale
を実装することになると思うのですが、現在の方式で進めていくのは使う側のソースの可読性の意味でも
問題があると思っています。
また、Hash引数にすれば、例えばgdk_pixbuf_new_from_dataのcolorspaceやbits_per_sample
のようなものを省略可能にできるので使いやすくなると思っています。

もし移行は問題だとすれば、現在の引数に追加で1個のHashも受け付ける形式であれば
よろしいでしょうか？

Re: [ruby-gnome2-devel-ja] Gdk::Pixbuf.newのhash引数化

[Kouhei S. <ko...@co...>]

須藤です。

In <CAMyNdeXyx3kk=q+H=6jqmN_+=HPM...@ma...>
  "[ruby-gnome2-devel-ja] Gdk::Pixbuf.newのhash引数化" on Sun, 25 Dec 2011 23:30:46 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

> Gdk::Pixbuf.newのソースがちょっと混沌としているのと使い勝手が悪いので
> hash引数に変更したいのですが、いかがでしょうか？

これは互換性を捨てるという事ですか？
それとも、1引数のHashも受け付けるようにするということですか？

後者なら反対する理由はありませんが、前者ならこの情報だけだと
反対すると思います。もっとそれっぽい理由付きなら反対しなくな
るかもしれませんが。。。

[ruby-gnome2-devel-ja] Gdk::Pixbuf.newのhash引数化

[Masaaki A. <mas...@gm...>]

青柳です。

Gdk::Pixbuf.newのソースがちょっと混沌としているのと使い勝手が悪いので
hash引数に変更したいのですが、いかがでしょうか？

Re: [ruby-gnome2-devel-ja] ID的なパラメータについて

[Kouhei S. <ko...@co...>]

須藤です。

In <CAM...@ma...>
  "Re: [ruby-gnome2-devel-ja] ID的なパラメータについて" on Mon, 19 Dec 2011 22:12:27 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

> プロパティへの対応もする必要があるのでglib2を見たら、type_to_prop_(setter|getter)_table
> のような変換関数テーブルを使った仕組みがあるようですので、それを利用しようと考えています。
> が、以下のようにテーブルへアクセスする際のキーがrb_str_new2、rb_intern、CSTR2RVAL
> とまちまちになっています。
> rbgobj_register_property_setter():
>     rb_hash_aset(table, rb_str_new2(g_param_spec_get_name(pspec)),
>                  Data_Wrap_Struct(rb_cData, NULL, NULL, func));
>  rbgobj_register_property_getter():
>     rb_hash_aset(table, rb_str_new2(g_param_spec_get_name(pspec)),
>                  Data_Wrap_Struct(rb_cData, NULL, NULL, func));
> rg_set_property():
>     rb_hash_aref(table, rb_intern(g_param_spec_get_name(pspec)));
> rg_get_property():
>     rb_hash_aref(table, CSTR2RVAL(g_param_spec_get_name(pspec)));
> 
> どれかに統一したいのですが、何が良いでしょうか？

できればrb_intern()、無理ならCSTR2RVAL()ですかねぇ。

Re: [ruby-gnome2-devel-ja] ID的なパラメータについて

[Masaaki A. <mas...@gm...>]

青柳です。

> であれば、rb_sym_to_s()の方がよさそうです。

rb_sym_to_sを使用するように変更しました。


プロパティへの対応もする必要があるのでglib2を見たら、type_to_prop_(setter|getter)_table
のような変換関数テーブルを使った仕組みがあるようですので、それを利用しようと考えています。
が、以下のようにテーブルへアクセスする際のキーがrb_str_new2、rb_intern、CSTR2RVAL
とまちまちになっています。
rbgobj_register_property_setter():
    rb_hash_aset(table, rb_str_new2(g_param_spec_get_name(pspec)),
                 Data_Wrap_Struct(rb_cData, NULL, NULL, func));
 rbgobj_register_property_getter():
    rb_hash_aset(table, rb_str_new2(g_param_spec_get_name(pspec)),
                 Data_Wrap_Struct(rb_cData, NULL, NULL, func));
rg_set_property():
    rb_hash_aref(table, rb_intern(g_param_spec_get_name(pspec)));
rg_get_property():
    rb_hash_aref(table, CSTR2RVAL(g_param_spec_get_name(pspec)));

どれかに統一したいのですが、何が良いでしょうか？

Re: [ruby-gnome2-devel-ja] G_DEF_SETTERなど

[Kouhei S. <ko...@co...>]

須藤です。

In <CAMyNdeUzCD+rxuAKMSNv9DE__d-8vHmKDjKO=A_dnP=uj...@ma...>
  "Re: [ruby-gnome2-devel-ja] G_DEF_SETTERなど" on Sun, 18 Dec 2011 19:04:27 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

> あと、忘れてましたがmodule_functionは意図して（プライベートメソッドが必要という意味で）
> 使用している箇所はあるのでしょうか？

どうなんでしょうねぇ。
rb_define_singleton_method()みたいなのがないからな気がします
が。。。

> もしsingletonで十分なのであれば、singletonに統一していきたいです。

十分そうなところであればsingletonにしても大丈夫です！

> # https://github.com/ruby-gnome2/ruby-gnome2/pull/77
> # を確認してマージしていただけると助かります。

しました！

Re: [ruby-gnome2-devel-ja] G_DEF_SETTERなど

[Masaaki A. <mas...@gm...>]

青柳です。

> でも、最近のRubyだとXXX=の戻り値はメソッド定義に関わらず引数
> の値になっている気がするので、aliasで十分な気もします。

この仕様は昔からだったわけではないのですか。
いつ頃からなんですかね。

あと、忘れてましたがmodule_functionは意図して（プライベートメソッドが必要という意味で）
使用している箇所はあるのでしょうか？
もしsingletonで十分なのであれば、singletonに統一していきたいです。

# https://github.com/ruby-gnome2/ruby-gnome2/pull/77
# を確認してマージしていただけると助かります。

Re: [ruby-gnome2-devel-ja] G_DEF_SETTERなど

[Kouhei S. <ko...@co...>]

須藤です。

In <CAM...@ma...>
  "[ruby-gnome2-devel-ja] G_DEF_SETTERなど" on Sun, 18 Dec 2011 16:42:24 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

> ニコライさんが
> http://sourceforge.net/mailarchive/message.php?msg_id=28076951
> この辺で、速度を気にされて？G_DEF_SETTERSからG_DEF_SETTERを使うように
> 変更されているようです。
> ちょっと面倒なので、必要であればsetterも同時に定義するrb_define_methodを
> rbg_define_methodとして定義し、それを使うように変更していきたいです。
> （singletonとmodule_functionも同様）
> いかがでしょうか？

はい、よいと思います。

> また、setterを現在メソッド定義で行っていますが、aliasで十分な気もするのですが、
> どうでしょうか？

なんか、戻り値がどうこうな話があったんじゃないかなぁと思いま
す。

  object.set_XXX("AAA")

のときはobjectを返すのがよいけど

  object.XXX = "AAA"

のときは"AAA"を返すのがよい、みたいな。

後者は、

  other_varaible = object.XXX = "AAA"

が書けるようにしたいということですね。

でも、最近のRubyだとXXX=の戻り値はメソッド定義に関わらず引数
の値になっている気がするので、aliasで十分な気もします。
（Ruby 1.8.5とかのサポートはもうdropしているので。）

> それと、G_REPLACE_*のようなマクロを定義しているようですが、この辺は
> 実害があっての話なのでしょうか？

すでに存在するメソッドを上書きするとwarningがでるからじゃな
いかと思います。たぶん。

[ruby-gnome2-devel-ja] G_DEF_SETTERなど

[Masaaki A. <mas...@gm...>]

青柳です。

ニコライさんが
http://sourceforge.net/mailarchive/message.php?msg_id=28076951
この辺で、速度を気にされて？G_DEF_SETTERSからG_DEF_SETTERを使うように
変更されているようです。
ちょっと面倒なので、必要であればsetterも同時に定義するrb_define_methodを
rbg_define_methodとして定義し、それを使うように変更していきたいです。
（singletonとmodule_functionも同様）
いかがでしょうか？
また、setterを現在メソッド定義で行っていますが、aliasで十分な気もするのですが、
どうでしょうか？

それと、G_REPLACE_*のようなマクロを定義しているようですが、この辺は
実害があっての話なのでしょうか？

Re: [ruby-gnome2-devel-ja] ID的なパラメータについて

[Kouhei S. <ko...@co...>]

須藤です。

In <CAMyNdeWx+jo1BAyqxdWvgP=KKf...@ma...>
  "Re: [ruby-gnome2-devel-ja] ID的なパラメータについて" on Sun, 18 Dec 2011 14:10:52 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

>>>     if (SYMBOL_P(*value)) {
>>>         str = rb_String(*value);
>>
>> 文字列への変換はStringValue()を使ったほうがいいです。
> 
> これは、シンボルがto_strを持っていないため、rb_Stringを使用しました。

なるほど。
であれば、rb_sym_to_s()の方がよさそうです。
どちらもruby.hじゃなくてintern.hの方なのでアレなのですが。。。

> g_freeしてもらうのは、漏れる可能性が高いため、やめた方がいいと思うので
> バッファを渡す以下のような方向で修正しましたが、いかがでしょうか？

よいと思います！

Re: [ruby-gnome2-devel-ja] ID的なパラメータについて

[Masaaki A. <mas...@gm...>]

青柳です。

> あぁ、そうではなく、単にスタック上にVALUEが置いてあればGCの
> ときにスタック上のVALUEをmarkしてくれるから大丈夫なんです。

なるほど、根本的に理解していませんでした。。。
RB_GC_GUARDの辺りやスタック上に残り易くなる云々は、まだよく分かっていませんが
いつか勉強しようと思います。


>>     if (SYMBOL_P(*value)) {
>>         str = rb_String(*value);
>
> 文字列への変換はStringValue()を使ったほうがいいです。

これは、シンボルがto_strを持っていないため、rb_Stringを使用しました。


> こんな感じでvalueの他にバッファ用のVALUEも別途受け取ってstr
> の代わりに使うように大丈夫そうな気がしますが、それだと使いづ
> らいですよねぇ。
>  http://d.hatena.ne.jp/nagachika/20111011/ruby_extension_library_howto_tmp_buffer
>
> あとは、const gchar *じゃなくてgchar *を返して呼び出し側で
> g_free()してもらうという案もありますが、そっちもひと手間増え
> ちゃいますよねぇ。

g_freeしてもらうのは、漏れる可能性が高いため、やめた方がいいと思うので
バッファを渡す以下のような方向で修正しましたが、いかがでしょうか？

#define RVAL2GLIBID(v, buf) (rbg_rval2glibid(&(v), &(buf), FALSE))
#define RVAL2GLIBID_ACCEPT_NIL(v, buf) (rbg_rval2glibid(&(v), &(buf), TRUE))

const gchar *
rbg_rval2glibid(volatile VALUE *value, volatile VALUE *buf, gboolean accept_nil)
{
    gchar *id, *p;

    if (accept_nil && NIL_P(*value))
        return NULL;

    if (SYMBOL_P(*value)) {
        *buf = rb_String(*value);
    } else {
        StringValue(*value);
        *buf = rb_str_dup(*value);
    }
    RB_GC_GUARD(*buf);

    id = RSTRING_PTR(*buf);
    for (p = id; *p; p++)
        if (*p == '_')
            *p = '-';

    return id;
}

/* 呼び出し側 */
static VALUE
rg_set_foo(VALUE self, VALUE id)
{
    VALUE buf;
    gtk_bar_set_foo(_SELF(self), RVAL2GLIBID(id, buf));
    return self;
}

Re: [ruby-gnome2-devel-ja] ID的なパラメータについて

[Kouhei S. <ko...@co...>]

須藤です。

In <CAMyNdeUg5F=HjS...@ma...>
  "Re: [ruby-gnome2-devel-ja] ID的なパラメータについて" on Fri, 16 Dec 2011 21:12:37 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

>>> 例えば、rbg_rval2cstrでは、StringValueをコールして、RSTRING_PTRでポインタを返しています。
>>> StringValueはhttp://doc.ruby-lang.org/ja/1.8.7/function/StringValue.htmlによると、
>>> GCから保護されるとのことなので、オブジェクトの開放はされずに残り続けると理解しましたが、
>>> リークしていることになるのでしょうか？
>>
>> あぁ、これは、関数の実行中はGCされない、くらいの意味です。
>> 関数がもろもろreturnしていって、Cの世界からRubyの世界に戻っ
>> て、誰からも参照されなくなったらGC対象になります。
> 
> なるほど。ということは
> * 通常、GVLでロックされているのでCの関数実行中はGCされることはない
> * ただし、rb_thread_blocking_region？でGVLを意図的に外している場合はGCされうる
> * その場合でも、StringValueで保護していればCの関数実行中はGCされない
> みたいな事なんでしょうか？（ソース読んだことないから見当はずれっぽいなぁ）

あぁ、そうではなく、単にスタック上にVALUEが置いてあればGCの
ときにスタック上のVALUEをmarkしてくれるから大丈夫なんです。

怪しい時は

  VALUE ruby_object;
  ...
  RB_GC_GUARD(ruby_object);

としておくと確実にmark対象になります。

なので、

> 以下のような感じで実装してみましたが、いかがでしょうか？
> 
> #define RVAL2GLIBID(v) (rbg_rval2glibid(&(v), FALSE))
> #define RVAL2GLIBID_ACCEPT_NIL(v) (rbg_rval2glibid(&(v), TRUE))
> 
> const gchar *
> rbg_rval2glibid(VALUE *value, gboolean accept_nil)

一応volatileを付けておいたほうがいいかなぁと思いました。

rbg_rval2glibid(volatile VALUE *value, gboolean accept_nil)

たぶん、これで呼び出し元のVALUEがスタック上に残りやすくなる
んじゃないかと思います。（volatileがどのくらい効くのかわかっ
ていない。）

> {
>     VALUE str;
>     gchar *id, *p;
> 
>     if (accept_nil && NIL_P(*value))
>         return NULL;
> 
>     if (SYMBOL_P(*value)) {
>         str = rb_String(*value);

文字列への変換はStringValue()を使ったほうがいいです。
rb_String()だと何がなんでも文字列に変換するんですが、
StringValue()だとto_strがあるオブジェクトだけ文字列に変換し
ます。

Ruby本体はto_strとか明示的な変換メソッドが定義されていない限
り暗黙的に変換しないのでそれに合わせたほうがよいと思います。

まぁ、今回はシンボル相手なのでどちらでも結果は変わらないので
すが、一応StringValue()を使っていたほうがよいかと思います。。。

>     } else {
>         StringValue(*value);
>         str = rb_str_dup(*value);
>     }
>     StringValue(str); /* 必要？ */

これはRB_GC_GUARD(str)で十分だと思います。

>     id = RSTRING_PTR(str);
>     for (p = id; *p; p++)
>         if (*p == '_')
>             *p = '-';
> 
>     return id;

あぁ、文字列を直接書き換えるんですかぁ。。。
であれば、ちょっとこの方向だとしんどいですね。。。
*valueを直接書き換えてもよければ、呼び出し元がVALUEを持つ
（=スタック上に残る）のでこれでもいいんですが、*valueじゃな
いstrに入れてるStringはこの関数を抜けたらスタックから消えて
しまうのでrbg_rval2glibid()が返すgchar *がGCされてしまうかも
しれません。

こんな感じでvalueの他にバッファ用のVALUEも別途受け取ってstr
の代わりに使うように大丈夫そうな気がしますが、それだと使いづ
らいですよねぇ。
  http://d.hatena.ne.jp/nagachika/20111011/ruby_extension_library_howto_tmp_buffer

あとは、const gchar *じゃなくてgchar *を返して呼び出し側で
g_free()してもらうという案もありますが、そっちもひと手間増え
ちゃいますよねぇ。

むぅ。

Re: [ruby-gnome2-devel-ja] ID的なパラメータについて

[Masaaki A. <mas...@gm...>]

青柳です。

>> 例えば、rbg_rval2cstrでは、StringValueをコールして、RSTRING_PTRでポインタを返しています。
>> StringValueはhttp://doc.ruby-lang.org/ja/1.8.7/function/StringValue.htmlによると、
>> GCから保護されるとのことなので、オブジェクトの開放はされずに残り続けると理解しましたが、
>> リークしていることになるのでしょうか？
>
> あぁ、これは、関数の実行中はGCされない、くらいの意味です。
> 関数がもろもろreturnしていって、Cの世界からRubyの世界に戻っ
> て、誰からも参照されなくなったらGC対象になります。

なるほど。ということは
* 通常、GVLでロックされているのでCの関数実行中はGCされることはない
* ただし、rb_thread_blocking_region？でGVLを意図的に外している場合はGCされうる
* その場合でも、StringValueで保護していればCの関数実行中はGCされない
みたいな事なんでしょうか？（ソース読んだことないから見当はずれっぽいなぁ）

以下のような感じで実装してみましたが、いかがでしょうか？

#define RVAL2GLIBID(v) (rbg_rval2glibid(&(v), FALSE))
#define RVAL2GLIBID_ACCEPT_NIL(v) (rbg_rval2glibid(&(v), TRUE))

const gchar *
rbg_rval2glibid(VALUE *value, gboolean accept_nil)
{
    VALUE str;
    gchar *id, *p;

    if (accept_nil && NIL_P(*value))
        return NULL;

    if (SYMBOL_P(*value)) {
        str = rb_String(*value);
    } else {
        StringValue(*value);
        str = rb_str_dup(*value);
    }
    StringValue(str); /* 必要？ */

    id = RSTRING_PTR(str);
    for (p = id; *p; p++)
        if (*p == '_')
            *p = '-';

    return id;
}

Re: [ruby-gnome2-devel-ja] ID的なパラメータについて

[Kouhei S. <ko...@co...>]

須藤です。

In <CAM...@ma...>
  "Re: [ruby-gnome2-devel-ja] ID的なパラメータについて" on Thu, 15 Dec 2011 22:54:27 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

> 実装しようとして、いきなりつまりました。。。
> まだ、文字列周辺のメモリ管理をどうしているのか、よく分かっていないので教えてください。
> 
> 例えば、rbg_rval2cstrでは、StringValueをコールして、RSTRING_PTRでポインタを返しています。
> StringValueはhttp://doc.ruby-lang.org/ja/1.8.7/function/StringValue.htmlによると、
> GCから保護されるとのことなので、オブジェクトの開放はされずに残り続けると理解しましたが、
> リークしていることになるのでしょうか？

あぁ、これは、関数の実行中はGCされない、くらいの意味です。
関数がもろもろreturnしていって、Cの世界からRubyの世界に戻っ
て、誰からも参照されなくなったらGC対象になります。

Re: [ruby-gnome2-devel-ja] ID的なパラメータについて

[Masaaki A. <mas...@gm...>]

青柳です。

>> 例えば、stock idのようにID的な扱いをするパラメータにシンボルも使えるように
>> * 文字列とシンボルを許容する
>> * '-'の代わりに'_'も使えるようにする
>> というように統一していきたいです。
>> そのため、glib2にRVAL2GTKIDのようなマクロを定義しようと考えています。
>> いかがでしょうか？
>
> いいと思います！

ありがとうございます！
実装しようとして、いきなりつまりました。。。
まだ、文字列周辺のメモリ管理をどうしているのか、よく分かっていないので教えてください。

例えば、rbg_rval2cstrでは、StringValueをコールして、RSTRING_PTRでポインタを返しています。
StringValueはhttp://doc.ruby-lang.org/ja/1.8.7/function/StringValue.htmlによると、
GCから保護されるとのことなので、オブジェクトの開放はされずに残り続けると理解しましたが、
リークしていることになるのでしょうか？

Re: [ruby-gnome2-devel-ja] ID的なパラメータについて

[Kouhei S. <ko...@co...>]

須藤です。

In <CAM...@ma...>
  "[ruby-gnome2-devel-ja] ID的なパラメータについて" on Thu, 15 Dec 2011 20:55:24 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

> 例えば、stock idのようにID的な扱いをするパラメータにシンボルも使えるように
> * 文字列とシンボルを許容する
> * '-'の代わりに'_'も使えるようにする
> というように統一していきたいです。
> そのため、glib2にRVAL2GTKIDのようなマクロを定義しようと考えています。
> いかがでしょうか？

いいと思います！

[ruby-gnome2-devel-ja] ID的なパラメータについて

[Masaaki A. <mas...@gm...>]

青柳です。

例えば、stock idのようにID的な扱いをするパラメータにシンボルも使えるように
* 文字列とシンボルを許容する
* '-'の代わりに'_'も使えるようにする
というように統一していきたいです。
そのため、glib2にRVAL2GTKIDのようなマクロを定義しようと考えています。
いかがでしょうか？

Re: [ruby-gnome2-devel-ja] interfaceの実装など

[Kouhei S. <ko...@co...>]

須藤です。

In <CAMyNdeVS9LTtURtav+D2R_iYinXwVPL+gYF1=JUc...@ma...>
  "Re: [ruby-gnome2-devel-ja] interfaceの実装など" on Tue, 13 Dec 2011 23:57:13 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

>> であれば、私なら↓という感じで実装する気がします。
>>
>>  1. Ruby/GtkSourceView3内でGtkSourceCompletionProviderを実
>>     装したRubyGtkSourceCompletionProviderのようなクラスを定義
>>  2. 1.で定義したクラスにはProcを登録できるようにする
>>  3. 1.で定義したクラスの各メソッドの実装は2.で登録したProc
>>     を呼び出すようにする
>>
>>
>> ただ、GtkSourceCompletionProviderはメソッドが多いみたいなので、
>> 大変そうなら、一部のメソッドのみサポートとか、（そんなに大事
>> なものでなければ）いっそサポートしない（あるいは後回しにする）
>> というのもアリかも、とは思いました。
> 
> やっぱりバインドする仕組みを作る必要がありますよね。

そうですねぇ。↑以外だとProcを登録するのではなくてRubyでクラ
スを1つ作ってそれのメソッドを呼び出すようにするとかですかねぇ。

  class RubyCompletionProvider
    def match(...)
      # gtk_source_completion_provider_match()が呼ばれたらこ
      # のメソッドを呼ぶ
    end
    ...
  end

> GtkSourceCompletionProviderを諦めるとGtkSourceCompletion全体を
> 諦めることになってしまうと思うので悩ましい。。。
> 他の実装を進めつつ考えます。

わかりました！

Re: [ruby-gnome2-devel-ja] interfaceの実装など

[Masaaki A. <mas...@gm...>]

青柳です。

> gtk_source_completion_add_provider()をバインドするというのは、
> Rubyレベルで補完をカスタマイズできるようにしたいってことです
> よね？

カスタマイズできるようにしたいというよりも、GtkSourceCompletionを使用する場合、
自分でGtkSourceCompletionProviderを実装することが前提になっていると
理解しています。


> であれば、私なら↓という感じで実装する気がします。
>
>  1. Ruby/GtkSourceView3内でGtkSourceCompletionProviderを実
>     装したRubyGtkSourceCompletionProviderのようなクラスを定義
>  2. 1.で定義したクラスにはProcを登録できるようにする
>  3. 1.で定義したクラスの各メソッドの実装は2.で登録したProc
>     を呼び出すようにする
>
>
> ただ、GtkSourceCompletionProviderはメソッドが多いみたいなので、
> 大変そうなら、一部のメソッドのみサポートとか、（そんなに大事
> なものでなければ）いっそサポートしない（あるいは後回しにする）
> というのもアリかも、とは思いました。

やっぱりバインドする仕組みを作る必要がありますよね。
GtkSourceCompletionProviderを諦めるとGtkSourceCompletion全体を
諦めることになってしまうと思うので悩ましい。。。
他の実装を進めつつ考えます。

Re: [ruby-gnome2-devel-ja] interfaceの実装など

[Kouhei S. <ko...@co...>]

須藤です。

In <CAMyNdeWh3rGA1OWkTyapM=KTkK9f-EfZCvj=qtb...@ma...>
  "Re: [ruby-gnome2-devel-ja] interfaceの実装など" on Tue, 13 Dec 2011 21:07:16 +0900,
  Masaaki Aoyagi <mas...@gm...> wrote:

> 例えば、GtkSourceCompletionProvider自体はG_DEF_INTERFACEでモジュールとして定義できるのですが、
> たぶんgtk_source_completion_add_providerあたりでGtkSourceCompletionProviderのインスタンスを
> 渡す必要があると思うのですが、実装したGObjectが存在しないため、インスタンス生成をどうやって行うかが
> 分からないです。

gtk_source_completion_add_provider()をバインドするというのは、
Rubyレベルで補完をカスタマイズできるようにしたいってことです
よね？

であれば、私なら↓という感じで実装する気がします。

  1. Ruby/GtkSourceView3内でGtkSourceCompletionProviderを実
     装したRubyGtkSourceCompletionProviderのようなクラスを定義
  2. 1.で定義したクラスにはProcを登録できるようにする
  3. 1.で定義したクラスの各メソッドの実装は2.で登録したProc
     を呼び出すようにする


ただ、GtkSourceCompletionProviderはメソッドが多いみたいなので、
大変そうなら、一部のメソッドのみサポートとか、（そんなに大事
なものでなければ）いっそサポートしない（あるいは後回しにする）
というのもアリかも、とは思いました。


>> そうです。。。debやrpmではgemみたいに各パッケージ毎にディレ
>> クトリを掘るのではなく、共通のディレクトリにヘッダーファイル
>> を置くのです。
>> （/usr/lib/ruby/vendor_ruby/1.9.1/x86_64-linux/以下とか）
>>
>> なので、ヘッダーファイルにはrbgtk3.hの用にバージョンを入れた
>> 方がいいと思っています。
> 
> なるほど。そうなんですね。
> ということで、バージョンを入れるようにしました。

ありがとうございます！