You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(60) |
Jul
(52) |
Aug
(67) |
Sep
(167) |
Oct
(186) |
Nov
(173) |
Dec
(220) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(37) |
Feb
(66) |
Mar
(89) |
Apr
(71) |
May
(32) |
Jun
(61) |
Jul
(64) |
Aug
(99) |
Sep
(33) |
Oct
(31) |
Nov
(50) |
Dec
(41) |
2004 |
Jan
(9) |
Feb
(9) |
Mar
(25) |
Apr
(23) |
May
(8) |
Jun
|
Jul
(1) |
Aug
(9) |
Sep
(1) |
Oct
(31) |
Nov
(38) |
Dec
|
2005 |
Jan
(16) |
Feb
(49) |
Mar
(14) |
Apr
(1) |
May
|
Jun
(12) |
Jul
(25) |
Aug
(18) |
Sep
(48) |
Oct
(76) |
Nov
(20) |
Dec
|
2006 |
Jan
(16) |
Feb
(12) |
Mar
(4) |
Apr
(5) |
May
(77) |
Jun
(37) |
Jul
(15) |
Aug
|
Sep
(3) |
Oct
(15) |
Nov
(7) |
Dec
(27) |
2007 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
(7) |
Jun
(18) |
Jul
(44) |
Aug
(12) |
Sep
(1) |
Oct
(13) |
Nov
(15) |
Dec
(5) |
2008 |
Jan
|
Feb
|
Mar
(16) |
Apr
(2) |
May
(8) |
Jun
(1) |
Jul
|
Aug
|
Sep
(8) |
Oct
(6) |
Nov
|
Dec
|
2009 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(3) |
2010 |
Jan
(8) |
Feb
(8) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(17) |
Oct
(7) |
Nov
(3) |
Dec
|
2011 |
Jan
(34) |
Feb
(47) |
Mar
(12) |
Apr
(1) |
May
(2) |
Jun
(2) |
Jul
(20) |
Aug
(4) |
Sep
(31) |
Oct
(16) |
Nov
(26) |
Dec
(40) |
2012 |
Jan
(10) |
Feb
(8) |
Mar
|
Apr
(5) |
May
(8) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(8) |
2013 |
Jan
(2) |
Feb
(33) |
Mar
(21) |
Apr
(10) |
May
(29) |
Jun
(19) |
Jul
(6) |
Aug
(4) |
Sep
|
Oct
(21) |
Nov
(21) |
Dec
(7) |
2014 |
Jan
(3) |
Feb
(12) |
Mar
(9) |
Apr
(4) |
May
(12) |
Jun
|
Jul
|
Aug
(5) |
Sep
(23) |
Oct
(29) |
Nov
(2) |
Dec
(1) |
2015 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
|
Dec
(8) |
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: Kouhei S. <ko...@co...> - 2006-05-18 01:09:26
|
須藤です. 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として出力します. と,こんな感じでわかりますか? |
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: Masao M. <mu...@hi...> - 2006-05-17 15:40:10
|
須藤さん むとうです。 そうそう、質問し忘れていたんですが。 On Sun, 14 May 2006 21:57:51 +0900 (JST) Kouhei Sutou <ko...@co...> wrote: > 須藤です. > > Evinceで使われているXpdf由来のPDFレンダリングエンジンである > PopplerのGLibバインディングのRubyバインディングを書いていま > す. > http://pub.cozmixng.org/~kou/archives/poppler.tar.gz > > poppler-glib(PopplerのGLibバインディング)はcairoとのインター > フェイスもあるので,PDFをGTK+のウィジェットに書き出したり, > PNGやPS,PDFに書き出すことも出来ます. Ruby/PopplerとRuby/Cairoの守備範囲の違いって何でしょうか? 微妙にかぶっているような・・・。 -- .:% 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-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: 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: 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: 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: 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: 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: 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: 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: Kouhei S. <ko...@co...> - 2006-05-14 12:58:00
|
須藤です. Evinceで使われているXpdf由来のPDFレンダリングエンジンである PopplerのGLibバインディングのRubyバインディングを書いていま す. http://pub.cozmixng.org/~kou/archives/poppler.tar.gz poppler-glib(PopplerのGLibバインディング)はcairoとのインター フェイスもあるので,PDFをGTK+のウィジェットに書き出したり, PNGやPS,PDFに書き出すことも出来ます. そんなRuby/Popplerですが,GLibバインディングのRubyバインディ ングというだけあってRuby/GLibに依存しています.そのため, Ruby-GNOME2 プロジェクトに含まれていると好都合なのですが, CVSにつっこんでもよいですか? 問題点は,現在存在するpoppler-glibではコンパイルできないこと です.PopplerのBugzillaに上がっている私のパッチを当てたCVS headじゃないとコンパイルできません. # だって,素のpoppler-glibはぜんぜんGLibアプリケーションっぽ # くないんだもん... |
From: Kouhei S. <ko...@co...> - 2006-05-11 13:00:22
|
須藤です. In <200...@hi...> "Re: [ruby-gnome2-devel-ja] RubyGObjectHookModule#initialie" on Wed, 10 May 2006 03:12:38 +0900, Masao Mutoh <mu...@hi...> wrote: > > RubyGObjectHookModule#initializeを定義しないと,上記の > > TestLabel.new("label")でも動くような気がしますが,試してはい > > ません. > > 確かそのままでは動かなかったと思います。 > というのは、TestLabel.newしたときのinitializeメソッドが、実は > Gtk::Labelのinitializeメソッドだとすると、そのときのGTypeはGtk::Label > のそれになり、TestLabelのGTypeが使われなくなってしまうからです。 わかりました. とりあえず,今のところは必要がないので,見なかったことにしま す. |
From: Masao M. <mu...@hi...> - 2006-05-09 18:12:49
|
むとうです。 On Tue, 09 May 2006 23:07:15 +0900 (JST) Kouhei Sutou <ko...@co...> wrote: > 須藤です. > > rbgobj_object.cのtype_registerの中で,RubyGObjectHookModule > を作って,そのinitialieをgobj_initializeにしていますが,これ > だと以下のような場合に少し予想外の動作をします. > > > class TestLabel < Gtk::Label > type_register > end > > Gtk::Label.new("label") # OK > TestLabel.new("label") > # => `initialize': wrong argument type String (expected Hash) (TypeError) > > > こうしているのにはなにか理由があるのだと思いますが,パッと見 > た感じではわかりませんでした. あぁ、これは、type_registerを呼んだときはデフォルトで TestLabel.new(:label => "label") のように呼ぶようにする必要があるんですよね。 > RubyGObjectHookModule#initializeを定義しないと,上記の > TestLabel.new("label")でも動くような気がしますが,試してはい > ません. 確かそのままでは動かなかったと思います。 というのは、TestLabel.newしたときのinitializeメソッドが、実は Gtk::Labelのinitializeメソッドだとすると、そのときのGTypeはGtk::Label のそれになり、TestLabelのGTypeが使われなくなってしまうからです。 そうなるとsignalを追加しようとしたときにTestLabelに追加したつもりが実は Gtk::Labelに追加されていた、なんてことになり、都合が悪かったと思います。 #sample/type_register(2).rbを参考にいじってみるとすぐ問題がわかると思います。 わかりづらい、というのは同意しますし、この辺、実はまだうまく練られていなくて Rubyっぽくない最たる部分の一つだとは思っていますが、うまい解決策が思いつかないので そのまま長いこと放置してしまっているんですよね。何か改善案があれば歓迎です。 それでは。 -- .:% Masao Mutoh<mu...@hi...> |
From: Kouhei S. <ko...@co...> - 2006-05-09 14:07:26
|
須藤です. rbgobj_object.cのtype_registerの中で,RubyGObjectHookModule を作って,そのinitialieをgobj_initializeにしていますが,これ だと以下のような場合に少し予想外の動作をします. class TestLabel < Gtk::Label type_register end Gtk::Label.new("label") # OK TestLabel.new("label") # => `initialize': wrong argument type String (expected Hash) (TypeError) こうしているのにはなにか理由があるのだと思いますが,パッと見 た感じではわかりませんでした. RubyGObjectHookModule#initializeを定義しないと,上記の TestLabel.new("label")でも動くような気がしますが,試してはい ません. |
From: SHITAMORI A. <si...@gm...> - 2006-04-23 14:54:09
|
下森です 06/04/23 に Masao Mutoh<mu...@hi...> さんは書きました: > ・・・実は、rbbrのCVS版はかなり機能が追加されています。 > そちらを使うことができるようでしたら、そちらを使った方が楽かと思います。 > CVS最新版ではAPIドキュメントをダウンロードする仕組み持っていますし、特に > 設定なしで日本語の表示も可能ですので、上記のような対応は不要です。 わかりました、CVS版を使ってみます。お返事ありがとうございました。 |
From: Masao M. <mu...@hi...> - 2006-04-23 14:42:04
|
むとうです。 On Sun, 23 Apr 2006 17:53:06 +0900 "SHITAMORI Akira" <si...@gm...> wrote: > はじめまして、下森といいます。 > > Ruby-GNOME2 API Documentsをrbbrでみようとダウンロードして > /usr/share/rbbr/rd > に展開したのですがGtkを選択しても表示されません。 > > 環境はDebian GNU/Linuxのsidです。 > rbbrのバージョンは0.6.0です。 > > ii rbbr 0.6.0-3 a browser for > Ruby classes and documentation > > ruby -r debug /usr/bin/rbbrで実行してみると以下のように > でたのでjaディレクトリを削除したところ表示されるようになりました。 > > /usr/lib/ruby/1.8/rbbr/doc/rd.rb:24: `ディレクトリです - > /usr/share/rbbr/rd/ja' (Errno::EISDIR) > from /usr/lib/ruby/1.8/rbbr/doc.rb:81:in `initialize' > from /usr/lib/ruby/1.8/rbbr/doc.rb:79:in `initialize' > from /usr/lib/ruby/1.8/rbbr/ui/gtk/browser.rb:155:in `initialize' > from /usr/lib/ruby/1.8/rbbr/ui/gtk.rb:57:in `main' > from /usr/bin/rbbr:22 > > しかし日本語で読みたいのでja以下のファイルを /usr/share/rbbr/rd に持って > いくと > Gtk-CRITICAL **:gtk_text_buffer_emit_insert: assertion > `g_utf8_validate (text, len, NULL)' failed > とでてきます。 > とりあえずnkf -w で変換したところ日本語で表示されましたが > 正しい使いかたには思えないので…どういう手順でいれればいいのか > 教えていただけないでしょうか。 なるほど...。 まず、rbbr-0.6.0は日本語に対応していないです(というか想定した作りになっていません)。 ところが、現状のruby-gnome2-api.tar.gzはja/フォルダを持ち、そこに日本語の ドキュメントが入っています。 なので、rbbr-0.6.0のまま利用する場合、下森さんが行ったように、 jaフォルダの削除を行う必要があります。 さらに、ruby-gnome2-apiの日本語ドキュメントはeuc-jpですので、これを単純に /usr/share/rbbr/rd配下にコピーしても"utf-8じゃないよ"というエラーメッセージ が出ることになります。 なので、日本語を表示したい場合はja/配下のファイルをいったんutf-8に変換しないと いけないということになります。 ・・・実は、rbbrのCVS版はかなり機能が追加されています。 そちらを使うことができるようでしたら、そちらを使った方が楽かと思います。 CVS最新版ではAPIドキュメントをダウンロードする仕組み持っていますし、特に 設定なしで日本語の表示も可能ですので、上記のような対応は不要です。 -- .:% Masao Mutoh<mu...@hi...> |
From: SHITAMORI A. <si...@gm...> - 2006-04-23 09:00:18
|
はじめまして、下森といいます。 Ruby-GNOME2 API Documentsをrbbrでみようとダウンロードして /usr/share/rbbr/rd に展開したのですがGtkを選択しても表示されません。 環境はDebian GNU/Linuxのsidです。 rbbrのバージョンは0.6.0です。 ii rbbr 0.6.0-3 a browser for Ruby classes and documentation ruby -r debug /usr/bin/rbbrで実行してみると以下のように でたのでjaディレクトリを削除したところ表示されるようになりました。 /usr/lib/ruby/1.8/rbbr/doc/rd.rb:24: `ディレクトリです - /usr/share/rbbr/rd/ja' (Errno::EISDIR) from /usr/lib/ruby/1.8/rbbr/doc.rb:81:in `initialize' from /usr/lib/ruby/1.8/rbbr/doc.rb:79:in `initialize' from /usr/lib/ruby/1.8/rbbr/ui/gtk/browser.rb:155:in `initialize' from /usr/lib/ruby/1.8/rbbr/ui/gtk.rb:57:in `main' from /usr/bin/rbbr:22 しかし日本語で読みたいのでja以下のファイルを /usr/share/rbbr/rd に持って いくと Gtk-CRITICAL **:gtk_text_buffer_emit_insert: assertion `g_utf8_validate (text, len, NULL)' failed とでてきます。 とりあえずnkf -w で変換したところ日本語で表示されましたが 正しい使いかたには思えないので…どういう手順でいれればいいのか 教えていただけないでしょうか。 |
From: Masao M. <mu...@hi...> - 2006-04-20 14:38:12
|
むとうです。 On Thu, 20 Apr 2006 21:27:08 +0900 (JST) Kouhei Sutou <ko...@co...> wrote: > 須藤です. > > # SPAM扱いされたので,Subjectをエセ英語に. > > Ruby-GNOME2のHikiのサイドバーの上の方には他言語へのリンクが > あり,それぞれの言語のFrontPageへのリンクになっています. > > しかし,普段は日本語版を読んでいるけど,記述が古いようなので > 英語版を読みたいと思ったときにこのリンクは使いづらいと思いま > す.なぜなら,リンクをたどるとFrontPageに戻ってしまうので, > リンクをたどった後に,他の言語のページの中から今まで読んでい > たページに移動しなければいけないからです. > > 試していませんが,以下のようなパッチで「今見ているページの他 > の言語へのリンク」になるようと思います.このような変更はいか > がでしょうか? 残念ながら、英語版とそれ以外はページIDがそもそも違うんですよね。 大丈夫なページもあるのですが、ダメなページの方が多いです。 何かうまい解決策があると良いのですが。 -- .:% Masao Mutoh<mu...@hi...> |
From: Kouhei S. <ko...@co...> - 2006-04-20 12:27:13
|
須藤です. # SPAM扱いされたので,Subjectをエセ英語に. Ruby-GNOME2のHikiのサイドバーの上の方には他言語へのリンクが あり,それぞれの言語のFrontPageへのリンクになっています. しかし,普段は日本語版を読んでいるけど,記述が古いようなので 英語版を読みたいと思ったときにこのリンクは使いづらいと思いま す.なぜなら,リンクをたどるとFrontPageに戻ってしまうので, リンクをたどった後に,他の言語のページの中から今まで読んでい たページに移動しなければいけないからです. 試していませんが,以下のようなパッチで「今見ているページの他 の言語へのリンク」になるようと思います.このような変更はいか がでしょうか? --- language.rb.orig 2006-04-20 21:14:24.000000000 +0900 +++ language.rb 2006-04-20 21:16:24.000000000 +0900 @@ -1,16 +1,17 @@ def language(language) str = "" [["en", "/"], - ["es", "/es/index.html"], - ["fr", "/fr/index.html"], - ["de", "/de/index.html"], - ["it", "/it/index.html"], - ["ja", "/ja/index.html"], - ["pt_BR", "/pt_BR/index.html"]].each do |lang| + ["es", "/es/"], + ["fr", "/fr/"], + ["de", "/de/"], + ["it", "/it/"], + ["ja", "/ja/"], + ["pt_BR", "/pt_BR/"]].each do |lang| if lang[0] == language str << "[#{lang[0]}] " else - str << %Q![<a href="#{lang[1]}">#{lang[0]}</a>] ! + href = "#{lang[1]}hiki.cgi?#{@page.escapeHTML}" + str << %Q![<a href="#{href}">#{lang[0]}</a>] ! end end %Q[<span class="language">#{str}</span>] |
From: Kouhei S. <ko...@co...> - 2006-03-18 09:41:21
|
須藤です. In <200...@co...> "[ruby-gnome2-devel-ja] signal_connectしたハンドラは自動で削除してくれない?" on Tue, 07 Mar 2006 21:10:10 +0900 (JST), Kouhei Sutou <ko...@co...> wrote: > 現在,GLib::Object#signal_connectで登録したハンドラは自分で > 削除しないと削除されないようです. > このため, > > object.signal_connect("XXX") do > ... > end > > というようにハンドラを登録すると,ハンドラがobjectの参照を持っ > たまま生き残ってしまい,objectがGCされません. グローバルなテーブルにハンドラを登録していたのを各オブジェク トにハンドラを登録するようにして直してみました. ただ,このためにひとつAPIを追加しました.オブジェクトにハン ドラを登録するg_rclosure_attachです.g_rclosure_newでハンド ラを作ったら,ハンドラを登録するオブジェクトに登録しなければ いけなくなりました. # g_rclosure_newにオブジェクトを渡してもよかったのですが, # ハンドラの作成とハンドラの登録は別処理かなぁと思ったので. このため,Ruby/GTK2のrbgtkaccelgroup.cとRuby/GNOME2の rbgnome-app-helper.cも変更しました. 今回の修正は,↓のテストスクリプトやgtk-demo/main.rb,Rabbit が正常に動くのを確認しました. > require 'glib2' > > def x(disconnect) > o = GLib::Object.new > id = o.signal_connect("notify") {} > o.signal_handler_disconnect(id) if disconnect > nil > end > > [true, false].each do |disconnect| > GC.disable > 100.times {x(disconnect)} > p [disconnect, :before, ObjectSpace.each_object(GLib::Object){}] > GC.enable > GC.start > p [disconnect, :after, ObjectSpace.each_object(GLib::Object){}] > end > > このスクリプトを実行するとこうなるはずです. > > [true, :before, 100] > [true, :after, 0] > [false, :before, 100] > [false, :after, 100] |
From: Kouhei S. <ko...@co...> - 2006-03-18 02:57:59
|
須藤です. GNOME 2.14が出たのでRuby/RSVGをlibrsvg 2.14に対応させておき ました. 今まではRSVG::HandleからGdk::Pixbufを作って,Cairo::Context に描画することしか出来ませんでしたが,RSVG::Handleから直接 Cairo::Contextに描画できるようになっています. |
From: Masao M. <mu...@hi...> - 2006-03-07 14:41:39
|
むとうです。 On Tue, 07 Mar 2006 21:10:10 +0900 (JST) Kouhei Sutou <ko...@co...> wrote: > 須藤です. > > 現在,GLib::Object#signal_connectで登録したハンドラは自分で > 削除しないと削除されないようです. > > このため, > > object.signal_connect("XXX") do > ... > end > > というようにハンドラを登録すると,ハンドラがobjectの参照を持っ > たまま生き残ってしまい,objectがGCされません. <snip> > -- > 現状: > > 登録されたハンドラはCレベルのグローバルなハッシュテーブルに > 保存され,rubyのGCからも保護されています.このハッシュテーブ > ルにはハンドラとsignal_connectの第二引数以降の値を保存してい > ます. > > ハッシュテーブルの情報はグローバルなハッシュテーブルで管理さ > れているため,ハンドラが登録されているオブジェクトが死んでも > 生き残ります.このため,signal_handler_disconnectで明示的に > ハンドラを削除しないと,ハンドラが登録対象のオブジェクトを参 > 照しつづけるため,登録対象のオブジェクトがGCされません. > > 解決策案: > > ハッシュテーブルにハンドラだけではなく,登録対象のオブジェク > トを見付けることができる情報(idとかGObjectのポインタとか) > も含めておく.g_object_weak_refで登録対象のオブジェクトが死 > んだのを判断できるようにして,登録対象のオブジェクトが死んだ > らハッシュテーブルからハンドラを削除する. > > ただし,同じハンドラが複数のオブジェクトに登録されることもあ > るため,登録された回数とオブジェクトが死んだときにハンドラを > 削除する回数のバランスを保たないと,SEGVする気がする. > > こんな感じでよさそうな気がするけど,どうかなぁ. > > table = { > handler1 => [target_obj1, target_obj2], > handler2 => [target_obj1, target_obj3], > ..., > } > > ハンドラ登録: > > table[handler] ||= [] > table[handler] << target_obj > > ハンドラ削除: > table[table.index(handler), 1] = nil > table.delete(handler) if table[handler].empty? 行けそうな気がします。ぜひ試してみてくださいな。 1点、かなり以前にさかいさんが指摘されている 循環参照問題が絡んでくるかもしれませんのでその辺も注意してください。 http://www.tom.sfc.keio.ac.jp/~sakai/d/?date=20020802#c02 http://www.tom.sfc.keio.ac.jp/~sakai/d/?date=20020915 -- .:% Masao Mutoh<mu...@hi...> |