K.Maebashi's BBS

>というわけで、あわせて修正した版をもうじきUPします。 UPしました。 私のところではこれで動いています。 test.dkm以外のサンプルプログラムは、テスト用シェルスクリプトtest.shを使って、 % sh ./test.sh のようにすればまとめて実行できます。これで、test以下の.dkmのファイル名から 拡張子を除いたものの名前だけがずらずらと出れば成功、diffが相違を検出したら なにか問題が起きてます。 なにかあれば教えてください。 いろいろと報告ありがとうございました > つよしさん # いまどきEUCは時代錯誤か…… 確かに。

>$ cd test/ >$ echo $LANG >ja_JP.UTF-8 >$ find . -type f -exec nkf -w --overwrite {} \; すみません、見落としていましたが(前回の投稿のコマンドプロンプトのところに 形跡がありました…)、この変換はmain/test以下でやっていたのですね。 Diksamは、エラーメッセージを日本語で出します(これはこれでどうかという 人もいそうですが)。また、そのエラーメッセージは、compilerとdvm以下の error_message.cに埋め込まれています。 現在ダウンロードできるDiksamのソースでは、error_message.cの文字コードが EUCになっています。以下のエラーは、これをDiksamの内部文字コード(wchar_t)に 変換しようとして失敗しているために発生しています。 >$ ../diksam test.dkm >Assertion failure (wc_format != NULL) file..error.c line..92 >wc_format is null. よって、LANGがja_JP.UTF-8な環境で動かすには、コンパイル前に、 error_message.cをUTF-8に変換しなければなりません。 それだけで動くかと思って試してみたところ、share/wchar.cの中に 1文字分のマルチバイト文字列が2文字までであることを想定しているところが あって、UTF-8だと1文字が3バイトになるのでそこでもエラーが出ました。 というわけで、あわせて修正した版をもうじきUPします。

前橋さん こんばんは 初心者なので最初からやり直しました。 端末のコピーアンドペースとです。 ここから $ tar zxvf diksam_0_4_01_unix.tgz $ cd diksam_unix/main/ $ make ＜省略＞ cc ../compiler/compiler.o ../compiler/builtin/builtin.o ../dvm/dvm.o ../share/share.o ../memory/mem.o ../debug/dbg.o ./main.o -o diksam -lm $ cd test/ $ echo $LANG ja_JP.UTF-8 $ find . -type f -exec nkf -w --overwrite {} \; $ ../diksam test.dkm Assertion failure (wc_format != NULL) file..error.c line..92 wc_format is null. Assertion failure (wc_format != NULL) file..error.c line..92 wc_format is null. アボートしました $ ここまで。。。 一つ前の前橋さんの書き込みすべて理解できていません。 僕にできるのは、こんな感じです。いじょう～ debian lenny

>utf-8 なコードを　diksam　は受け付けない >ということですか？！ >utf な環境は、多いです！！ Diksamを作り始めた頃は、まだUTF-8が主流ではなかった、ような気がしているの ですが(私が遅れていただけかもしれません)、最近は確かにUTF-8な環境がかなり 多くなっていますね。 >＠~/Desktop/diksam_unix/main/test$ find . -exec nkf -w -overwrite {} \; >で utf-8 に変換し実行するとエラーになります。 ところでこれですが、この時、$LANGは何になっていたでしょうか? >Assertion failure (wc_format != NULL) file..error.c line..92 >wc_format is null. これを見る限り、error_message.c内の日本語文字列(UTF-8に変換されている)を ワイド文字列に変換しようとして失敗しているようです。 Diksamは、現在のデフォルトエンコーディングでマルチバイト文字列をワイド文字列に 変換しようとします(main.cに「setlocale(LC_CTYPE, "");」と書いてあります)。 よって、現在の$LANGがja_JP.EUC-JP等になっていれば、正しく変換できません。 >utf-8 なコードを　diksam　は受け付けない >ということですか？！ で、この件ですが、ソースを確認してみたところ、error_message.cをUTF-8に 変換してコンパイルされており、環境も正しくUTF-8になっていれば、UTF-8を 受け付けるのではないかと思います(まだ試せていません)。 先の投稿でUTF-8に未対応、ということを書きましたが、本来、普通に8bitを 通しさえすれば、UTF-8は文字列リテラル等に問題なく使えるはずです(UTF-8という のはそういうことを意図したエンコーディングです)。にも関わらず、crowbarで UTF-8対応がわざわざ必要になったのは、Shift-JIS対応のため特定のバイトの次の バイトを特別扱いする、という対応をしているためで、Diksamをよく見てみたら、 そもそもShift-JISの対応が入っていませんでした… というわけで、現在のWindows版のDiksamは、ソースがShift-JISであることを 期待しているにもかかわらず、「表」等の文字を文字列リテラルに入れると エラーになります(いわゆる0x5C問題)。Diksam on Windowsとか言っときながらこれは さすがにまずいので、早急に対応します。 >他　少し試しましたが　セグメンテーションエラーとか　いろいろ、、、 さすがの私もtest.shくらいは流してから出してますので、testディレクトリ以下の ものが動かないなら、何らかの環境に依存する問題かと思います。 できれば詳細を教えてください。

