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

Re: [ruby-gnome2-devel-ja] =?ISO-2022-JP?B?GyRCSkwlRyUjJWwbKEI=?==?ISO-2022-JP?B?GyRCJS8lSCVqJEckTiVTJWslSRsoQg==?=

[Masao M. <mut...@gm...>]

むとうです。
＃なんだか、私のプロバイダからだとメールが送れたり送れなかったり・・・。

On Thu, 25 May 2006 23:03:29 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
>
> 以前はソースコードのディレクトリとは別のディレクトリでビルド出来たはず
> ですが、久しぶりに試したらビルドに失敗しました。
> Makefileがビルド用のディレクトリではなくソースコードのディレクトリに作
> られてしまったりしています。

あれ？
なんでしょう。その辺、全然いじった記憶がないんですけど・・・。

-- 
.:% Masao Mutoh<mu...@hi...>

[ruby-gnome2-devel-ja] =?iso-2022-jp?B?GyRCSkwlRyUjJWwlLyVIJWokRyROJVMlayVJGyhC?=

[Masahiro S. () <sa...@to...>]

酒井です。

以前はソースコードのディレクトリとは別のディレクトリでビルド出来たはず
ですが、久しぶりに試したらビルドに失敗しました。
Makefileがビルド用のディレクトリではなくソースコードのディレクトリに作
られてしまったりしています。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] "warning: GRClosure invoking callback: already destroyed"

[Masao M. <mut...@gm...>]

むとうです。

On Thu, 25 May 2006 10:57:20 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
>
> From: Masao Mutoh <mu...@hi...>
> Date: Sat, 20 May 2006 13:13:39 +0900
>
> > むとうです。
>
> > > > 手元で試しましたが、少なくともCVS版では落ちません。
> > > > 理論上落ちるという話でしょうか。偶然なのかな。
> > > > なんか対応したっけ・・・・忘れてますが(苦笑)。
> > >
> > > 私の手元の環境では
> > > (eval):11: warning: GRClosure invoking callback: already destroyed
> > > が出ました。環境は
> > > * 昨日のCVSのRuby-GNOME2
> > > * ruby 1.9.0 (2006-01-19) [i386-cygwin]
> > > * Cygwin標準パッケージのgtk+ 2.6.10, glib 2.6.6
> > > です。
> >
> > うーん。なんでだろう。rubyが1.8.4だからなのかな・・・。
>
> GC周りはよくわからないですね。
>
> > > RubyのGCのmark phaseでrb_gc_mark()するという話です。
> > >
> > > # ついでに、オブジェクトのプロパティを同様にmarkするのも良さそう。
> > > # parentもプロパティなので須藤さんの案を包摂しますし。
> >
> > Gtk::TextViewとGtk::TextBufferはコンテナとその子供、という関係では
> > 無いので、この例では、gtk_container_forallの対応をしてもNGではないでしょうか。
>
> この場合Gtk::TextBufferはGtk::TextViewのbufferプロパティになっているので、
> プロパティをmarkするようにすればこの例についてはOKです。

なるほど・・・。
親玉をmarkする際に、そのときに存在するすべてのプロパティ値を
拾ってmarkするようにしてしまう、という感じですね。こちらは
コンテナ、GObjectならなんでも実施するという感じですね。

ところで、久しぶりに実装をお願いできませんか？

どうも私が実装するととんちんかんなことをしてしまいそうな気がして・・・。
その点、さかいさんなら安心です(^^;)。

それでは。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] GC related callback for Gtk.idle_add and Gtk.timeout_add.

[Masao M. <mu...@hi...>]

むとうです。

On Thu, 25 May 2006 11:14:08 +0900
"Kouhei Sutou" <ko...@co...> wrote:

> 須藤です．
> 
> 
> 06/05/25 に Kouhei Sutou<ko...@co...> さんは書きました:
> 
> > > できれば、glibの方もお願いしちゃってよろしいでしょうか？
> > > ＃rbglib_maincontext.cあたりかな。
> >
> > わかりました．
> > 明日やっておきます．
> 
> ざくっとやってみましたが，いくつか問題点が見えてきました．
> 
> * funcをそのままdataとしてg_idle_addしているわけではないので，
>   idle_removeが動かなくなる．

なるほど。正直、削除できなくてもいいやぁ、くらいで実装してしまった記憶が(^^;)。
idle_addの方で、
g_idle_addの戻り値をキーにしてfuncオブジェクトを保持して、
g_idle_removeの方は、g_idle_addの戻り値を引数として受け取って、そのfuncオブジェクト
を検索し、dataとして渡す、と言う感じでどうでしょうか？

> * GLib::Source.removeでG_REMOVE_RELATIVEしていないのでリーク
>   する．G_REMOVE_RELATIVEできるようにするには．．．GLib::Source
>   にG_RELATIVE2しておくとよいのかなぁ．．．

