ruby-gnome2-devel-ja — Ruby-GNOME2 developer's Mailing list. in Japanese.

Re: [ruby-gnome2-devel-ja] enum/flags =?iso-2022-jp?B?GyRCJE4lLyVpJTkyPRsoQg==?=

[Masahiro S. () <sa...@to...>]

さかいです。

From: Masahiro Sakai (酒井政裕) <sa...@to...>
Subject: [ruby-gnome2-devel-ja] enum/flags のクラス化
Date: Sun, 06 Apr 2003 20:57:47 +0900 (JST)

> GEnum/GFlagsの派生タイプを現在は整数として扱っていますが、
> これをそれぞれのクラスのオブジェクトとして扱うように
> 変更しようかと考えています。

基本的な部分が実装出来たのでパッチをつけます。

> デメリットは
> * Rubyレベルのフラグのチェック方法はこれまでと互換性を保てないかも(?)
>   (「0 < (x & FOO)」みたいなコードは特に互換性を維持する気になれない...)

これも出来るようになりました。

# Fixnum#==はcoerceを使わないのに、Fixnum#<はcoerceを使うんですね。
# ちょっと混乱してしまいました。

> とりあえず、手元では以下のような事が出来るようになっています。
> 
> require 'gtk2'
> Gtk::Window::Type = GLib::Type['GtkWindowType'].to_class
> 
> p Gtk::Window::Type.values
> #=> [#<Gtk::Window::Type value=0 name="GTK_WINDOW_TOPLEVEL" nick="toplevel">,
> #    #<Gtk::Window::Type value=1 name="GTK_WINDOW_POPUP" nick="popup">]
> 
> p Gtk::Window::Type::TOPLEVEL
> #=> #<Gtk::Window::Type value=0 name="GTK_WINDOW_TOPLEVEL" nick="toplevel">

--
酒井 政裕 / Masahiro Sakai

[ruby-gnome2-devel-ja] GScanner

[Masahiro S. () <sa...@to...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] yendot
Date: Fri, 11 Apr 2003 02:51:36 +0900

> むとうです。

> > > ところで、話は変わりますが、GScannerあたりって実装する予定ないです？
> > > ＃ってかRuby/GTK側で呼んでるところがいくつかあるので欲しいんですよね。
> > 
> > いまの所は無いです。
> 
> はぅぅ。そんなつれないことをおっしゃらずにインプリしていただけない
> でしょうか。
> お暇なときで構いませんので....。