前橋さん >$ ../diksam rand.dkm は、実行確認できました。 >他　少し試しましたが　セグメンテーションエラーとか　いろいろ、、、 他、いくつか実行出来ました。 エラーが出るのは、引数とか？与えないといけないのかな？ $ ../diksam mathtest.dkm ok!! $ ../diksam downcast.dkm ok!! etc...

前橋さん ありがとうございます。 ＠~/Desktop/diksam_unix/main/test$ find . -exec nkf -w -overwrite {} \; で utf-8 に変換し実行するとエラーになります。 ＠~/Desktop/diksam_unix/main/test$ ../diksam test.dkm Assertion failure (wc_format != NULL) file..error.c line..92 wc_format is null. Assertion failure (wc_format != NULL) file..error.c line..92 wc_format is null. アボートしました ＠~/Desktop/diksam_unix/main/test$ そもそも utf-8 なコードを　diksam　は受け付けない ということですか？！ utf な環境は、多いです！！ $ ../diksam rand.dkm は、実行確認できました。 他　少し試しましたが　セグメンテーションエラーとか　いろいろ、、、

>../diksam test.dkm > >と実行してみるのはどうでしょうか。 追記ですが、 このtest.dkmは日本語を含みますが、文字コードはEUCです。 現時点のLinux版diksamはEUCのソースしか受け付けないので、UTF-8な環境では 環境の設定を変えるか日本語部分を削ったほうがよいかもしれません。 # crowbarの最新版(未公開)ではUTF-8にも対応しているので、 # 同じ修正をDiksamにも入れようと思いつつ忘れてました…

>diksam　がうまく動くか　試したいのですが？ mainディレクトリの下にtestディレクトリがあります。 その下で ../diksam test.dkm と実行してみるのはどうでしょうか。 同じディレクトリにあるシェルスクリプト「test.sh」は、そこにある テストスクリプトを一括実行し、正しい結果とdiffを取ります。

前橋さん ありがとうございます。 $ sudo aptitude install bison $ sudo aptitude install flex $ pwd /home/tntn/Desktop/diksam_unix/main $ make 以上で　diksam　を作成できました。 diksam　がうまく動くか　試したいのですが？

つよしさん、はじめまして。 >debian lenny でコンパイルエラーになります。 >何が足りないのでしょうか？ >gcc は、4.3 ヴァージョンをインストールしました。 >$ make … >make[1]: yacc: コマンドが見つかりませんでした 見てのとおり、yaccが入っていません。 Debianなら、bisonをパッケージインストールすれば、シンボリックリンクを 勝手に作って、「yacc」で実行できるようになったような気がします。 gccやyaccが標準で入っていない環境なら、おそらくlexも入っていないでしょうから、 flexも入れる必要がありそうです。 もし、bisonやflexは入れたけれど「yacc」や「lex」としては実行できない、 ということなら、compilerディレクトリ以下のMakefileを修正し、 yacc -dv diksam.y となっているところ(2箇所)を、 bison --yacc -dv diksam.y に、 lex diksam.l となっているところを flex diksam.l にしてください。 それはそれとして、 >（Linux版では、Ｕフォーは、ダメですか？：入門者） 残念ながらダメです……

前橋さま debian lenny でコンパイルエラーになります。 何が足りないのでしょうか？ gcc は、4.3 ヴァージョンをインストールしました。 （Linux版では、Ｕフォーは、ダメですか？：入門者） $ make cd ../compiler; make; make[1]: ディレクトリ `/home/tntn/Desktop/diksam_unix/compiler' に入ります yacc -dv diksam.y make[1]: yacc: コマンドが見つかりませんでした make[1]: *** [y.tab.h] エラー 127 make[1]: ディレクトリ `/home/tntn/Desktop/diksam_unix/compiler' から出ます make: *** [../compiler/compiler.o] エラー 2 $

