K.Maebashi's BBS

さっそく正誤表で対応して頂き、ありがとうございます。 >改行なしの行を食わせるためにはファイルからリダイレクト等しなければならないので うぐぅ、私は単純に 「入力が char_buf のサイズ（1024）を超えていて fgets がナル文字を付けた場合」 を想定しておりましたです。

ああそうか、レクサの問題というより、 テストドライバをそんなに厳密に書いていないというだけの話ですね。 ありがとうございました。

>となっています。'\0'に出会ったら BAD_TOKEN として処理するという意図だと思いますが、 >現状だと'\0'が現れた時点でwhileを抜けてしまうので、 >st_line_pos がインクリメントされないまま再び get_token() が呼ばれてしまい、 >実行時に無限ループに陥ります。 BAD_TOKENが返ってきているのにまたget_token()を呼ぶほうが変なんじゃ、と 思って本に掲載されているソースのテストドライバを確認したのですが、 END_OF_LINE_TOKENのチェックはしていてもBAD_TOKENのチェックをしていないので、 たとえば改行で終わらないファイルをリダイレクトで食わせたときに、 確かに無限ループになりますね。 電卓のパーサと組み合わせる限りではそんなにおかしなことにはならないような 気もします。 バグかというと微妙ではないかと思いますが、補足を入れておきます。 ># ただいま「プログラミング言語を作る」を骨の髄までしゃぶる勢いで読んでます。 ># 面白すぎて睡眠不足（笑）。 ありがとうございます。また何かあればご指摘ください。

「プログラミング言語を作る」p.59の、 lexicalanalyzer.c の23～24行からの構造を見ると、 token->kind = BAD_TOKEN; while(st_line[st_line_pos] != '\0'){ /* メインの処理 */ } となっています。'\0'に出会ったら BAD_TOKEN として処理するという意図だと思いますが、 現状だと'\0'が現れた時点でwhileを抜けてしまうので、 st_line_pos がインクリメントされないまま再び get_token() が呼ばれてしまい、 実行時に無限ループに陥ります。 一度ご確認ください。 # ただいま「プログラミング言語を作る」を骨の髄までしゃぶる勢いで読んでます。 # 面白すぎて睡眠不足（笑）。

ご回答ありがとうございます。 >-が降ってきた時点でそれまでの分をreduceしないと左結合にならないわけですが、 >現状、ここでshift/reduce conflictが起きており、shiftが優先されるため >結合規則が逆順になっています。 なるほどー、よく分かりました。もし右結合を明示したければ expression /* 「式」とは… */ : primary_expression /* 「一次式」、 */ | primary_expression ADD expression /* または、「一次式」 + 「式」 */ と書くべきなわけですね。 そもそも件名に「『一回以上の繰り返し』の定義」なんて書いちゃいましたが、 ただ単にそう定義するだけならレクサのレベルの話であって、 階層的な解析木を築くための構文規則を定めるのがパーサの役割だから、 結合規則によって規則の書き方が変わって当然なのですね。 結果的には誤植（？）がきっかけで非常に勉強になりました。引き続き読み進めていきます。

>expression /* 「式」とは… */ > : primary_expression /* 「一次式」、 */ > | expression ADD expression /* または、「式」 + 「式」 */ > （以下略） >だと、 >yacc: 4 shift/reduce conflicts. >となりますね。 申しわけありません。これはやはり間違いと判断すべきだと思います。 >どうしてそうなるのかは、まだ自分で説明できません……。 1 - 2 - 3 - 4 - 5 のような式のとき、 -が降ってきた時点でそれまでの分をreduceしないと左結合にならないわけですが、 現状、ここでshift/reduce conflictが起きており、shiftが優先されるため 結合規則が逆順になっています。 この構文規則は、優先順位を気にしなくてよいのなら…という文脈で出てきていた はずですし、その趣旨は構文規則を簡単にしたかったためなのですが、 結合規則まで気にしないとは書いてないですし、警告が出るのはそれ自体まずいですね。 数日中にWeb上で補足を入れます。ご指摘ありがとうございました。