それじゃあ、クラス自体はそのうち...
でも、GScannerの事をよく理解していないので
あんまし期待しないでくださいね。(^^;

--
酒井 政裕 / Masahiro Sakai

[ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?B?Z29iamVjdBskQiROJS8laSU5JHIbKEJSdWJ5GyRCJCskaURqNUEbKEI=?=

[Masahiro S. () <sa...@to...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] gobjectのクラスをRubyから定義
Date: Sun, 13 Apr 2003 13:34:59 +0900

> むとうです。
> 
> 今、cvs updateかけたら、GLib::Object.class_newが
> GLib::Object.register_typeに変わってて、ちと作りかけて
> いたモノが動かなくなってしまったのでアイデアだけ(^^;)。

今のregister_typeは
  class MyButton < Gtk::Button
    register_type(nil, 0)
  end
のように使います。

第一引数が名前なのですが、無名クラスでない場合は
nilを指定するとname.gsub(/::/, '')が使われるようになっています。
第二引数はフラグです。

# それからsignal_newの引数も若干変更しています。

> この件ですが、もう少しRubyっぽく見せれないかと考えてます。
> で、Class.inheritedでうまく引っかけられないかと思って以下のような
> ことを考えました。

> ただ、signal_newするタイミングが問題で、普通にクラスの宣言部分で
> 
> class MyButton  < Gtk::Button
>   signal_new("hogehoge", .... )
> end
> 
> と書いてしまうと、Class.inheritedが呼ばれる前にsignal_newが呼ばれてしまい、
> 結局、Gtk::Buttonのシグナルとして"hogehoge"が登録されてしまいます。

これはまずいですね。この手のクラスメソッドは、
固有のGTypeを持たないようなクラスでは例外を発生させる事にしました。

> このアイデアは、GLib::Objectを継承する全てのクラスがGType
> にマッピングされるので、コーディング時に明示的に登録する必要が無い点が
> 良い点なのじゃないかなと思っています。
> signalを自分で作りたいといったときはMyButton.gobject_initを定義しなければ
> いけないと言うのがちとイケてない気がしなくもないですが、許容範囲かなと。
> 
> まだきちんと実装できていないので穴があるかもしれませんが、
> こんな方向性はどうでしょうか？　＞　さかいさん

Class#inheritedを使って自動登録する事も考えた事はあるのですが、
* 無名クラスの場合に名前をどうするか?
* 少なくとも現時点ではRubyでの通常のクラスと非互換性が大きいので、
  無条件にクラスを登録してしまうのはまずい
といった理由で諦めていました。

--
酒井 政裕 / Masahiro Sakai

[ruby-gnome2-devel-ja] rbbr

[Masahiro S. () <sa...@to...>]

さかいです

rbbrをちょっといじって、
プロパティのデフォルト値を表示するようにしてみました。
ついでにプロパティのTypeのカラムも有効にしました。

ところで、プロパティのBlurbはリストビューに表示するには長すぎなので、
DocViewerの部分に表示したいのですが、どうでしょうか?

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] =?ISO-2022-JP?B?Z29iamVjdBskQiROGyhC?= =?ISO-2022-JP?B?GyRCJS8laSU5JHIbKEJSdWJ5GyRCJCskaURqNUEbKEI=?=

[Masao M. <mu...@hi...>]

むとうです。

今、cvs updateかけたら、GLib::Object.class_newが
GLib::Object.register_typeに変わってて、ちと作りかけて
いたモノが動かなくなってしまったのでアイデアだけ(^^;)。

On Sat, 05 Apr 2003 00:24:43 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> MyButton = GLib::Object.class_new(Gtk::Button, "MyButton"){
>   def instance_init
>     puts "MyButton#instance_init is called"
>   end
> 
>   signal_new("hogehoge",
>              GLib::Signal::RUN_FIRST | GLib::Signal::ACTION,
>              GLib::Type["void"], GLib::Type["gint"], GLib::Type["GObject"])
> 
>   def real_hogehoge(*args)
>     puts "signal hogehoge is emitted: args=#{args.inspect}"
>   end
> }

この件ですが、もう少しRubyっぽく見せれないかと考えてます。
で、Class.inheritedでうまく引っかけられないかと思って以下のような
ことを考えました。

----------------------
module GLib
  class Object
    def Object.inherited(subclass)
        #ここで登録（このままでは動かないです）
        register_type(subclass)
        subclass.gobject_init
    end
  end
end

class MyButton  < Gtk::Button
  def MyButton.gobject_init
    signal_new("hogehoge", .... )
  end
  def real_hogehoge(*args)
    puts "signal hogehoge is emitted: args=#{args.inspect}"
  end
end
----------------------

class_newの時に上記のようなコードを書いてみて、とりあえず、MyButtonを
GTypeとして登録することは可能になりました。
ただ、signal_newするタイミングが問題で、普通にクラスの宣言部分で

class MyButton  < Gtk::Button
  signal_new("hogehoge", .... )
end

と書いてしまうと、Class.inheritedが呼ばれる前にsignal_newが呼ばれてしまい、
結局、Gtk::Buttonのシグナルとして"hogehoge"が登録されてしまいます。
そこで、MyButton.gobject_initというのが定義されていたらそれを呼び出す
形にすればよいんじゃないか....というところでごにょごにょやっていたら
今に至ってしまいました。

------------
このアイデアは、GLib::Objectを継承する全てのクラスがGType
にマッピングされるので、コーディング時に明示的に登録する必要が無い点が
良い点なのじゃないかなと思っています。
signalを自分で作りたいといったときはMyButton.gobject_initを定義しなければ
いけないと言うのがちとイケてない気がしなくもないですが、許容範囲かなと。

まだきちんと実装できていないので穴があるかもしれませんが、
こんな方向性はどうでしょうか？　＞　さかいさん

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] Action signals

[Masao M. <mu...@hi...>]

むとうです。

On Sun, 13 Apr 2003 04:03:25 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 
> From: Masao Mutoh <mu...@hi...>
> Subject: Re: [ruby-gnome2-devel-ja] Action signals
> Date: Sun, 13 Apr 2003 01:56:23 +0900
> 
> > むとうです。
> 
> > > 特異メソッドによるシグナルハンドラの定義って
> > > 実際にはどれくらい使われてるんでしょう?
> > 
> > ドキュメントがほとんど無い（Ruby/GTKのころの五十嵐さんのドキュメントに
> > あったような記憶はありますが）ですし、使ってる例もほとんどないので、
> > 存在そのものを知らない人が多い気はします(^^;)。
> > 個人的には、このアプローチ(特異メソッドによるシグナルハンドラの定義)
> > ってあまり好きではないんですよねぇ。
> > この際、無くしちゃうとか。
> 
> 私も無くしてしまって構わないと思います。
> 他の人はどうでしょうか?
> 
> P.S
> ちなみにsignal_connectは
>   obj.signal_connect(name, extra_args...){|obj, args..., extra_args...|
>     ...
>   }
> という形で使えるようになっていますが、
> このextra_argsの部分もほとんどの人は存在を知らない気がします。