なるほど・・・。確かにそのような対応が必要そうですね。

> * GLib::Idle.addでpriorityも設定出来るようにした方がよさげだ
>   けど，現在はfuncをblockとしてではなくoptionalとして取得でき
>   るようになっているので，priorityを入れるための引数の順番が
>   悩ましい．

g_idle_add()からg_idle_add_full()にしたい、ってことですよね。

これ、API変えちゃいましょう。互換性を持たせておけばいいです。

GLib::Idle.add(&func)
GLib::Idle.add(priority, &func)

APIリファレンスからは前者をObsolete扱いで抜かしちゃえばいいでしょう。

idle_add(argc, argv, self)
{
    VALUE arg1, arg2;

    rb_scan_args(argc, argv, "02", &arg1, &arg2);

    if arg1 がProc
    else arg1がpriority

   


-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] GC related callback for Gtk.idle_add and Gtk.timeout_add.

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

須藤です．


06/05/25 に Kouhei Sutou<ko...@co...> さんは書きました:

> > できれば、glibの方もお願いしちゃってよろしいでしょうか？
> > ＃rbglib_maincontext.cあたりかな。
>
> わかりました．
> 明日やっておきます．

ざくっとやってみましたが，いくつか問題点が見えてきました．

* funcをそのままdataとしてg_idle_addしているわけではないので，
  idle_removeが動かなくなる．

* GLib::Source.removeでG_REMOVE_RELATIVEしていないのでリーク
  する．G_REMOVE_RELATIVEできるようにするには．．．GLib::Source
  にG_RELATIVE2しておくとよいのかなぁ．．．

* GLib::Idle.addでpriorityも設定出来るようにした方がよさげだ
  けど，現在はfuncをblockとしてではなくoptionalとして取得でき
  るようになっているので，priorityを入れるための引数の順番が
  悩ましい．

Re: [ruby-gnome2-devel-ja] "warning: GRClosure invoking callback: already destroyed"

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Sat, 20 May 2006 13:13:39 +0900

> むとうです。

> > > 手元で試しましたが、少なくともCVS版では落ちません。
> > > 理論上落ちるという話でしょうか。偶然なのかな。
> > > なんか対応したっけ・・・・忘れてますが(苦笑)。
> > 
> > 私の手元の環境では
> > (eval):11: warning: GRClosure invoking callback: already destroyed
> > が出ました。環境は
> > * 昨日のCVSのRuby-GNOME2
> > * ruby 1.9.0 (2006-01-19) [i386-cygwin]
> > * Cygwin標準パッケージのgtk+ 2.6.10, glib 2.6.6
> > です。
> 
> うーん。なんでだろう。rubyが1.8.4だからなのかな・・・。

GC周りはよくわからないですね。

> > RubyのGCのmark phaseでrb_gc_mark()するという話です。
> > 
> > # ついでに、オブジェクトのプロパティを同様にmarkするのも良さそう。
> > # parentもプロパティなので須藤さんの案を包摂しますし。
> 
> Gtk::TextViewとGtk::TextBufferはコンテナとその子供、という関係では
> 無いので、この例では、gtk_container_forallの対応をしてもNGではないでしょうか。

この場合Gtk::TextBufferはGtk::TextViewのbufferプロパティになっているので、
プロパティをmarkするようにすればこの例についてはOKです。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] GC related callback for Gtk.idle_add and Gtk.timeout_add.

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

須藤です．

In <200...@hi...>
  "Re: [ruby-gnome2-devel-ja] GC related callback for Gtk.idle_add and Gtk.timeout_add." on Wed, 24 May 2006 23:06:04 +0900,
  Masao Mutoh <mu...@hi...> wrote:

> > とりあえずコミットしてもよいですか？
> 
> あ、はい、そうですね。お願いします。

コミットしました．

> できれば、glibの方もお願いしちゃってよろしいでしょうか？
> ＃rbglib_maincontext.cあたりかな。

わかりました．
明日やっておきます．

Re: [ruby-gnome2-devel-ja] GC related callback for Gtk.idle_add and Gtk.timeout_add.

[Masao M. <mu...@hi...>]

むとうです。

On Wed, 24 May 2006 22:04:03 +0900 (JST)
Kouhei Sutou <ko...@co...> wrote:

> 須藤です．
> 
> In <200...@hi...>
>   "Re: [ruby-gnome2-devel-ja] GC related callback for Gtk.idle_add and Gtk.timeout_add." on Wed, 24 May 2006 21:57:40 +0900,
>   Masao Mutoh <mu...@hi...> wrote:
> 
> > 確かに効果がありました。
> > 
> > [:before, 201]
> > [:after, 101]
> > 
> > 101個は残るんですね・・・。そういうものなんでしょうか？
> > ぱっと見た限りでは0になるのかなぁ、と思っていたのですが・・・。
> 
> 繰り返しの間になにか処理を挟んでからまたGC.startすると消える
> かもしれませんが．．．
> 
> とりあえずコミットしてもよいですか？