人に聞く前に、実験してみるべきでした。 expression /* 「式」とは… */ : primary_expression /* 「一次式」、 */ | expression ADD expression /* または、「式」 + 「式」 */ （以下略） だと、 yacc: 4 shift/reduce conflicts. となりますね。 どうしてそうなるのかは、まだ自分で説明できません……。

「プログラミング言語を作る」p43～p44にかけてのソースに、 expression /* 「式」とは… */ : primary_expression /* 「一次式」、 */ | expression ADD expression /* または、「式」 + 「式」 */ （以下略） とあるのを見て、はたと疑問に思いました。 これって、 expression /* 「式」とは… */ : primary_expression /* 「一次式」、 */ | expression ADD primary_expression /* または、「式」 + 「一次式」 */ （以下略） としなくてもよいのでしょうか？ 他のソースではそうなっているので、反射的に「あっ、間違いだ！」と思ってしまったのですが、 よく考えると、これでもいいような気がします。 一般に、「hoge は piyo の1回以上の繰り返しである」という定義を、 hoge : piyo | hoge piyo と書かずに hoge : piyo | hoge hoge と書いてはいけない理由って、何かありますでしょうか？

こんにちは。 どうもありがとうございます。 私はSEですが、ゲームが嫌いで一切ゲームをしませんので、どういう想定で 書かれているのか理解できませでした。 このサイトは７年程前から知っていたのですが、７年来の疑問がやっと晴れました。 ありがとうございました。 >そうです。 >ネットワーク対戦オセロのサーバを立てるなら、そりゃ複数の対戦を同時に >行えるようにするでしょ、と思ってこう書いているのですが、確かにここで >引っ掛かりを覚える方もいらっしゃるかもしれませんね。 >ちょっと表現を考えてみます。 >

こんにちは。 >この例は、ネットワーク対戦＝複数の対戦が同時に行われる　という意味で >書かれていると理解すればよいのでしょうか。 そうです。 ネットワーク対戦オセロのサーバを立てるなら、そりゃ複数の対戦を同時に 行えるようにするでしょ、と思ってこう書いているのですが、確かにここで 引っ掛かりを覚える方もいらっしゃるかもしれませんね。 ちょっと表現を考えてみます。

「疑りぶかいあなたのためのオブジェクト指向再入門」を読ませていただきました。 そこで、疑問に思ったのが、ネットワーク対戦でオセロをする話なのですが、 どうして、ネットワーク対戦になると「複数のオセロの盤面を管理しなければならない」のかです。 ネットワーク対戦であっても、常にAさんとBさんというような一組だけが対戦する のであれば、オセロ盤は一つ管理すればいいだけですよね。 AさんとBさん、CさんとDさん、EさんとFさんというように複数の対戦が 同時期に行われる場合に、初めて複数管理する必要があると思いますが。 この例は、ネットワーク対戦＝複数の対戦が同時に行われる　という意味で 書かれていると理解すればよいのでしょうか。 よろしくお願いします。

>> 本に掲載したURLにリダイレクトを置くことで対処いたしました。 >と書かれていますが、エラーページが表示されているようです。 まさかと思って試してみたところその通りでした。 どうやら、リダイレクトのページをhttp://kmaebashi.com/devlang/ 直下(bookの 下でなく)に置き、置いたときの動作テストもそこを確認してしまったようです。 さきほど修正いたしました。 ここに書いても仕方がないのかもしれませんが、辿りつけなかった方には 重ね重ね申しわけありませんでした。お詫び申し上げます。 通りすがり様、情報ありがとうございました。

こんにちは。 > 本に掲載したURLにリダイレクトを置くことで対処いたしました。 と書かれていますが、エラーページが表示されているようです。 私はドメイン名からトップに飛び無事に辿り着けましたが…

