You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(47) |
Jul
(47) |
Aug
(75) |
Sep
(6) |
Oct
(5) |
Nov
|
Dec
(5) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(2) |
Feb
(5) |
Mar
(5) |
Apr
|
May
|
Jun
(1) |
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: KUBO T. <ku...@ji...> - 2002-08-18 05:57:15
|
久保@茅ヶ崎市です。 KUBO Takehiro <ku...@ji...> writes: > KUBO Takehiro <ku...@ji...> writes: > >> すみません。遅れてしまいましたが、 >> ・GtkArg 周りの変更 >> ・Gnome::CanvasItem#grab の BUG FIX >> ・Gnome::CanvasItem#get の実装 >> ・Gnome::CanvasGroup#item_new の変更 >> を行いたいので、今日中(というか明日の未明までに)パッチを出します。 > > ううむ。GtkArg 周りの変更の動作チェックしてたら、バグを埋め込んでしまっ > たようです。 > ちょっと時間がかかりそう.....。 わかってみると、単純でした。 *GTK_RELOC_XXX(*arg) = ???; とすべきところを GTK_VALUE_XXX(*arg) = ???; としていました。 では、GtkArg 周りの変更のパッチを出します。URL は http://www.jiubao.org/tmp/stage-2.dif です。 修正・追加したファイル 修正: gtk/src/global.c gtk/src/global.h gtk/src/rbgtk.c gtk/src/rbgtk.h gtk/src/rbgtkobject.c 追加: gtk/src/rbgtkarg.c 主な変更点は、 ・global.c の arg_to_value(), rbgtkobject.c の arg_set_value() を rbgtkarg.c の rbgtk_arg_get(), rbgtk_arg_set() へそれぞれ変更。 gtk/src/global.c 削除: VALUE arg_to_value(arg) gtk/src/rbgtkobject.c 削除: static void arg_set_value(arg, value) 変更: static void signal_setup_args(obj, sig, argc, params, args) 変更: void signal_callback(widget, data, nparams, params) ・ruby のオブジェクトの GtkArg への set/get の方式が埋め込みだったのを 動的に登録できるようにした。 # Gnome::CanvasItem#set の修正および, Gnome::CanvasItem#get 追加への布石 gtk/src/rbgtkarg.c 追加: void rbgtk_register_r2b_func(type, func) 追加: void rbgtk_register_b2r_func(type, func) 追加: void rbgtk_arg_init(arg, type, name); 追加: void rbgtk_arg_set(arg, obj); 追加: VALUE rbgtk_arg_get(arg); 追加: void Init_gtk_arg() gtk/src/rbgtk.c 修正: Init_gtk_gtk() 上記2点の変更にともなうヘッダファイルの修正 gtk/src/global.h gtk/src/rbgtk.h 以上です。 では、再見 -- 神奈川県茅ヶ崎市在住 久保 健洋 email: ku...@ji... web: http://www.jiubao.org GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1 9F47 C001 1F93 AC08 2262 |
From: KUBO T. <ku...@ji...> - 2002-08-18 02:37:05
|
久保@茅ヶ崎市です。 KUBO Takehiro <ku...@ji...> writes: > すみません。遅れてしまいましたが、 > ・GtkArg 周りの変更 > ・Gnome::CanvasItem#grab の BUG FIX > ・Gnome::CanvasItem#get の実装 > ・Gnome::CanvasGroup#item_new の変更 > を行いたいので、今日中(というか明日の未明までに)パッチを出します。 ううむ。GtkArg 周りの変更の動作チェックしてたら、バグを埋め込んでしまっ たようです。 ちょっと時間がかかりそう.....。 では、再見 -- 神奈川県茅ヶ崎市在住 久保 健洋 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...> - 2002-08-17 17:27:42
|
むとうです。 On Sun, 18 Aug 2002 01:00:10 +0900 KUBO Takehiro <ku...@ji...> wrote: > 久保@茅ヶ崎市です。 > > Masao Mutoh <mu...@hi...> writes: > > >> すみません。遅れてしまいましたが、 > >> ・GtkArg 周りの変更 > >> ・Gnome::CanvasItem#grab の BUG FIX > >> ・Gnome::CanvasItem#get の実装 > >> ・Gnome::CanvasGroup#item_new の変更 > >> を行いたいので、今日中(というか明日の未明までに)パッチを出します。 > >> > >> 手許では動いているのですが、パッチの整理をもう少ししたいもので。 > > まず、問題の起こらなそうなパッチを出します。上記4点のうち、2番目と 4番 > 目の修正です。URL は > http://www.jiubao.org/tmp/stage-1.dif > です。 ありがとうございます。 修正内容を詳しく書いていただいたのでとても助かりました。 CVSにあげておきましたので確認の方、お願いします。 > 修正内容: > (4) Gnome::CanvasGroup#item_new の内部ロジックの変更 > > 変更個所: > gnome/src/rbgnome-canvas-group.c > 削除: static int kind_of(klass, target) > 追加: void rbgnome_register_citem_type(klass, type) > 修正: static VALUE group_item_new(argc, argv, self) > 修正: void Init_gnome_canvas_group() > > gnome/src/rbgnome-canvas-item.c > 修正: void Init_gnome_canvas_item() > > gnome/src/rbgnome.h > 追加: void rbgnome_register_citem_type(VALUE, GtkType) > > 目的: > 元々の Gnome::CanvasGroup#item_new では、ruby のクラスと GtkType の > 対応が埋め込みになっていた。本パッチにより、ruby のクラスと GtkType > の対応を動的に登録できるようした。 > gdk-pixbuf に含まれる GnomeCanvasPixbuf 対応への布石です。 > # 現在のところ、GnomeCanvasPixbuf を始める予定はありません。m(__)m これなんですが、Ruby-GNOME2では(たぶん)gobjectの型システムの部分で 吸収できる部分があると思います。詳しくコード追っていないのでウソ言ってるかも しれませんが(^^;)。 > > あ、でも、リリースは8末にするつもりなので、そんなに急いでいただかなくて > > 結構ですよ。 > > 私は、"熱しやすくて冷めやすい"なんで、熱いうちにドバッとやったほうが良 > いのです。 > あと、締め切りがないと、いつまでもいじってばっかになりそうなんで。p(^^;) なるほど(^^;)。 メンテナとしてはパッチは小さい方が助かりますんで、今回みたいにキリが良い ところでちょこちょこ出してくださると助かります。 それでは。 -- .:% Masao Mutoh<mu...@hi...> |
From: KUBO T. <ku...@ji...> - 2002-08-17 16:02:22
|
久保@茅ヶ崎市です。 Masao Mutoh <mu...@hi...> writes: >> すみません。遅れてしまいましたが、 >> ・GtkArg 周りの変更 >> ・Gnome::CanvasItem#grab の BUG FIX >> ・Gnome::CanvasItem#get の実装 >> ・Gnome::CanvasGroup#item_new の変更 >> を行いたいので、今日中(というか明日の未明までに)パッチを出します。 >> >> 手許では動いているのですが、パッチの整理をもう少ししたいもので。 まず、問題の起こらなそうなパッチを出します。上記4点のうち、2番目と 4番 目の修正です。URL は http://www.jiubao.org/tmp/stage-1.dif です。 修正内容: (2) Gnome::CanvasItem#grab と Gnome::CanvasItem#ungrab の BUG 修正および、 それに対応するサンプルの修正 変更個所: gnome/src/rbgnome-canvas-item.c で修正した関数 citem_grab() citem_ungrab() gnome/sample/test-gnome/canvas-arrowhead.rb gnome/sample/test-gnome/canvas-primitives.rb 目的: test-gnome.rb の Gnome::Canvas のサンプルで、Primitives, Antialias, Arrowhead でドラッグしている最中、カーソルの形状が変わるようにした。 陳謝: カーソル形状が変わらないのはサンプルを書いたときから気付いてたが、 原因追及はしてなかった......。 (4) Gnome::CanvasGroup#item_new の内部ロジックの変更 変更個所: gnome/src/rbgnome-canvas-group.c 削除: static int kind_of(klass, target) 追加: void rbgnome_register_citem_type(klass, type) 修正: static VALUE group_item_new(argc, argv, self) 修正: void Init_gnome_canvas_group() gnome/src/rbgnome-canvas-item.c 修正: void Init_gnome_canvas_item() gnome/src/rbgnome.h 追加: void rbgnome_register_citem_type(VALUE, GtkType) 目的: 元々の Gnome::CanvasGroup#item_new では、ruby のクラスと GtkType の 対応が埋め込みになっていた。本パッチにより、ruby のクラスと GtkType の対応を動的に登録できるようした。 gdk-pixbuf に含まれる GnomeCanvasPixbuf 対応への布石です。 # 現在のところ、GnomeCanvasPixbuf を始める予定はありません。m(__)m 謝辞: さかいさんの Ruby-GNOME2 でのやりかたを参考にしました。 > あ、でも、リリースは8末にするつもりなので、そんなに急いでいただかなくて > 結構ですよ。 私は、"熱しやすくて冷めやすい"なんで、熱いうちにドバッとやったほうが良 いのです。 あと、締め切りがないと、いつまでもいじってばっかになりそうなんで。p(^^;) では、再見 -- 神奈川県茅ヶ崎市在住 久保 健洋 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...> - 2002-08-17 14:18:08
|
むとうです。 On Sat, 17 Aug 2002 09:02:17 +0900 KUBO Takehiro <ku...@ji...> wrote: > 久保%帰省中@茅ヶ崎市です。 > > Masao Mutoh <mu...@hi...> writes: > > > むとうです。 > > > > 結構、間があいてしまったし、今回はRuby/GNOME周りで > > 大幅な機能追加ができましたので、8末に新バージョンを > > リリースしようと思います。 > > 何かありましたら、それまでにどうぞ。 > > すみません。遅れてしまいましたが、 > ・GtkArg 周りの変更 > ・Gnome::CanvasItem#grab の BUG FIX > ・Gnome::CanvasItem#get の実装 > ・Gnome::CanvasGroup#item_new の変更 > を行いたいので、今日中(というか明日の未明までに)パッチを出します。 > > 手許では動いているのですが、パッチの整理をもう少ししたいもので。 すばらしい! あ、でも、リリースは8末にするつもりなので、そんなに急いでいただかなくて 結構ですよ。 それでは。 -- .:% Masao Mutoh<mu...@hi...> |
From: KUBO T. <ku...@ji...> - 2002-08-17 00:02:23
|
久保%帰省中@茅ヶ崎市です。 Masao Mutoh <mu...@hi...> writes: > むとうです。 > > 結構、間があいてしまったし、今回はRuby/GNOME周りで > 大幅な機能追加ができましたので、8末に新バージョンを > リリースしようと思います。 > 何かありましたら、それまでにどうぞ。 すみません。遅れてしまいましたが、 ・GtkArg 周りの変更 ・Gnome::CanvasItem#grab の BUG FIX ・Gnome::CanvasItem#get の実装 ・Gnome::CanvasGroup#item_new の変更 を行いたいので、今日中(というか明日の未明までに)パッチを出します。 手許では動いているのですが、パッチの整理をもう少ししたいもので。 では、再見 -- 神奈川県茅ヶ崎市在住 久保 健洋 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...> - 2002-08-16 15:48:57
|
むとうです。 結構、間があいてしまったし、今回はRuby/GNOME周りで 大幅な機能追加ができましたので、8末に新バージョンを リリースしようと思います。 何かありましたら、それまでにどうぞ。 -- .:% Masao Mutoh<mu...@hi...> |
From: Masao M. <mu...@hi...> - 2002-08-15 14:22:08
|
むとうです。 Daniel Carreraさんが、Ruby/GTKのチュートリアルを 作ってくださいました。 http://ruby-gnome.sourceforge.net/tutorial/ すばらしい! -- .:% Masao Mutoh<mu...@hi...> |
From: Masao M. <mu...@hi...> - 2002-08-07 14:46:08
|
むとうです。 On Wed, 07 Aug 2002 23:22:48 +0900 Masahiro Sakai <s01...@sf...> wrote: > さかいです。 > > From: Masahiro Sakai <s01...@sf...> > Subject: [ruby-gnome-users-ja] Re: Gimp-Ruby > Date: Wed, 31 Jul 2002 20:10:27 +0900 > > > 手元で少しコードを整理してからimportしてみます。 > > 報告が遅くなってしまいましたが、 > Gimp-Rubyをインポートしました。 > > 気が向いたら見てやって下さいませ。 ruby-gnome-users-enの方にもアナウンスしてみては? #つーかしちゃおうかな(^^;)。 -- .:% Masao Mutoh<mu...@hi...> |
From: Masahiro S. <s01...@sf...> - 2002-08-07 14:22:52
|
さかいです。 From: Masahiro Sakai <s01...@sf...> Subject: [ruby-gnome-users-ja] Re: Gimp-Ruby Date: Wed, 31 Jul 2002 20:10:27 +0900 > 手元で少しコードを整理してからimportしてみます。 報告が遅くなってしまいましたが、 Gimp-Rubyをインポートしました。 気が向いたら見てやって下さいませ。 -- さかい |
From: Masao M. <mu...@hi...> - 2002-08-06 12:56:39
|
むとうです。 On Tue, 06 Aug 2002 00:45:30 +0900 KUBO Takehiro <ku...@ji...> wrote: > 久保@茅ヶ崎市です。 > > Seiya Nishizawa <se...@ku...> writes: > > >> 上の例では GanvasRect の幅を試行錯誤で決めてます。本当は CanvasText の > >> 幅を取得して、それを使用するのが良いんですが、まだ実装されてません。実 > >> 装するとしたら、 > >> Gnome::CanvasText#get("text_width") > >> Gnome::CanvasText#get("text_height") > >> という API になるでしょう。 > > これはぜひほしいですね。(って他人まかせな発言ですが。) > > 一応作りました。 > ただ、正式なパッチではないです。 わかりました。 本パッチはCVSには反映させず正式なパッチを待ちます。 > GtkArg 関係のコードが、 > gnome/src/rbgnome-canvas-item.c の set_gtkarg() > gtk/src/rbgtkobject.c の arg_set_value() > gtk/src/global.c の arg_to_value() > に分散しているので、こいつを整理してから正式パッチを作成します。 ここかぁ。この辺は整理されてないのでちょっとイヤなところなんですよね...。 -- .:% Masao Mutoh<mu...@hi...> |
From: Masao M. <mu...@hi...> - 2002-08-06 12:53:31
|
むとうです。 On Mon, 05 Aug 2002 22:14:26 +0900 KUBO Takehiro <ku...@ji...> wrote: > 久保@茅ヶ崎市です。 > > 上記2点のパッチを > http://www.jiubao.org/tmp/art-affine.diff.gz > に置きました。 > > 変更の内訳: (略) ありがとうございます。パッチをCVSに反映させました。 ちなみに、sampleでRuby/Gnomeとなっている表記をRuby/GNOME にしました。 それにしても、久保さんはいとも簡単にサクッと実装されますね。 とても私にはかないません。脱帽です。 #って書くとちょっとえらそうかつ皮肉に聞こえるかもしれませんが #他意はありません。純粋に。 Ruby/GNOMEは未開拓な部分が多いのでもしよろしければ 他の部分もパチっていただけたらなと思います。 #あ、いや、あくまでもこちらの希望なんですが。 それでは。 -- .:% Masao Mutoh<mu...@hi...> |
From: KUBO T. <ku...@ji...> - 2002-08-05 15:48:37
|
久保@茅ヶ崎市です。 Seiya Nishizawa <se...@ku...> writes: >> 上の例では GanvasRect の幅を試行錯誤で決めてます。本当は CanvasText の >> 幅を取得して、それを使用するのが良いんですが、まだ実装されてません。実 >> 装するとしたら、 >> Gnome::CanvasText#get("text_width") >> Gnome::CanvasText#get("text_height") >> という API になるでしょう。 > これはぜひほしいですね。(って他人まかせな発言ですが。) 一応作りました。 patch 本体は、 http://www.jiubao.org/tmp/canvasitem-get.diff.gz で、西澤さんのソースをベースにしたサンプルが http://www.jiubao.org/tmp/canvasitem-get.rb にあります。 パッチの内容は、 ・Gnome::CanvasItem#set の単純化 (仕様を誤解してて複雑になってたのが半分になった) ・Gnome::CanvasItem#get の追加 です。 ただ、正式なパッチではないです。 GtkArg 関係のコードが、 gnome/src/rbgnome-canvas-item.c の set_gtkarg() gtk/src/rbgtkobject.c の arg_set_value() gtk/src/global.c の arg_to_value() に分散しているので、こいつを整理してから正式パッチを作成します。 では、再見 -- 神奈川県茅ヶ崎市在住 久保 健洋 email: ku...@ji... web: http://www.jiubao.org GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1 9F47 C001 1F93 AC08 2262 |
From: KUBO T. <ku...@ji...> - 2002-08-05 13:17:29
|
久保@茅ヶ崎市です。 Masao Mutoh <mu...@hi...> writes: >> メールとは別バージョンのパッチを >> http://www.jiubao.org/tmp/yet-another-patch.diff >> に置きました。 >> >> メールのパッチでは static のデータ構造に self を直接入れてましたが、 >> yet-another-patch では、stack 上にデータをとっています。 > > こちらにもう一つのメールの方のパッチをあててCVSにあげました。 ありがとうございます。 >> あとは、 >> ・Gnome::CanvasPoints#free の削除とそれに関係するサンプルの修正 >> ・Gnome::Canvas の Art::Affine 対応のやり直し >> ですね。 > > Gnome::CanvasPoints#ref, unrefも削除する方向でお願いします。 はい、これも削除しました。 上記2点のパッチを http://www.jiubao.org/tmp/art-affine.diff.gz に置きました。 変更の内訳: Art::Affine 対応 gnome/extconf.rb # インクルードファイルのパスを追加 gnome/src/lib/gnome.rb # require 'libart' を追加 gnome/src/rbgnome-canvas-item.c # 変更: affine_absolute, affine_relative # 新規: i2c_affine, i2w_affine gnome/src/rbgnome-canvas.c # 削除: w2c_affline # 新規: w2c_affine Gnome::CanvasPoints#free, ref, unref の 削除 gnome/sample/test-gnome/canvas-arrowhead.rb # points.free() を削除 gnome/sample/test-gnome/canvas-primitives.rb # points.free() を削除 gnome/src/rbgnome-canvas-util.c # free, ref, unref 削除 libart/sample/gnome-canvas.rb # points.free() を削除 > ところで、sample/gnome-canvas.rbが動かなくなっているようです。 > gnome-canvas.rb:67:in `affine_relative': wrong argument type Art::Affine (expected Array) > (TypeError) > from gnome-canvas.rb:67:in `setup_canvas_frame' > from gnome-canvas.rb:116:in `initialize' > from gnome-canvas.rb:108:in `upto' > from gnome-canvas.rb:108:in `initialize' > from gnome-canvas.rb:107:in `upto' > from gnome-canvas.rb:107:in `initialize' > from gnome-canvas.rb:125:in `new' > from gnome-canvas.rb:125:in `main' > from gnome-canvas.rb:129 Gnome::Canvas が Art::Affine 対応してなかったので、上のパッチで直りま す。 では、再見 -- 神奈川県茅ヶ崎市在住 久保 健洋 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...> - 2002-08-04 15:44:14
|
むとうです。 On Sun, 04 Aug 2002 22:28:27 +0900 KUBO Takehiro <ku...@ji...> wrote: > 久保@茅ヶ崎市です。 > > メールとは別バージョンのパッチを > http://www.jiubao.org/tmp/yet-another-patch.diff > に置きました。 > > メールのパッチでは static のデータ構造に self を直接入れてましたが、 > yet-another-patch では、stack 上にデータをとっています。 こちらにもう一つのメールの方のパッチをあててCVSにあげました。 > マルチスレッドで同時に同じコードが動くときには、stack 上にデータがある > のが良いけど、考えてみると ruby のマルチスレッドはネイティブスレッドで > はないのだから、ここまで考える必要がなかった.....。 まぁ、現状はそうですがこちらの方が良いと思います。 > あとは、 > ・Gnome::CanvasPoints#free の削除とそれに関係するサンプルの修正 > ・Gnome::Canvas の Art::Affine 対応のやり直し > ですね。 Gnome::CanvasPoints#ref, unrefも削除する方向でお願いします。 > libart モジュールを > http://www.jiubao.org/tmp/ruby-libart.tar.gz > に置きました。将来の拡張のため、ちょっと増長なファイル構成になってます。 > > ちゃんとメンテナにむとうさんの名前を書いておきました。(^^;) ありがとうございます。 READMEを変えてCVSにaddしました。次のRuby-GNOMEリリースから一緒にリリースしましょう。 ところで、sample/gnome-canvas.rbが動かなくなっているようです。 gnome-canvas.rb:67:in `affine_relative': wrong argument type Art::Affine (expected Array) (TypeError) from gnome-canvas.rb:67:in `setup_canvas_frame' from gnome-canvas.rb:116:in `initialize' from gnome-canvas.rb:108:in `upto' from gnome-canvas.rb:108:in `initialize' from gnome-canvas.rb:107:in `upto' from gnome-canvas.rb:107:in `initialize' from gnome-canvas.rb:125:in `new' from gnome-canvas.rb:125:in `main' from gnome-canvas.rb:129 取り急ぎ、ご報告まで。 -- .:% Masao Mutoh<mu...@hi...> |
From: KUBO T. <ku...@ji...> - 2002-08-04 14:22:13
|
久保@茅ヶ崎市です。 KUBO Takehiro <ku...@ji...> writes: >> もし、また出るようなことがあったらメールしますが、 >> ステータスとしては久保さんのパッチでフィクスできたということでお願いします。 >> #お手数おかけして申し訳ないです。 > > メールとは別バージョンのパッチを > http://www.jiubao.org/tmp/yet-another-patch.diff > に置きました。 すみません。commit して頂いたばかりなのに申し訳ありませんが、間違いが ありました。 ---------------- ここから ---------------- diff -u -r1.7 rbgnome-app-helper.c --- rbgnome-app-helper.c 4 Aug 2002 13:57:19 -0000 1.7 +++ rbgnome-app-helper.c 4 Aug 2002 14:12:15 -0000 @@ -365,7 +365,7 @@ inf = g_new(GnomeUIInfo, len + 2); inf[0].type = GNOME_APP_UI_BUILDER_DATA; inf[0].label = inf[0].hint = NULL; - inf[0].moreinfo = &RbGnome_UIBuilder; + inf[0].moreinfo = uibdata; ret = &inf[1]; } else { ret = inf = g_new(GnomeUIInfo, len + 1); ---------------- ここまで ---------------- が抜けてました。 ary_to_ui_info の引数を増やしたのはこのためだったのに忘れてました。m(__)m もっとも、ary_to_ui_info() の第二引数を真で呼ぶコードはないので、この 部分が走ることはありません。 将来的にも ary_to_ui_info() の第二引数が真になることがないのなら、 ary_to_ui_info() の引数は1つだけで十分でしょう。 では、再見 -- 神奈川県茅ヶ崎市在住 久保 健洋 email: ku...@ji... web: http://www.jiubao.org GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1 9F47 C001 1F93 AC08 2262 |
From: KUBO T. <ku...@ji...> - 2002-08-04 13:31:30
|
久保@茅ヶ崎市です。 Masao Mutoh <mu...@hi...> writes: > ...が、すみません、これ、私のコンパイル・インストールミスだと思います。 > 西澤さんのレポートを見てから、もしかして...と思ってRuby/GNOME関連の > ライブラリをmake cleanしてmakeし直したところ現象がでなくなりました。 ふぅ。なにはともあれ、解決して良かった。 > もし、また出るようなことがあったらメールしますが、 > ステータスとしては久保さんのパッチでフィクスできたということでお願いします。 > #お手数おかけして申し訳ないです。 メールとは別バージョンのパッチを http://www.jiubao.org/tmp/yet-another-patch.diff に置きました。 メールのパッチでは static のデータ構造に self を直接入れてましたが、 yet-another-patch では、stack 上にデータをとっています。 マルチスレッドで同時に同じコードが動くときには、stack 上にデータがある のが良いけど、考えてみると ruby のマルチスレッドはネイティブスレッドで はないのだから、ここまで考える必要がなかった.....。 うーん、メールのパッチで十分かな? あとは、 ・Gnome::CanvasPoints#free の削除とそれに関係するサンプルの修正 ・Gnome::Canvas の Art::Affine 対応のやり直し ですね。 >> たしかに、画面系にはあまり興味ありません。m(__)m >> それならどうして GnomeCanvas に手をつけたかというと、Linux で動くデー >> タベースの設計ツール(Erwinもどき)が欲しかったから。 > > Ruby-GNOMEで実装するのですか?それはすごい。 > 期待してます。 いえ、過去形です。今はそんな気力ない....。p(^^;) >> > 久保さんにやっていただくとホントは良いのかもしれませんが(^^;)、 >> > そこを押しつけるのもなんですので、私がメンテナを引き受けますよ。 >> お願いします。 > 了解です。 libart モジュールを http://www.jiubao.org/tmp/ruby-libart.tar.gz に置きました。将来の拡張のため、ちょっと増長なファイル構成になってます。 ちゃんとメンテナにむとうさんの名前を書いておきました。(^^;) では、再見 -- 神奈川県茅ヶ崎市在住 久保 健洋 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...> - 2002-08-04 12:16:06
|
むとうです。 On Sun, 04 Aug 2002 19:10:18 +0900 KUBO Takehiro <ku...@ji...> wrote: > 久保@茅ヶ崎市です。 > > Masao Mutoh <mu...@hi...> writes: > > > 試してみたのですが、まだ発生します。 > > ただ、前よりは落ちづらくなったような感じですので上のパッチは > > 効果があるかと思います。もしかしたら同様の問題がまだあるのかも > > しれませんね。 > > > > #上記の2.3.を多めに繰り返して試してみてください。 > > CVS のソース + 前のメールの ad-hoc パッチで 2. 3. の2回ずつを 3セット、 > 5回ずつを 6セットしたのですが、落ちません。 > どれぐらいの頻度で落ちますか? > あと、落ちるのは、 > メニューの「ファイル」→「閉じる」 > のタイミングのみですか? タイミングはこの場合のみです。 ...が、すみません、これ、私のコンパイル・インストールミスだと思います。 西澤さんのレポートを見てから、もしかして...と思ってRuby/GNOME関連の ライブラリをmake cleanしてmakeし直したところ現象がでなくなりました。 もし、また出るようなことがあったらメールしますが、 ステータスとしては久保さんのパッチでフィクスできたということでお願いします。 #お手数おかけして申し訳ないです。 > > たぶん、この部分のメンテナが明示的にいない(というか久保さん的には > > 興味がない)のが問題だろう、ということでしょう。 > > たしかに、画面系にはあまり興味ありません。m(__)m > それならどうして GnomeCanvas に手をつけたかというと、Linux で動くデー > タベースの設計ツール(Erwinもどき)が欲しかったから。 Ruby-GNOMEで実装するのですか?それはすごい。 期待してます。 > > 久保さんにやっていただくとホントは良いのかもしれませんが(^^;)、 > > そこを押しつけるのもなんですので、私がメンテナを引き受けますよ。 > > お願いします。 了解です。 それでは。 -- .:% Masao Mutoh<mu...@hi...> |
From: Seiya N. <se...@ku...> - 2002-08-04 10:44:18
|
西澤です。 On Sun, 04 Aug 2002 19:10:18 +0900 KUBO Takehiro <ku...@ji...> wrote: > 久保@茅ヶ崎市です。 > > Masao Mutoh <mu...@hi...> writes: > > > 試してみたのですが、まだ発生します。 > > ただ、前よりは落ちづらくなったような感じですので上のパッチは > > 効果があるかと思います。もしかしたら同様の問題がまだあるのかも > > しれませんね。 > > 私の環境ではパッチを当てたあとは今のところ一回も落ちていません。 環境によるのでしょうか Vine Linux2.5 kernel 2.4.18 glibc 2.2.4 gcc 2.95 ruby 1.6.7 glib 1.2.10 gtk+ 1.2.10 gnome-libs 1.4.1.2 ---------- Seiya Nishizawa se...@ku... |
From: KUBO T. <ku...@ji...> - 2002-08-04 10:19:55
|
久保@茅ヶ崎市です。 Masahiro Sakai <s01...@sf...> writes: > ところで、 > http://www.gnome.org/~mathieu/libart/libart-affine-transformation-matrices.html#ART-AFFINE-MULTIPLY > には > | void art_affine_multiply (double dst[6], > | const double src1[6], > | const double src2[6]); > | > | Multiplies two affine transforms together, i.e. the resulting dst is > | equivalent to doing first src1 then src2. > とあります。 > > これをそのまま > | static VALUE > | affine_multiply(self, right) > | VALUE self, right; > | { > | double affine[6]; > | art_affine_multiply(affine, Affine_Ptr(self), get_art_affine(right)); > | return make_art_affine(affine); > | } > としてラップしてありますが、「*」演算子を使うならば、 > 数学での写像の結合の記法に合わせて、 > 右辺の方をsrc1にしたほうが良いような気がします。 確かに数学的にはそうですね。逆にしましょう。 > アフィン変換について良く知らないので、はずしてたらすいません。 私も良く知りません。Art::Affine を作るまで、アフィン変換のこと知らなかっ た。 では、再見 -- 神奈川県茅ヶ崎市在住 久保 健洋 email: ku...@ji... web: http://www.jiubao.org GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1 9F47 C001 1F93 AC08 2262 |
From: KUBO T. <ku...@ji...> - 2002-08-04 10:13:14
|
久保@茅ヶ崎市です。 Masao Mutoh <mu...@hi...> writes: > 試してみたのですが、まだ発生します。 > ただ、前よりは落ちづらくなったような感じですので上のパッチは > 効果があるかと思います。もしかしたら同様の問題がまだあるのかも > しれませんね。 > > #上記の2.3.を多めに繰り返して試してみてください。 CVS のソース + 前のメールの ad-hoc パッチで 2. 3. の2回ずつを 3セット、 5回ずつを 6セットしたのですが、落ちません。 どれぐらいの頻度で落ちますか? あと、落ちるのは、 メニューの「ファイル」→「閉じる」 のタイミングのみですか? メモリの空きはどれぐらいありますか? 私の環境、Oracle 9i を動かすために 768 Mバイトあるもんで、普段はメモリ があまっているのです。 # Oracle 9i は起動させるだけで最低 256M は占有する。p(^^;) もしくは、私が無意識にしていない操作をむとうさんがしているのかもしれな い。動画の画面キャプチャーができたら良いのだが.....。 > たぶん、この部分のメンテナが明示的にいない(というか久保さん的には > 興味がない)のが問題だろう、ということでしょう。 たしかに、画面系にはあまり興味ありません。m(__)m それならどうして GnomeCanvas に手をつけたかというと、Linux で動くデー タベースの設計ツール(Erwinもどき)が欲しかったから。 > 久保さんにやっていただくとホントは良いのかもしれませんが(^^;)、 > そこを押しつけるのもなんですので、私がメンテナを引き受けますよ。 お願いします。 >> libgnome-2.so は X に依存してないので、X のライブラリのない環境で >> libgnome-2.so の関数を使いたい場合は gnome と gnomeui を別々にするメリッ >> トはあるでしょう。 > > なるほど...。 > 今、APIリファレンスをざっと見ているのですが、現在のRuby/GNOMEは > どちらかというと、gnomeui(とgnomecanvas)ですね。 > > gnomeの方のAPIを見ると、これらを単独で使いたいと思うかというと微妙ですね。 > 私が言うのもなんですが(^^;)。 > > でも、Xに依存しないでも使える部分を別出しにするというのはそれはそれで > 有効でしょうね....、といいつつ、Ruby自体に同様の機能を提供する別のライブラリ > があるものが多いので、積極的に開発していくかというと気が萎えますが。 私も API (というか includeファイル)を見てみましたが、X なしで使うかど うかは微妙ですね。 >> libgnomeui-2.so は libgnomecanvas-2.so に依存してますが、 >> libgnomecanvas-2.so は libgnomeui-2.so に依存してません。 >> うーむ、libgnomeui-2.so を使わずに libgnomecanvas-2.so を使う場面があ >> るのだろうか? >> これは今のところわからないので、別にするかどうかは保留。 > > きっと生GTK + libgnomecanvasという組み合わせを想定してるのでしょう。 > というか、そういうアプリケーションが(すでに)あるんじゃないかな。 /usr/lib の下をさぐってきたら、libbonoboui-2 がそうなってました。 > でも、Ruby/GNOME的にはこれはgnomeuiと一緒で良さそうな気がします。 ですね。 >> >> >> ・ruby の配列か? それ用のクラスか? > ざっくり勉強してみました。 > さかいさんもコメントくれていますが、久保さんの方法(クラスAffineを用意する) > が良いと思います。 安堵。 > そしたら、これ、libartにしましょうか。ドキュメント周りもLibartって > 書いてありますし。 了解。 では、再見 -- 神奈川県茅ヶ崎市在住 久保 健洋 email: ku...@ji... web: http://www.jiubao.org GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1 9F47 C001 1F93 AC08 2262 |
From: Masahiro S. <s01...@sf...> - 2002-08-04 08:21:34
|
さかいです。 From: Masahiro Sakai <s01...@sf...> Subject: [ruby-gnome-users-ja] Re: text on Gdk Drawable Date: Sun, 04 Aug 2002 02:49:57 +0900 > 「*」や「multiply」は写像としての結合を表わしているのでしょう。 > # アフィン変換は写像で、しかも写像としての結合に関して閉じています。 > # もっといえば、群になるはずです。 ところで、 http://www.gnome.org/~mathieu/libart/libart-affine-transformation-matrices.html#ART-AFFINE-MULTIPLY には | void art_affine_multiply (double dst[6], | const double src1[6], | const double src2[6]); | | Multiplies two affine transforms together, i.e. the resulting dst is | equivalent to doing first src1 then src2. とあります。 これをそのまま | static VALUE | affine_multiply(self, right) | VALUE self, right; | { | double affine[6]; | art_affine_multiply(affine, Affine_Ptr(self), get_art_affine(right)); | return make_art_affine(affine); | } としてラップしてありますが、「*」演算子を使うならば、 数学での写像の結合の記法に合わせて、 右辺の方をsrc1にしたほうが良いような気がします。 アフィン変換について良く知らないので、はずしてたらすいません。 -- さかい |
From: Masao M. <mu...@hi...> - 2002-08-04 04:55:22
|
むとうです。 On Sun, 04 Aug 2002 12:04:51 +0900 KUBO Takehiro <ku...@ji...> wrote: > 久保@茅ヶ崎市です。 > > 再現しました。 良かったです。 > > 1. test-gnomeでcanvasを選択 -> GnomeCanvasのダイアログがポップアップ > > 2. 全てのイメージを1つずつマウスでドラッグしてずらしてみる > > 3. 次のタブで2.と同様のことを行う。 > > 4. しばらくいろいろなタブで2.3.を繰り返す。 > > 5. メニューの「ファイル」→「閉じる」 > > どうも、 > メニューの「ファイル」→「閉じる」 > が肝だったようです。 > > いつも Window の枠の(×)(閉じる)を押して、メニューから閉じてなかったの > で気付きませんでした。m(__)m > > gdb で追っていったところ、GtkPixmapMenuItem にたいするコールバックで落 > ちてました。引数を調べると、signal_callback() の data がコールバック用 > のデータではなくて、Float の配列になっていた。どうも GC で解放され、再 > 利用され、別のデータがはいりこんだ領域をそのまま使用しようとしたことが > 直接の原因のようでした。 > > とりあえず add-hoc なパッチ > で試していただけませんか? 試してみたのですが、まだ発生します。 ただ、前よりは落ちづらくなったような感じですので上のパッチは 効果があるかと思います。もしかしたら同様の問題がまだあるのかも しれませんね。 #上記の2.3.を多めに繰り返して試してみてください。 > ここの考え方の違いは、私は > > Art::Affine 以外のものを実装する人はいないのではないか。 > つまり、将来も現状と変わらないのではないか。 > > と思っているのに対し、むとうさんは > > Art::Affine 以外のものを実装する人はいるかもしれない。 > 将来のために、現状のものでも別出しするべきだ。 > > ということですね。 > > うーん、私はオープンソースの意義をあまり信じてないのか? > ここはむとうさんに合わせます。 たぶん、この部分のメンテナが明示的にいない(というか久保さん的には 興味がない)のが問題だろう、ということでしょう。 久保さんにやっていただくとホントは良いのかもしれませんが(^^;)、 そこを押しつけるのもなんですので、私がメンテナを引き受けますよ。 > >> > 例えば、Ruby-GNOME2ではglib, gtk, gnomeをそれぞれ別出しにしていますし、 > >> > pango, bonoboといったものもおそらく別出しになるでしょう。 > >> > >> 分割の基準は、tar-ball 毎ですか? それとも作成されるライブラリ毎ですか? > > > > 一番大きいのは、それをRubyから別々にrequireしたいかどうかというところ > > だと思います。 > > では、そういう基準で考えます。 > > >> GNOME2 ではライブラリ毎に tar-ball が作られるようなので、どちらにしろ > >> libart_lgpl が別になるのは当然として gnome は gnome, gnomeui, gnomecanvas > >> の3分割になるでしょう。 > > > > gnome, gnomeui, gnomecanvasをそれぞれ別々にrequireすることでどのような > > メリット・デメリットがあるのかというのは議論が必要かと思います。 > > libgnome-2.so は X に依存してないので、X のライブラリのない環境で > libgnome-2.so の関数を使いたい場合は gnome と gnomeui を別々にするメリッ > トはあるでしょう。 なるほど...。 今、APIリファレンスをざっと見ているのですが、現在のRuby/GNOMEは どちらかというと、gnomeui(とgnomecanvas)ですね。 gnomeの方のAPIを見ると、これらを単独で使いたいと思うかというと微妙ですね。 私が言うのもなんですが(^^;)。 でも、Xに依存しないでも使える部分を別出しにするというのはそれはそれで 有効でしょうね....、といいつつ、Ruby自体に同様の機能を提供する別のライブラリ があるものが多いので、積極的に開発していくかというと気が萎えますが。 > libgnomeui-2.so は libgnomecanvas-2.so に依存してますが、 > libgnomecanvas-2.so は libgnomeui-2.so に依存してません。 > うーむ、libgnomeui-2.so を使わずに libgnomecanvas-2.so を使う場面があ > るのだろうか? > これは今のところわからないので、別にするかどうかは保留。 きっと生GTK + libgnomecanvasという組み合わせを想定してるのでしょう。 というか、そういうアプリケーションが(すでに)あるんじゃないかな。 でも、Ruby/GNOME的にはこれはgnomeuiと一緒で良さそうな気がします。 > > 今のところ、Ruby/GNOMEはgnome, gnomeui, gnomecanvasは1つのrequireで > > 呼び出すことができるようになっています。 > > 私は使用者の便宜を考えるとこのままで良いかなぁ、と漠然と思っていたのですが、 > > 私も漠然とそう思っています。(^^;) まずはgnomeuiの方をメインに開発していく感じでしょうね....。 いっそのこと、gnomeという名前はいったんやめて、gnomeuiに変えようかなぁ。 #Ruby-GNOME2での話です。 > > もし、久保さん(あるいは他の方)が、分けたいと言うことであれば、 > > それを分けるメリットをあげていただければ考えます。 > > Ruby/Gnome に関しては、公開されてから時間もたっているし、クリティカル > な問題がないがきり分ける必要はないと思います。 おっしゃるとおり、Ruby-GNOMEに関しては特に大きな手を入れることは 考えていません。 Ruby-GNOME2ではその辺からしっかり考えて行きたいと思います。 > >> >> ・ruby の配列か? それ用のクラスか? > (snip) > > すみません。ここ、全く理解できませんでした。 > > ちょっと時間をください。もうちょっと勉強してみます。 > > はい。 ざっくり勉強してみました。 さかいさんもコメントくれていますが、久保さんの方法(クラスAffineを用意する) が良いと思います。 > >> >> ・クラスの名前 > >> > >> libart_lgpl 別出しは了承しているので、スキップ > > > > ふと思ったのですが、libart_lgplって、libartの方が良いでしょうか。 > > どちらが一般的なのかな。 > > libart_lgpl の README を見ると、 > This is the LGPL'd component of libart. All functions needed for > running the Gnome canvas, and for printing support, will be going in > here. The GPL'd component will be getting various enhanced functions > for specific applications. > と書いてあります。 > > つまり、libart から GPL のコードを抜いたのが libart_lgpl なのかなと思っ > ていたのですが、 > http://www.artofcode.com/libart.html > から取得できるソースコードも libart_lgpl でした。 > > うーん、GPL のコードのはいった libart ってあるのかな? > > ちなみに Debian のパッケージでは、libart パッケージに libart_lgpl がは > いっていました。 そしたら、これ、libartにしましょうか。ドキュメント周りもLibartって 書いてありますし。 -- .:% Masao Mutoh<mu...@hi...> |
From: KUBO T. <ku...@ji...> - 2002-08-04 03:29:12
|
久保@茅ヶ崎市です。 Masao Mutoh <mu...@hi...> writes: > ひょっとして、私が言っているセグメンテーション違反のバグはこれが > 原因ですか? > #私が確認しているのはこのパッチをあてる前のものです。 いえ、違います。 >> これはどちらが良いでしょうか? >> Gnome;:CanvasPoints#free >> がないほうが実装はかなり単純になりそうです。 > > げげっ。 > ここまでソースをおわなかったのですが.... > おっしゃるとおり、free()はGCに任せるべきです。 > というか、free()だけではなく、 > ref/unrefに関してもはRuby/GNOMEのソース内で > 吸収する必要があります。 もちろん明示的に free しなくても GC 時に free されますが、どうも、明示 的に free できるオプションもつけたくなってしまう。たとえば、ファイルや データベースへの接続は、ファイル記述子の枯渇やDBサーバへの負荷を考える と GC に任せずに明示的にクローズするべきだし、明示的な解放ができるのな らば、そういうオプションも用意したくなってしまう。 けどまあ、Gnome::CanvasPoints の場合は使用する資源はメモリのみなので、 まったく別の話しですね。メモリの場合、足りなくなったら GC が走って解放 されますし。 明示的な free を用意するかどうかは、そのオブジェクトの利用する資源がど ういう種類のものかを考えてから実装するようにします。 > ref/unref, malloc/freeの仕組みをユーザが考えずに済むというのが > は、Ruby-GNOMEの最大のウリの1つです。 まあ、それが GC のある言語のウリなのですけど。 では、再見 -- 神奈川県茅ヶ崎市在住 久保 健洋 email: ku...@ji... web: http://www.jiubao.org GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1 9F47 C001 1F93 AC08 2262 |
From: KUBO T. <ku...@ji...> - 2002-08-04 03:07:49
|
久保@茅ヶ崎市です。 # 今日の用事つぶれ暇になったので、ソースいじりを開始しました。 Masao Mutoh <mu...@hi...> writes: >> 確かに安定しないことにはリリースできませんね。だけど、私のところでは前 >> のメールで書いた一回しか異常終了してないのです。GC.start を呼びまくっ >> たりもしたんですが再現なし。 > > 1回異常終了したのであれば、やはり(システムがよほど不安定になったなどの > 別の要素がない以上)再現性の可能性はあるわけで、 > あとは手順が確定できるかどうかということになりますよね。 ええ。 > 前も書きましたが、以下の手順で再現しませんか? > 私の環境(後述)だと100%確実に再現します。 再現しました。 > 1. test-gnomeでcanvasを選択 -> GnomeCanvasのダイアログがポップアップ > 2. 全てのイメージを1つずつマウスでドラッグしてずらしてみる > 3. 次のタブで2.と同様のことを行う。 > 4. しばらくいろいろなタブで2.3.を繰り返す。 > 5. メニューの「ファイル」→「閉じる」 どうも、 メニューの「ファイル」→「閉じる」 が肝だったようです。 いつも Window の枠の(×)(閉じる)を押して、メニューから閉じてなかったの で気付きませんでした。m(__)m gdb で追っていったところ、GtkPixmapMenuItem にたいするコールバックで落 ちてました。引数を調べると、signal_callback() の data がコールバック用 のデータではなくて、Float の配列になっていた。どうも GC で解放され、再 利用され、別のデータがはいりこんだ領域をそのまま使用しようとしたことが 直接の原因のようでした。 とりあえず add-hoc なパッチ ----------------------- ここから ----------------------- diff -u -r1.6 rbgnome-app-helper.c --- rbgnome-app-helper.c 4 Feb 2002 00:27:27 -0000 1.6 +++ rbgnome-app-helper.c 4 Aug 2002 01:59:09 -0000 @@ -322,6 +322,7 @@ id = rb_intern(signal_name); data = rb_ary_new3(3, (VALUE)uiinfo->moreinfo, INT2NUM(id), args); add_relative((VALUE)uiinfo->moreinfo, data); + add_relative((VALUE)uibdata->data, (VALUE)uiinfo->moreinfo); gtk_signal_connect_full(GTK_OBJECT(uiinfo->widget), signal_name, 0, signal_callback, @@ -474,6 +475,7 @@ return Qnil; } + RbGnome_UIBuilder.data = (gpointer)self; gnome_app_create_menus_custom(GNOME_APP(get_widget(self)), uiinfo, &RbGnome_UIBuilder); @@ -492,6 +494,7 @@ return Qnil; } + RbGnome_UIBuilder.data = (gpointer)self; gnome_app_create_toolbar_custom(GNOME_APP(get_widget(self)), uiinfo, &RbGnome_UIBuilder); @@ -531,6 +534,7 @@ return Qnil; } + RbGnome_UIBuilder.data = (gpointer)self; gnome_app_insert_menus_custom(GNOME_APP(get_widget(self)), STR2CSTR(path), uiinfo, ----------------------- ここまで ----------------------- で試していただけませんか? static なデータ領域に self をぶち込んでるのがちょっと気持ち悪いので、 正式なパッチでは、stack 上に GnomeUIBuilderData を取るようにします。 > この現象は、add_relative()の抜け等、RubyのGC周りで起きる症状に > 酷似していますが厳密にそれが原因かどうかはわかりません。 まさに add_relative() のようです。 デバッカではひっかかってないけど、他に一点、Gnome::Canvas まわりで潜在 的にあやしそうなところ(直さなくても問題化しないかもしれない)があるので、 そっちのパッチも作ります。 >> うーむ、Gdk::Drawable で自前で affine 変換するという目的には使えるかも >> しれない。ただそのためには、Art::Affine のみではなくて、libart_lgpl の >> 関数をひと通り用意しないといけないでしょう。 > > その通りです。 > それがしやすいように最初から用意しておくと言うことです。 > > 逆に言えば、Ruby-GNOME全体としてみたとき、gnomeモジュールのためだけに > libart_lgplをローカルに実装するということはできません。 > >> 現状では、Art::Affine のみなので、「モジュール名が Art なのに gnome.so >> に入っているのは気持ち悪い」ということしか別出しする意味はないと思いま >> す。 > > そういうわけではありません。 ここの考え方の違いは、私は Art::Affine 以外のものを実装する人はいないのではないか。 つまり、将来も現状と変わらないのではないか。 と思っているのに対し、むとうさんは Art::Affine 以外のものを実装する人はいるかもしれない。 将来のために、現状のものでも別出しするべきだ。 ということですね。 うーん、私はオープンソースの意義をあまり信じてないのか? ここはむとうさんに合わせます。 >> > 例えば、Ruby-GNOME2ではglib, gtk, gnomeをそれぞれ別出しにしていますし、 >> > pango, bonoboといったものもおそらく別出しになるでしょう。 >> >> 分割の基準は、tar-ball 毎ですか? それとも作成されるライブラリ毎ですか? > > 一番大きいのは、それをRubyから別々にrequireしたいかどうかというところ > だと思います。 では、そういう基準で考えます。 >> GNOME2 ではライブラリ毎に tar-ball が作られるようなので、どちらにしろ >> libart_lgpl が別になるのは当然として gnome は gnome, gnomeui, gnomecanvas >> の3分割になるでしょう。 > > gnome, gnomeui, gnomecanvasをそれぞれ別々にrequireすることでどのような > メリット・デメリットがあるのかというのは議論が必要かと思います。 libgnome-2.so は X に依存してないので、X のライブラリのない環境で libgnome-2.so の関数を使いたい場合は gnome と gnomeui を別々にするメリッ トはあるでしょう。 libgnomeui-2.so は libgnomecanvas-2.so に依存してますが、 libgnomecanvas-2.so は libgnomeui-2.so に依存してません。 うーむ、libgnomeui-2.so を使わずに libgnomecanvas-2.so を使う場面があ るのだろうか? これは今のところわからないので、別にするかどうかは保留。 > 今のところ、Ruby/GNOMEはgnome, gnomeui, gnomecanvasは1つのrequireで > 呼び出すことができるようになっています。 > 私は使用者の便宜を考えるとこのままで良いかなぁ、と漠然と思っていたのですが、 私も漠然とそう思っています。(^^;) > もし、久保さん(あるいは他の方)が、分けたいと言うことであれば、 > それを分けるメリットをあげていただければ考えます。 Ruby/Gnome に関しては、公開されてから時間もたっているし、クリティカル な問題がないがきり分ける必要はないと思います。 >> >> ・ruby の配列か? それ用のクラスか? (snip) > すみません。ここ、全く理解できませんでした。 > ちょっと時間をください。もうちょっと勉強してみます。 はい。 >> >> ・クラスの名前 >> >> libart_lgpl 別出しは了承しているので、スキップ > > ふと思ったのですが、libart_lgplって、libartの方が良いでしょうか。 > どちらが一般的なのかな。 libart_lgpl の README を見ると、 This is the LGPL'd component of libart. All functions needed for running the Gnome canvas, and for printing support, will be going in here. The GPL'd component will be getting various enhanced functions for specific applications. と書いてあります。 つまり、libart から GPL のコードを抜いたのが libart_lgpl なのかなと思っ ていたのですが、 http://www.artofcode.com/libart.html から取得できるソースコードも libart_lgpl でした。 うーん、GPL のコードのはいった libart ってあるのかな? ちなみに Debian のパッケージでは、libart パッケージに libart_lgpl がは いっていました。 では、再見 -- 神奈川県茅ヶ崎市在住 久保 健洋 email: ku...@ji... web: http://www.jiubao.org GnuPG fingerprint = 5F7B C8EF CA16 57D0 FDE1 9F47 C001 1F93 AC08 2262 |