[#26664] refactoring tcltklib.c (deleted ip check) — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>

山本です。

22 messages 2005/08/01
[#26665] Re: refactoring tcltklib.c (deleted ip check) — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/08/01

山本です。

[#26668] Re: refactoring tcltklib.c (deleted ip check) — Hidetoshi NAGAI <nagai@...> 2005/08/01

永井@知能.九工大です.

[#26678] Re: refactoring tcltklib.c (deleted ip check) — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/08/01

山本です。

[#26684] Re: refactoring tcltklib.c (deleted ip check) — Hidetoshi NAGAI <nagai@...> 2005/08/01

永井@知能.九工大です.

[#26686] Re: refactoring tcltklib.c (deleted ip check) — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/08/01

山本です。

[#26817] test/socket/test_tcp.rb freeze on windows — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>

山本です。

12 messages 2005/08/18

[#26829] cannot check EOF of pipe on windows — "U.Nakamura" <usa@...>

こんにちは、なかむら(う)です。

19 messages 2005/08/19
[#26830] Re: cannot check EOF of pipe on windows — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/08/19

山本です。

[#26831] Re: cannot check EOF of pipe on windows — "U.Nakamura" <usa@...> 2005/08/19

こんにちは、なかむら(う)です。

[#26832] Re: cannot check EOF of pipe on windows — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/08/19

山本です。

[#26836] Re: cannot check EOF of pipe on windows — nobuyoshi nakada <nobuyoshi.nakada@...> 2005/08/19

なかだです。

[#26872] irb -I/ruby -Iと$LOAD_PATH — akira yamada / やまだあきら <akira@...>

Debianユーザからruby -Iとirb -Iで

17 messages 2005/08/24
[#26873] Re: irb -I/ruby -Iと$LOAD_PATH — nobuyoshi nakada <nobuyoshi.nakada@...> 2005/08/24

なかだです。

[#26875] Re: irb -I/ruby -Iと$LOAD_PATH — akira yamada / やまだあきら <akira@...> 2005/08/24

nobuyoshi nakada wrote:

[#26885] Re: irb -I/ruby -Iと$LOAD_PATH — keiju@... (石塚圭樹) 2005/08/26

けいじゅ@いしつかです.

[#26897] fail on make install — KIMURA Koichi <kimura.koichi@...>

木村です。

28 messages 2005/08/29
[#26898] Re: fail on make install — "U.Nakamura" <usa@...> 2005/08/29

こんにちは、なかむら(う)です。

[#26903] Re: fail on make install — KIMURA Koichi <kbk@...> 2005/08/29

木村です。

[#26922] Re: fail on make install — KIMURA Koichi <kimura.koichi@...> 2005/08/30

木村です。

[#26926] Re: fail on make install — KIMURA Koichi <kimura.koichi@...> 2005/08/31

木村です。

[#26927] Re: fail on make install — "U.Nakamura" <usa@...> 2005/08/31

こんにちは、なかむら(う)です。

[#26928] Re: fail on make install — KIMURA Koichi <kimura.koichi@...> 2005/08/31

木村です。

[#26929] Re: fail on make install — "U.Nakamura" <usa@...> 2005/08/31

こんにちは、なかむら(う)です。

[#26930] Re: fail on make install — nobuyoshi nakada <nobuyoshi.nakada@...> 2005/08/31

なかだです。

[#26931] Re: fail on make install — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/08/31

山本です。

[#26933] Re: fail on make install — nobu@... 2005/08/31

なかだです。

[#26938] Re: fail on make install — nobuyoshi nakada <nobuyoshi.nakada@...> 2005/09/01

なかだです。

[#26939] Re: fail on make install — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp> 2005/09/01

山本です。

[#26900] multiplying empty string — nobuyoshi nakada <nobuyoshi.nakada@...>

19 messages 2005/08/29
[#26904] Re: multiplying empty string — Yukihiro Matsumoto <matz@...> 2005/08/29

まつもと ゆきひろです

[#26907] Re: multiplying empty string — Tanaka Akira <akr@...17n.org> 2005/08/29

In article <1125327516.070646.12845.nullmailer@x31.priv.netlab.jp>,

[#26909] Re: multiplying empty string — Yukihiro Matsumoto <matz@...> 2005/08/29

まつもと ゆきひろです

[ruby-dev:26755] Re: TkCheckbutton#variable as getter?

From: Hidetoshi NAGAI <nagai@...>
Date: 2005-08-06 13:36:47 UTC
List: ruby-dev #26755
永井@知能.九工大です.

From: H.Yamamoto <ocean@m2.ccsnet.ne.jp>
Subject: [ruby-dev:26752] Re: TkCheckbutton#variable as getter?
Date: Sat, 6 Aug 2005 13:02:21 +0900
Message-ID: <20050806130210.AE382EA0.ocean@m2.ccsnet.ne.jp>
> 動作を確認したのでコミットしておきました。(TkLabel#textvariable も該当する
> のでそのようにして)

ありがとうございます.お手数をかけました.
手元では Tcl/Tk 拡張についてもチェックしましたので,
後で適用しておきます.

> 始め、コピペが嫌いなのと、'variable' という名前が TkVariable の ID となる文字列
> の意味で使われているかどうか、保証できないのではないかと思ってためらいがあった
> のですが、すでに Font などで tk.rb にフレームワークが存在する上、動くとあまり
> 気にならなくなったので(汗)コミットしておきました。

まぁ,'variable' という名前からすると大丈夫そうに思いますし,
もし違っているクラスがあればそのクラスで __*_optkeys を
置き換えればいいだけですので目をつぶりませんか?

configinfo 等のメソッドは,当初選択した方法をベースに adhoc に拡張を
重ねてきたためにああなってしまいました.(^_^;
これだけ対応が個別化してくるのであれば別の方法を選んだのでしょうけど,
この辺りの先見の明のなさがアマチュアですね.(;_;)

# 互換性上,公式適用済みの分は維持しないといけないので.

属性値を返す際に特別な処理が必要となるケースがあっても
これ以上 configinfo などには特別な対応をせずに済むように,
__methodcall_optkeys のような方法で対応できるように
しようかと思ってます.
これは,あと一つ特殊処理を加えることと同じであることは
頭の痛いところですが.
-- 
                                       永井 秀利 (九工大 知能情報)
                                           nagai@ai.kyutech.ac.jp

In This Thread