う、知りませんでした(^^;)。

> # これも個人的には無くしてしまいたい...

私も無くしてしまって良いと思います。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] Action signals

[Masahiro S. () <sa...@to...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] Action signals
Date: Sun, 13 Apr 2003 01:56:23 +0900

> むとうです。

> > 特異メソッドによるシグナルハンドラの定義って
> > 実際にはどれくらい使われてるんでしょう?
> 
> ドキュメントがほとんど無い（Ruby/GTKのころの五十嵐さんのドキュメントに
> あったような記憶はありますが）ですし、使ってる例もほとんどないので、
> 存在そのものを知らない人が多い気はします(^^;)。
> 個人的には、このアプローチ(特異メソッドによるシグナルハンドラの定義)
> ってあまり好きではないんですよねぇ。
> この際、無くしちゃうとか。

私も無くしてしまって構わないと思います。
他の人はどうでしょうか?

P.S
ちなみにsignal_connectは
  obj.signal_connect(name, extra_args...){|obj, args..., extra_args...|
    ...
  }
という形で使えるようになっていますが、
このextra_argsの部分もほとんどの人は存在を知らない気がします。
# これも個人的には無くしてしまいたい...

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Multi-threading support

[Nobuyoshi N. <nob...@so...>]

なかだです。

At Sun, 13 Apr 2003 01:52:09 +0900,
Masao Mutoh wrote:
> > 一番単純そうなgtk/sample/misc/window.rbで試しましたが、やはりデッ
> > ドロックしました。環境はRedHat 8.1、gtk2-2.1.5です。
> 
> gtk2-2.1.5って微妙なバージョンですね。gtk2-2.2.1でも同様でしょうか。

なるほど。8.1っていってもbetaから入れてますから、ダメダメなのか
も。

> > ちなみに、G_THREADS_ENABLEDを#undefしてさらにMakefileから
> > -pthreads, -lpthreads, -lgthreads-2.0などを抜いても同じです。
> 
> マジすか？
> これ、G_THREADS_ENABLEDをundefしてダメだったらRuby-GNOME2側からだと
> 何の対処もできないような気が....。

どれかのライブラリが勝手にリンクしてしまうようです。ともあれバー
ジョンを上げてみます。

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

Re: [ruby-gnome2-devel-ja] Action signals

[Masao M. <mu...@hi...>]

むとうです。

On Sat, 12 Apr 2003 22:50:26 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 
> From: Masao Mutoh <mu...@hi...>
> Subject: Re: [ruby-gnome2-devel-ja] Action signals
> Date: Sat, 12 Apr 2003 00:34:37 +0900
> 
> > むとうです。
> 
> > ちと、普通のメソッド（やプロパティ）とメソッド名が重複しないか
> > 心配ですが、とくに問題ないようでしたら、experimentalではなく
> > 本採用ということでどうでしょうか。
> 
> 通常のメソッドやプロパティの方が後から定義されるため、
> それらを上書きしてしまう事はないはずで、
> 名前の重複はそれほど気にする必要はないでしょう。

なるほど。
 
> そういえば、特異メソッドによるシグナルハンドラの定義を使っていると
> 混乱しそうな気はしますが、このコードを有効にしなくても、
> シグナル名と同名のメソッドは既にたくさんあるんですよね...

そうですね。Gtk::Buttonなんかもそうですし。
 
> 特異メソッドによるシグナルハンドラの定義って
> 実際にはどれくらい使われてるんでしょう?

ドキュメントがほとんど無い（Ruby/GTKのころの五十嵐さんのドキュメントに
あったような記憶はありますが）ですし、使ってる例もほとんどないので、
存在そのものを知らない人が多い気はします(^^;)。
個人的には、このアプローチ(特異メソッドによるシグナルハンドラの定義)
ってあまり好きではないんですよねぇ。
この際、無くしちゃうとか。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] Multi-threading support

[Masao M. <mu...@hi...>]

むとうです。

On Sun, 13 Apr 2003 01:33:51 +0900
Nobuyoshi Nakada <nob...@so...> wrote:

