[#25976] tnono dumps core — nobu@...

なかだです。

16 messages 2005/04/02
[#25977] Re: tnono dumps core — Masaki Suketa <masaki.suketa@...> 2005/04/03

助田です。

[#25998] ruby 1.8.3 preview予定 — Yukihiro Matsumoto <matz@...>

まつもと ゆきひろです

45 messages 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

なかだです。

[#26100] FileUtils.rm_rf security problem — Tanaka Akira <akr@...17n.org>

ふと、CVE で perl 関係のを見ていたら、File::Path の rmtree に関するも

21 messages 2005/04/26
[#26102] Re: FileUtils.rm_rf security problem — Tanaka Akira <akr@...17n.org> 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

青木です。

[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

In This Thread