前橋さま ウィンドウズ版Diksamの公開おめでとうございます。 Ｕフォーの絵　見ました。それが動いたりするのですか？すごい！！ Linuxから書き込んでいますが、Linuxでは、Ｕフォーは出来ないのかな？

こんにちは。 >前橋言語の作例は、ありませんか？ すみません、今のところサンプルプログラムとしては配布ディレクトリの compiler/test以下にあるものぐらいしかないです。 >パズルとか電卓とか？ >前橋さんの電卓ネタを前橋言語で書き換えるとか？ Diksam用のyaccはないので、再帰下降パーサを手書きすれば電卓ぐらいは 作れそうではありますが、文字列処理の手段がsubstr()しかなくて、 もちろんそれでもできますけれど効率が悪いので、"abc"[2]で'c'が取れるように したりとか、当然同時に文字リテラルも必要になって、とか、 いずれにしてもライブラリがこれではたいした物は作れないのでライブラリを 補強して、とか、やりたいことはいくつもありますし実現も難しくないのですが、 何をするにも時間が不足しております。 ライブラリの方は現在追加してまして、近々、何かしらちょっとは楽しいプログラムが 作れるようにしようとは思っているのですが。 すみません、Macユーザのたろうさんには大変申し訳ないのですが、今度追加される ライブラリ部分は当面Windows専用になります…

管理人（前橋）さま 前橋言語の作例は、ありませんか？ パズルとか電卓とか？ 前橋さんの電卓ネタを前橋言語で書き換えるとか？

>>$(CC) $(CFLAGS) -o $@ -I../../include builtin_conv.c $(CONV_OBJS) >> ↑ >> >>としてやればうまくいくのではないでしょうか。 > >前橋さん >コンパイル通りました。 情報ありがとうございます。次回リリースからは、Makefileを修正しておきます。 Macでも動いたということで、嬉しいです。

再帰も出来ますね！あたりまえ？ 何か使えそうな気配です！！ $ vi saiki int fact(int n) { if (n==0) { return 1; } else { return n*fact(n-1); } } println(fact(3)); println(fact(4)); println(fact(5)); println(fact(10)); $ diksam saiki 6 24 120 3628800 $

> >ここでこういうエラーが出ているということは、diksamの展開ディレクトリ以下の、 >compiler/builtinディレクトリのMakefileの20行目の > >$(CC) $(CFLAGS) -o$@ -I../../include builtin_conv.c $(CONV_OBJS) > >の「-o$@」の「-o」と「$@」の間に空白を入れ、 > >$(CC) $(CFLAGS) -o $@ -I../../include builtin_conv.c $(CONV_OBJS) > ↑ > >としてやればうまくいくのではないでしょうか。 前橋さん コンパイル通りました。 感謝、感激です。 ありがとうございます。 試してみました。 スキル不足でこんなのでいい？ ＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾ $ vi ppp.dk println("hello, たろう."); int s = 0; int i; for (i=1; i<=10; i=i+1) { s += i; print(i); println(" たろう"); } $ diksam ppp.dk hello, たろう. 1 たろう 2 たろう 3 たろう 4 たろう 5 たろう 6 たろう 7 たろう 8 たろう 9 たろう 10 たろう $ ＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾ 以上。

こんにちは。 >　マックosx で、コンパイルしたいのですが可能ですか？ >powerpc g3 インテルマックでは、ありません。 (略) >ld: unknown flag: -obuiltin_conv MacOS XのCコンパイラがどんなコンパイラなのか私は知らないのですが、 「-obuiltin_conv」というオプションはないよ、というエラーを出しています。 ここは、「-o」というフラグで実行形式の名前を指定しているところで、 私の知っているたいていのコンパイラでは、-oの後ろに空白を入れても入れなくても OKでした。 ここでこういうエラーが出ているということは、diksamの展開ディレクトリ以下の、 compiler/builtinディレクトリのMakefileの20行目の $(CC) $(CFLAGS) -o$@ -I../../include builtin_conv.c $(CONV_OBJS) の「-o$@」の「-o」と「$@」の間に空白を入れ、 $(CC) $(CFLAGS) -o $@ -I../../include builtin_conv.c $(CONV_OBJS) ↑ としてやればうまくいくのではないでしょうか。 確証はありませんが >ld -r -o mem.o memory.o storage.o このへんでは-oオプションがちゃんと効いているところからすると可能性は 高いと思います。 実際に試してくださった方がいらっしゃると励みになります。ありがとうございました。