> なかだです。
> 
> At Sun, 9 Mar 2003 22:03:26 +0900,
> Masao Mutoh wrote:
> > > > enの方で要望が出ていたのでマルチスレッドに対応してみました。
> > > > 
> > > > gtk2ライブラリが初期化(init.c)されるときに
> > > >     g_thread_init (NULL);
> > > >     gdk_threads_init();
> > > > 
> > > > を呼び出しています。
> > > > ＃これはRubyから呼び出す関数にしようと思ったのですが、
> > > > ＃タイミング的にここでやらないとうまく動作しませんでした。
> > > 
> > > ruby-talkで、pthreadとリンクした拡張ライブラリをロードすると終
> > > 了するときにデッドロックするという話がありましたが、大丈夫でし
> > > たか。
> > 
> > 少なくとも私の環境上では、初期化だけなら大丈夫でした。
> > みなさんの環境でも試していただけると助かります。
> 
> 一番単純そうなgtk/sample/misc/window.rbで試しましたが、やはりデッ
> ドロックしました。環境はRedHat 8.1、gtk2-2.1.5です。

gtk2-2.1.5って微妙なバージョンですね。gtk2-2.2.1でも同様でしょうか。
 
> ちなみに、G_THREADS_ENABLEDを#undefしてさらにMakefileから
> -pthreads, -lpthreads, -lgthreads-2.0などを抜いても同じです。

マジすか？
これ、G_THREADS_ENABLEDをundefしてダメだったらRuby-GNOME2側からだと
何の対処もできないような気が....。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] Multi-threading support

[Nobuyoshi N. <nob...@so...>]

なかだです。

At Sun, 9 Mar 2003 22:03:26 +0900,
Masao Mutoh wrote:
> > > enの方で要望が出ていたのでマルチスレッドに対応してみました。
> > > 
> > > gtk2ライブラリが初期化(init.c)されるときに
> > >     g_thread_init (NULL);
> > >     gdk_threads_init();
> > > 
> > > を呼び出しています。
> > > ＃これはRubyから呼び出す関数にしようと思ったのですが、
> > > ＃タイミング的にここでやらないとうまく動作しませんでした。
> > 
> > ruby-talkで、pthreadとリンクした拡張ライブラリをロードすると終
> > 了するときにデッドロックするという話がありましたが、大丈夫でし
> > たか。
> 
> 少なくとも私の環境上では、初期化だけなら大丈夫でした。
> みなさんの環境でも試していただけると助かります。

一番単純そうなgtk/sample/misc/window.rbで試しましたが、やはりデッ
ドロックしました。環境はRedHat 8.1、gtk2-2.1.5です。

ちなみに、G_THREADS_ENABLEDを#undefしてさらにMakefileから
-pthreads, -lpthreads, -lgthreads-2.0などを抜いても同じです。

gdbで動かしてCtrl-Cで止めたところのバックトレース。