あ、はい、そうですね。お願いします。

できれば、glibの方もお願いしちゃってよろしいでしょうか？
＃rbglib_maincontext.cあたりかな。


-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] GC related callback for Gtk.idle_add and Gtk.timeout_add.

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

須藤です．

In <200...@hi...>
  "Re: [ruby-gnome2-devel-ja] GC related callback for Gtk.idle_add and Gtk.timeout_add." on Wed, 24 May 2006 21:57:40 +0900,
  Masao Mutoh <mu...@hi...> wrote:

> 確かに効果がありました。
> 
> [:before, 201]
> [:after, 101]
> 
> 101個は残るんですね・・・。そういうものなんでしょうか？
> ぱっと見た限りでは0になるのかなぁ、と思っていたのですが・・・。

繰り返しの間になにか処理を挟んでからまたGC.startすると消える
かもしれませんが．．．

とりあえずコミットしてもよいですか？

Re: [ruby-gnome2-devel-ja] GC related callback for Gtk.idle_add and Gtk.timeout_add.

[Masao M. <mu...@hi...>]

むとうです。

On Wed, 24 May 2006 12:41:32 +0900
"Kouhei Sutou" <ko...@co...> wrote:

> 須藤です．
> 
> 06/05/24 に Masao Mutoh<mu...@hi...> さんは書きました:
> 
> > むむむ。パッチ試してみたのですが、私の環境だと
> >
> > [:before, 100]
> > [:after, 100]
> >
> > になっちゃいます...。なんでだろう。
> >
> > $ ruby -v
> > ruby 1.9.0 (2006-05-23) [i686-linux]
> > --enable-thread版、Sjoredパッチ付きのRuby/GLib2使用。
> 
> CVS版のrubyを使ったら私もそうなりました．
> が，以下のスクリプトならパッチの効果がわかりました．

確かに効果がありました。

[:before, 201]
[:after, 101]

101個は残るんですね・・・。そういうものなんでしょうか？
ぱっと見た限りでは0になるのかなぁ、と思っていたのですが・・・。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] GC related callback for Gtk.idle_add and Gtk.timeout_add.

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

須藤です．

06/05/24 に Masao Mutoh<mu...@hi...> さんは書きました:

> むむむ。パッチ試してみたのですが、私の環境だと
>
> [:before, 100]
> [:after, 100]
>
> になっちゃいます...。なんでだろう。
>
> $ ruby -v
> ruby 1.9.0 (2006-05-23) [i686-linux]
> --enable-thread版、Sjoredパッチ付きのRuby/GLib2使用。

CVS版のrubyを使ったら私もそうなりました．
が，以下のスクリプトならパッチの効果がわかりました．

---
require "gtk2"

Gtk.init

class A; end

def idle_start
  i = 100
  as = []
  Gtk.idle_add do
    as << A.new
    i -= 1
    if i.zero?
      Gtk.main_quit
      false
    else
      true
    end
  end
end

def idle_test
  idle_start
  Gtk.main
end

10.times do |i|
  idle_test
  p [:before, ObjectSpace.each_object(A) {}]
  GC.start
  p [:after, ObjectSpace.each_object(A) {}]
end
---

Re: [ruby-gnome2-devel-ja] GC related callback for Gtk.idle_add and Gtk.timeout_add.

[Masao M. <mu...@hi...>]

むとうです。

On Tue, 23 May 2006 11:56:52 +0900
"Kouhei Sutou" <ko...@co...> wrote:

> 須藤です．
> 
> 以下のようなスクリプトを実行すると，Gtk.idle_addに設定したコールバック
> が（もう呼ばれないのに）GCされずに残ってしまいます．このため，コールバッ
> クのクロージャが参照しているオブジェクトもGCされなくなってしまいます．

<snip>
 
> 実行結果:
> [:before, 100]
> [:after, 100]
> 
> 
> 添付のパッチを当てると，手元ではこんな実行結果になりました:
> [:before, 100]
> [:after, 2]
> 
> 
> # パッチ中で，id_relative_callbacksじゃなくてid__idle_callbacks__とかを
> # 使っているのはidleとかtimeoutでidが重複したら嫌だなぁと思ったからです．

むむむ。パッチ試してみたのですが、私の環境だと

[:before, 100]
[:after, 100]

になっちゃいます...。なんでだろう。

$ ruby -v
ruby 1.9.0 (2006-05-23) [i686-linux]
--enable-thread版、Sjoredパッチ付きのRuby/GLib2使用。