青餓鬼さん、yuyaさん、ありがとうございます。 管理人が放置してしまいましてすみません。 この結論を関連ページに追記しました。ありがとうございました。 >とりあえず、Macの人に対しては >「とりあえずUTF-8版を試してください。 >駄目なら export LANG=ja_JP.UTF-8 としてからUTF-8版を再度試してください。」 >って指針で、多くの人に使ってもらえそうですね。

青餓鬼さん、試していただいてありがとうございます。 とりあえず、Macの人に対しては 「とりあえずUTF-8版を試してください。 駄目なら export LANG=ja_JP.UTF-8 としてからUTF-8版を再度試してください。」 って指針で、多くの人に使ってもらえそうですね。 私のほうも、ここらで追究を一段落させていただきます。 ありがとうございました。

>(1)10.5のほうはUTF-8版Diksamが無修正で動いた、と理解してよいのでしょうか？ Mac OSX 10.5の方はコマンドの追加もなく、ちゃんと動きました。 >(2)10.4でLANGが設定されていないとなると、LC_ALLが設定されているのでしょうかね。 >差し支えなければ echo $LC_ALL も試してみてください。 echo $LC_ALL の実行結果は、Mac OSXの10.4、10.5共に(空文)でした。

>私のPPCMac G5には、Mac OS X 10.4と10.5の二つのバージョンをインストールして使い分けていますが、10.4の方で実行した　echo $LANGの結果は(空文)でした。 >ついでに覗いた10.5のほうは ja_JP.UTF-8 でした。 返信ありがとうございます。 (1)10.5のほうはUTF-8版Diksamが無修正で動いた、と理解してよいのでしょうか？ (2)10.4でLANGが設定されていないとなると、LC_ALLが設定されているのでしょうかね。 差し支えなければ echo $LC_ALL も試してみてください。 MacOS X のことは全然分かんないや……。FreeBSDベースらしいということと、 http://homepage3.nifty.com/toshi3/osx2t.html の最後に >Mac OS Xではファイル名はUTF-8、Unixに由来する部分では日本語EUC、 >従来のMac OSに由来する部分ではShift-JISと、複数の文字コードが混 >在して使用されている。 と書かれていて、とにかく複雑なことになってる、ってことは分かりました。 あと、Unicode正規化の方式も違うようで、 http://labs.unoh.net/2007/09/unicode-on-mac.html 手元で実験できない私としては混沌とするばかりです。

>export LANG=ja_JP.UTF-8 > >で正常動作するということは、もとのLANGはUTFじゃなかったということですね。 >ちなみに、上のコマンドを実行する前の echo $LANG の結果は何だったのでしょうか？ 私のPPCMac G5には、Mac OS X 10.4と10.5の二つのバージョンをインストールして使い分けていますが、10.4の方で実行した　echo $LANGの結果は(空文)でした。 ついでに覗いた10.5のほうは ja_JP.UTF-8 でした。 環境変数LANGに何も指定されてなくても日本語が表示されるところを見ると別の環境変数があるのでしょうが、それについての解説は見つけることはできていません。 以上

export LANG=ja_JP.UTF-8 で正常動作するということは、もとのLANGはUTFじゃなかったということですね。 ちなみに、上のコマンドを実行する前の echo $LANG の結果は何だったのでしょうか？

Macで実行する際、UTF-8の場合exportコマンドで環境変数を指定すると、正常に実行することがわかりました。 >export LANG=ja_JP.UTF-8 このコマンドを実行した後に DIKSAM を実行すると、サンプルと同じ結果を得ることができます。 Macの技術解説書にこのあたりを体系的に記述したものが見あたらず、たまたま読んだコマンドリファレンスの、別のコマンドの実行例に、上に掲げた一文があり、早速実行すると、エラーなく実行できました。 なお、EUCの場合は、ターミナル上の日本語表示が文字化けしますので、別の環境変数があるのかもしれません。これ以上、深入りは当面控えておきます。 以上