Program received signal SIGINT, Interrupt.
0x400b36a6 in sigsuspend () from /lib/libc.so.6
(gdb) bt
#0  0x400b36a6 in sigsuspend () from /lib/libc.so.6
#1  0x40c3df38 in pthread_getconcurrency () from /lib/libpthread.so.0
#2  0x40c3fb00 in sem_timedwait () from /lib/libpthread.so.0
#3  0x40c3ca77 in pthread_mutex_lock () from /lib/libpthread.so.0
#4  0x400ed060 in flockfile () from /lib/libc.so.6
#5  0x400efaa8 in ungetc () from /lib/libc.so.6
#6  0x4069207e in pango_read_line () from /usr/lib/libpango-1.0.so.0
#7  0x406825eb in pango_find_map () from /usr/lib/libpango-1.0.so.0
#8  0x40682943 in pango_find_map () from /usr/lib/libpango-1.0.so.0
#9  0x40682d79 in pango_find_map () from /usr/lib/libpango-1.0.so.0
#10 0x406823a8 in pango_find_map () from /usr/lib/libpango-1.0.so.0
#11 0x406864a8 in pango_itemize () from /usr/lib/libpango-1.0.so.0
#12 0x40685c92 in pango_itemize () from /usr/lib/libpango-1.0.so.0
#13 0x4068d05f in no_shape_filter_func () from /usr/lib/libpango-1.0.so.0
#14 0x4068b594 in pango_layout_get_cursor_pos () from /usr/lib/libpango-1.0.so.0
#15 0x4068b899 in pango_layout_get_extents () from /usr/lib/libpango-1.0.so.0
#16 0x407f2209 in gtk_label_get () from /usr/lib/libgtk-x11-2.0.so.0
#17 0x40318fe1 in g_cclosure_marshal_VOID__BOXED () from /usr/lib/libgobject-2.0.so.0
#18 0x40305187 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0
#19 0x40304e17 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#20 0x4031794f in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
#21 0x40317268 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#22 0x40317573 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
#23 0x40856c91 in gtk_size_group_remove_widget () from /usr/lib/libgtk-x11-2.0.so.0
#24 0x4085702f in _gtk_size_group_compute_requisition () from /usr/lib/libgtk-x11-2.0.so.0
#25 0x408ff34a in gtk_widget_size_request () from /usr/lib/libgtk-x11-2.0.so.0
#26 0x4076f3a0 in gtk_button_get_relief () from /usr/lib/libgtk-x11-2.0.so.0
#27 0x40318fe1 in g_cclosure_marshal_VOID__BOXED () from /usr/lib/libgobject-2.0.so.0
#28 0x40305187 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0
#29 0x40304e17 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#30 0x4031794f in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
#31 0x40317268 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#32 0x40317573 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
#33 0x40856c91 in gtk_size_group_remove_widget () from /usr/lib/libgtk-x11-2.0.so.0
#34 0x4085702f in _gtk_size_group_compute_requisition () from /usr/lib/libgtk-x11-2.0.so.0
#35 0x408ff34a in gtk_widget_size_request () from /usr/lib/libgtk-x11-2.0.so.0
#36 0x40910358 in gtk_window_reshow_with_initial_size () from /usr/lib/libgtk-x11-2.0.so.0
#37 0x40318fe1 in g_cclosure_marshal_VOID__BOXED () from /usr/lib/libgobject-2.0.so.0
#38 0x40305187 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0
#39 0x40304e17 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#40 0x4031794f in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
#41 0x40317268 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#42 0x40317573 in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
#43 0x40856c91 in gtk_size_group_remove_widget () from /usr/lib/libgtk-x11-2.0.so.0
#44 0x4085702f in _gtk_size_group_compute_requisition () from /usr/lib/libgtk-x11-2.0.so.0
#45 0x408ff34a in gtk_widget_size_request () from /usr/lib/libgtk-x11-2.0.so.0
#46 0x40911744 in _gtk_window_unset_focus_and_default () from /usr/lib/libgtk-x11-2.0.so.0
#47 0x4090f9ab in gtk_window_reshow_with_initial_size () from /usr/lib/libgtk-x11-2.0.so.0
#48 0x403183a7 in g_cclosure_marshal_VOID__VOID () from /usr/lib/libgobject-2.0.so.0
#49 0x40305187 in g_cclosure_new_swap () from /usr/lib/libgobject-2.0.so.0
#50 0x40304e17 in g_closure_invoke () from /usr/lib/libgobject-2.0.so.0
#51 0x4031794f in g_signal_emit_by_name () from /usr/lib/libgobject-2.0.so.0
#52 0x40317268 in g_signal_emit_valist () from /usr/lib/libgobject-2.0.so.0
#53 0x40317494 in g_signal_emit () from /usr/lib/libgobject-2.0.so.0
#54 0x408fdf77 in gtk_widget_show () from /usr/lib/libgtk-x11-2.0.so.0
#55 0x407a2054 in gtk_container_get_focus_hadjustment () from /usr/lib/libgtk-x11-2.0.so.0
#56 0x408fe516 in gtk_widget_show_all () from /usr/lib/libgtk-x11-2.0.so.0
#57 0x406daf71 in widget_show_all () from /usr/lib/ruby/site_ruby/1.8/i686-linux/gtk2.so
#58 0x08062767 in rb_call0 (klass=1075613928, recv=1075683748, id=9937, oid=4294967292, argc=0,
    argv=0x0, body=0x40c91cc8, nosuper=1) at /home/nobu/src/ruby/1.8/eval.c:4746
#59 0x08059d04 in rb_call (klass=1075613928, recv=1075683748, mid=9937, argc=0, argv=0x0, scope=0)
    at /home/nobu/src/ruby/1.8/eval.c:4963
#60 0x0805618b in rb_eval (self=1075743148, n=0xfffffffc) at /home/nobu/src/ruby/1.8/eval.c:2895
#61 0x08053281 in ruby_exec () at /home/nobu/src/ruby/1.8/eval.c:1181
#62 0x080532f5 in ruby_run () at /home/nobu/src/ruby/1.8/eval.c:1349
#63 0x080521c9 in main (argc=2, argv=0xbffff6c4, envp=0xbffff6d0)
    at /home/nobu/src/ruby/1.8/main.c:50
#64 0x400a0b87 in __libc_start_main () from /lib/libc.so.6
(gdb) p *ruby_current_node
$4 = {flags = 12154943, nd_file = 0x81392c9 "gtk/sample/misc/window.rb", u1 = {node = 0x2699,
    id = 9881, value = 9881, cfunc = 0x2699, tbl = 0x2699}, u2 = {node = 0x0, id = 0, argc = 0,
    value = 0}, u3 = {node = 0x2, id = 2, state = 2, entry = 0x2, cnt = 2, value = 2}}
(gdb) p ruby_current_node->flags>>19
$5 = 23

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?B?GyRCJUElZSE8JUglaiUiJWsbKEI=?=