です。

-- 
.:% Masao Mutoh<mu...@hi...>

[ruby-gnome2-devel-ja] GC related callback for Gtk.idle_add and Gtk.timeout_add.

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

須藤です．

以下のようなスクリプトを実行すると，Gtk.idle_addに設定したコールバック
が（もう呼ばれないのに）GCされずに残ってしまいます．このため，コールバッ
クのクロージャが参照しているオブジェクトもGCされなくなってしまいます．

---
require "gtk2"

Gtk.init

class A; end

def idle_start
  i = 100
  as = []
  Gtk.idle_add do
    as << A.new
    i -= 1
    if i.zero?
      Gtk.main_quit
      false
    else
      true
    end
  end
end

idle_start

Gtk.main

p [:before, ObjectSpace.each_object(A) {}]
GC.start
p [:after, ObjectSpace.each_object(A) {}]
---

実行結果:
[:before, 100]
[:after, 100]


添付のパッチを当てると，手元ではこんな実行結果になりました:
[:before, 100]
[:after, 2]


# パッチ中で，id_relative_callbacksじゃなくてid__idle_callbacks__とかを
# 使っているのはidleとかtimeoutでidが重複したら嫌だなぁと思ったからです．

Re: [ruby-gnome2-devel-ja] Ruby/Vte

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

須藤です．

In <200...@hi...>
  "Re: [ruby-gnome2-devel-ja] Ruby/Vte" on Thu, 18 May 2006 00:04:32 +0900,
  Masao Mutoh <mu...@hi...> wrote:

> > ドキュメントは明日の日中にでも．．．

報告おくれましたがやっておきました．

> それは助かります。ところでenの方でアナウンスしませんか？
> 次のリリースには含めるからデバッグよろしく！みたいな。

こちらもやっておきました．
ただ，私の書き方が悪いのだと思いますが，リアクションがないの
がなんとも．．．

Re: [ruby-gnome2-devel-ja] "warning: GRClosure invoking callback: already destroyed"

[Masao M. <mu...@hi...>]

むとうです。

On Sat, 20 May 2006 04:12:02 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
> 
> From: Masao Mutoh <mu...@hi...>
> Date: Sat, 20 May 2006 02:37:56 +0900
> 
> > むとうです。
> 
> > > 実際に現在のコードで問題が起こる例を探してみました。
> > > 
> > >   fsel = Gtk::FileSelection.new
> > >   fsel.ok_button.signal_connect('clicked'){}
> > >   GC.start
> > >   fsel.ok_button.clicked
> > > 
> > > この場合には返り値との間に親子関係が成立することがあらかじめ分かってい
> > > るので、ok_button内でG_CHILD_ADDすれば良いですが、そうでない場合にはよ
> > > り悩ましいと思います。
> > 
> > 手元で試しましたが、少なくともCVS版では落ちません。
> > 理論上落ちるという話でしょうか。偶然なのかな。
> > なんか対応したっけ・・・・忘れてますが(苦笑)。
> 
> 私の手元の環境では
> (eval):11: warning: GRClosure invoking callback: already destroyed
> が出ました。環境は
> * 昨日のCVSのRuby-GNOME2
> * ruby 1.9.0 (2006-01-19) [i386-cygwin]
> * Cygwin標準パッケージのgtk+ 2.6.10, glib 2.6.6
> です。

うーん。なんでだろう。rubyが1.8.4だからなのかな・・・。
 
> > まぁ、でも理論的には、CHILD_ADD(CHILD_SETかな)すべし、
> > というのが正解だとは思うんですけど。
> 
> 親子関係が成立すると予めわかっている場合にはそれで良いのですが、
> そうでない場合にはどうします?
> 
> 例えば、このボタンがok_buttonメソッドの返り値としてではなく、
> 「現在のマウスポインタの直下のウィジェットを返す」という関数の返り値
> として渡ってきたとしたら……

確かにそれはあり得ますね。
 