diksam_0_4_unix.tgz 前橋さま 　マックosx で、コンパイルしたいのですが可能ですか？ powerpc g3 インテルマックでは、ありません。 makeの実行画面を示します。 ＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾ $ tar zxf diksam_0_4_unix.tgz $ ls diksam_0_4_unix.tgz diksam_unix/ $ cd diksam_unix/compiler/ $ make yacc -dv diksam.y lex diksam.l cc -c -g lex.yy.c -I/usr/local/include -I../include cc -c -g y.tab.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG main.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG interface.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG create.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG fix_tree.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG generate.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG string.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG wchar.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG util.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG error.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG error_message.c -I/usr/local/include -I../include cc -c -g -Wall -ansi -Wswitch-enum -DDEBUG builtin/builtin.c -I/usr/local/include -I../include cd ../dvm; make; cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include execute.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include load.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include heap.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include native.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include nativeif.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include wchar.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include util.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include error.c cc -c -g -DDEBUG -Wall -ansi -Wswitch-enum -I../include error_message.c ld -r -o dvm.o execute.o load.o heap.o native.o nativeif.o wchar.o util.o error.o error_message.o cd ../share; make; cc -c -g -I../include -DDEBUG -Wall -ansi -Wswitch-enum -I../include dispose.c cc -c -g -I../include -DDEBUG -Wall -ansi -Wswitch-enum -I../include opcode.c cc -c -g -I../include -DDEBUG -Wall -ansi -Wswitch-enum -I../include disassemble.c cc -c -g -I../include -DDEBUG -Wall -ansi -Wswitch-enum -I../include wchar.c cc -c -g -I../include -DDEBUG -Wall -ansi -Wswitch-enum -I../include util.c ld -r -o share.o dispose.o opcode.o disassemble.o wchar.o util.o cd ../memory; make; cc -c -g -DDEBUG -Wall -I../include memory.c cc -c -g -DDEBUG -Wall -I../include storage.c ld -r -o mem.o memory.o storage.o cd ../debug; make; cc -c -g -Wall -DDBG_NO_DEBUG -I../include debug.c ld -r -o dbg.o debug.o cd ./builtin; make; cc -g -DDEBUG -Wall -ansi -Wswitch-enum -obuiltin_conv -I../../include builtin_conv.c ../../memory/memory.o ../../debug/debug.o ld: unknown flag: -obuiltin_conv make[1]: *** [builtin_conv] Error 1 make: *** [diksam] Error 2 $ ＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾＾

ローカルにPHP5の環境を作ったのですが、デフォルトのphp.iniの設定が違いすぎていて、まだ一部動かせていません。 magic_quotes_gpcはOffだわ(これは正しいのですが)、asp_tagsはOffだわ、short_open_tagもOffだわで、これではサーバがPHP5に移行した際、どんな設定になっているかが問題のように思います。 ……と思っていたら、どうもPHPの移行には混在期間があって、当面は今のままで動くようです(PHP5にしたければ拡張子を変えろと)。なので今日はもう寝ます。

この掲示板(を含むうちのWebページ一式)をホスティングしてくれている会社から、 以下の通知が来ました。 >この度、Zend社のPHP4サポート終了の告知を受けまして、サーバーシステムの >保全のため、PHP5へのアップデートを行います。全共用サーバーにおきまして、 >PHP4のご利用ができなくなります。至急設置スクリプトの対応状況をご確認、 >更新をお願いいたします。 この通知が来たのはだいぶ前のことなのですが、いろいろあって放置しているうちに、 変更の期日が10/29に迫ってしまいました。 この掲示板を作った時点の環境は当時のPCが壊れた時点で失われていて、 今現状のLet's Noteの環境にPHPとApacheを入れてみたのですが、まだPHPが 動かせていないようです。 もうちょっといじってみるつもりですが、10/29の時点でこの掲示板が動かなく なっていたら、それが原因とお考えくださいませ。

>（ぱ）さんが、賞金１万円出して >（ぱ）さんが作ったOSで、プログラミングコンテストをする。 OSを作った覚えはないので、プログラミング言語ですかね。 1万円というと、いにしえのBASICマガジンの原稿料がそれぐらいだったと思います。 ベーマガ相当のプログラムが集まるのなら、最優秀賞に1万円くらい出すのは 惜しくないですが、結局ほとんど集まらず、hello, worldに1万円出すハメに なったりして。

（ぱ）さんが、賞金１万円出して （ぱ）さんが作ったOSで、プログラミングコンテストをする。 無責任な書き込みでした。本気！