[Masahiro S. () <sa...@to...>]

さかいです。

From: Nobuyoshi Nakada <nob...@so...>
Subject: Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] チュートリアル
Date: Sat, 12 Apr 2003 22:48:53 +0900

> なかだです。

> > > ということは、こういうのは無限ループ?
> > > 
> > > button.signal_connect("clicked") {
> > >   puts "Hello World\n"
> > >   break
> > > }
> > > 
> > > Gtk.main
> > 
> > 今試したら、その通りでした。

あ、すいません。
無限ループというのは勘違いでした。
# Gtk.main内ののメインループの話かと思ってしまってました。

シグナルハンドラからbreakで脱出しても、
Proc#callを呼び出した側には普通にnilが返って来るので、
シグナルハンドラから通常に戻った場合と何も変わりません。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] =?ISO-2022-JP?B?GyRCJUElZSE8JUglaiUiJWsbKEI=?=

[Nobuyoshi N. <nob...@so...>]

なかだです。

At Sat, 12 Apr 2003 22:36:47 +0900 (JST),
Masahiro Sakai (酒井政裕) wrote:
> > > シグナルを内部で発生させる関数はgtk_main()以外にも大量にあるので、
> > > それら一個一個の呼び出しの後で、例外が保存されているか確認して、
> > > 再送出するのは実際には難しいです。
> > 
> > ひょっとして、ありとあらゆるGlibのメソッドでチェックが必要になっ
> > てしまう?
> 
> はい。

うーん、それはさすがにイヤですねぇ。とはいえrubyの例外もいつ発
生するか分からないし。となるとできることはやっぱりrb_protect()
までですか。

> > ということは、こういうのは無限ループ?
> > 
> > button.signal_connect("clicked") {
> >   puts "Hello World\n"
> >   break
> > }
> > 
> > Gtk.main
> 
> 今試したら、その通りでした。
> この振舞には違和感がありますか?

私としてはありますが、まぁよく分かってないので自信はありません。
というか、そういう形で再入して大丈夫なんでしょうか。

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

Re: [ruby-gnome2-devel-ja] Action signals

[Masahiro S. () <sa...@to...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] Action signals
Date: Sat, 12 Apr 2003 00:34:37 +0900

> むとうです。

> ちと、普通のメソッド（やプロパティ）とメソッド名が重複しないか
> 心配ですが、とくに問題ないようでしたら、experimentalではなく
> 本採用ということでどうでしょうか。

通常のメソッドやプロパティの方が後から定義されるため、
それらを上書きしてしまう事はないはずで、
名前の重複はそれほど気にする必要はないでしょう。


そういえば、特異メソッドによるシグナルハンドラの定義を使っていると
混乱しそうな気はしますが、このコードを有効にしなくても、
シグナル名と同名のメソッドは既にたくさんあるんですよね...

特異メソッドによるシグナルハンドラの定義って
実際にはどれくらい使われてるんでしょう?

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?B?GyRCJUElZSE8JUglaiUiJWsbKEI=?=

[Masahiro S. () <sa...@to...>]

さかいです。

From: Nobuyoshi Nakada <nob...@so...>
Subject: Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] チュートリアル
Date: Sat, 12 Apr 2003 01:28:55 +0900

> なかだです。

> > シグナルを内部で発生させる関数はgtk_main()以外にも大量にあるので、
> > それら一個一個の呼び出しの後で、例外が保存されているか確認して、
> > 再送出するのは実際には難しいです。
> 
> ひょっとして、ありとあらゆるGlibのメソッドでチェックが必要になっ
> てしまう?

はい。

> > > そういえば、シグナルハンドラからbreakしたらどうなるんでしたっけ。
> > 
> > 特別な事は何もしていないので、
> > 普通のProcからbreakするのと変わらないはずです。
> 
> ということは、こういうのは無限ループ?
> 
> button.signal_connect("clicked") {
>   puts "Hello World\n"
>   break
> }
> 
> Gtk.main

今試したら、その通りでした。
この振舞には違和感がありますか?

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] =?ISO-2022-JP?B?GyRCJUElZSE8JUglaiUiJWsbKEI=?=

[Nobuyoshi N. <nob...@so...>]

なかだです。

At Thu, 10 Apr 2003 21:44:49 +0900 (JST),
Masahiro Sakai (酒井政裕) wrote:
> > > いっそのこと、シグナルハンドラからの大域脱出は
> > > rb_protect()で止めてしまおうかなぁ。
> > 
> > 例外が発生したらどこかに保存してGtk.main_quit、Gtk.mainの後始末
> > として再送出?
> 
> そう出来たらよいのですが、
> シグナルを内部で発生させる関数はgtk_main()以外にも大量にあるので、
> それら一個一個の呼び出しの後で、例外が保存されているか確認して、
> 再送出するのは実際には難しいです。