> > > ではもう一つ見つけた例を。
> > > 
> > >   view = Gtk::TextView.new
> > >   iter = view.get_iter_at_location(0,0)
> > >   iter.buffer.signal_connect('changed'){ puts "changed" }
> > >   GC.start
> > >   view.insert_at_cursor("foo")
> > 
> > こちらも、私の環境では普通に動きますね・・・。
> 
> 同じく私の手元の環境ではエラーになりました。
> 
> > こちらも理論的には、iter.bufferでCHILD_SETすべし、というのが正解だとは思うんですけど。
> 
> そう簡単にはいかないよう少し嫌らしい例にしてあります(^^;
> 普通iterはbufferよりも寿命の短いオブジェクトなので、iterからbufferを参
> 照させるだけでは解決にはならず、解決にはbufferの本当の所有者であるview 
> からbufferを参照させなければなりません。しかし、iter自身はviewへの参照
> を持っていないので、iter.bufferの変更だけで対処することは出来ません。

なるほど・・・。
 
> 一つの解決法はGtk::TextView.newでbufferをCHILD_SETすることでしょう。
> iter.bufferの変更という局所的な変更で解決出来ないのは良い気分ではない
> ですが、とにかく一応は解決は出来ます。
> 
> しかし、もし同様の状況で仮にviewからbufferへの参照を得るAPIも存在しな
> いとしたらどうでしょうか。その場合にはこのような方法すら取れないわけ
> で……

うーん、そこまで考えていませんでした。
 
> > > それと、Gtk::Container(とその派生クラス)ではmark時にgtk_container_forallで
> > > 子供を列挙してmarkすべきですね。そうすれば、コンテナの場合の親子関係に
> > > ついては個別に対処する必要はなくなると思います。
> > 
> > それって、例えばGtk::FileSelection.newしたタイミングで実施するイメージですかね。
> 
> 違います。
> RubyのGCのmark phaseでrb_gc_mark()するという話です。
> 
> # ついでに、オブジェクトのプロパティを同様にmarkするのも良さそう。
> # parentもプロパティなので須藤さんの案を包摂しますし。

Gtk::TextViewとGtk::TextBufferはコンテナとその子供、という関係では
無いので、この例では、gtk_container_forallの対応をしてもNGではないでしょうか。

なんかまだ消化不良みたいです。いつものことですが（苦笑）

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] "warning: GRClosure invoking callback: already destroyed"

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Sat, 20 May 2006 02:37:56 +0900

> むとうです。

> > 実際に現在のコードで問題が起こる例を探してみました。
> > 
> >   fsel = Gtk::FileSelection.new
> >   fsel.ok_button.signal_connect('clicked'){}
> >   GC.start
> >   fsel.ok_button.clicked
> > 
> > この場合には返り値との間に親子関係が成立することがあらかじめ分かってい
> > るので、ok_button内でG_CHILD_ADDすれば良いですが、そうでない場合にはよ
> > り悩ましいと思います。
> 
> 手元で試しましたが、少なくともCVS版では落ちません。
> 理論上落ちるという話でしょうか。偶然なのかな。
> なんか対応したっけ・・・・忘れてますが(苦笑)。

私の手元の環境では
(eval):11: warning: GRClosure invoking callback: already destroyed
が出ました。環境は
* 昨日のCVSのRuby-GNOME2
* ruby 1.9.0 (2006-01-19) [i386-cygwin]
* Cygwin標準パッケージのgtk+ 2.6.10, glib 2.6.6
です。

> まぁ、でも理論的には、CHILD_ADD(CHILD_SETかな)すべし、
> というのが正解だとは思うんですけど。

親子関係が成立すると予めわかっている場合にはそれで良いのですが、
そうでない場合にはどうします?

例えば、このボタンがok_buttonメソッドの返り値としてではなく、
「現在のマウスポインタの直下のウィジェットを返す」という関数の返り値
として渡ってきたとしたら……

> > ではもう一つ見つけた例を。
> > 
> >   view = Gtk::TextView.new
> >   iter = view.get_iter_at_location(0,0)
> >   iter.buffer.signal_connect('changed'){ puts "changed" }
> >   GC.start
> >   view.insert_at_cursor("foo")
> 
> こちらも、私の環境では普通に動きますね・・・。

同じく私の手元の環境ではエラーになりました。

> こちらも理論的には、iter.bufferでCHILD_SETすべし、というのが正解だとは思うんですけど。