今回実行していた「app.exe」が処理が成功しているにもかかわらず、 '1'を返していたため、makeが その戻り値を検出し、処理を停止してしまって いたようです。 ('-'を付加することにより逃げました。） 774RRさんありがとうございました。

返信、ありがとうございます。 >なので app.exe target.dat 0<source.dat は本質的に正しい入力であって、 なるほど、そうなんですか。 >なので 0< となるのは「実行できない」の原因ではないと思われまっする。 >「実行できない」の詳細について記載がないのでこれ以上の判断は出来ません。 >本体プログラム側のバグを疑ってください。 今回実行したい「app.exe」が特にエラーメッセージを表示せず、 何故実行できないのかわからなかったため、この'0'が付加することによるのかな と想像してしまいました。 仰るとおり、本体プログラム側を疑って調査してみます。 ありがとうございました。

標準入力のリダイレクトは < で行うのですがこれは本来 0< の略記なのです。 http://itpro.nikkeibp.co.jp/article/COLUMN/20060228/231093/ たとえば un*x のコンソール上では $ cat hoge.txt Hoge! $ cat 0<hoge.txt Hoge! $ // と、このように同じ動作をするのが正常な動きでありんす。 んで XP/2000 のコマンドプロンプトである cmd.exe もこの表記を受け付けます。 D:\MYWORK>cat 0<hoge.txt Hoge! D:\MYWORK> なので app.exe target.dat 0<source.dat は本質的に正しい入力であって、 期待したとおりに動くはずです。実際俺のところでは cmd.exe bash.exe の両方で このように0<と手入力しても期待通りの正しい動きをします。 さてここまで納得していただけたでしょうか。この例の場合、バッチファイル中には < としか書いていないリダイレクト記号を、誰かが勝手に (make がやっているのか cmd.exe がやっているのか、他の誰かかは不明) 0< と置換しているわけです（実害ないけど妙なことをやってるよね・・・） 0< となっていても俺んとこでは期待通り動作しています。 なので 0< となるのは「実行できない」の原因ではないと思われまっする。 「実行できない」の詳細について記載がないのでこれ以上の判断は出来ません。 本体プログラム側のバグを疑ってください。

cygwin をインストールして確認しましたが、 やはり、Borlandのmakeと同じ結果でした。 確認方法は、下記のようなmakefile及び バッチファイルを用意して、 (ダミーの"source.dat"と"app.exe"も用意して) --- makefile -------------------- target.dat : source.dat test.bat --------------------------------- --- test.bat -------------------- app.exe target.dat < source.dat --------------------------------- cygwin上？でmakeを実行しました。 すると、やはり'<'の前に'0'が付加されます。 --------------------------------- $ make test.bat app.exe target.dat 0<source.dat ~ --------------------------------- 何故でしょうか? 環境は、下記です。 GNU make 3.81 Windows XP Professional Version 2002 Service Pack 2

>file1.hoge ではなく hoge1.txt みたいに８文字ドット３文字以下の >過去互換性重視なファイル名に変えてみると良いかもしれん、ということぢゃ >直るかもしれんし、直らんかもしれん。どっとはらい。 理解できました。ありがとうございました。 引き続き試してみます。

ちなみに GNU make はソースコード提供なので開発環境がないと作れない make 自体は開発環境の一部であり、これがうまく動かないのではコンパイルできない という自己矛盾の状況に陥るわけだ。 cygwin 開発環境一式持ってくるほうが結局面倒が無いかも知れんっす。 そーすると gcc コンパイラ自体も入手できちゃうので某の出番は無い可能性が・・・ 掲示板のスペースで cygwin の解説など不可能っぽいので http://journal.mycom.co.jp/special/2002/cygwin/index.html

むかしむかし、あるところに MS-DOS というものがあってのぉ MS-DOS ではファイル名に「８文字以下 ドット ３文字以下」しか使えなかったのぢゃ その関係でなぁ、 Win95 以後のソフトでも８文字ドット３文字のファイル名しか 扱えないような、そーいう過去互換性重視なモノもあったのぢゃよ # 某の make がそういう過去互換重視なものかどうかは知らんがのぉ hoge.exe は４文字ドット３文字だから問題ない file1.txt は５文字ドット３文字だから問題ない のぢゃが file1.hoge や file2.piyo は５文字ドット４文字なのでな、 過去互換性重視なソフトに取っては非互換なファイル名なのぢゃよ file1.hoge ではなく hoge1.txt みたいに８文字ドット３文字以下の 過去互換性重視なファイル名に変えてみると良いかもしれん、ということぢゃ 直るかもしれんし、直らんかもしれん。どっとはらい。