[#37959] [Bug:trunk] I can modify literals — Yusuke ENDOH <mame@...>

遠藤です。

13 messages 2009/02/10

[#38005] Is URI.decode() broken? — MOROHASHI Kyosuke <moronatural@...>

もろはしです。いつもお世話になっております。

39 messages 2009/02/14
[#38006] Re: Is URI.decode() broken? — Nobuyoshi Nakada <nobu@...> 2009/02/14

なかだです。

[#38009] Re: Is URI.decode() broken? — "NARUSE, Yui" <naruse@...> 2009/02/14

成瀬です、

[#38016] Re: Is URI.decode() broken? — Fujioka <fuj@...> 2009/02/15

xibbarこと藤岡です。

[#38017] Re: Is URI.decode() broken? — "NARUSE, Yui" <naruse@...> 2009/02/15

成瀬です。

[#38040] Re: Is URI.decode() broken? — akira yamada / やまだあきら <akira@...> 2009/02/17

NARUSE, Yui さんは書きました:

[#38124] Re: Is URI.decode() broken? — "NARUSE, Yui" <naruse@...> 2009/03/03

成瀬です。

[#39214] Re: Is URI.decode() broken? — akira yamada / やまだあきら <akira@...> 2009/09/02

(2009年03月03日 22:45), NARUSE, Yui さんは書きました:

[#39218] Re: Is URI.decode() broken? — "NARUSE, Yui" <naruse@...> 2009/09/02

成瀬です。

[#39236] Re: Is URI.decode() broken? — Tanaka Akira <akr@...> 2009/09/05

In article <4A9E44DD.6050706@airemix.jp>,

[#39242] Re: Is URI.decode() broken? — KOSAKI Motohiro <kosaki.motohiro@...> 2009/09/07

小崎@思いつきを適当に書いてみるテスト

[#39246] Re: Is URI.decode() broken? — Tanaka Akira <akr@...> 2009/09/07

In article <20090907091830.2C7A.A69D9226@jp.fujitsu.com>,

[#38096] 多重代入やメソッド引数の展開でto_aが呼ばれます — nagachika <nagachika00@...>

nagachika と申します。

10 messages 2009/02/26

[#38098] ブロック引数と括弧・引数なしsuper — Shugo Maeda <shugo@...>

前田です。

12 messages 2009/02/27

[ruby-dev:38036] Re: Stack Caching を有効にした時のビルドについて

From: SASADA Koichi <ko1@...>
Date: 2009-02-16 18:03:55 UTC
List: ruby-dev #38036
 ささだです.

nagachika wrote::
> ついでに訊いてしまいますが STACK_CACHING のオプションの扱いというのは
> 今後どうなっていくのでしょうか。今後有効にする可能性はあるでしょうか。
> もう廃れていくオプションなののだとしたらあんまり深追いしてもなぁと
> 思いまして。

 今実装しているのは two level five state stack caching ですが,one
level でいいんじゃない,とか,two level にしても three state でいいん
じゃない,とか,色々ありそうなんで,まだ実験しないといけない話かと思いま
す.とりあえず,もうちょっと柔軟にしてみたいなぁ,と思います.

> Stack Caching 用に生成された命令語のスタック消費量がレジスタによる
> キャッシュを考慮していないために、 catch_table_entry に保存される sp が
> 違うためのようです。
> また CATCH_TYPE_RESCUEの場合にスタックトップに積まれるべき値が
> キャンセルされるために sp をデクリメントしている処理は、Stack Caching 有効時
> には結果がレジスタに格納される予定になるので不要になると思います。
> (BREAK, NEXTのほうはもしかしたら違うかも)

 たしか,stack caching を実装し,実験していたときは sp の計算をまともに
やっていなかったような気がします.というわけで,バグが出たんでしょうねぇ.

> tool/instruction.rb を修正してスタック消費量にレジスタの状態遷移を考慮するように
> してみました。
> ただこれでもまだ make は途中で失敗してしまいます。

 調査とかありがとうございます.

 というわけで,まだ道は遠そうです.この辺に関しても色々と有用な論文が出
ているので,誰かがっつり取り組んでくれるといいんですが.

-- 
// SASADA Koichi at atdot dot net

In This Thread