そう簡単にはいかないよう少し嫌らしい例にしてあります(^^;
普通iterはbufferよりも寿命の短いオブジェクトなので、iterからbufferを参
照させるだけでは解決にはならず、解決にはbufferの本当の所有者であるview 
からbufferを参照させなければなりません。しかし、iter自身はviewへの参照
を持っていないので、iter.bufferの変更だけで対処することは出来ません。

一つの解決法はGtk::TextView.newでbufferをCHILD_SETすることでしょう。
iter.bufferの変更という局所的な変更で解決出来ないのは良い気分ではない
ですが、とにかく一応は解決は出来ます。

しかし、もし同様の状況で仮にviewからbufferへの参照を得るAPIも存在しな
いとしたらどうでしょうか。その場合にはこのような方法すら取れないわけ
で……

> > それと、Gtk::Container(とその派生クラス)ではmark時にgtk_container_forallで
> > 子供を列挙してmarkすべきですね。そうすれば、コンテナの場合の親子関係に
> > ついては個別に対処する必要はなくなると思います。
> 
> それって、例えばGtk::FileSelection.newしたタイミングで実施するイメージですかね。

違います。
RubyのGCのmark phaseでrb_gc_mark()するという話です。

# ついでに、オブジェクトのプロパティを同様にmarkするのも良さそう。
# parentもプロパティなので須藤さんの案を包摂しますし。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] "warning: GRClosure invoking callback: already destroyed"

[Masao M. <mu...@hi...>]

むとうです。

On Fri, 19 May 2006 18:51:53 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
> 
> From: Masao Mutoh <mu...@hi...>
> Date: Wed, 17 May 2006 23:28:14 +0900
> 
> > むとうです。
> > 
> > 先をこされてしまった（笑）。
> > 
> > さかいさん、ご無沙汰です。お元気でしょうか。
> 
> 元気ですよ。
> むとうさんもRHG読書会とかに来てくれれば会えるのに(^^;

いやぁ、私がRHG読書会なんて出席したらきっと無口な人だなぁ、
と思われちゃいますよ（苦笑）。
 
> > なので、おっしゃるとおり、gtk側による影響は確かにあるかもされませんですけど、
> > どうなんでしょう。通常に使ってる分には問題ないと思ってますが・・・。
> 
> 確かに大抵の場合には問題ないとは思いますが……

この件は次のメールにて。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] "warning: GRClosure invoking callback: already destroyed"

[Masao M. <mu...@hi...>]

むとうです。

On Fri, 19 May 2006 19:10:25 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
> 
> From: "Kouhei Sutou" <ko...@co...>
> Date: Thu, 18 May 2006 14:37:06 +0900
> 
> > 須藤です．
> > 
> > 06/05/18 に 酒井政裕 Masahiro Sakai<sa...@to...> さんは書きました:
> > 
> > > 例えばgtk側でオブジェクトの参照関係の変更が発生する場合には、
> > > 新しい参照関係に対してG_CHILD_ADDしなおす必要がありますよね。
> > 
> > うーん，こんな場合ですかねぇ．．．
> > 
> >   xxx = widget.get_xxx # (*)
> >   xxx.signal_connect("...") {}
> >   xxx = nil
> >   GC.start
> > 
> > (*): get_xxxはなにかGTK+内部で勝手に作ったウィジェットを返す．
> 
> 実際に現在のコードで問題が起こる例を探してみました。
> 
>   fsel = Gtk::FileSelection.new
>   fsel.ok_button.signal_connect('clicked'){}
>   GC.start
>   fsel.ok_button.clicked
> 
> この場合には返り値との間に親子関係が成立することがあらかじめ分かってい
> るので、ok_button内でG_CHILD_ADDすれば良いですが、そうでない場合にはよ
> り悩ましいと思います。

手元で試しましたが、少なくともCVS版では落ちません。
理論上落ちるという話でしょうか。偶然なのかな。
なんか対応したっけ・・・・忘れてますが(苦笑)。

まぁ、でも理論的には、CHILD_ADD(CHILD_SETかな)すべし、
というのが正解だとは思うんですけど。

require 'gtk2'
Gtk.init
fsel = Gtk::FileSelection.new
fsel.ok_button.signal_connect('clicked'){p "a"}
GC.start
GC.start
GC.start
GC.start
GC.start
fsel.ok_button.clicked

> > > ですが、それはgtk側での参照関係の変更がどんなタイミングで発生するかを
> > > すべて把握していないと不可能で、新たなライブラリや将来のgtkの内部変更
> > > も考えると、それが果たして現実的な解なのか...私にはわからないです。
> > 
> > 不可能かもしれないですけど，数はそんなに多くないと思うので現実的だと思い
> > ます．あ，見付けたらそのつど直していくぐらいでいいんじゃないかという意味
> > ですけど．．．
> 
> ではもう一つ見つけた例を。
> 
>   view = Gtk::TextView.new
>   iter = view.get_iter_at_location(0,0)
>   iter.buffer.signal_connect('changed'){ puts "changed" }
>   GC.start
>   view.insert_at_cursor("foo")

こちらも、私の環境では普通に動きますね・・・。
こちらも理論的には、iter.bufferでCHILD_SETすべし、というのが正解だとは思うんですけど。

> > # あ，widget->parentがあるやつはmarkしておくというのはどうだろう．
> 
> それは良いと思います。

良いとは思うのですが、このコードを入れる場所が悩ましいですね。
Ruby/GLibにif(obj.class.gtk?)みたいなコードは入れたくないですし・・・。
 
> それと、Gtk::Container(とその派生クラス)ではmark時にgtk_container_forallで
> 子供を列挙してmarkすべきですね。そうすれば、コンテナの場合の親子関係に
> ついては個別に対処する必要はなくなると思います。

それって、例えばGtk::FileSelection.newしたタイミングで実施するイメージですかね。
確かにその方が確実かつ修正範囲が少ないとは思うのですが、それだと、性能劣化がちょっと
いやだなぁ。fsel.ok_buttonなんかで取得する際にG_CHILD_SETをこつこつ
やっていった方が、Lazyで性能的には良いと思うのですけど。

ひとまず、上記の部分はG_CHILD_SETを入れておきます。他に良いアイデアが出てきたら
そのときに削除すればいいでしょう、ということで。
＃ GOBJ2RVALP(obj, parent) みたいなマクロがあると良いのだろうか。

他にも気づいたら言ってくださいませ。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] "warning: GRClosure invoking callback: already destroyed"