>HEAP_THRESHOLD_SIZEが小さいと、頻繁にGCが走って遅くなるのはわかるのですが、 >死んでしまうのはおかしいと思うのですが…… >念のため当方でcrowbar_book_ver.0.2において、HEAP_THRESHOLD_SIZEを元に戻した >上で2000*2000*2の多次元配列を確保したところ、時間はかなりかかったようですが >死にはしませんでした。(Windows Vista環境) > 私もcrowbarcer_ver.0.2をターミナルで実行したところ時間はすごく掛かりましたが正常に終了しました．申し訳ないです．こちらも確認すべきでした． 私が開発環境はMacのXcodeです．GUIにcrowbarを組み込んでいます．ちなみにOS Xの10.６です． どこか実装にミスがあるのかもしれませんね＾＾；要素が大きくなるときだけGC_mark()で止まってるようなのですが難しいですね．本当にお手数かけました．

>尚，私の環境では200*200*200では４秒ほどなのですが2000*2000*2の多次元配列を利用した場合EXC_BAD_ACCESSで止まってしまいデバッガが起動していました． >実際にHEAP_THRESHOLD_SIZEを変更したところ多少時間はかかるものの正常に実行されました． HEAP_THRESHOLD_SIZEが小さいと、頻繁にGCが走って遅くなるのはわかるのですが、 死んでしまうのはおかしいと思うのですが…… 念のため当方でcrowbar_book_ver.0.2において、HEAP_THRESHOLD_SIZEを元に戻した 上で2000*2000*2の多次元配列を確保したところ、時間はかなりかかったようですが 死にはしませんでした。(Windows Vista環境)

>>サイトの説明:http://kmaebashi.com/programmer/devlang/array.htmlでは下記のコードが追加されています． >>#GCされないようにおまじない >>CRB_push_value(inter, &ret); >> >>CRB_pop_value(inter); > >これは、ネイティブ関数内で確保したオブジェクトがGCされないように >スタックに積んでいるわけですが、この方法は、ネイティブ関数を書く人に >(面倒くさいという意味で)負担をかけますので、 >Webページ版においても以下のページで方法を変更しています。 > >http://kmaebashi.com/programmer/devlang/crowbar_0_4_02.html > >前者の方法が後者の方法に比べて優れているところは特にないと思いますので、 >本の方では、最初から後者の方法で実装しているわけです。 >本では、後者の方法について、171ページで説明しています。 > >>私の実行環境ではnew_array()関数でたまに(要素数が大きくなると)gc_mark()の >>ところで止まってしまいます．私の実装ミスか，その部分のコードが足りない >>せいなのか分からないので質問させていただきました． > >crowbarのGCは単純なstop the world式のmark sweep GCなので、オブジェクト数が >増えてくるとmarkに時間がかかります。1次元の配列なら、多少数が多くても >オブジェクト数はひとつだからよいのですが、多次元ですと、現状の実装では >確保の途中で(無駄に)GCが動くのでかなり遅くなることがあります。new_array()の >中で不要なオブジェクトが増えることはないので、この間GCの発生を抑止する >方がよいのでしょうが、現状ではそうなっていません。 >ひとまずこちらでは、100×100×100の配列程度であればすぐに返りましたが、 >200×200×200だと30秒近く待たされました。 > >簡単にチューニングするには、crowbar.hのHEAP_THRESHOLD_SIZEを増やすという >方法があります。これは、どれだけのサイズのオブジェクトを確保したらGCを >動かすかという閾値で、現状では256KBになっています。 > 早速の返信ありがとうございます． 私はver0.2を参考にしていたのでそれ以降を見ていませんでした．申し訳ありません．最後まで読んで質問するべきでした． >>多次元ですと、現状の実装では確保の途中で(無駄に)GCが動くのでかなり遅くなることがあります なるほど納得しました．実装ミスというわけではないのですね．安心しました． 尚，私の環境では200*200*200では４秒ほどなのですが2000*2000*2の多次元配列を利用した場合EXC_BAD_ACCESSで止まってしまいデバッガが起動していました． 実際にHEAP_THRESHOLD_SIZEを変更したところ多少時間はかかるものの正常に実行されました． どうしても多次元で要素数が多い場合にも対応する必要があるため本当に助かりました． 有り難うございます．

