From: KUBO T. <ku...@ji...> - 2004-11-14 03:24:59
|
久保です。 遅れました。m(__)m Masao Mutoh <mu...@hi...> writes: > うーむ、まだ出ますか...。 > たぶん、libgnomecanvasとgtk+でのg_object_refの内部での使い方あたりの > 違いに問題があるんじゃないかなぁ、と思ってはいるのですが...。 GnomeCanvas が削除された後に GnomeCanvasItem が削除されて、 - gnome_canvas_item_dispose() - redraw_if_visible() - gnome_canvas_request_redraw() --> GnomeCanvas は削除されているのでwarning となっているところまではつきとめました。 とりあえずは rbgnome-canvas-item.c の citem_intialize() で g_object_ref(group); の代りに g_object_ref(_SELF(self)); とするとwarningは消えるのですが、これは明らかに間違った対処方法(二重ref) なのでCVSに入れるわけにはいかない。 うーむ。今週リリースですよね。 問題ではあるけど coredump するとかいった critical な問題ではないので known bug としてリリースしてしまっても良いかな。 # 次に私が作業できるのは水曜以降(これから仕事)となるので。m(__)m -- 久保 健洋 email: ku...@ji... web: http://www.jiubao.org GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1 9F47 C001 1F93 AC08 2262 |
From: Masao M. <mu...@hi...> - 2004-11-14 09:53:47
|
むとうです。 On Sun, 14 Nov 2004 19:51:05 +0900 KUBO Takehiro <ku...@ji...> wrote: > 久保です。 > > うーむ、まだ出ますか...。 > > たぶん、libgnomecanvasとgtk+でのg_object_refの内部での使い方あたりの > > 違いに問題があるんじゃないかなぁ、と思ってはいるのですが...。 > > GnomeCanvas が削除された後に GnomeCanvasItem が削除されて、 > > - gnome_canvas_item_dispose() > - redraw_if_visible() > - gnome_canvas_request_redraw() > --> GnomeCanvas は削除されているのでwarning > > となっているところまではつきとめました。 > とりあえずは rbgnome-canvas-item.c の citem_intialize() で > g_object_ref(group); > の代りに > g_object_ref(_SELF(self)); > とするとwarningは消えるのですが、これは明らかに間違った対処方法(二重ref) > なのでCVSに入れるわけにはいかない。 他のやつもこの辺が問題だったんですよね。 この現象ってrequest_redrawする前段階に二重にunrefされてるから GnomeCanvasが削除されてるんですよね。 だとすれば、二重refであっても、それが適正な回数であれば問題ないと思います。 問題は適正かどうかなのですが、これはこれで難しそうですね。 この場合のメモリリークは許容範囲内かもしれないですし(^^;)。 もしかしたら他のメソッドでg_object_refをしないといけない場所があるのかも しれませんね。 ちなみに、これって、久保さんの環境だとサンプルでも再現しますか? というのは私の環境ではもうこの現象出ていないんですよね。 > うーむ。今週リリースですよね。 はい。今作業中です。 > 問題ではあるけど coredump するとかいった critical な問題ではないので > known bug としてリリースしてしまっても良いかな。 そうしましょう。 > # 次に私が作業できるのは水曜以降(これから仕事)となるので。m(__)m そ、それはお疲れさまですm(__)m。 -- .:% Masao Mutoh<mu...@hi...> |
From: KUBO T. <ku...@ji...> - 2004-11-21 10:29:16
|
久保です。 Masao Mutoh <mu...@hi...> writes: >> GnomeCanvas が削除された後に GnomeCanvasItem が削除されて、 >> >> - gnome_canvas_item_dispose() >> - redraw_if_visible() >> - gnome_canvas_request_redraw() >> --> GnomeCanvas は削除されているのでwarning >> >> となっているところまではつきとめました。 >> とりあえずは rbgnome-canvas-item.c の citem_intialize() で >> g_object_ref(group); >> の代りに >> g_object_ref(_SELF(self)); >> とするとwarningは消えるのですが、これは明らかに間違った対処方法(二重ref) >> なのでCVSに入れるわけにはいかない。 > > 他のやつもこの辺が問題だったんですよね。 > > この現象ってrequest_redrawする前段階に二重にunrefされてるから > GnomeCanvasが削除されてるんですよね。 いいえ。GnomeCanvas が削除されること自体は問題ないのですが、その時点で GnomeCanvasItem が ruby 側から ref されているのが問題なのではないかと 思います。おそらく GnomeCanvasItem は GnomeCanvas のみから参照されてい るという前提ではないかと。 試しに ruby 側からの ref をなくすために gnomecanvas/sample/canvas.rb に以下のパッチを当てて実行したところ、終了時のエラーが出なくなりました。 # signal_connect を無効化させているのは、signal_connect は ruby オブジェ # クトへの参照を保持している場合があるためです。 citem_intialize() の g_object_ref(group) を消した状態でも同じです。 ---------------------- ここから ---------------------- --- canvas.rb.~1.5.~ 2002-11-05 20:26:21.000000000 +0900 +++ canvas.rb 2004-11-21 17:36:23.000000000 +0900 @@ -40,6 +40,14 @@ require 'canvas-rich-text' require 'canvas-curve' +module Gnome + class CanvasItem + def signal_connect(*dummy) + # do nothing + end + end +end + class CanvasSample < Gtk::Window def initialize super(Gtk::Window::TOPLEVEL) @@ -64,5 +72,6 @@ Gtk.init canvas = CanvasSample.new() +GC.start Gtk::main() ---------------------- ここまで ---------------------- > だとすれば、二重refであっても、それが適正な回数であれば問題ないと思います。 > 問題は適正かどうかなのですが、これはこれで難しそうですね。 > この場合のメモリリークは許容範囲内かもしれないですし(^^;)。 glib のソースの g_object_last_unref() に手を加えて個々のオブジェクトが 削除されるタイミングを見たところ、citem_intialize() に g_object_ref(group) がついている状態だと GnomeCanvasGroup は最後まで削 除されませんでした。おそらくむとうさんのところでエラーが消えたのは libgnomecanvas 側、ruby 側両方の終了処理が終わっても GnomeCanvasGroup の ref が残っていて最後まで gnome_canvas_item_dispose() が呼ばれなかっ たためではないかと思います。 > もしかしたら他のメソッドでg_object_refをしないといけない場所があるのかも > しれませんね。 Ruby/GLib2 に手をいれないといけないような予感が....。 今の Ruby/GLib2 だと、GObject に対応する ruby object を生成すると GObject の refcount が 1 上がるのですが、refcount を上げずに weakref のみで参照する ruby object が必要かも。 > ちなみに、これって、久保さんの環境だとサンプルでも再現しますか? > というのは私の環境ではもうこの現象出ていないんですよね。 再現しています。 あと、むとうさんの今日の commit で、エラー時の core dump がまた起きる ようになりました。finalizer が走っている最中に例外が上がると core を吐 くようです。 では、再見 -- 久保 健洋 email: ku...@ji... web: http://www.jiubao.org GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1 9F47 C001 1F93 AC08 2262 |
From: Masao M. <mu...@hi...> - 2004-11-21 13:46:55
|
むとうです。 On Mon, 22 Nov 2004 02:55:43 +0900 KUBO Takehiro <ku...@ji...> wrote: > 久保です。 > > Masao Mutoh <mu...@hi...> writes: > > >> GnomeCanvas が削除された後に GnomeCanvasItem が削除されて、 > >> > >> - gnome_canvas_item_dispose() > >> - redraw_if_visible() > >> - gnome_canvas_request_redraw() > >> --> GnomeCanvas は削除されているのでwarning > >> > >> となっているところまではつきとめました。 > >> とりあえずは rbgnome-canvas-item.c の citem_intialize() で > >> g_object_ref(group); > >> の代りに > >> g_object_ref(_SELF(self)); > >> とするとwarningは消えるのですが、これは明らかに間違った対処方法(二重ref) > >> なのでCVSに入れるわけにはいかない。 > > > > 他のやつもこの辺が問題だったんですよね。 > > > > この現象ってrequest_redrawする前段階に二重にunrefされてるから > > GnomeCanvasが削除されてるんですよね。 > > いいえ。GnomeCanvas が削除されること自体は問題ないのですが、その時点で > GnomeCanvasItem が ruby 側から ref されているのが問題なのではないかと > 思います。おそらく GnomeCanvasItem は GnomeCanvas のみから参照されてい > るという前提ではないかと。 > 試しに ruby 側からの ref をなくすために gnomecanvas/sample/canvas.rb > に以下のパッチを当てて実行したところ、終了時のエラーが出なくなりました。 > # signal_connect を無効化させているのは、signal_connect は ruby オブジェ > # クトへの参照を保持している場合があるためです。 > > citem_intialize() の g_object_ref(group) を消した状態でも同じです。 > > だとすれば、二重refであっても、それが適正な回数であれば問題ないと思います。 > > 問題は適正かどうかなのですが、これはこれで難しそうですね。 > > この場合のメモリリークは許容範囲内かもしれないですし(^^;)。 > > glib のソースの g_object_last_unref() に手を加えて個々のオブジェクトが > 削除されるタイミングを見たところ、citem_intialize() に > g_object_ref(group) がついている状態だと GnomeCanvasGroup は最後まで削 > 除されませんでした。おそらくむとうさんのところでエラーが消えたのは > libgnomecanvas 側、ruby 側両方の終了処理が終わっても GnomeCanvasGroup > の ref が残っていて最後まで gnome_canvas_item_dispose() が呼ばれなかっ > たためではないかと思います。 > > > もしかしたら他のメソッドでg_object_refをしないといけない場所があるのかも > > しれませんね。 > Ruby/GLib2 に手をいれないといけないような予感が....。 > 今の Ruby/GLib2 だと、GObject に対応する ruby object を生成すると > GObject の refcount が 1 上がるのですが、refcount を上げずに weakref > のみで参照する ruby object が必要かも。 なるほど...。 あ、もしかして、RBGTK_INITIALIZEでg_object_refしてるのもマズイですかねぇ。 一度、そのあたりを見直す時期なのかもしれませんね。 > > ちなみに、これって、久保さんの環境だとサンプルでも再現しますか? > > というのは私の環境ではもうこの現象出ていないんですよね。 > > 再現しています。 うーん、なんでだろう。やっぱり何かのバージョンの違いなのかなぁ。 > あと、むとうさんの今日の commit で、エラー時の core dump がまた起きる > ようになりました。finalizer が走っている最中に例外が上がると core を吐 > くようです。 げげっ、すみません。直します。うぬぬぬ。 -- .:% Masao Mutoh<mu...@hi...> |
From: KUBO T. <ku...@ji...> - 2004-11-21 18:00:27
|
久保です。 Masao Mutoh <mu...@hi...> writes: >> Ruby/GLib2 に手をいれないといけないような予感が....。 >> 今の Ruby/GLib2 だと、GObject に対応する ruby object を生成すると >> GObject の refcount が 1 上がるのですが、refcount を上げずに weakref >> のみで参照する ruby object が必要かも。 > > なるほど...。 > あ、もしかして、RBGTK_INITIALIZEでg_object_refしてるのもマズイですかねぇ。 > 一度、そのあたりを見直す時期なのかもしれませんね。 少なくとも GnomeCanvasItem の場合は GObject の refcount は上げないほう が良さそうですが、一律に同じ変更を加えると他の GtkObject で逆に問題を 起こしそうな感じがします。 # というか、quick hack でやってみたら落ちた....。 GtkObject と GnomeCanvasItem の使用方法の違いが影響しているのかも。 例えば、GtkObject は Object を生成してからどこかに所属させるという手順 で使用しますが、GnomeCanvasItem は Object を生成する時点でどこに所属さ せるかを指定させます。これが Object の管理方法の違いに影響しているので はないかと推測しています。 # 現時点では単なる推測です。確認していません。p(^^;) >> > ちなみに、これって、久保さんの環境だとサンプルでも再現しますか? >> > というのは私の環境ではもうこの現象出ていないんですよね。 >> >> 再現しています。 > > うーん、なんでだろう。やっぱり何かのバージョンの違いなのかなぁ。 依存するとしたら、finalizer が ruby object を free する順番かな。 では、再見 -- 久保 健洋 email: ku...@ji... web: http://www.jiubao.org GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1 9F47 C001 1F93 AC08 2262 |
From: Masao M. <mu...@hi...> - 2004-11-22 13:58:44
|
むとうです。 On Mon, 22 Nov 2004 10:18:18 +0900 KUBO Takehiro <ku...@ji...> wrote: > 久保です。 > > Masao Mutoh <mu...@hi...> writes: > > >> Ruby/GLib2 に手をいれないといけないような予感が....。 > >> 今の Ruby/GLib2 だと、GObject に対応する ruby object を生成すると > >> GObject の refcount が 1 上がるのですが、refcount を上げずに weakref > >> のみで参照する ruby object が必要かも。 > > > > なるほど...。 > > あ、もしかして、RBGTK_INITIALIZEでg_object_refしてるのもマズイですかねぇ。 > > 一度、そのあたりを見直す時期なのかもしれませんね。 > > 少なくとも GnomeCanvasItem の場合は GObject の refcount は上げないほう > が良さそうですが、一律に同じ変更を加えると他の GtkObject で逆に問題を > 起こしそうな感じがします。 > # というか、quick hack でやってみたら落ちた....。 実は私もやってみました... がダメでした... orz。 > GtkObject と GnomeCanvasItem の使用方法の違いが影響しているのかも。 > 例えば、GtkObject は Object を生成してからどこかに所属させるという手順 > で使用しますが、GnomeCanvasItem は Object を生成する時点でどこに所属さ > せるかを指定させます。これが Object の管理方法の違いに影響しているので > はないかと推測しています。 > # 現時点では単なる推測です。確認していません。p(^^;) なるほど。まずはその辺を調べた方が良さそうですね。 もしかしたらGnomeCanvasのみで対応した方が良いかもしれない、という結論も あるかもしれませんね。 > >> > ちなみに、これって、久保さんの環境だとサンプルでも再現しますか? > >> > というのは私の環境ではもうこの現象出ていないんですよね。 > >> > >> 再現しています。 > > > > うーん、なんでだろう。やっぱり何かのバージョンの違いなのかなぁ。 > > 依存するとしたら、finalizer が ruby object を free する順番かな。 この辺、ややこしいですねぇ。うーん、またしばらく悩みますです。 -- .:% Masao Mutoh<mu...@hi...> |
From: Kouhei S. <ko...@co...> - 2004-10-14 05:22:56
|
須藤です. In <200...@hi...> "Re: [ruby-gnome2-devel-ja] Maintainer wanted" on Thu, 14 Oct 2004 01:51:34 +0900, Masao Mutoh <mu...@hi...> wrote: > あと、実は、CVSとリリースのポリシーというのがあります。 > > 1. [SourceForge]/ruby-gnome2/ruby-gnome2/xxxxx > > 2. [SourceForge]/ruby-gnome2/xxxxx > > gnomeprintの場合はどちらを取っていただいても結構です。 単独リリースする理由が見付からないので,1.でお願いします. > あと、もう一つ。これはお願い事なのですが、(おいおいで構わないので) > APIリファレンス(英語版)も書いていただけると....。 了解しました. # あぁ,書かなければいけないAPIリファレンスが増えていく... > > * Windows版のバイナリを用意してもらえるかも > > う、Windows版ですか...(^^;)。gnomeprint自体のWindows版って > どこかに転がってましたっけ? あ,やはりないんですか. FreeBSDのPortsのlibgnomeprintも2.6なので,気軽に遊べるように なるのはまだ先のようですね. > はい。ただ、後方互換性を考えると、リリースするまでに一度 > APIだけは見直しておいた方がいいと思います。 了解しました. > > gnome_print_config_get{,_boolean,_int,_double}()はそれぞれ別 > > ^^^ > > メソッドとしてマッピングしたままでよろしいですか? > > # できれば一つにまとめたいけど,どうしたらいいんだろう... > > そうなんです。そういった場合は元のまま別メソッド化するしかないですよね。 とりあえず,get_*(key)とget(key, type=:string)(typeに型を指 定すると対応するget_*に振り分ける)を用意しておこうと思いま す. > おっと、そうそう、須藤さんのSFのアカウントを教えてください。 ktouです. |
From: Masao M. <mu...@hi...> - 2004-10-17 15:59:52
|
むとうです。 On Wed, 13 Oct 2004 00:56:17 +0900 Masao Mutoh <mu...@hi...> wrote: > むとうです。 > > On Tue, 12 Oct 2004 23:51:25 +0900 (JST) > > Kouhei Sutou <ko...@co...> wrote: > > あ,このコードはlibgnomeprint 2.8以降を要求するので, > > extconf.rbでライブラリのバージョンをチェックできるとうれしい > > です. > > > > 例えばこんなのがあって > > > > module PKGConfig > > module_function > > def or_newer?(pkg, version) > > STDOUT.print("checking for #{pkg} version (>= #{version})... ") > > STDOUT.flush > > mod_version = `#{@@cmd} --modversion #{pkg}`.chomp > > result = (mod_version.split(".") <=> version.split(".")) >= 0 > > result_message = result ? "yes" : "no" > > STDOUT.print "#{result_message}\n" > > result > > end > > end > > > > こんな風に使えたらどうでしょうか. > > > > PKGConfig.or_newer?("libgnomeprint-2.2", "2.8") or exit 1 > > これいいですね。採用する方向で検討します。 > #名前はちょっと変えるかも...。 これですが、PKGConfig.have_package()のAPIを以下のようにバージョン 情報を入れれるよう変更しました。 PKGConfig.have_package(pkg, major = 0, minor = 0, micro = 0) libgnomeprintの場合、以下のようにすれば良いと思います。 PKGConfig.have_package("libgnomeprint-2.2", 2, 8) もちろん、今までと互換性は残したので現状のextconf.rbを変更する 必要はありません。 ちなみにPKGConfig.check_version?というメソッドも追加しましたが、 こちらを直接使う必要は無いでしょう。 #でも、これ見て、mkmf-gnome2.rbを全体的に書き直したくなって #しまいました...。(^^;) それでは。 -- .:% Masao Mutoh<mu...@hi...> |
From: Erwan L. <elo...@gm...> - 2004-10-13 07:17:28
|
5Yid44KB44G+44GX44Gm44CB44Ko44Ob44Ov44Oz44Gn44GZ44CCCgroi7Hoqp7jga7jg6rjgrnj g4jjgafoh6rlt7HntLnku4vjgZfjgZ/jgpPjgafjgZnjgYzjgIHku4rjgYvjgolSdWJ5L0dTdHJl YW1lcuOBqFJ1YnkvR3RrVHJheUljb27jgpLjg6Hjg7Pjg4bjg4rjg7PjgrnjgZfjgabjgb/jgb7j gZnjga7jgafjgojjgo3jgZfjgY/jgYrpoZjjgYTjgZfjgb7jgZnjgIIKCgotLSAKRXJ3YW4gTG9p c2FudAo= |
From: Masao M. <mu...@hi...> - 2004-10-13 15:59:13
|
はじめまして、エホワン。 Hi Erwan, メンテナのむとうです。よろしくお願いします。 I'm Masao Mutoh, Ruby-GNOME2 maintainer. Masao is first-name, and Mutoh is familiy name. So I usually use Masao in English ML but Mutoh in Japanese ML ;). さっそくですが。 実はgmailは、UTF-8を使っていますが、一部の日本語の メーラ(MUA)では、日本語が読めない場合があります。 通常は、ISO-2022-JPというcharsetを使います。 Actually, gmail uses UTF-8 for encoding messages. But usually Japanese MUA(mailer) uses ISO-2022-JP. Now, many MUA support UTF-8, too. But some japanese may be not read your messages. # And I'm afraid you can read japanese in this mail? gmail以外でメールすることは可能ですか? So, Could you use other MUA except gmail? I think it's no problem even Yahoo! mail(www.yahoo.co.jp). ご迷惑おかけしますがよろしくお願いします。 Sorry for incovenient. とにもかくにも、ようこそRuby-GNOME2 ProjectTeamへ。 Anyway, I should say, you're welcome! On Wed, 13 Oct 2004 16:17:08 +0900 Erwan Loisant <elo...@gm...> wrote: > 初めまして、エホワンです。 > > 英語のリストで自己紹介したんですが、今からRuby/GStreamerとRuby/GtkTrayIconをメンテナンスしてみますのでよろしくお願いします。 > > > -- > Erwan Loisant -- .:% Masao Mutoh<mu...@hi...> |
From: Kenichi.Tamura <sgs...@ni...> - 2004-10-15 13:36:17
|
たむらです。 Masao Mutoh wrote: >>MoonWolf氏のOne-Click Ruby Installer for Windows日本語版が >>Ruby-GNOME2を含むようになりました。 > > > おぉ、それはそれは。 > ご存じでしたら教えていただきたいのですが、 > それのコンパイル環境ってVCですか?MinGWですか? VCのフリー版ですね。 DotNot SDKとか。URL忘れちゃった。ircでMoonWolfさんに教えてあげたんだけど ただ、彼は情報共有というか、ステータスとか苦労したこととか日記以外に さらさないから、他の人から何やってるのか見えないんだよね。 > すごいですね。 > 各アプリがきちんとアップデートしつづけることができれば > RPA/Gemsより強力ですね(^^;)。 > > >>gtk-demo\main.rbで試すと最初の画面は表示される。いくつかは成功。 >>PixBuffのサンプルで落ちますた。 > > > うーん、なんでしょう。 > 近いうちに試してみます。 この辺は、るびまが明日リリースなので、来週ちょっと画面取りながら 見ようかと思ってます。 -- たむらけんいち<URL:htttp://www.rubyist.net/~tamura/d/> Gmailしたい方、メールください(残:5) |
From: Masao M. <mu...@hi...> - 2004-10-15 16:18:38
|
むとうです。 On Fri, 15 Oct 2004 22:35:46 +0900 "Kenichi.Tamura" <sgs...@ni...> wrote: > たむらです。 > > Masao Mutoh wrote: > >>MoonWolf氏のOne-Click Ruby Installer for Windows日本語版が > >>Ruby-GNOME2を含むようになりました。 > > > > > > おぉ、それはそれは。 > > ご存じでしたら教えていただきたいのですが、 > > それのコンパイル環境ってVCですか?MinGWですか? > > VCのフリー版ですね。 なるほど。でも、GTK+の方はMinGWですよね? てっきり、Ruby(VC) / Ruby/GTK2(MinGW) / GTK+(MinGW)という コンパイラの違いがまずいのかなぁと思ってたのですが...。 > DotNot SDKとか。URL忘れちゃった。ircでMoonWolfさんに教えてあげたんだけど > ただ、彼は情報共有というか、ステータスとか苦労したこととか日記以外に > さらさないから、他の人から何やってるのか見えないんだよね。 まぁ、日記はChangeLogではないですからねー、こればっかりは。 逆にCVSとか使えば良いような気はしますけどね。 > >>gtk-demo\main.rbで試すと最初の画面は表示される。いくつかは成功。 > >>PixBuffのサンプルで落ちますた。 > > > > うーん、なんでしょう。 > > 近いうちに試してみます。 > > この辺は、るびまが明日リリースなので、来週ちょっと画面取りながら > 見ようかと思ってます。 それは助かります。どーも、最近忙しくて...(T_T)。 -- .:% Masao Mutoh<mu...@hi...> |
From: Masao M. <mu...@hi...> - 2004-10-24 15:24:28
|
むとうです。 On Fri, 15 Oct 2004 22:35:46 +0900 "Kenichi.Tamura" <sgs...@ni...> wrote: > たむらです。 > > Masao Mutoh wrote: > >>MoonWolf氏のOne-Click Ruby Installer for Windows日本語版が > >>Ruby-GNOME2を含むようになりました。 > > > > > > おぉ、それはそれは。 > > ご存じでしたら教えていただきたいのですが、 > > それのコンパイル環境ってVCですか?MinGWですか? > > VCのフリー版ですね。 > DotNot SDKとか。URL忘れちゃった。ircでMoonWolfさんに教えてあげたんだけど > ただ、彼は情報共有というか、ステータスとか苦労したこととか日記以外に > さらさないから、他の人から何やってるのか見えないんだよね。 > >>gtk-demo\main.rbで試すと最初の画面は表示される。いくつかは成功。 > >>PixBuffのサンプルで落ちますた。 ふと気づいたのですが、One click Installer版でもMinGW版でも動くものもありますね。 やはり画像周りを扱うとダメなことが多いようです。 何か部分的に悪さしているところがありそうですね。うーん。 どなたか何か思い当たるフシとか経験とかお持ちの方いらっしゃいませんか? -- .:% Masao Mutoh<mu...@hi...> |