[Masahiro S. () <sa...@to...>]

酒井です。

From: "Kouhei Sutou" <ko...@co...>
Date: Thu, 18 May 2006 14:37:06 +0900

> 須藤です．
> 
> 06/05/18 に 酒井政裕 Masahiro Sakai<sa...@to...> さんは書きました:
> 
> > 例えばgtk側でオブジェクトの参照関係の変更が発生する場合には、
> > 新しい参照関係に対してG_CHILD_ADDしなおす必要がありますよね。
> 
> うーん，こんな場合ですかねぇ．．．
> 
>   xxx = widget.get_xxx # (*)
>   xxx.signal_connect("...") {}
>   xxx = nil
>   GC.start
> 
> (*): get_xxxはなにかGTK+内部で勝手に作ったウィジェットを返す．

実際に現在のコードで問題が起こる例を探してみました。

  fsel = Gtk::FileSelection.new
  fsel.ok_button.signal_connect('clicked'){}
  GC.start
  fsel.ok_button.clicked

この場合には返り値との間に親子関係が成立することがあらかじめ分かってい
るので、ok_button内でG_CHILD_ADDすれば良いですが、そうでない場合にはよ
り悩ましいと思います。

> > ですが、それはgtk側での参照関係の変更がどんなタイミングで発生するかを
> > すべて把握していないと不可能で、新たなライブラリや将来のgtkの内部変更
> > も考えると、それが果たして現実的な解なのか...私にはわからないです。
> 
> 不可能かもしれないですけど，数はそんなに多くないと思うので現実的だと思い
> ます．あ，見付けたらそのつど直していくぐらいでいいんじゃないかという意味
> ですけど．．．

ではもう一つ見つけた例を。

  view = Gtk::TextView.new
  iter = view.get_iter_at_location(0,0)
  iter.buffer.signal_connect('changed'){ puts "changed" }
  GC.start
  view.insert_at_cursor("foo")

> # あ，widget->parentがあるやつはmarkしておくというのはどうだろう．

それは良いと思います。

それと、Gtk::Container(とその派生クラス)ではmark時にgtk_container_forallで
子供を列挙してmarkすべきですね。そうすれば、コンテナの場合の親子関係に
ついては個別に対処する必要はなくなると思います。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] "warning: GRClosure invoking callback: already destroyed"

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Wed, 17 May 2006 23:28:14 +0900

> むとうです。
> 
> 先をこされてしまった（笑）。
> 
> さかいさん、ご無沙汰です。お元気でしょうか。

元気ですよ。
むとうさんもRHG読書会とかに来てくれれば会えるのに(^^;

> なので、おっしゃるとおり、gtk側による影響は確かにあるかもされませんですけど、
> どうなんでしょう。通常に使ってる分には問題ないと思ってますが・・・。

確かに大抵の場合には問題ないとは思いますが……

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Ruby/Poppler

[Masao M. <mu...@hi...>]

むとうです。

On Thu, 18 May 2006 22:38:39 +0900 (JST)
Kouhei Sutou <ko...@co...> wrote:

> 須藤です．
> 
> In <200...@hi...>
>   "Re: [ruby-gnome2-devel-ja] Ruby/Poppler" on Thu, 18 May 2006 22:16:06 +0900,
>   Masao Mutoh <mu...@hi...> wrote:
> 
> > ＃なんとなく一緒のプロジェクトになってくれると嬉しいように思うのですが、
> > ＃やっぱり難しいんでしょうかねぇ。
> 
> え！？それは嫌です．
> cairoは単に出力デバイス（と出力するためのAPI）を抽象化してい
> るだけだと私は思っているので，cairoが入力のAPIまで抱えてしま
> うのはちょっと．．．

あー、別にRuby-GNOME2で一緒にしようという話ではないですのでお気に
なさらぬよう。

単に入力・出力両方サポートしたライブラリがあれば使う方は楽で良いのにな、
という話、というか個人的な感想です。
 
> PopplerはC++なので，一緒にしようとするとcairo側もPoppler側も
> お互い不幸になる気がします．
> 
> # おまけにPopplerのソースはそんなによさげじゃないですし．．．

そうなんですか。それじゃぁ一緒にはならないでしょうね。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] Ruby/Poppler

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

