[#25976] tnono dumps core — nobu@...
なかだです。
16 messages
2005/04/02
[#25977] Re: tnono dumps core
— Masaki Suketa <masaki.suketa@...>
2005/04/03
助田です。
[#25978] Re: tnono dumps core
— nobu@...
2005/04/03
なかだです。
[#25979] Re: tnono dumps core
— Hidetoshi NAGAI <nagai@...>
2005/04/03
永井@知能.九工大です.
[#25980] Re: tnono dumps core
— nobu@...
2005/04/03
なかだです。
[#25982] Re: tnono dumps core
— Hidetoshi NAGAI <nagai@...>
2005/04/04
永井@知能.九工大です.
[#25981] tktable doesn't have selection_present — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
9 messages
2005/04/03
[#25986] Re: tktable doesn't have selection_present
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2005/04/04
山本です。
[#25988] Re: tktable doesn't have selection_present
— Hidetoshi NAGAI <nagai@...>
2005/04/04
永井@知能.九工大です.
[#25989] Re: tktable doesn't have selection_present
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2005/04/04
山本です。
[#25998] ruby 1.8.3 preview予定 — Yukihiro Matsumoto <matz@...>
まつもと ゆきひろです
45 messages
2005/04/07
[#25999] irb マージ[Re: ruby 1.8.3 preview予定]
— keiju@... (石塚圭樹)
2005/04/07
けいじゅ@いしつかです.
[#26011] bcc32、win32 での install-doc の動作
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2005/04/10
山本です。
[#26012] Re: bcc32、win32 での install-doc の動作
— nobu@...
2005/04/10
なかだです。
[#26013] Re: bcc32、win32 での install-doc の動作
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2005/04/11
山本です。
[#26014] Re: bcc32、win32 での install-doc の動作
— "U.Nakamura" <usa@...>
2005/04/11
こんにちは、なかむら(う)です。
[#26034] Re: bcc32、win32 での install-doc の動作
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2005/04/12
山本です。
[#26035] Re: bcc32、win32 での install-doc の動作
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2005/04/12
山本です。
[#26036] Re: bcc32、win32 での install-doc の動作
— "U.Nakamura" <usa@...>
2005/04/12
こんにちは、なかむら(う)です。
[#26040] Re: bcc32、win32 での install-doc の動作
— nobu@...
2005/04/13
なかだです。
[#26041] Re: bcc32、win32 での install-doc の動作
— "U.Nakamura" <usa@...>
2005/04/13
こんにちは、なかむら(う)です。
[#26042] Re: bcc32、win32 での install-doc の動作
— nobu@...
2005/04/13
なかだです。
[#26043] Re: bcc32、win32 での install-doc の動作
— "U.Nakamura" <usa@...>
2005/04/13
こんにちは、なかむら(う)です。
[#26045] Re: bcc32、win32 での install-doc の動作
— nobu@...
2005/04/13
なかだです。
[#26049] Re: bcc32、win32 での install-doc の動作
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2005/04/14
山本です。
[#26051] Re: bcc32、win32 での install-doc の動作
— nobu@...
2005/04/14
なかだです。
[#26059] Re: bcc32、win32 での install-doc の動作
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2005/04/14
山本です。
[#26060] Re: bcc32、win32 での install-doc の動作
— nobu@...
2005/04/15
なかだです。
[#26067] Re: bcc32、win32 での install-doc の動作
— "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
2005/04/15
山本です。
[#26047] "Florian Frank": Small 1.9 fixes — keiju@... (Keiju ISHITSUKA)
けいじゅ@いしつかです.
10 messages
2005/04/13
[#26048] Re: "Florian Frank": Small 1.9 fixes
— Yukihiro Matsumoto <matz@...>
2005/04/13
[#26050] Re: "Florian Frank": Small 1.9 fixes
— keiju@... (石塚圭樹)
2005/04/14
けいじゅ@いしつかです.
[#26079] absolute path in $LOADED_FEATURES — nobu@...
なかだです。
6 messages
2005/04/18
[#26096] Re: Win32: Ruby & APR; build problems for Ruby Subversion SWIGbindings — "H.Yamamoto" <ocean@...2.ccsnet.ne.jp>
山本です。
4 messages
2005/04/23
[#26100] FileUtils.rm_rf security problem — Tanaka Akira <akr@...17n.org>
ふと、CVE で perl 関係のを見ていたら、File::Path の rmtree に関するも
21 messages
2005/04/26
[#26101] Re: FileUtils.rm_rf security problem
— Yukihiro Matsumoto <matz@...>
2005/04/26
まつもと ゆきひろです
[#26102] Re: FileUtils.rm_rf security problem
— Tanaka Akira <akr@...17n.org>
2005/04/26
[#26103] Re: FileUtils.rm_rf security problem
— Yukihiro Matsumoto <matz@...>
2005/04/26
まつもと ゆきひろです
[#26190] Re: FileUtils.rm_rf security problem
— Minero Aoki <aamine@...>
2005/05/20
青木です。
[#26191] Re: FileUtils.rm_rf security problem
— Tanaka Akira <akr@...17n.org>
2005/05/20
In article <20050520171837N.aamine@loveruby.net>,
[#26192] Re: FileUtils.rm_rf security problem
— Minero Aoki <aamine@...>
2005/05/20
青木です。
[#26197] Re: FileUtils.rm_rf security problem
— Minero Aoki <aamine@...>
2005/05/21
青木です。
[#26234] Re: FileUtils.rm_rf security problem
— Tanaka Akira <akr@...17n.org>
2005/05/26
In article <20050526081855Q.aamine@loveruby.net>,
[#26237] Re: FileUtils.rm_rf security problem
— Minero Aoki <aamine@...>
2005/05/26
青木です。
[#26238] Re: FileUtils.rm_rf security problem
— Tanaka Akira <akr@...17n.org>
2005/05/26
In article <20050526203322Z.aamine@loveruby.net>,
[#26105] close(2) without flushing buffer for redirection in child process — Tomoaki NISHIYAMA <tomoakin@...>
ruby-devの皆様
3 messages
2005/04/27
[#26113] race condition in fixnum..fixnum ? — Tanaka Akira <akr@...17n.org>
例によってとあるソフトウェアで core を吐いたので調べたところ、
5 messages
2005/04/30
[ruby-dev:25987] Re: some trouble on ext/tk/sample
From:
Hidetoshi NAGAI <nagai@...>
Date:
2005-04-04 09:22:27 UTC
List:
ruby-dev #25987
永井@知能.九工大です.
From: H.Yamamoto <ocean@m2.ccsnet.ne.jp>
Subject: [ruby-dev:25985] Re: some trouble on ext/tk/sample
Date: Mon, 4 Apr 2005 11:06:53 +0900
Message-ID: <20050404110633.C4F08578.ocean@m2.ccsnet.ne.jp>
> >仕方ないので,一度 backgroundimage オプションを参照して,
> >エラーが出たらこれを使わないように変更しました.
>
> configure を引数なしで呼ぶと、利用可能なオプションを返すという説明があったので
> これが使えるかもしれません。
この情報であれば,configinfo メソッドで得られます.
その場合,backgroundimage オプションを持つかどうかは
得られた配列で assoc メソッドを使って得る必要があります.
また,current_configinfo メソッドを使えば,{key=>value, ... } の
Hash で現在のオプション設定を得ることができます.
こちらであれば key? メソッドで調べることができます.
というわけで,configinfo または current_configinfo を
使っても良かったのですが,Tcl/Tk が返してくる文字列情報を
Ruby/Tk 内部で変換して,さらにその Array または Hash で
検索をかけねばならないのであれば,直接に問題のオプションを参照して
エラーを捕まえた方が手っ取り早いかなと考えた次第です.
> ////////////////////////////////////////////////////////////////////////////////
>
> ところで、Random のデモがあまりにも重いので
> http://sourceforge.net/projects/tktreectrl で落とした tcl/tk 版を試したところ、
> 何と数十倍の速度差がありました。
エンコーディング変換処理を頻繁に呼んでしまってますので
そうなっちゃいますね.(^_^;
現在の tktreectrl.rb では全般に tk_call や tk_send を呼んでおり,
スピード面でのチューニングは施していません.
tk_call または tk_send は Tk サイドを手っ取り早く呼べるんですが,
明らかに変換の必要がないケースでも変換処理を行ってしまいます.
その点がかなりの無駄になっています.
ですので,tk_call_without_enc や tk_send_without_enc と,
_get_eval_string(val, true) とを組み合わせて,
変換処理を行う引数を絞ってやるだけで,
かなりのスピードアップになるはずです.
例えば
----------------------------------------
def item_collapse(item)
tk_send('item', 'collapse', item)
self
end
----------------------------------------
を
----------------------------------------
def item_collapse(item)
tk_send_without_enc('item', 'collapse', _get_eval_string(item, true))
self
end
----------------------------------------
とするだけでもスピードアップになりますし,
item に non-ascii が来ないことが明らかであれば,
----------------------------------------
def item_collapse(item)
tk_send_without_enc('item', 'collapse', _get_eval_string(item, false))
self
end
----------------------------------------
として,エンコード変換をしないように指定しまうこともできます.
ただし,将来のバージョンで non-ascii が指定されるケースが生じた場合に
手を入れなければ対応できなくなるのが難点です.
# もちろん,_get_eval_string には任せないという方法もあります.
試してはいませんが,今回のケースではループ内で使われているメソッドを
上記2番目のようにするだけでも倍近くの速度アップができるかもしれません.
> ボトルネックを調べるために、前田さんのプロファイラ(http://svn.shugo.net/src/ruby-prof/trunk/)
> を走らせてみたので結果を添付します。何となく invoke 系と encode 系がボトルネックのように
> 見えたので、TclTkIp#_fromUTF8 と TclTkIp#_toUTF8 で全部 ASCII 文字だったらそのまま文字を返すような
> ハックをしたところ、1秒ほど速くなりました。
# tcltklib.c でそれらのメソッドに関係する Tcl 関数を呼び出す前に
# チェックするということですよね?
この方法では文字列スキャンのコストがかかってしまいますが,
判断誤りの心配がなくそれだけ早くなるなら有効な対策かもしれませんね.
--
永井 秀利 (九工大 知能情報)
nagai@ai.kyutech.ac.jp