けいじゅ＠日本ラショナルソフトウェアです.

In [ruby-list :11793 ] the message: "[ruby-list:11793] Re: [racc] help
me ", on Jan/29 00:04(JST) aamine / dp.u-netsurf.ne.jp writes:

>あおきです。

>> パーズそのものの速度は大部早いみたいですね. 処理はscannerのボトルネッ
>> クだけって感じです.
>
>みたいですね。
>lexもどきの文法ファイルからCとRubyのソースを出力するとかも考えたの
>ですが、RubyのProcをよびだすコストが正規表現の速度差をうわまわったら
>意味がないし。
>Rubyでがんばる方向では、正規表現を複数回よびだすのをやめて
>
>/(\Apat1)|(\Apat2)|(\Apat3)|(\Apat4)|...|(\ApatN)/
>
>でスキャンするとか。
>それで、あとからどのカッコにマッチしたのか調べる。
>モード変化は、Regexpをまるごととりかえてしまうことで実装。
>MatchingDataに「nilでない最初の括弧」とかいう情報があると
>かなり高速になるんですけどね。(できるかな？もしかして)

rtagsで使っているrubyのscannerは正規表現を使っていないんですけどね. だ
からかえって遅いのかな(^^;;;

でも, 私の実力ではrubyの字句を完全に識別できるような複雑な正規表現は書
けないし(^^;;; 

>> >> # あと, もうちょっとraccのコンパイル速度が早くなると嬉しいんですが(^^;;;

>うう。いろいろやってみたのですが、アルゴリズムを変えない限り
>今の速度で限界みたいです。これは明日にでも。
>
># bisonのコードでも見て勉強してきますです。

(^^;;; すばらしいっ!!

>> rtags.ryの件は後半にあるほとんど無駄なトークンをscanner側で1つにしちゃ
>> えばきっと状態数がかなり少なくなるので, rtagsのパーズは早くなるとは思
>> うのですが...
>
>そうですね。INTEGERとFLOATとXSTRINGと…あれ？即値全部かな

rtagsのレベルだとほとんどいらないですよね.

>> ところで, 生成したパーザで出てくるデフォルトのエラーのメッセージの意味
>> が良く分からないのですが... 
>> 
>> Racc parse error
>>   unexpected token ''
>> 
>>   LR state  = 0136139127128136139131151136139123124136139117136139117136139106
>> 
>> ってなっている時, どういう意味になっているのでしょうか?
>
>すみません、parser.rbのバグでした。パッチつけます。

バグでしたか(^^;;; フカーイ意味があるのかと...

>tokenが空文字列になってるほうはひきつづき調査中です。

お願いします(__


__
................................石塚 圭樹＠日本ラショナルソフトェア...
----------------------------------->> e-mail: keiju / rational.com <<---