須藤です．

In <200...@hi...>
  "Re: [ruby-gnome2-devel-ja] Ruby/Poppler" on Thu, 18 May 2006 22:16:06 +0900,
  Masao Mutoh <mu...@hi...> wrote:

> ＃なんとなく一緒のプロジェクトになってくれると嬉しいように思うのですが、
> ＃やっぱり難しいんでしょうかねぇ。

え！？それは嫌です．
cairoは単に出力デバイス（と出力するためのAPI）を抽象化してい
るだけだと私は思っているので，cairoが入力のAPIまで抱えてしま
うのはちょっと．．．

PopplerはC++なので，一緒にしようとするとcairo側もPoppler側も
お互い不幸になる気がします．

# おまけにPopplerのソースはそんなによさげじゃないですし．．．

Re: [ruby-gnome2-devel-ja] Ruby/Poppler

[Masao M. <mu...@hi...>]

むとうです。

On Thu, 18 May 2006 22:07:04 +0900 (JST)
Kouhei Sutou <ko...@co...> wrote:

> 須藤です．
> 
> In <200...@hi...>
>   "Re: [ruby-gnome2-devel-ja] Ruby/Poppler" on Thu, 18 May 2006 21:46:34 +0900,
>   Masao Mutoh <mu...@hi...> wrote:
> 
> > ちょっと質問の仕方が悪かったです。CairoってPDF出力機能持ってますよね？
> > だとすると、PopplerもCairoもPDFに出力できる、という意味では重複してる
> > んじゃないかなと。
> > とすると、内部的な描画に関してはAPIが違うにしてもPoppler/Cairoともに
> > 同じことができるんじゃないかと思ったわけです。
> 
> あ，なるほど．
> それだと少し勘違いしていると思います．
> 
> > ひょっとして、入力にPDFが使えるかどうか、という差なのでしょうか？
> 
> そうですね．
> こんな感じです．
> 
> PDF       -> Poppler -> Pixbuf/cairo
> (Poppler) -> cairo   -> PNG/PS/PDF/Gdk::Drawable

なるほど。納得できました。

＃なんとなく一緒のプロジェクトになってくれると嬉しいように思うのですが、
＃やっぱり難しいんでしょうかねぇ。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] Ruby/Poppler

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

須藤です．

In <200...@hi...>
  "Re: [ruby-gnome2-devel-ja] Ruby/Poppler" on Thu, 18 May 2006 21:46:34 +0900,
  Masao Mutoh <mu...@hi...> wrote:

> ちょっと質問の仕方が悪かったです。CairoってPDF出力機能持ってますよね？
> だとすると、PopplerもCairoもPDFに出力できる、という意味では重複してる
> んじゃないかなと。
> とすると、内部的な描画に関してはAPIが違うにしてもPoppler/Cairoともに
> 同じことができるんじゃないかと思ったわけです。

あ，なるほど．
それだと少し勘違いしていると思います．

> ひょっとして、入力にPDFが使えるかどうか、という差なのでしょうか？

そうですね．
こんな感じです．

PDF       -> Poppler -> Pixbuf/cairo
(Poppler) -> cairo   -> PNG/PS/PDF/Gdk::Drawable

Re: [ruby-gnome2-devel-ja] Ruby/Poppler

[Masao M. <mu...@hi...>]

むとうです。

On Thu, 18 May 2006 10:09:21 +0900
"Kouhei Sutou" <ko...@co...> wrote:

> 須藤です．
> 
> 
> 06/05/18 に Masao Mutoh<mu...@hi...> さんは書きました:
> 
> > Ruby/PopplerとRuby/Cairoの守備範囲の違いって何でしょうか？
> > 微妙にかぶっているような・・・。
> 
> Poppler自体はcairoを使って描画しています．
> PDFをパースして，描画位置を決めたりしているのがPopplerだと思います．
> GTK+(GDK)と同じでPopplerもcairoをバックエンドとして使っているという
> ことです．
> 
> Ruby/Popplerもrcairo(Cairo::Context)を使って描画できます．
> rcairoを使わないでPDFをレンダリングする場合はPixbufとして出力します．
> 
> と，こんな感じでわかりますか？

ちょっと質問の仕方が悪かったです。CairoってPDF出力機能持ってますよね？
だとすると、PopplerもCairoもPDFに出力できる、という意味では重複してる
んじゃないかなと。
とすると、内部的な描画に関してはAPIが違うにしてもPoppler/Cairoともに
同じことができるんじゃないかと思ったわけです。

ひょっとして、入力にPDFが使えるかどうか、という差なのでしょうか？

-- 
.:% Masao Mutoh<mu...@hi...>