Menu
▾
▴
ruby-gnome2-devel-ja — Ruby-GNOME2 developer's Mailing list. in Japanese.
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...> - 2011-09-12 12:35:00
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] enumやflagsの規則について" on Mon, 12 Sep 2011 19:56:26 +0900, Masaaki Aoyagi <mas...@gm...> wrote: >>> warnのメッセージの中にcallerの結果も入れた方が便利かなぁと思 >>> いました。メッセージがでてもどこで出ているかわからないと直す >>> のに時間がかかってしまうので。 >> >> warningが出てるのを分かりつつ使うということもあると思うので、デフォルトでcallerまで含めるのは >> 止めておいた方がいいように思います。 > > すみません。スタック全部出すと勘違いして返信してしまいました。 > 考えてみたら、使っている場所だけ分かればいいのですね。 > 単純に、こんな感じで出せばよいでしょうか？ はい！いいと思います！ > それと、 >>> * GNOMEUtilsというよりは、GLib::XXXの中に入れたほうがいい >>> かなぁと思いました。 > > Forwardableに倣って、GLib::Deprecatableとかどうでしょうか？ GNOMEUtilsよりずっとよいと思います！ そうしましょう！ |
|
From: Masaaki A. <mas...@gm...> - 2011-09-12 10:56:34
|
青柳です。
>> warnのメッセージの中にcallerの結果も入れた方が便利かなぁと思
>> いました。メッセージがでてもどこで出ているかわからないと直す
>> のに時間がかかってしまうので。
>
> warningが出てるのを分かりつつ使うということもあると思うので、デフォルトでcallerまで含めるのは
> 止めておいた方がいいように思います。
すみません。スタック全部出すと勘違いして返信してしまいました。
考えてみたら、使っている場所だけ分かればいいのですね。
単純に、こんな感じで出せばよいでしょうか？
Index: lib/vte/deprecated.rb
===================================================================
--- lib/vte/deprecated.rb (リビジョン 4633)
+++ lib/vte/deprecated.rb (作業コピー)
@@ -9,7 +9,7 @@
def define_deprecated_method(deprecated_method, new_method)
if public_method_defined?(new_method)
define_method(deprecated_method) do |*args, &block|
- warn "'#{deprecated_method}' has been deprecated. Use '#{new_method}'."
+ warn "#{caller[0]}: '#{deprecated_method}' has been
deprecated. Use '#{new_method}'."
__send__(new_method, *args, &block)
end
end
@@ -20,7 +20,7 @@
def const_missing(deprecated_const)
if new_const = (@@deprecated_const[self] || {})[deprecated_const.to_sym]
if new_const = constant_get(new_const)
- warn "'#{[name, deprecated_const].join('::')}' has been
deprecated. Use '#{new_const}'."
+ warn "#{caller[0]}: '#{[name, deprecated_const].join('::')}'
has been deprecated. Use '#{new_const}'."
const_set(deprecated_const, new_const)
end
end
それと、
>> * GNOMEUtilsというよりは、GLib::XXXの中に入れたほうがいい
>> かなぁと思いました。
Forwardableに倣って、GLib::Deprecatableとかどうでしょうか？
|
|
From: Masaaki A. <mas...@gm...> - 2011-09-11 12:48:54
|
青柳です。 > * require 'vte/deprecated.rb'ではなく、 > require 'vte/deprecated'にしてもらえますか？ 修正しました。 > * GNOMEUtilsというよりは、GLib::XXXの中に入れたほうがいい > かなぁと思いました。 いい場所と名前は、ありますか？ 今のところ思いつかなくて。。。 > * define_XXXは外に出してよいと思いますが、constant_getは外 > に出したくないかなぁと思いました。 privateに変更しました。 > * 定数のときもwarningを出したほうが便利かも。 > const_missingを使って、最初にアクセスされたときにwarning > 出しながらconst_setするとそんな動作になりそう。 const_missingを使って、warning出力するようにしました。 ただ、const_defined?で確認して何かやっているようなコードがあると問題が出ますが、 ないですよね。 >> また、match_set_cursor～ についてIFをまとめた方が良いと思います。 >> 添付のパッチのようにまとめて、既にリリース済みのmatch_set_cursor_typeについては >> deprecatedとしてwarningを出すようにするのは、いかがでしょうか？ > > その通りだと思います。 > warnのメッセージの中にcallerの結果も入れた方が便利かなぁと思 > いました。メッセージがでてもどこで出ているかわからないと直す > のに時間がかかってしまうので。 warningが出てるのを分かりつつ使うということもあると思うので、デフォルトでcallerまで含めるのは 止めておいた方がいいように思います。 何かしらの設定で、callerも出力できるようにするというのは、いいかもしれないですが 以上の内容でコミットしましたので、ご確認ください。 |
|
From: Kouhei S. <ko...@co...> - 2011-09-11 09:52:50
|
須藤です。
In <CAMyNdeW_eiHUcBmagqD_W97AA9OC1nw2osxaoq-VFquu=ei...@ma...>
"Re: [ruby-gnome2-devel-ja] enumやflagsの規則について" on Sun, 11 Sep 2011 18:34:38 +0900,
Masaaki Aoyagi <mas...@gm...> wrote:
> 既存のenumやflagsについて、命名規則に即した定義が欲しいと思います。
> そこで、添付のパッチのように命名規則に即したものをCで実装するようにし、
> 既存の名前はrubyレベルで実装するというのは、いかがでしょうか？
いいと思います。
細かいですが、少し気になった点を。。。
* require 'vte/deprecated.rb'ではなく、
require 'vte/deprecated'にしてもらえますか？
そっちの方がよく使われる書き方なので。
* GNOMEUtilsというよりは、GLib::XXXの中に入れたほうがいい
かなぁと思いました。
（後で移動しようと考えているかとは思いますが、一応、気に
なったので書いてみました。）
* define_XXXは外に出してよいと思いますが、constant_getは外
に出したくないかなぁと思いました。
* 定数のときもwarningを出したほうが便利かも。
const_missingを使って、最初にアクセスされたときにwarning
出しながらconst_setするとそんな動作になりそう。
> また、match_set_cursor〜 についてIFをまとめた方が良いと思います。
> 添付のパッチのようにまとめて、既にリリース済みのmatch_set_cursor_typeについては
> deprecatedとしてwarningを出すようにするのは、いかがでしょうか？
その通りだと思います。
warnのメッセージの中にcallerの結果も入れた方が便利かなぁと思
いました。メッセージがでてもどこで出ているかわからないと直す
のに時間がかかってしまうので。
> とりあえず、こんな感じで実装してみましたが、もっといいやり方がありそうな気も。。。
方向はよいと思うので、コミットしてリポジトリ上でブラッシュアッ
プしていくというのでもいいかなぁと思います。
|
|
From: Masaaki A. <mas...@gm...> - 2011-09-11 09:34:45
|
青柳です。 既存のenumやflagsについて、命名規則に即した定義が欲しいと思います。 そこで、添付のパッチのように命名規則に即したものをCで実装するようにし、 既存の名前はrubyレベルで実装するというのは、いかがでしょうか？ また、match_set_cursor〜 についてIFをまとめた方が良いと思います。 添付のパッチのようにまとめて、既にリリース済みのmatch_set_cursor_typeについては deprecatedとしてwarningを出すようにするのは、いかがでしょうか？ とりあえず、こんな感じで実装してみましたが、もっといいやり方がありそうな気も。。。 |
|
From: Kouhei S. <ko...@co...> - 2011-09-11 00:44:45
|
須藤です。 In <CAMyNdeX8vJHWOMZ776j=eO-...@ma...> "[ruby-gnome2-devel-ja] メソッドの戻り値をselfにするパッチなど" on Sun, 11 Sep 2011 02:34:21 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > 命名規則のページに、voidを返却する場合、メソッドはselfを返却するようにするとされていますが、 > そうなっていなものがありますので、修正するパッチを添付します。 > また、プロパティが追加されたことにより、不要になっているメソッドがあります。 > プロパティが追加されたバージョンからは、メソッド定義をしないようにするパッチも添付します。 > コミットしてもよろしいでしょうか？ はい、OKです！ |
|
From: Kouhei S. <ko...@co...> - 2011-09-11 00:40:49
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] vteの実装をしてみました" on Sun, 11 Sep 2011 01:29:13 +0900, Masaaki Aoyagi <mas...@gm...> wrote: >> rb_grn_*()は関数のprefixをrb_grnではなく、Ruby-GNOME2のやり >> 方にあわせて変えてしまってOKです！ > > Hash引数は他にも使うところが出てきてglibに移動することになると踏んでるので、 > その時に場所や名前を考えればいいかなということで、そのままの名前にしておきました。 なるほど！ それでよいと思います！ >> vte_terminal_fork_command_full()も__vte_pty_spawn()もどちら >> もchild_setupにVtePtyを渡してくれないのでだいぶ厳しいですね。 >> >> 思いついたのは、こんなのですが、大変なので、とりあえず、 >> child_setupは未サポートがいいんじゃないかと思います。 ... > > やっぱり、ややこしい事をしないといけないのですね。 > 未サポートにしました。 はい、それが現実的かと思います。 >> あと、（うろ覚えですが）いくつか気になった所があるのですが、 >> これはコミット後に直すのでもいいかなぁと思っています。 >> >> * NIL_P(xxx) ? NULL : RVAL2CSTR(xxx)の代わりに >> RVAL2CSTR_ACCEPT_NIL(xxx)というのが使えた気がする。 >> （うろ覚え） >> * NIL_P(xxx) ? NULL : RVAL2GOBJ(xxx)は >> RVAL2GOBJ(xxx)だけでいけた気がする。 >> （うろ覚え） > > この手のパターンは色々な所で使っていそうなので、どこかのタイミングで > 一気に作業した方がいいかなと思います。 わかりました！ >>> 今回対象となるメソッドは、search_set_gregex と search_set_wrap_around ですが、 >>> 代入メソッドを定義した方が良いでしょうか？ >> >> あった方がRubyっぽく書けるような気がするのでお願いします。 > > エイリアスを定義するようにしました。 ありがとうございます！ >> search_set_gregex()とsearch_get_gregex()について少し考えてみ >> たのですが、現状はGLib::Regexpがなく、今後も追加するかどうか >> はまだ検討する余地があると思う(*)ので、今のところは以下のよ >> うにするのはいかがでしょうか？ >> >> * search_set_gregex: 引数は文字列を受け取り、内部でGRegexp >> を生成して使う。 >> * search_get_gregex: APIを提供しない。あるいは >> g_regex_get_pattern()の値を返す。 >> >> (*) RubyのRegexpとGLib::Regexがあると混乱しそうとか、Rubyの >> Regexpの方が断然使いやすいのでGLib::Regexがある意味があ >> るのかとか。 > > match_add_gregexもあるので、とりあえずGRegex関連は実装を見合わせました。 はい。必要になったらまた検討することにしましょう。 >>> fork_command_full を外に出さないようにしようと考えています。 >> >> 私もそれがいいと思います！ > > メソッド定義を削除しました。 ありがとうございます！ > 以上の内容でコミットしましたので、ご確認ください。 確認しました！ よいと思います！ |
|
From: Masaaki A. <mas...@gm...> - 2011-09-10 17:34:27
|
青柳です。 命名規則のページに、voidを返却する場合、メソッドはselfを返却するようにするとされていますが、 そうなっていなものがありますので、修正するパッチを添付します。 また、プロパティが追加されたことにより、不要になっているメソッドがあります。 プロパティが追加されたバージョンからは、メソッド定義をしないようにするパッチも添付します。 コミットしてもよろしいでしょうか？ |
|
From: Masaaki A. <mas...@gm...> - 2011-09-10 16:29:20
|
青柳です。 > rb_grn_*()は関数のprefixをrb_grnではなく、Ruby-GNOME2のやり > 方にあわせて変えてしまってOKです！ Hash引数は他にも使うところが出てきてglibに移動することになると踏んでるので、 その時に場所や名前を考えればいいかなということで、そのままの名前にしておきました。 > vte_terminal_fork_command_full()も__vte_pty_spawn()もどちら > もchild_setupにVtePtyを渡してくれないのでだいぶ厳しいですね。 > > 思いついたのは、こんなのですが、大変なので、とりあえず、 > child_setupは未サポートがいいんじゃないかと思います。 > > 1. pipeを作る。 > 2. child_setupの引数として、読み込み用のpipeと渡されたブロッ > ク引数を持つ構造体を作る。 > 3. vte_terminal_fork_command_full()を呼び出す。 > 4. child_setupの中では読み込み用のpipeをreadする。 > （ここでブロック。） > 5. vte_terminal_fork_command_full()が返ってきたら > vte_terminal_get_pty_object()でVtePtyを取ってきて、 > 書き込み用のpipeに取ってきたVtePtyのアドレスをwriteする。 > 6. 5.の書き込み用のpipeをclose。（まだ早いかも。） > 7. 4.でブロックしていたreadから5.で取ってきたVtePtyのアド > レスがわかるので、それを引数にしてvte_pty_child_setup() > を呼び出す。 > 8. child_setupの中で4.の読み込み用のpipeをclose。 > 9. child_setupの中でブロック引数を呼び出す。 やっぱり、ややこしい事をしないといけないのですね。 未サポートにしました。 > あと、（うろ覚えですが）いくつか気になった所があるのですが、 > これはコミット後に直すのでもいいかなぁと思っています。 > > * NIL_P(xxx) ? NULL : RVAL2CSTR(xxx)の代わりに > RVAL2CSTR_ACCEPT_NIL(xxx)というのが使えた気がする。 > （うろ覚え） > * NIL_P(xxx) ? NULL : RVAL2GOBJ(xxx)は > RVAL2GOBJ(xxx)だけでいけた気がする。 > （うろ覚え） この手のパターンは色々な所で使っていそうなので、どこかのタイミングで 一気に作業した方がいいかなと思います。 >> 今回対象となるメソッドは、search_set_gregex と search_set_wrap_around ですが、 >> 代入メソッドを定義した方が良いでしょうか？ > > あった方がRubyっぽく書けるような気がするのでお願いします。 エイリアスを定義するようにしました。 > search_set_gregex()とsearch_get_gregex()について少し考えてみ > たのですが、現状はGLib::Regexpがなく、今後も追加するかどうか > はまだ検討する余地があると思う(*)ので、今のところは以下のよ > うにするのはいかがでしょうか？ > > * search_set_gregex: 引数は文字列を受け取り、内部でGRegexp > を生成して使う。 > * search_get_gregex: APIを提供しない。あるいは > g_regex_get_pattern()の値を返す。 > > (*) RubyのRegexpとGLib::Regexがあると混乱しそうとか、Rubyの > Regexpの方が断然使いやすいのでGLib::Regexがある意味があ > るのかとか。 match_add_gregexもあるので、とりあえずGRegex関連は実装を見合わせました。 >> fork_command_full を外に出さないようにしようと考えています。 > > 私もそれがいいと思います！ メソッド定義を削除しました。 以上の内容でコミットしましたので、ご確認ください。 |
|
From: Kouhei S. <ko...@co...> - 2011-09-10 14:34:26
|
須藤です。 In <CAMyNdeVbrcpyHB6knrm_-BvhHAJR4Rq=s2m...@ma...> "Re: [ruby-gnome2-devel-ja] vteの実装をしてみました" on Sat, 10 Sep 2011 21:15:40 +0900, Masaaki Aoyagi <mas...@gm...> wrote: >> * 引数のデフォルトを fork_command に合わせる > > これは、0.26.2 の vte_terminal_fork_command が vte_terminal_fork_command_full を > 使用して実装されているので、それに合わせています。 > また、この方法で fork_command が fork_command_full を兼ねられるようにして良いなら > fork_command_full を外に出さないようにしようと考えています。 私もそれがいいと思います！ |
|
From: Kouhei S. <ko...@co...> - 2011-09-10 14:33:56
|
須藤です。
In <CAMyNdeUKdponJE=fMSV4hSvEtEEywoX=fUe...@ma...>
"Re: [ruby-gnome2-devel-ja] vteの実装をしてみました" on Tue, 6 Sep 2011 20:17:42 +0900,
Masaaki Aoyagi <mas...@gm...> wrote:
> 教えて頂いたことを踏まえ、いくつか変更しましたので差分を添付します。
ありがとうございます！
> 前回からの変更点は、
> * fork_command_full を Hash 引数に変更
いいと思います！
rb_grn_*()は関数のprefixをrb_grnではなく、Ruby-GNOME2のやり
方にあわせて変えてしまってOKです！
> * 引数のデフォルトを fork_command に合わせる
いいと思います！
> * ブロック引数を省略した場合は、child_setup を渡さないように
> これにより、ブロックを省略した場合は動くようになりましたが、ブロックを渡した場合は相変わらずよく分からない。。。
少し考えてみたのですが、
vte_terminal_fork_command_full()も__vte_pty_spawn()もどちら
もchild_setupにVtePtyを渡してくれないのでだいぶ厳しいですね。
思いついたのは、こんなのですが、大変なので、とりあえず、
child_setupは未サポートがいいんじゃないかと思います。
1. pipeを作る。
2. child_setupの引数として、読み込み用のpipeと渡されたブロッ
ク引数を持つ構造体を作る。
3. vte_terminal_fork_command_full()を呼び出す。
4. child_setupの中では読み込み用のpipeをreadする。
（ここでブロック。）
5. vte_terminal_fork_command_full()が返ってきたら
vte_terminal_get_pty_object()でVtePtyを取ってきて、
書き込み用のpipeに取ってきたVtePtyのアドレスをwriteする。
6. 5.の書き込み用のpipeをclose。（まだ早いかも。）
7. 4.でブロックしていたreadから5.で取ってきたVtePtyのアド
レスがわかるので、それを引数にしてvte_pty_child_setup()
を呼び出す。
8. child_setupの中で4.の読み込み用のpipeをclose。
9. child_setupの中でブロック引数を呼び出す。
> * fork_command で引数を省略した際と Hash で渡した際は fork_command_full に処理を委譲する
> * vte_terminal_fork_command が使われる場合は、warning メッセージを出力する
> * search_get_wrap_around が"?"付きメソッドになっていなかったので修正
いいと思います！
> いかがでしょうか？
コミットしてください！
あと、（うろ覚えですが）いくつか気になった所があるのですが、
これはコミット後に直すのでもいいかなぁと思っています。
* NIL_P(xxx) ? NULL : RVAL2CSTR(xxx)の代わりに
RVAL2CSTR_ACCEPT_NIL(xxx)というのが使えた気がする。
（うろ覚え）
* NIL_P(xxx) ? NULL : RVAL2GOBJ(xxx)は
RVAL2GOBJ(xxx)だけでいけた気がする。
（うろ覚え）
>> search_{get,set}_XXXなんですが、{get,set}を先頭に持ってきて
>> {get,set}_search_XXXにするのはいかがでしょうか？set_が先頭に
>> ないとG_DEF_SETTERSでsearch_XXX=みたいなメソッドを自動生成す
>> るやつが動かない気がするんです。
>>
>> でも、これもメソッド名の統一感的に難しそうですねぇ。うーん。
>
> これは、以下の命名規則のページでも動詞の削除などをしないとされているので、個別対応となると思っています。
> 大して数はないので、それでいいのかなと。
> http://ruby-gnome2.sourceforge.jp/hiki.cgi?Naming+and+Conversion+Rules
> 今回対象となるメソッドは、search_set_gregex と search_set_wrap_around ですが、
> 代入メソッドを定義した方が良いでしょうか？
あった方がRubyっぽく書けるような気がするのでお願いします。
> また、見ていて気づいたのですが search_set_gregex はNULL許容のため、引数がオプショナルになっており
> search_set_gregex()とコールするとNULLを渡した事になり、設定が解除されてしまいそうです。
> 引数を必須にしておいた方が良いでしょうか？
あぁ、そうですね。
オプショナルにしないほうがいいと思います。
search_set_gregex()とsearch_get_gregex()について少し考えてみ
たのですが、現状はGLib::Regexpがなく、今後も追加するかどうか
はまだ検討する余地があると思う(*)ので、今のところは以下のよ
うにするのはいかがでしょうか？
* search_set_gregex: 引数は文字列を受け取り、内部でGRegexp
を生成して使う。
* search_get_gregex: APIを提供しない。あるいは
g_regex_get_pattern()の値を返す。
(*) RubyのRegexpとGLib::Regexがあると混乱しそうとか、Rubyの
Regexpの方が断然使いやすいのでGLib::Regexがある意味があ
るのかとか。
|
|
From: Masaaki A. <mas...@gm...> - 2011-09-10 12:15:46
|
青柳です。 ちょっと説明不足だったかもしれないので、補足します。 > * 引数のデフォルトを fork_command に合わせる これは、0.26.2 の vte_terminal_fork_command が vte_terminal_fork_command_full を 使用して実装されているので、それに合わせています。 また、この方法で fork_command が fork_command_full を兼ねられるようにして良いなら fork_command_full を外に出さないようにしようと考えています。 |
|
From: Masaaki A. <mas...@gm...> - 2011-09-06 11:17:54
|
青柳です。 >> それと、glib に GRegex を実装する必要があると思われます。 > > うーん、Rubyの世界にもRegexpがあるので、できればGRegexは外に > は出したくないんですよね。文字列化Regexpを渡すと中で勝手に > GRegexに変換してあげるっていうのは難しいですよねぇ。 完全隠蔽は、難しいでしょうね。 >> * ブロック引数を受ける場合、rb_scan_args で"&"指定をする方法と rb_block_proc を使用する方法があるようですが、 >> ブロックを省略可能にする場合は、前者で行う必要があるということなのでしょうか？ > > rb_block_procを使う場合もrb_block_given_p()で確認できます。 > （Rubyレベルのblock_given?と同じものです。） > > rb_scan_argsの"&"も中ではrb_block_given_p()とrb_block_proc() > を使っているので、rb_scan_args()もrb_block_proc()もどちらも > 同じです。ただ、rb_scan_args()は便利関数として提供されている > ので、rb_scan_args()で事足りる場合はrb_scan_args()を使うのが > よいかと思います。 > >> * vte_terminal_fork_command_full の引数は、NULL許容のものをオプショナルとしています。 >> そのため、Cの引数と順番が異なってしまっていますが、どうするのが良いのでしょうか？ > > Hashとして引数をとれるようにするのがよいかと思います。 > Ruby 1.9.3のrb_scan_args()は":"でそういうことができるように > なった。。。のですが、あれ、なんかいま見たら思っていたより便 > 利になっていないですね。。。 > > Hashの中身も変数に代入してくれるかと思っていたのですが、そこ > まではやってくれないですねぇ。 > > https://github.com/ranguba/rroonga/blob/master/ext/groonga/rb-grn-utils.c > ここにrb_grn_scan_options()というのがあって、これを使うと > rb_scan_args()のようにHashから各オプションの値を変数に代入し > てくれます。あと、未知のオプションを指定したらエラーを報告し > ます。 > > 私が書いたものなので、持ってきてRuby-GNOME 2のライセンスに変 > 更して取り込んでも大丈夫です。 > > >> * vte_terminal_fork_command_full 自身の使い方がよく分からないです。 >> 添付のサンプルファイルのようにしても、子プロセスの入出力がウィジェットに繋がらない？ような感じです。 > > 見てみました。 > child_setupを指定する場合は、child_setup内で > vte_pty_child_setup()を呼んであげないとダメみたいです。 > > > vte_terminal_fork_command()がdeprecatedで > vte_terminal_fork_command_full()になったんですね。Rubyレベル > ではどちらもTerminal#fork_commandになると使いやすそうな気が > しますが、APIがかなり変わっているので難しそうですね。。。 教えて頂いたことを踏まえ、いくつか変更しましたので差分を添付します。 前回からの変更点は、 * fork_command_full を Hash 引数に変更 * 引数のデフォルトを fork_command に合わせる * ブロック引数を省略した場合は、child_setup を渡さないように これにより、ブロックを省略した場合は動くようになりましたが、ブロックを渡した場合は相変わらずよく分からない。。。 * fork_command で引数を省略した際と Hash で渡した際は fork_command_full に処理を委譲する * vte_terminal_fork_command が使われる場合は、warning メッセージを出力する * search_get_wrap_around が"?"付きメソッドになっていなかったので修正 といったところです。 いかがでしょうか？ > search_{get,set}_XXXなんですが、{get,set}を先頭に持ってきて > {get,set}_search_XXXにするのはいかがでしょうか？set_が先頭に > ないとG_DEF_SETTERSでsearch_XXX=みたいなメソッドを自動生成す > るやつが動かない気がするんです。 > > でも、これもメソッド名の統一感的に難しそうですねぇ。うーん。 これは、以下の命名規則のページでも動詞の削除などをしないとされているので、個別対応となると思っています。 大して数はないので、それでいいのかなと。 http://ruby-gnome2.sourceforge.jp/hiki.cgi?Naming+and+Conversion+Rules 今回対象となるメソッドは、search_set_gregex と search_set_wrap_around ですが、 代入メソッドを定義した方が良いでしょうか？ また、見ていて気づいたのですが search_set_gregex はNULL許容のため、引数がオプショナルになっており search_set_gregex()とコールするとNULLを渡した事になり、設定が解除されてしまいそうです。 引数を必須にしておいた方が良いでしょうか？ |
|
From: Kouhei S. <ko...@co...> - 2011-09-04 12:59:58
|
須藤です。 In <CAMyNdeVjE4BQajM-6Eh84Spq=R-c...@ma...> "[ruby-gnome2-devel-ja] vteの実装をしてみました" on Sun, 4 Sep 2011 14:42:41 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > vteを実装した差分を添付しますので、ご確認ください。 > 対象バージョンは、0.26.2です。 おぉ！ > それと、glib に GRegex を実装する必要があると思われます。 うーん、Rubyの世界にもRegexpがあるので、できればGRegexは外に は出したくないんですよね。文字列化Regexpを渡すと中で勝手に GRegexに変換してあげるっていうのは難しいですよねぇ。 > また、実装する際に、いくつか疑問がありましたので教えてください。 > * ブロック引数を受ける場合、rb_scan_args で"&"指定をする方法と rb_block_proc を使用する方法があるようですが、 > ブロックを省略可能にする場合は、前者で行う必要があるということなのでしょうか？ rb_block_procを使う場合もrb_block_given_p()で確認できます。 （Rubyレベルのblock_given?と同じものです。） rb_scan_argsの"&"も中ではrb_block_given_p()とrb_block_proc() を使っているので、rb_scan_args()もrb_block_proc()もどちらも 同じです。ただ、rb_scan_args()は便利関数として提供されている ので、rb_scan_args()で事足りる場合はrb_scan_args()を使うのが よいかと思います。 > * vte_terminal_fork_command_full の引数は、NULL許容のものをオプショナルとしています。 > そのため、Cの引数と順番が異なってしまっていますが、どうするのが良いのでしょうか？ Hashとして引数をとれるようにするのがよいかと思います。 Ruby 1.9.3のrb_scan_args()は":"でそういうことができるように なった。。。のですが、あれ、なんかいま見たら思っていたより便 利になっていないですね。。。 Hashの中身も変数に代入してくれるかと思っていたのですが、そこ まではやってくれないですねぇ。 https://github.com/ranguba/rroonga/blob/master/ext/groonga/rb-grn-utils.c ここにrb_grn_scan_options()というのがあって、これを使うと rb_scan_args()のようにHashから各オプションの値を変数に代入し てくれます。あと、未知のオプションを指定したらエラーを報告し ます。 私が書いたものなので、持ってきてRuby-GNOME 2のライセンスに変 更して取り込んでも大丈夫です。 > * vte_terminal_fork_command_full 自身の使い方がよく分からないです。 > 添付のサンプルファイルのようにしても、子プロセスの入出力がウィジェットに繋がらない？ような感じです。 見てみました。 child_setupを指定する場合は、child_setup内で vte_pty_child_setup()を呼んであげないとダメみたいです。 vte_terminal_fork_command()がdeprecatedで vte_terminal_fork_command_full()になったんですね。Rubyレベル ではどちらもTerminal#fork_commandになると使いやすそうな気が しますが、APIがかなり変わっているので難しそうですね。。。 search_{get,set}_XXXなんですが、{get,set}を先頭に持ってきて {get,set}_search_XXXにするのはいかがでしょうか？set_が先頭に ないとG_DEF_SETTERSでsearch_XXX=みたいなメソッドを自動生成す るやつが動かない気がするんです。 でも、これもメソッド名の統一感的に難しそうですねぇ。うーん。 |
|
From: Masaaki A. <mas...@gm...> - 2011-09-04 05:42:48
|
青柳です。 vteを実装した差分を添付しますので、ご確認ください。 対象バージョンは、0.26.2です。 ただ、ビルドが通ることは確認していますが、動作確認は出来ておりません。 それと、glib に GRegex を実装する必要があると思われます。 また、実装する際に、いくつか疑問がありましたので教えてください。 * ブロック引数を受ける場合、rb_scan_args で"&"指定をする方法と rb_block_proc を使用する方法があるようですが、 ブロックを省略可能にする場合は、前者で行う必要があるということなのでしょうか？ * vte_terminal_fork_command_full の引数は、NULL許容のものをオプショナルとしています。 そのため、Cの引数と順番が異なってしまっていますが、どうするのが良いのでしょうか？ * vte_terminal_fork_command_full 自身の使い方がよく分からないです。 添付のサンプルファイルのようにしても、子プロセスの入出力がウィジェットに繋がらない？ような感じです。 以上、よろしくお願いします。 |
|
From: Kouhei S. <ko...@co...> - 2011-08-28 07:23:18
|
須藤です。 In <CAM...@ma...> "[ruby-gnome2-devel-ja] enumやflagsの規則について" on Sun, 28 Aug 2011 16:06:59 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > 今後実装するものについて、以下のようなenumやflagsの規則を提案します。 > > * 定義はG_DEF_CLASSで行う(G_DEF_CONSTANTSは使わない) > * 所属する名前空間は、キャメルケースで分離してパスが最長一致する名前空間とする > （ここでのパスとは、Vte::TerminalならVteTerminalとする） > 例）VteTerminalCursorBlinkModeの場合 > * キャメルケースで分離 > Vte, Terminal, Cursor, Blink, Mode > * VteTerminalCursorBlink, VteTerminalCursor, VteTerminal と順番にパスが一致する名前空間を探す > Vte::Terminalが一致するので、Vte::Terminalに属す > * クラス名は所属する名前空間のパスを削除したものとする > 例）VteTerminalCursorBlinkMode → CursorBlinkMode > > いかがでしょうか？ > 参考として、いくつかのライブラリで定義されているenumとflagsのリストを添付します。 ありがとうございます！ よいと思います！ > また、命名規則に合っていないファイルがありましたので、ファイル名を変更しようと思います。 > よろしいでしょうか？ > rbvte-access.c → rbvte-terminalaccessible.c はい、こちらもOKです！ |
|
From: Masaaki A. <mas...@gm...> - 2011-08-28 07:07:06
|
青柳です。 今後実装するものについて、以下のようなenumやflagsの規則を提案します。 * 定義はG_DEF_CLASSで行う(G_DEF_CONSTANTSは使わない) * 所属する名前空間は、キャメルケースで分離してパスが最長一致する名前空間とする （ここでのパスとは、Vte::TerminalならVteTerminalとする） 例）VteTerminalCursorBlinkModeの場合 * キャメルケースで分離 Vte, Terminal, Cursor, Blink, Mode * VteTerminalCursorBlink, VteTerminalCursor, VteTerminal と順番にパスが一致する名前空間を探す Vte::Terminalが一致するので、Vte::Terminalに属す * クラス名は所属する名前空間のパスを削除したものとする 例）VteTerminalCursorBlinkMode → CursorBlinkMode いかがでしょうか？ 参考として、いくつかのライブラリで定義されているenumとflagsのリストを添付します。 また、命名規則に合っていないファイルがありましたので、ファイル名を変更しようと思います。 よろしいでしょうか？ rbvte-access.c → rbvte-terminalaccessible.c |
|
From: Kouhei S. <ko...@co...> - 2011-08-19 14:37:53
|
須藤です。 In <CAJW8SQf=S9B...@ma...> "[ruby-gnome2-devel-ja] [PATCH] goocanvas 1.0.0 x86-mingw32でのrequireエラーについて" on Fri, 19 Aug 2011 23:18:45 +0900, HAYASHI Kentaro <ke...@gm...> wrote: > goocanvasを試すにあたって、以下のエラーになったのでパッチを送ります。 > 手元の環境では問題なさそうですがどうでしょうか。 ありがとうございます！ そのまま取り込みました！ |
|
From: HAYASHI K. <ke...@gm...> - 2011-08-19 14:19:32
|
林です。
goocanvasを試すにあたって、以下のエラーになったのでパッチを送ります。
手元の環境では問題なさそうですがどうでしょうか。
c:\ruby\bin>ruby -v
ruby 1.9.2p290 (2011-07-09) [i386-mingw32]
c:\ruby\bin>gem search goocanvas
*** LOCAL GEMS ***
goocanvas (1.0.0 x86-mingw32)
c:\ruby\bin>ruby -e "require 'goocanvas'"
c:/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `require': no
such file to load -- goocanvas.so (LoadError)
from c:/ruby/lib/ruby/site_ruby/1.9.1/rubygems/custom_require.rb:36:in `
require'
from c:/ruby/lib/ruby/gems/1.9.1/gems/goocanvas-1.0.0-x86-mingw32/lib/go
ocanvas.rb:3:in `<top (required)>'
from <internal:lib/rubygems/custom_require>:33:in `require'
from <internal:lib/rubygems/custom_require>:33:in `rescue in require'
from <internal:lib/rubygems/custom_require>:29:in `require'
from -e:1:in `<main>'
--
HAYASHI Kentaro <ke...@gm...>
|
|
From: Masaaki A. <mas...@gm...> - 2011-07-24 12:59:26
|
青柳です。 コミット完了しました。 ご確認、ありがとうございました！ |
|
From: Kouhei S. <ko...@co...> - 2011-07-24 12:46:38
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] 命名規則などの提案" on Sun, 24 Jul 2011 21:26:27 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > 最後に命名規則を適用するパッチです。 > ご確認をお願いします。 これもお願いします！ |
|
From: Masaaki A. <mas...@gm...> - 2011-07-24 12:26:33
|
青柳です。 最後に命名規則を適用するパッチです。 ご確認をお願いします。 |
|
From: Kouhei S. <ko...@co...> - 2011-07-24 11:56:15
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] 命名規則などの提案" on Sun, 24 Jul 2011 19:15:19 +0900, Masaaki Aoyagi <mas...@gm...> wrote: > まず、名前空間毎にファイルを分離するパッチです。 > cTerminalEraseBinding のような変数は不要だったので削除もしています。 > よろしければ、コミットいたします。 お願いします！！！ |
|
From: Masaaki A. <mas...@gm...> - 2011-07-24 10:15:25
|
青柳です。 まず、名前空間毎にファイルを分離するパッチです。 cTerminalEraseBinding のような変数は不要だったので削除もしています。 よろしければ、コミットいたします。 |
|
From: Kouhei S. <ko...@co...> - 2011-07-24 09:22:37
|
須藤です。 In <CAM...@ma...> "Re: [ruby-gnome2-devel-ja] 命名規則などの提案" on Sun, 24 Jul 2011 18:17:19 +0900, Masaaki Aoyagi <mas...@gm...> wrote: >> 関数の方もマクロの方もprefixは揃えた方がよいと思うので、 >> rg_/RG_でいかがでしょうか！？ > > では、rg_poll のあたりの関数はいずれ変更するということで。 そうですね。 > マクロの方は、RG_DEF_CONVERSION というのだけありますが、そのままでもいいでしょうか？ はい。今回の変更の方針とぶつかるものではないと思うので、その ままでよいと思います！ > 今までの内容をまとめると、 > > * 1ファイル＝1名前空間（クラスまたはモジュール）とする > * ファイル名は rb<名前空間>.c とし、名前空間のネストは - で繋ぐ > 例）Vte::Terminal → rbvte-terminal.c > * 名前空間の変数名（RG_TARGET_NAMESPACE）は、m<モジュール名> または c<クラス名> とする > （グローバルスコープの場合は、prefixとして rg_ を付ける） > 例）Vte::Terminal → cTerminal > * rubyからのIFになっている関数名は、rg_<メソッド名> とする > （シングルトンメソッドの場合は、rg_s_<メソッド名>、モジュール関数の場合は、rg_m_<メソッド名>） > 使用マクロ：RG_DEF_METHOD、RG_DEF_SMETHOD、RG_DEF_MODFUNC > * ? 付きメソッドの関数名は、末尾に ? の代わりに _p を付ける > 使用マクロ：RG_DEF_METHOD_P、RG_DEF_SMETHOD_P、RG_DEF_MODFUNC_P > * ! 付きメソッドの関数名は、末尾に ! の代わりに _bang を付ける > 使用マクロ：RG_DEF_METHOD_BANG > * 演算子メソッドの関数名は、rg_(|s_|m_)operator_<任意> とする > 使用マクロ：RG_DEF_METHOD_OPERATOR、RG_DEF_SMETHOD_OPERATOR、RG_DEF_MODFUNC_OPERATOR > > こんな感じで、よろしいでしょうか？ よいと思います！ |
10 messages has been excluded from this view by a project administrator.