>サイトの説明:http://kmaebashi.com/programmer/devlang/array.htmlでは下記のコードが追加されています． >#GCされないようにおまじない >CRB_push_value(inter, &ret); > >CRB_pop_value(inter); これは、ネイティブ関数内で確保したオブジェクトがGCされないように スタックに積んでいるわけですが、この方法は、ネイティブ関数を書く人に (面倒くさいという意味で)負担をかけますので、 Webページ版においても以下のページで方法を変更しています。 http://kmaebashi.com/programmer/devlang/crowbar_0_4_02.html 前者の方法が後者の方法に比べて優れているところは特にないと思いますので、 本の方では、最初から後者の方法で実装しているわけです。 本では、後者の方法について、171ページで説明しています。 >私の実行環境ではnew_array()関数でたまに(要素数が大きくなると)gc_mark()の >ところで止まってしまいます．私の実装ミスか，その部分のコードが足りない >せいなのか分からないので質問させていただきました． crowbarのGCは単純なstop the world式のmark sweep GCなので、オブジェクト数が 増えてくるとmarkに時間がかかります。1次元の配列なら、多少数が多くても オブジェクト数はひとつだからよいのですが、多次元ですと、現状の実装では 確保の途中で(無駄に)GCが動くのでかなり遅くなることがあります。new_array()の 中で不要なオブジェクトが増えることはないので、この間GCの発生を抑止する 方がよいのでしょうが、現状ではそうなっていません。 ひとまずこちらでは、100×100×100の配列程度であればすぐに返りましたが、 200×200×200だと30秒近く待たされました。 簡単にチューニングするには、crowbar.hのHEAP_THRESHOLD_SIZEを増やすという 方法があります。これは、どれだけのサイズのオブジェクトを確保したらGCを 動かすかという閾値で、現状では256KBになっています。

配列の確保、およびネイティブ関数の書き方についての質問です サイトの説明:http://kmaebashi.com/programmer/devlang/array.htmlでは下記のコードが追加されています． #GCされないようにおまじない CRB_push_value(inter, &ret); CRB_pop_value(inter); ところがこのコードの部分は本書及び，サンプルソースでも書かれていませんでした． これは必要ないということでしょうか？ またそのような関数名はないようなのですが，eval.cのpush_value(),pop_value()のことでしょうか？ 私の実行環境ではnew_array()関数でたまに(要素数が大きくなると)gc_mark()のところで止まってしまいます．私の実装ミスか，その部分のコードが足りないせいなのか分からないので質問させていただきました．

>crowbarのfor文どのように実装されているのですか。 >本を何回も読みましたが見逃してしまっているかもしれませんので、本にあるならば、ページ番号を教えてください。 p.115でwhileの実装についてコード込みで説明しています。 p.115には、「ここから呼び出される関数を全部見ていくのは紙面の無駄ですので、 ここでは代表としてwhile文で呼び出されるexecute_while_statement()を取り上げ ます。」と書いてあります。 紙面節約のため代表としてwhileを取り上げているわけですから、forについての 直接の説明はありません。whileを参考にソースを読めばわかるという意図で 省略しているわけです。

crowbarのfor文どのように実装されているのですか。 本を何回も読みましたが見逃してしまっているかもしれませんので、本にあるならば、ページ番号を教えてください。

>create.oなどOファイルがありますが、これには機械語とリンク処理に必要な情報が含まれている、と考えていいのですか。 何を知りたいのかわかりませんが、その通りです。

create.oなどOファイルがありますが、これには機械語とリンク処理に必要な情報が含まれている、と考えていいのですか。Oファイルを見てみると機械語みたいなものが書いてありました。