Menu
▾
▴
ruby-gnome2-devel-ja
|
From: Nobuyoshi N. <nob...@so...> - 2002-05-28 14:16:26
|
なかだです。
At Tue, 28 May 2002 21:50:00 +0900,
Masao Mutoh wrote:
> > 上記の設定は[ruby-list:19886]からのスレッドでつけること
> > にしたようで、私の~/.emacsにはこんな定義が入っています。
> >
> > (c-add-style
> > "ruby"
> > '("bsd"
> > (c-basic-offset . 4)
> > (c-offsets-alist
> > (case-label . 2)
> > (label . 2)
> > (statement-case-intro . 2))))
>
> じゃ、コミッターの方はこれを入れてemacsで整形してから
> コミットっつーことにしましょうか。
(statement-case-open . 2)
も入れといたほうがいいような。
あるいは~/.indent.proに。
-kr
--no-blank-lines-after-declarations
--blank-lines-after-procedures
--no-space-after-function-call-names
--brace-indent0
--braces-on-if-line
--dont-cuddle-else
--case-indentation2
--case-brace-indentation2
--declaration-indentation0
--else-endif-column0
--continue-at-parentheses
--parameter-indentation4
--procnames-start-lines
--
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
中田 伸悦
|
|
From: Masao M. <mu...@hi...> - 2002-05-28 16:28:33
|
むとうです。 On Tue, 28 May 2002 23:16:16 +0900 Nobuyoshi Nakada <nob...@so...> wrote: > なかだです。 > > (statement-case-open . 2) > > も入れといたほうがいいような。 > > あるいは~/.indent.proに。 > > -kr > --no-blank-lines-after-declarations > --blank-lines-after-procedures > --no-space-after-function-call-names > --brace-indent0 > --braces-on-if-line > --dont-cuddle-else > --case-indentation2 > --case-brace-indentation2 > --declaration-indentation0 > --else-endif-column0 > --continue-at-parentheses > --parameter-indentation4 > --procnames-start-lines > んじゃそうしましょう。他に何かありますか？ -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masao M. <mu...@hi...> - 2002-05-31 17:27:29
|
むとうです。 On Tue, 28 May 2002 01:45:16 +0900 Hiroshi IGARASHI <ig...@ru...> wrote: > いがらしです。 > > ・コードの自動生成 > > これも以前、五十嵐さんの方で話が合ったような記憶があります。 > > どのようなモノなのでしょうか？ ＞ 五十嵐さん > > これできちゃうようであればあっという間ですよね(^-^)。 > (1) *.defsファイルからのwrapper生成 > > GTK+のソースにはオブジェクト・関数・列挙型などが宣言された > ファイルがついてきて、これからCコードを生成する方法です。 > pygtk(Python/GTK),pygnome(Python/GNOME)などはこれ。 > [ruby-ext:01637]あたりで触れてます。 > > モノは以下の場所にありますが、まだ不完全な代物です。 > 私も詳細は覚えていないのでこれから見てみます^_^; > http://www.ruby-lang.org/~iga/files/gnome-ruby-proto-20010313.tar.gz > gnome-ruby-proto-20010317.tar.gz > gnome-ruby-proto-20010916.tar.gz ひとまず、gnome-ruby-proto-20010916.tar.gzだけ試してみました。 ＃生成されたコードを見ただけですが。 他のも見た方が良いのでしょうか？ で、ちょっと質問です。 ・この*.defsファイルってどこにあるんでしょうか？ GTK+-2.0のソースにはついてきていないような気がします....。 ・GdkRGB等が無いのですがこれはなぜでしょうか？ *.defsにない？ -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masahiro S. <s01...@sf...> - 2002-08-10 11:18:18
|
devel-enの方でも話題になってましがたが、 やっぱ、自動生成ってなんとか利用出来ないかなぁ。 gtkのクラスで未実装なのは多分、高々20か30クラス程度なんですが、 この調子で書いていく事を考えたら、正直ウンザリしてきました。 -- さかい |
|
From: Masao M. <mu...@hi...> - 2002-09-19 16:11:34
|
むとうです。 On Fri, 20 Sep 2002 00:03:40 +0900 Masahiro Sakai <s01...@sf...> wrote: > From: Masahiro Sakai <s01...@sf...> > Subject: Re: [ruby-gnome2-devel-ja] wrapper generation > Date: Sat, 10 Aug 2002 20:18:07 +0900 > > > devel-enの方でも話題になってましがたが、 > > やっぱ、自動生成ってなんとか利用出来ないかなぁ。 > > 今.defsファイルからの自動生成スクリプトを書いて実験しています。 > atkではそれなりにはうまく行っている感じ。 へぇ。おもしろそうですね。期待してます。 > # そういえば、Gauche-gtkは.defsファイルを使わずに、 > # ヘッダファイルから直接生成してるんですね。 .defsを使わずにできるならその方が確実でしょうねぇ。 -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masahiro S. <s01...@sf...> - 2002-10-09 15:37:51
|
さかいです。 From: Masao Mutoh <mu...@hi...> Subject: Re: [ruby-gnome2-devel-ja] wrapper generation Date: Fri, 20 Sep 2002 01:11:28 +0900 > むとうです。 > > 今.defsファイルからの自動生成スクリプトを書いて実験しています。 > > atkではそれなりにはうまく行っている感じ。 > > へぇ。おもしろそうですね。期待してます。 細々といじってはいたのですが、実用的になる前に飽きてしまったので、 http://web.sfc.keio.ac.jp/~s01397ms/tmp/ruby-gnome2-autogen.tar.gz に残骸を置いておきます。 やっつけ仕事なのでソースは非常に汚いです (^^;) が、 生成されたコードから部品を取るくらいには使える……かも(?) # ちなみに、現在のrbgtktextview.cは生成されたコードが元になっています。 -- 酒井 政裕 / Masahiro Sakai |
|
From: Masao M. <mu...@hi...> - 2002-10-12 18:36:02
|
むとうです。 On Thu, 10 Oct 2002 02:11:45 +0900 Masao Mutoh <mu...@hi...> wrote: > > 細々といじってはいたのですが、実用的になる前に飽きてしまったので、 > > http://web.sfc.keio.ac.jp/~s01397ms/tmp/ruby-gnome2-autogen.tar.gz > > に残骸を置いておきます。 > > > > やっつけ仕事なのでソースは非常に汚いです (^^;) が、 > > 生成されたコードから部品を取るくらいには使える……かも(?) > > # ちなみに、現在のrbgtktextview.cは生成されたコードが元になっています。 > > ありがとうございます。 > ちょっと見てみます。でも連休かな(^^;)。 見てみました。 ここまで作ったのは純粋にすごいと思います。後少しのような気も するのですが...。 ただ、今のコーディングルールに合わないところが多いので部品取りには 使いづらいかも。 ところで、ちょっと気になったのですが、たとえば、 G_TYPE_CHECK_INSTANCE_CAST(RVAL2GOBJ(self), GTK_TYPE_TEXT_VIEW, GtkTextView); が、 GTK_TEXT_VIEW(RVAL2GOBJ(self))じゃないのって何か特別な 理由があるのでしょうか？ P.S. ソースいじろうと思ったけどあきらめました。他のことを優先させたいので。 それでは。 -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masahiro S. <s01...@sf...> - 2002-10-13 11:25:42
|
さかいです。 From: Masao Mutoh <mu...@hi...> Subject: Re: [ruby-gnome2-devel-ja] wrapper generation Date: Sun, 13 Oct 2002 03:35:57 +0900 > ただ、今のコーディングルールに合わないところが多いので部品取りには > 使いづらいかも。 この辺りは、結構手を抜いています。 整形に関してはindent任せですし。 > ところで、ちょっと気になったのですが、たとえば、 > > G_TYPE_CHECK_INSTANCE_CAST(RVAL2GOBJ(self), GTK_TYPE_TEXT_VIEW, > GtkTextView); > > が、 GTK_TEXT_VIEW(RVAL2GOBJ(self))じゃないのって何か特別な > 理由があるのでしょうか？ GTK_TEXT_VIEW等のマクロ名は.defsファイルに含まれていないからです。 > P.S. > ソースいじろうと思ったけどあきらめました。他のことを優先させたいので。 それはとても賢明だと思います。(^^;) -- 酒井 政裕 / Masahiro Sakai |
|
From: Masao M. <mu...@hi...> - 2002-10-09 17:11:48
|
むとうです。 On Thu, 10 Oct 2002 00:37:45 +0900 Masahiro Sakai <s01...@sf...> wrote: > さかいです。 > > > 今.defsファイルからの自動生成スクリプトを書いて実験しています。 > > > atkではそれなりにはうまく行っている感じ。 > > > > へぇ。おもしろそうですね。期待してます。 > > 細々といじってはいたのですが、実用的になる前に飽きてしまったので、 > http://web.sfc.keio.ac.jp/~s01397ms/tmp/ruby-gnome2-autogen.tar.gz > に残骸を置いておきます。 > > やっつけ仕事なのでソースは非常に汚いです (^^;) が、 > 生成されたコードから部品を取るくらいには使える……かも(?) > # ちなみに、現在のrbgtktextview.cは生成されたコードが元になっています。 ありがとうございます。 ちょっと見てみます。でも連休かな(^^;)。 -- .:% Masao Mutoh<mu...@hi...> |
|
From: Masahiro S. <s01...@sf...> - 2002-09-19 15:21:31
|
From: Masahiro Sakai <s01...@sf...> Subject: Re: [ruby-gnome2-devel-ja] wrapper generation Date: Sat, 10 Aug 2002 20:18:07 +0900 > devel-enの方でも話題になってましがたが、 > やっぱ、自動生成ってなんとか利用出来ないかなぁ。 今.defsファイルからの自動生成スクリプトを書いて実験しています。 atkではそれなりにはうまく行っている感じ。 # そういえば、Gauche-gtkは.defsファイルを使わずに、 # ヘッダファイルから直接生成してるんですね。 -- さかい |
|
From: Masao M. <mu...@hi...> - 2002-06-01 03:19:54
|
むとうです。
On Sat, 01 Jun 2002 03:50:12 +0900
Hiroshi IGARASHI <ig...@ru...> wrote:
> いがらしです。
>
> > > (1) *.defsファイルからのwrapper生成
(略)
> > ・この*.defsファイルってどこにあるんでしょうか？
> > GTK+-2.0のソースにはついてきていないような気がします....。
>
> またまたすみません。
> 2.0になってからはついてきてないみたいですね。
>
> gnome-python独自にメンテするようになってしまったみたいです。
> CVSモジュールgnome-python(GTK+2.0と同じレポジトリにあります)の
> gnome-python/pygtk/gtk/*.defsなどを見て下さい。
>
> 上記gnome-rubyのプロトタイプの*.defsは、
> gnome-pythonからぱくらせてもらったもので、
> そのフォーマットについては、このモジュール内の
> gnome-python/pygtk/codegen/README.defs
> を見て下さい。プロトタイプを作った当時よりいろいろ
> 変更されてしまっているようです。
defsファイル自体は自動生成されるものではないのですね。
> にあるような関数群のことですよね。
> 当時の*.defsには入っていませんでした。
> 現在の gnome-python/pygtk/gtk/gdk.defs には含まれています。
> 例えばGdk::Drawable#draw_rgb_32_imageなら以下の通りです。
>
> (define-method draw_rgb_32_image
> (of-object "GdkDrawable")
> (c-name "gdk_draw_rgb_32_image")
> (return-type "none")
> (parameters
> '("GdkGC*" "gc")
> '("gint" "x")
> '("gint" "y")
> '("gint" "width")
> '("gint" "height")
> '("GdkRgbDither" "dith")
> '("guchar*" "buf")
> '("gint" "rowstride")
> )
> )
っていうか、これを書かなきゃいけないってコトですよね...。
まぁ、今は、すでにgnome-pythonのがあるということでそれを流用しようと
いうことだとは思いますが、将来的には。
＃gnome-pythonが未サポートなクラス・メソッドが無い場合は
＃独自実装するか、自分で上記フォーマットのファイルを作ってpatchを
＃gnome-pythonに送るかしないといけないってコトですよね。
これの仕様を覚えて、これを関数毎に書き、いがらしさんのツールを
メンテナンスしつつ、さらにRubyによるWrapperを書くというプロセス
を考えるのなら、従来通りC言語でプログラム書いた方が速いと思うのは
私だけでしょうか。
なんか、正直、自動生成に切り替えるメリットがわからなく
なってきました。
あ、いや、ヒューマンエラーを無くすことができるというのは
自動生成時には常に言われることなのでそれを置いておいたとして。
すでにある*.defsをgnome-pythonからもらってきて、
それからいがらしさんのツールでCのソースを生成して、
それをベースにRuby-GNOMEに無いメソッドやクラス・ライブラリ(bonoboなど)
を開発するということであれば十分使えると思うのですが。
それから、さらに生成されたソースを追ってはいるので追加質問です。
gtk_item_factory_create_items()のようにオブジェクトの配列を
渡すようなのはどうなっているのでしょうか？
defsで定義された引数が配列かどうかをどのように判別しているのか
ということと、配列の場合は引数のVALUEが配列であるとしそれを適切な
Cの型に変換する部分について知りたいです。
--
.:% Masao Mutoh<mu...@hi...>
|
|
From: Masao M. <mu...@hi...> - 2002-06-02 01:45:04
|
むとうです。 さらに追加で質問です。 構造体のメンバへのアクセス方法って提供されない のでしょうか。gtkcustom.cで対応するのかな？ ＃*.defsには無いようでしたので。 -- .:% Masao Mutoh<mu...@hi...> |
|
From: Hiroshi I. <ig...@ru...> - 2002-06-02 18:17:00
|
いがらしです。 なんか、言い訳がましい弁明が続きますが、 # 実際言い訳に過ぎないのですが... あくまでメンテナ当時の考えを説明している訳で もう自動生成にこだわっているわけではないので。 At Sat, 1 Jun 2002 12:19:49 +0900, Masao Mutoh <mu...@hi...> wrote: > > defsファイル自体は自動生成されるものではないのですね。 はい。1.2時代はヘッダファイル等から生成していましたが、 いつからか生成しないことになったようです。 きちんと経緯を調べたわけではありませんが、 おそらく各言語バインディングのAPIをヘッダファイル等から 導き出すには自明でない情報が必要で、結局手でメンテせざるを 得ないということになったのでは、と思います。 「自明でない情報」として以下のようなものがあります。 * あるメソッド(関数)・定数が属すべきクラス・モジュール * あるクラス・モジュールに属するとして、その名前 * メソッドの省略可能引数およびそのデフォルト値 * 公開するオブジェクト(構造体)のメンバ このあたりを記述できるように、defsファイルの フォーマットが拡張されてきているようです。 > > 現在の gnome-python/pygtk/gtk/gdk.defs には含まれています。 > > 例えばGdk::Drawable#draw_rgb_32_imageなら以下の通りです。 (snip) > っていうか、これを書かなきゃいけないってコトですよね...。 > まぁ、今は、すでにgnome-pythonのがあるということでそれを流用しようと > いうことだとは思いますが、将来的には。 > ＃gnome-pythonが未サポートなクラス・メソッドが無い場合は > ＃独自実装するか、自分で上記フォーマットのファイルを作ってpatchを > ＃gnome-pythonに送るかしないといけないってコトですよね。 まあ、そういうことになりますが、今の勢いなら 主要なAPIはカバーしていくと思いますよ。 > これの仕様を覚えて、これを関数毎に書き、いがらしさんのツールを > メンテナンスしつつ、さらにRubyによるWrapperを書くというプロセス > を考えるのなら、従来通りC言語でプログラム書いた方が速いと思うのは > 私だけでしょうか。 私もコードを書く人がいてコントロールできれば 従来通りが速いと思います。 > > なんか、正直、自動生成に切り替えるメリットがわからなく > なってきました。 > あ、いや、ヒューマンエラーを無くすことができるというのは > 自動生成時には常に言われることなのでそれを置いておいたとして。 これは、当時の私にとっては大きかったのです。 未実装部分を補うたくさんのパッチを送っていただきましたが、 * 品質・コーディングスタイルにむらがある。 * on-demandに自分が欲しいメソッド・定数だけ実装している。 等があって、マージする負荷が高かったので自動生成に向かっていました。 まあきちんとメンテナとしてコントロールできなかったのが そもそもの原因でしたので、それが解決できれば従来通りで 問題ないと思います。 > すでにある*.defsをgnome-pythonからもらってきて、 > それからいがらしさんのツールでCのソースを生成して、 > それをベースにRuby-GNOMEに無いメソッドやクラス・ライブラリ(bonoboなど) > を開発するということであれば十分使えると思うのですが。 はい、現在はそれで充分だと思っています。 あるいは、未実装ライブラリについても * 自動生成したAPIに後からRubyらしいAPIを手でかぶせるコスト (あるいはRubyらしいAPIを吐かせるためにツールをメンテするコスト) * 最初からC(+Ruby)でRubyらしいAPIを定義・実装するコスト の後者が小さければ、ツールを使うことはないでしょう。 Pythonより拡張ライブラリが書きやすい(一部逆の部分もありますが) こともあって、そういう場合の方が多いのかも知れません。 > それから、さらに生成されたソースを追ってはいるので追加質問です。 > > gtk_item_factory_create_items()のようにオブジェクトの配列を > 渡すようなのはどうなっているのでしょうか？ > defsで定義された引数が配列かどうかをどのように判別しているのか > ということと、配列の場合は引数のVALUEが配列であるとしそれを適切な > Cの型に変換する部分について知りたいです。 配列についてはサポートしていません。 At Sun, 2 Jun 2002 10:44:59 +0900, Masao Mutoh <mu...@hi...> wrote: > > 構造体のメンバへのアクセス方法って提供されない > のでしょうか。gtkcustom.cで対応するのかな？ > ＃*.defsには無いようでしたので。 これも提供していません。 構造体メンバも直接アクセスしていいものとまずいものがあるので、 gnome-pythonの新しいdefsファイルでは明示的に必要なメンバ名を 記述するようになっています。やるとしたら、これに対応した メソッドを生成するのでしょうけど... こうして考えてみると、わざわざ検討して頂くほどのものでは なかったかも。余計なお時間を取らせてしまいすみませんでした。 自動生成に関しての作業は少なくとも当面は中止して、 他の作業に注力しようと思います。 -- 五十嵐 宏 (Hiroshi IGARASHI) |
|
From: Masao M. <mu...@hi...> - 2002-06-03 12:56:24
|
むとうです。 On Mon, 03 Jun 2002 03:16:50 +0900 Hiroshi IGARASHI <ig...@ru...> wrote: > いがらしです。 > > なんか、言い訳がましい弁明が続きますが、 > # 実際言い訳に過ぎないのですが... > あくまでメンテナ当時の考えを説明している訳で > もう自動生成にこだわっているわけではないので。 いや、むしろ私の方がこだわっているかもしれません。 これができると大変楽なので。 > At Sat, 1 Jun 2002 12:19:49 +0900, > Masao Mutoh <mu...@hi...> wrote: > > > > defsファイル自体は自動生成されるものではないのですね。 （ざっくり略） > 自動生成に関しての作業は少なくとも当面は中止して、 > 他の作業に注力しようと思います。 了解です。 まずは自動化を念頭にベースの部分を整えましょうか。 -- .:% Masao Mutoh<mu...@hi...> |
Thanks for helping keep SourceForge clean.
X