ひょっとして、ありとあらゆるGlibのメソッドでチェックが必要になっ
てしまう?  それに、gtk_main()以外から発生したシグナルでも
main_quitしてしまうのはまずいかも知れませんね。

> > そういえば、シグナルハンドラからbreakしたらどうなるんでしたっけ。
> 
> 特別な事は何もしていないので、
> 普通のProcからbreakするのと変わらないはずです。

ということは、こういうのは無限ループ?

button.signal_connect("clicked") {
  puts "Hello World\n"
  break
}

Gtk.main

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

Re: [ruby-gnome2-devel-ja] =?ISO-2022-JP?B?GyRCJUElZSE8JUgbKEI=?= =?ISO-2022-JP?B?GyRCJWolIiVrGyhC?=

[Nobuyoshi N. <nob...@so...>]

なかだです。

At Fri, 11 Apr 2003 01:32:49 +0900,
Masao Mutoh wrote:
> > Ruby/Gtk側で安全柵としてそうしておくのはどうでしょうか。
> 
> って、何を意図されているのでしょうか。

いや、exitする前にquit_mainする必要があるなら、自動でするように
しとけばいいじゃんと思っただけなんですが、そんな単純なことでは
ないようですね。

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

Re: [ruby-gnome2-devel-ja] Action signals

[Masao M. <mu...@hi...>]

むとうです。

On Fri, 11 Apr 2003 11:05:25 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 
> From: Masao Mutoh <mu...@hi...>
> Subject: Re: [ruby-gnome2-devel-ja] Action signals
> Date: Fri, 11 Apr 2003 03:20:50 +0900
> 
> > むとうです。
> 
> > これのメリットって何でしょうか。
> > 例えば、単純にsignal_emit("cancel")をする場合に比べ、
> > 
> > def cancel
> >   signal_emit("cancel")
> > end
> > 
> > が自動定義されるとうれしいことって何かありますか。
> > 
> > 単にメソッドが増えるだけだとあまりうれしくないなぁと。
> 
> "They can also be thought of as by third-party code generically
> callable object methods."と書いてあるので、メソッドと考えられるものは
> 実際にメソッドにしてしまったほうが分かりやすいと考えました。

なるほど...。

確かにわかりやすくなりますね。

ちと、普通のメソッド（やプロパティ）とメソッド名が重複しないか
心配ですが、とくに問題ないようでしたら、experimentalではなく
本採用ということでどうでしょうか。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] Action signals

[Masahiro S. () <sa...@to...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] Action signals
Date: Fri, 11 Apr 2003 03:20:50 +0900

> むとうです。

> これのメリットって何でしょうか。
> 例えば、単純にsignal_emit("cancel")をする場合に比べ、
> 
> def cancel
>   signal_emit("cancel")
> end
> 
> が自動定義されるとうれしいことって何かありますか。
> 
> 単にメソッドが増えるだけだとあまりうれしくないなぁと。

"They can also be thought of as by third-party code generically
callable object methods."と書いてあるので、メソッドと考えられるものは
実際にメソッドにしてしまったほうが分かりやすいと考えました。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Action signals

[Masao M. <mu...@hi...>]

むとうです。

On Fri, 11 Apr 2003 02:17:47 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 
> 例えば、Gtk::MenuShellが持っているアクションシグナルは
> move-current, activate-current, cancel, cycle-focus の4つなので、
> これらを呼び出す以下のようなメソッドがGtk::MenuShellに自動定義されます。

なるほど。

これのメリットって何でしょうか。
例えば、単純にsignal_emit("cancel")をする場合に比べ、

def cancel
  signal_emit("cancel")
end

が自動定義されるとうれしいことって何かありますか。

単にメソッドが増えるだけだとあまりうれしくないなぁと。

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] yendot

[Masao M. <mu...@hi...>]

むとうです。

On Fri, 11 Apr 2003 02:30:26 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 
> From: Masao Mutoh <mu...@hi...>
> Subject: Re: [ruby-gnome2-devel-ja] yendot
> Date: Wed, 9 Apr 2003 02:56:53 +0900
> 
> > むとうです。
> 
> > ところで、話は変わりますが、GScannerあたりって実装する予定ないです？
> > ＃ってかRuby/GTK側で呼んでるところがいくつかあるので欲しいんですよね。
> 
> いまの所は無いです。

はぅぅ。そんなつれないことをおっしゃらずにインプリしていただけない
でしょうか。
お暇なときで構いませんので....。

> > P.S.
> > そういや、さかいさんもはじめられましたね、Ruby/GLibのAPIリファレンス。
> 
> いまさらですが、Hiki/RD素晴らしいですね。

