Menu
▾
▴
ruby-gnome2-devel-ja
|
From: Kouhei S. <ko...@co...> - 2006-05-17 05:35:32
|
須藤です． gnome-terminalなどで使われているターミナルエミュレータウィジェットの ライブラリであるVTEのバインディングを作りました． http://pub.cozmixng.org/~kou/archives/vte.tar.gz Ruby/Popplerもそうですが，これもRuby-GNOME2のリポジトリに入れていいで すか？ |
|
From: Masao M. <mu...@hi...> - 2006-05-17 11:57:17
|
むとうです。 On Wed, 17 May 2006 14:35:28 +0900 "Kouhei Sutou" <ko...@co...> wrote: > 須藤です． > > gnome-terminalなどで使われているターミナルエミュレータウィジェットの > ライブラリであるVTEのバインディングを作りました． > http://pub.cozmixng.org/~kou/archives/vte.tar.gz う、すごい勢いですね・・・。 > Ruby/Popplerもそうですが，これもRuby-GNOME2のリポジトリに入れていいで > すか？ いいですよん。APIドキュメントの方もお願いしますね。 ＃ruby-gstremaerの0.10.0対応を待って、次のリリースを考えましょうか・・・。 ところで、enの方で起こってる主にjoao関係の問題、 手伝っていただけないでしょうか。なんか難しいッス。 -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masao M. <mu...@hi...> - 2006-05-17 14:09:18
|
むとうです。 On Wed, 17 May 2006 21:09:53 +0900 (JST) Kouhei Sutou <ko...@co...> wrote: > 須藤です． > > > Ruby/Popplerもそうですが，これもRuby-GNOME2のリポジトリに入れていいで > > > すか？ > > > > いいですよん。APIドキュメントの方もお願いしますね。 > > ありがとうございます． > 徐々にやっていきます．．． よろしくです。;)。 > > ＃ruby-gstremaerの0.10.0対応を待って、次のリリースを考えましょうか・・・。 > > あれ？これってうまく進んでいるんでしたっけ？ Sjoerdが今enでがんばってるのはRuby/Gstreamerを改修しているからのようです。 そのついでにRuby/GLibにも手を入れているという。 といっても、今のところ彼の手元で修正かけているようです。 彼が彼自身でリリースしたいのなら、Ruby-GNOME2からforkしてもらっても良いかなぁ、 と思ってます（んでRuby-GNOME2からは削除）。 もちろん、マージしたいと言うことでしたらマージしますけどね。Ruby/GStreamerは 正直よくわかっていないんですよね（苦笑）。 にしてもSjoerdすごいですね。須藤さんもすごいですけどね ;)。 > > ところで、enの方で起こってる主にjoao関係の問題、 > > 手伝っていただけないでしょうか。なんか難しいッス。 > > ちょうど今から見てみようと思っていたところです． > 手元に，彼から直接もらった独自ライブラリがあるのでそれを少し > 動かしてみようと思います． ありがとうございます。 G_CHILD_ADD関係はまだ残っているかもしれませんね・・・。 次のリリースまでに膿を出し切れると良いのですが。 -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masao M. <mu...@hi...> - 2006-05-17 15:04:46
|
むとうです。 On Wed, 17 May 2006 23:49:02 +0900 (JST) Kouhei Sutou <ko...@co...> wrote: > 須藤です． > > In <200...@hi...> > "Re: [ruby-gnome2-devel-ja] Ruby/Vte" on Wed, 17 May 2006 23:09:10 +0900, > Masao Mutoh <mu...@hi...> wrote: > > > > > > Ruby/Popplerもそうですが，これもRuby-GNOME2のリポジトリに入れていいで > > > > > すか？ > > > > > > > > いいですよん。APIドキュメントの方もお願いしますね。 > > > > > > ありがとうございます． > > > 徐々にやっていきます．．． > > > > よろしくです。;)。 > > ぶちこんじゃいました． > ドキュメントは明日の日中にでも．．． それは助かります。ところでenの方でアナウンスしませんか？ 次のリリースには含めるからデバッグよろしく！みたいな。 > > といっても、今のところ彼の手元で修正かけているようです。 > > 彼が彼自身でリリースしたいのなら、Ruby-GNOME2からforkしてもらっても良いかなぁ、 > > と思ってます（んでRuby-GNOME2からは削除）。 > > もちろん、マージしたいと言うことでしたらマージしますけどね。Ruby/GStreamerは > > 正直よくわかっていないんですよね（苦笑）。 > > Ruby/GStreamerというかGStreamerが．．． いやぁ、そっちもSjoerdが直しちゃうんじゃないでしょうか。 ＃ちょっと願望も込めて。 > > にしてもSjoerdすごいですね。須藤さんもすごいですけどね ;)。 > > むとうさんもすごいです． > 隣の席の人といつも「続けることが大事なんだ」と言っています． > パクりまくっています． あはは。それはどうも。 どうも自分はきれいにコード書いたり、きれいな実装したり、 よいアイデアを思いついたりする才能がイマイチということわかりましたので、 まぁ、続けることも一つの才能だと思って必死でしがみついてますよ（苦笑）。 > > G_CHILD_ADD関係はまだ残っているかもしれませんね・・・。 > > 次のリリースまでに膿を出し切れると良いのですが。 > > 今使っているRuby/GTK+アプリケーションをHEADで動かしてもらう > のが一番いいと思うんですけど，常用されているRuby/GTK+アプリ > ケーションってあるのかしら．．． それを言われると痛いですね（苦笑）。 では、Rabbitで、と言いたいところですが、Rabbitが全てのコンポーネントを 網羅しているわけでも無いですしね・・・。gtk-demoあたりはまともに動いている と思うんですが・・・。 偶然GCが行われなかったら発生しなかったりするわけで、そういった意味でも 難しいですよねぇ。まぁ、その辺はオープンソースですから（にやり）。 -- .:% Masao Mutoh<mu...@hi...> |
|
From: Kouhei S. <ko...@co...> - 2006-05-21 10:40:23
|
須藤です． 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の方でアナウンスしませんか？ > 次のリリースには含めるからデバッグよろしく！みたいな。 こちらもやっておきました． ただ，私の書き方が悪いのだと思いますが，リアクションがないの がなんとも．．． |
|
From: Kouhei S. <ko...@co...> - 2006-05-17 14:18:30
|
須藤です．
In <200...@to...>
"[ruby-gnome2-devel-ja] "warning: GRClosure invoking callback: already destroyed"" on Wed, 17 May 2006 23:01:59 +0900 (JST),
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> 最近のRuby/GLib2のコードはあまり真面目に読んでいないですが、
> 多分以下のようなことが起きているのではないでしょうか。
正解です．
> b = Gtk::Button.new
> b.signal_connect('clicked'){ }
>
> # (中略) 「ボタンのgtk側オブジェクトはgtk側できちんと参照されているが、
> # Ruby側のオブジェクトは(変数b以外からは)辿れない」という状態になる。(1)
>
> b = nil
> GC.start
> # ボタンのRuby側オブジェクトがGCされ、GRClosureHolderもGCされ、
> # GRClosureのcountが0になる。
>
> # その後ボタンがクリックされる。
> # => "warning: GRClosure invoking callback: already destroyed"
>
> 現在のRuby-GNOME2は(1)のような状況が起らないようG_CHILD_ADD等で
> 頑張っているみたいですが、Ruby-GNOME2側でいくら頑張っても、
> gtk側のコードでオブジェクトの参照関係が変化するような場合もあるので、
> そのような状況を完全に排除するのは現実的ではないでしょう。
GTK+側でごにょごにょやっていても，G_CHILD_REMOVEが呼ばれない
限りRuby側の参照がなくなりはしないので，リークはするかもしれ
ないですがRuby側のボタンがGCされることはない気がします．
といっても，↑は適当に書いているので実際に酒井さんのいうケー
スがでるかもしれないです．私にはわからないです．
|
|
From: Kouhei S. <ko...@co...> - 2006-05-18 05:37:12
|
須藤です．
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+内部で勝手に作ったウィジェットを返す．
> ですが、それはgtk側での参照関係の変更がどんなタイミングで発生するかを
> すべて把握していないと不可能で、新たなライブラリや将来のgtkの内部変更
> も考えると、それが果たして現実的な解なのか...私にはわからないです。
不可能かもしれないですけど，数はそんなに多くないと思うので現実的だと思い
ます．あ，見付けたらそのつど直していくぐらいでいいんじゃないかという意味
ですけど．．．
# あ，widget->parentがあるやつはmarkしておくというのはどうだろう．
|
|
From: Masao M. <mu...@hi...> - 2006-05-19 17:38:12
|
むとうです。
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...>
|
|
From: Masao M. <mu...@hi...> - 2006-05-20 04:13:47
|
むとうです。
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...>
|
|
From: Masahiro S. ()
<sa...@to...> - 2006-05-25 01:59:08
|
酒井です。 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 |
|
From: Masahiro S. ()
<sa...@to...> - 2006-05-19 19:15:26
|
酒井です。
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
|
|
From: Masahiro S. ()
<sa...@to...> - 2006-05-19 10:12:04
|
酒井です。
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
|
|
From: Kouhei S. <ko...@co...> - 2006-05-17 14:49:08
|
須藤です． In <200...@hi...> "Re: [ruby-gnome2-devel-ja] Ruby/Vte" on Wed, 17 May 2006 23:09:10 +0900, Masao Mutoh <mu...@hi...> wrote: > > > > Ruby/Popplerもそうですが，これもRuby-GNOME2のリポジトリに入れていいで > > > > すか？ > > > > > > いいですよん。APIドキュメントの方もお願いしますね。 > > > > ありがとうございます． > > 徐々にやっていきます．．． > > よろしくです。;)。 ぶちこんじゃいました． ドキュメントは明日の日中にでも．．． > といっても、今のところ彼の手元で修正かけているようです。 > 彼が彼自身でリリースしたいのなら、Ruby-GNOME2からforkしてもらっても良いかなぁ、 > と思ってます（んでRuby-GNOME2からは削除）。 > もちろん、マージしたいと言うことでしたらマージしますけどね。Ruby/GStreamerは > 正直よくわかっていないんですよね（苦笑）。 Ruby/GStreamerというかGStreamerが．．． > にしてもSjoerdすごいですね。須藤さんもすごいですけどね ;)。 むとうさんもすごいです． 隣の席の人といつも「続けることが大事なんだ」と言っています． パクりまくっています． > G_CHILD_ADD関係はまだ残っているかもしれませんね・・・。 > 次のリリースまでに膿を出し切れると良いのですが。 今使っているRuby/GTK+アプリケーションをHEADで動かしてもらう のが一番いいと思うんですけど，常用されているRuby/GTK+アプリ ケーションってあるのかしら．．． |
|
From: Masahiro S. ()
<sa...@to...> - 2006-05-17 16:23:59
|
酒井です。 From: Kouhei Sutou <ko...@co...> Date: Wed, 17 May 2006 23:18:21 +0900 (JST) > 須藤です． > GTK+側でごにょごにょやっていても，G_CHILD_REMOVEが呼ばれない > 限りRuby側の参照がなくなりはしないので，リークはするかもしれ > ないですがRuby側のボタンがGCされることはない気がします． > > といっても，↑は適当に書いているので実際に酒井さんのいうケー > スがでるかもしれないです．私にはわからないです． 例えばgtk側でオブジェクトの参照関係の変更が発生する場合には、 新しい参照関係に対してG_CHILD_ADDしなおす必要がありますよね。 ですが、それはgtk側での参照関係の変更がどんなタイミングで発生するかを すべて把握していないと不可能で、新たなライブラリや将来のgtkの内部変更 も考えると、それが果たして現実的な解なのか...私にはわからないです。 -- 酒井 政裕 / Masahiro Sakai |
|
From: Kouhei S. <ko...@co...> - 2006-05-17 12:10:10
|
須藤です． In <200...@hi...> "Re: [ruby-gnome2-devel-ja] Ruby/Vte" on Wed, 17 May 2006 20:57:05 +0900, Masao Mutoh <mu...@hi...> wrote: > > gnome-terminalなどで使われているターミナルエミュレータウィジェットの > > ライブラリであるVTEのバインディングを作りました． > > http://pub.cozmixng.org/~kou/archives/vte.tar.gz > > う、すごい勢いですね・・・。 ははは．．． > > Ruby/Popplerもそうですが，これもRuby-GNOME2のリポジトリに入れていいで > > すか？ > > いいですよん。APIドキュメントの方もお願いしますね。 ありがとうございます． 徐々にやっていきます．．． > ＃ruby-gstremaerの0.10.0対応を待って、次のリリースを考えましょうか・・・。 あれ？これってうまく進んでいるんでしたっけ？ > ところで、enの方で起こってる主にjoao関係の問題、 > 手伝っていただけないでしょうか。なんか難しいッス。 ちょうど今から見てみようと思っていたところです． 手元に，彼から直接もらった独自ライブラリがあるのでそれを少し 動かしてみようと思います． |
|
From: Masahiro S. ()
<sa...@to...> - 2006-05-17 14:02:28
|
酒井です。
ご無沙汰しています。
From: Masao Mutoh <mu...@hi...>
Date: Wed, 17 May 2006 20:57:05 +0900
> むとうです。
> ところで、enの方で起こってる主にjoao関係の問題、
最近のRuby/GLib2のコードはあまり真面目に読んでいないですが、
多分以下のようなことが起きているのではないでしょうか。
b = Gtk::Button.new
b.signal_connect('clicked'){ }
# (中略) 「ボタンのgtk側オブジェクトはgtk側できちんと参照されているが、
# Ruby側のオブジェクトは(変数b以外からは)辿れない」という状態になる。(1)
b = nil
GC.start
# ボタンのRuby側オブジェクトがGCされ、GRClosureHolderもGCされ、
# GRClosureのcountが0になる。
# その後ボタンがクリックされる。
# => "warning: GRClosure invoking callback: already destroyed"
現在のRuby-GNOME2は(1)のような状況が起らないようG_CHILD_ADD等で
頑張っているみたいですが、Ruby-GNOME2側でいくら頑張っても、
gtk側のコードでオブジェクトの参照関係が変化するような場合もあるので、
そのような状況を完全に排除するのは現実的ではないでしょう。
--
酒井 政裕 / Masahiro Sakai
|
|
From: Masao M. <mu...@hi...> - 2006-05-17 14:28:22
|
むとうです。
先をこされてしまった（笑）。
さかいさん、ご無沙汰です。お元気でしょうか。
On Wed, 17 May 2006 23:18:21 +0900 (JST)
Kouhei Sutou <ko...@co...> wrote:
> 須藤です．
>
> In <200...@to...>
> "[ruby-gnome2-devel-ja] "warning: GRClosure invoking callback: already destroyed"" on Wed, 17 May 2006 23:01:59 +0900 (JST),
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
>
> > 最近のRuby/GLib2のコードはあまり真面目に読んでいないですが、
> > 多分以下のようなことが起きているのではないでしょうか。
>
> 正解です．
>
> > b = Gtk::Button.new
> > b.signal_connect('clicked'){ }
> >
> > # (中略) 「ボタンのgtk側オブジェクトはgtk側できちんと参照されているが、
> > # Ruby側のオブジェクトは(変数b以外からは)辿れない」という状態になる。(1)
> >
> > b = nil
> > GC.start
> > # ボタンのRuby側オブジェクトがGCされ、GRClosureHolderもGCされ、
> > # GRClosureのcountが0になる。
> >
> > # その後ボタンがクリックされる。
> > # => "warning: GRClosure invoking callback: already destroyed"
> >
> > 現在のRuby-GNOME2は(1)のような状況が起らないようG_CHILD_ADD等で
> > 頑張っているみたいですが、Ruby-GNOME2側でいくら頑張っても、
> > gtk側のコードでオブジェクトの参照関係が変化するような場合もあるので、
> > そのような状況を完全に排除するのは現実的ではないでしょう。
>
> GTK+側でごにょごにょやっていても，G_CHILD_REMOVEが呼ばれない
> 限りRuby側の参照がなくなりはしないので，リークはするかもしれ
> ないですがRuby側のボタンがGCされることはない気がします．
>
> といっても，↑は適当に書いているので実際に酒井さんのいうケー
> スがでるかもしれないです．私にはわからないです．
須藤さんもご指摘されているとおり、
少なくとも上記のRuby側による問題、については解決している・・・と思ってます。
きちんとGtk::Window等のウィンドウオブジェクトにaddされたウィジェットで
あれば、b = nilされてもGCの対象にはなりません。
逆に、ウィンドウオブジェクトにaddされていないオブジェクトでこのエラーメッセージ
が出るのはやむなし、だと思っています。その場合はユーザ側でGCされないような
工夫をすればよいかなと。
なので、おっしゃるとおり、gtk側による影響は確かにあるかもされませんですけど、
どうなんでしょう。通常に使ってる分には問題ないと思ってますが・・・。
＃でも、そのケースって、RubyのオブジェクトがGCされていなくても
＃問題出そうな気もします。
--
.:% Masao Mutoh<mu...@hi...>
|
|
From: Masahiro S. ()
<sa...@to...> - 2006-05-19 09:52:11
|
酒井です。 From: Masao Mutoh <mu...@hi...> Date: Wed, 17 May 2006 23:28:14 +0900 > むとうです。 > > 先をこされてしまった（笑）。 > > さかいさん、ご無沙汰です。お元気でしょうか。 元気ですよ。 むとうさんもRHG読書会とかに来てくれれば会えるのに(^^; > なので、おっしゃるとおり、gtk側による影響は確かにあるかもされませんですけど、 > どうなんでしょう。通常に使ってる分には問題ないと思ってますが・・・。 確かに大抵の場合には問題ないとは思いますが…… -- 酒井 政裕 / Masahiro Sakai |
|
From: Masao M. <mu...@hi...> - 2006-05-19 17:38:20
|
むとうです。 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...> |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X