ありがとうございます。
 
> 文法エラー時にエラー箇所が分かりにくいのが
> RWikiと比べて若干不満ですが、それ以外は完全に満足してます。

これ、うささんにも指摘されてるんですよねぇ。落ち着いたら考えます。
＃今、本職の方が山場なもので...。

それでは。
-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] yendot

[Masahiro S. () <sa...@to...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] yendot
Date: Wed, 9 Apr 2003 02:56:53 +0900

> むとうです。

> ところで、話は変わりますが、GScannerあたりって実装する予定ないです？
> ＃ってかRuby/GTK側で呼んでるところがいくつかあるので欲しいんですよね。

いまの所は無いです。

> P.S.
> そういや、さかいさんもはじめられましたね、Ruby/GLibのAPIリファレンス。

いまさらですが、Hiki/RD素晴らしいですね。

文法エラー時にエラー箇所が分かりにくいのが
RWikiと比べて若干不満ですが、それ以外は完全に満足してます。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Action signals

[Masahiro S. () <sa...@to...>]

さかいです。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] Action signals
Date: Fri, 11 Apr 2003 01:41:37 +0900

> むとうです。

> ちと、疲れてて英語読む気になれません(-o-;)。
> 
> というわけで、サンプルコードプリーズ！

例えば、Gtk::MenuShellが持っているアクションシグナルは
move-current, activate-current, cancel, cycle-focus の4つなので、
これらを呼び出す以下のようなメソッドがGtk::MenuShellに自動定義されます。

def move_current(x)
  signal_emit("move-current",x)
end

def activate_current(x)
  signal_emit("activate-current", x)
end

def cancel
  signal_emit("cancel")
end

def cycle_focus(x)
  signal_emit("cycle-focus", x)
end

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] Action signals

[Masao M. <mu...@hi...>]

むとうです。

On Thu, 10 Apr 2003 16:17:10 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 
> http://developer.gnome.org/doc/API/2.0/gobject/gobject-Signals.html#GSignalFlags
> によると、
> 
> Action signals are signals that may freely be emitted on alive
> objects from user code via g_signal_emit() and friends, without
> the need of being embedded into extra code that performs pre or
> post emission adjustments on the object. They can also be thought
> of as by third-party code generically callable object methods.
> 
> だそうなので、自動的にメソッドとして定義するコードを試しに入れてみました。
> --enable-experimentalで有効になります。

ちと、疲れてて英語読む気になれません(-o-;)。

というわけで、サンプルコードプリーズ！

-- 
.:% Masao Mutoh<mu...@hi...>

Re: [ruby-gnome2-devel-ja] Re: [ruby-gnome2-devel-ja] =?ISO-2022-JP?B?GyRCJUElZSE8JUglaiUiJWsbKEI=?=

[Masao M. <mu...@hi...>]

むとうです。

On Thu, 10 Apr 2003 16:04:49 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> さかいです。
> 
> From: Nobuyoshi Nakada <nob...@so...>
> Subject: Re: [ruby-gnome2-devel-ja] チュートリアル
> Date: Thu, 10 Apr 2003 15:24:38 +0900
> 
> > なかだです。
> > 
> > At Wed, 2 Apr 2003 23:36:29 +0900,
> > Masao Mutoh wrote:
> > > ただ、想定外のエラーとかの場合にat_exit, ENDを使いたい
> > > ということであれば、Gtk.mainの前でat_exit, ENDを
> > > 使ってブロックを登録してあげるということは可能です。
> > > ＃スレッド使うときはこういうat_exit,ENDが必要になる場合も
> > > ＃あるかもしれませんね。
> > 
> > Ruby/Gtk側で安全柵としてそうしておくのはどうでしょうか。
> 
> そういえば、シグナルハンドラから大域脱出すると、
> glib/gtk内でもメモリリークが発生してしまう事に気が付きました。。

さっきの続きですが、そう言った作りのアプリって
お行儀が悪いプログラムなんじゃないのかなぁ。
そのような状態で、例え、glib/gtk内でメモリリークが発生しなくても
プログラム的に正常に動作するようなものが作れるとは思えません。
＃ユーザインタフェイス含め。
というか、それを意図したGUIプログラムって書いてはいけない気がします。
まぁ、ひょっとして私が全く想定できていないようなパターンで、それを必要
とするパターンがあるのかもしれませんが...。

> いっそのこと、シグナルハンドラからの大域脱出は
> rb_protect()で止めてしまおうかなぁ。

それはありかも。
でも、そのようなときは少なくともデバッグ時はバグとしてエラー出力
されれば良いのですが...。

-- 
.:% Masao Mutoh<mu...@hi...>