K.Maebashi's BBS

>>　見間違いかもしれないけど、0.2.0はメモリーストレージを使ってないような･･･ >見間違いかと思います (^^; >了解しました、構文解析の所を今見た所確かにそうです。失礼いたしました。 >しかし、以前メモリートラブルでと話したとき、いつもmallocの中でこけてた >んです。 補足ですが、構文解析部分はMEM_Storageを使用してまとめて開放していますが、 コンパイルにより作られるDVM_Executableは各オブジェクトを個々にMEM_malloc()して 作っています。こちらは、配列のオーバーランなどすると、次のmalloc()で こける可能性が高いと思います(いまどきはそうでもないかも)。 malloc()で確保した領域を配列のオーバーランで壊したことを検出するために、 MEMではアプリケーションに渡す領域の前後を0xCDで埋めていて、これをチェックする 関数MEM_check_all_blocks()を用意しています。実際これでバグを見つけたことも 多いのですが、最近はLinux環境ではとっととvalgrindを使っていたりします。 Windowsで、フリーなvalgrind相当品があるかどうかは不勉強にて知りません。

>見間違いかと思います (^^; 了解しました、構文解析の所を今見た所確かにそうです。失礼いたしました。 しかし、以前メモリートラブルでと話したとき、いつもmallocの中でこけてた んです。それで思い違いをしたかな、結局追いきれなくてあきらめたんですけ ど。いや、相当粘ったんですよこれでも… >fix_tree.cでは主にTypeSpecifierを解析木に付加しますが、おっしゃるとおり、 >たとえばある式がintのTypeSpecifierを持っていて、それにマイナス演算子を適用した >このへんのことは以下にちょっとだけ書いてありました。 了解しました、と言うかまとめて開放だから無問題です。単に私がちょっとfixtree で手間取ったのが、それが理由だったんです。結局、メモリー監視デバックルーチ ンが、shared_ptrのような機能を持ってメモリー管理になってしまいましたんです。 もともとスマートポインターは重いからやめようと思ってた矢先の出来事で。 ええ、Boostのpoolに変えます… >「一番外側のブロック」ではなく、その名のとおり「現在のブロック」です。 了解しました。実はコメントを書き換えなおすの忘れてた。昔のままだった。 何も考えずに、有るのそのままコピペしてました。 >> ST_MemberExpression member_expression; // 使用していない？ >クラスを導入していないver.0.2では確かに使っていませんね。 了解しました。ありがとうございます。これなんだろう？調べなきゃと思っていました。

>　見間違いかもしれないけど、0.2.0はメモリーストレージを使ってないような･･･ 見間違いかと思います (^^; create.cで解析木のノードを確保する際も、fix_tree.cで主にTypeSpecifierを 確保する際も、最終的にはdkc_malloc()を呼んでいますし、dkc_malloc()は コンパイラが保持してるMEM_Storageを使用してメモリ確保しています。 http://kmaebashi.com/programmer/devlang/diksam_src_0_2/S/11.html#22 >　実は、構文解析で構文ツリーが出来た時点では、TOPのCT_Compilerのオブジェクトを >deleteすればディストラクタ繋がりできれいに総てのメモリーを解放できたのですが >Fixtreeを作ってみると、多重リンクはするはリンクが切れてフリーが山ほど出てくる >はで。 fix_tree.cでは主にTypeSpecifierを解析木に付加しますが、おっしゃるとおり、 たとえばある式がintのTypeSpecifierを持っていて、それにマイナス演算子を適用した ような場合には、マイナス演算子の式のTypeSpecifierは、その子ノードのものを 直接使用していたはずです(多重リンク)。また、[]演算子を適用するとTypeDeriveが 1段階外されますが、この時、[]演算子のノードのTypeSpecifierは、TypeDeriveの 連結リストの途中のノードを指します(その下のノードでは根元を参照していますが)。 このへんのことは以下にちょっとだけ書いてありました。 http://kmaebashi.com/programmer/devlang/diksam_0_1_comp.html | コンパイル時のTypeSpecifierは、なにしろ解析木のすべての式のノードに | 割り当てられます。たとえば「a + 1」という式がありaがint型の時、 | intを表現するためのTypeSpecifierが(「a」と「1」と「a + 1」のために) | (現状の実装では)3つ確保されています。でもよく考えれば「a + 1」のノードの | TypeSpecifier は左辺か右辺かどっちかのを直接参照してもよいはずで、 | 実際マイナス演算子ではそうしています。 | このように、TypeSpecifier構造体は、誰が所有者なのかわけがわからんような | こんがらがった参照で保持されているので、解析木の他の部分同様、 | コンパイル終了時に(MEM_Storageの機能を使用して)一括で破棄しています。 >class CT_Compiler : public CBase >{ >public: > CT_Block * current_block; // 一番外側のブロック 微妙に気になるのですが、current_blockは、少なくとも元のソースでは、 「一番外側のブロック」ではなく、その名のとおり「現在のブロック」です。 create.cにおいてBlockを生成する際に、親のブロックへの参照をセットするために 使用しています。 >class CT_Expression : public CBase >{ ... > union { > ST_MemberExpression member_expression; // 　　　使用していない？ これは、オブジェクトのメンバを参照するためのノードですが、 クラスを導入していないver.0.2では確かに使っていませんね。 ていうかソースには一応入っていたことに私の方が驚きました。

お疲れ様です。返事をもらえると嬉しいのですが、ごゆっくりどうぞ。 　↓のクラスを見てわかるとおりに、ほとんどstructをクラスにしたままです。内部 データが少し変わっていますが、structの全体接続構造はほとんどそのままです。 　私も意味もなくポリモルフィズムするのは好きではないし。本来の目的は クラスでパッキングして見通しを良くしよう。そして、書くことによる自身の 理解、そして必要機能の追加のためです。それと、diksamもほぼ同じ量のメモリー 確保をしていますよ。 　見間違いかもしれないけど、0.2.0はメモリーストレージを使ってないような･･･ class CT_Compiler : public CBase { public: int function_count; // 関数の数 CT_FunctionDefinition * function_list; // 関数のリスト CT_DeclarationList * declaration_list; // トップの宣言リスト CT_StatementList * statement_list; // トップのステートメントのリスト CT_Block * current_block; // 一番外側のブロック //== 式のツリーノード =========================================== class CT_Expression : public CBase { public: CT_TypeSpecifier *type; // E_ExpressionKind kind; // 式の種類 int line_number; union { E_Boolean boolean_value; // boolデータ　リテラル int int_value; // intデータ　リテラル double double_value; // doubeデータ　リテラル string *string_value; // stringデータ　リテラル ST_IdentifierExpression identifier; // 関数又は宣言文の識別子 ST_CommaExpression comma; // カンマ(,)式 ST_AssignExpression assign_expression; // 代入式 ST_BinaryExpression binary_expression; // 演算式 CT_Expression *minus_expression; // マイナス式 CT_Expression *logical_not; // 論理否定式 ST_FunctionCallExpression function_call_expression; // 関数式 ST_MemberExpression member_expression; // 　　　使用していない？ CT_ExpressionList *array_literal; // 配列データ　リテラル ST_IndexExpression index_expression; // 配列の添え字式 ST_IncrementOrDecrement inc_dec; // ++,--,式 ST_CastExpression cast; // キャスト演算式 ST_ArrayCreation array_creation; // 配列生成式 } u; 　実は、構文解析で構文ツリーが出来た時点では、TOPのCT_Compilerのオブジェクトを deleteすればディストラクタ繋がりできれいに総てのメモリーを解放できたのですが Fixtreeを作ってみると、多重リンクはするはリンクが切れてフリーが山ほど出てくる はで。メモリー監視・チェック・報告のデバックプログラムが、一躍メモリー管理 プログラムに昇格して、多重リンクや放置されたメモリーを管理して、きれいに掃除 することになりました。思わぬ副作用が･･･ 　今大改造中で動かせなかったのですが、構文解析時点で5千数百のnewをしていました。 　実は、ジェネレータとVM部分を始めていたのですが、ほしい仕様のための変更部分が 目立って見えてきたため、yacc,lex部分から大きく改造を始めてしまいました。 いま、#include　#define　構文の追加と最外枠のステートメント禁止、main()関数起動 を組み込み始めました。そして上の二つの構文のためにプリプロセッサを書いています。 だから、コンパイルは+1増えて4ステージになりました。#includeは単に外部ファイルを 同一ファイルとしてコンパイルできる普通の機能です。でも、その為にライン数管理が ファイル名+ライン数になってその部分が全体的改造に。 　本当は、一通り終わるまで新機能は入れないつもりでしたが、チョコチョコ変えている 時点で、もう全体変更しようと思ってしまった。

世間では連休で私も会社は休みだったはずですが何かとどたばたしてまして お返事が遅れましてすみません。 >　ちなみに、test.dkmで最高6800ぐらいnewします。 これで速度低下しないかと心配して、crowbarやDiksamではMEMモジュールを作って MEM_storage_malloc()を使ったのですが、C++でクラスを使おうとすると単純に 置き換えはできませんね(newのオーバーロードで置き換えはできますが、私には、 演算子のオーバーロード自体相当に腰が引けます。boostのように、汎用的で 一般的に知られたライブラリを使うのなら、だいぶ軽減されると思いますけど)。 ところで、DiksamをC++で書き直し、fix_tree.cppでたくさんnewが起きるということは、 DiksamでのExpressionやStatementの構造体をクラスにしておられるのだと思いますが、 これはやっぱり、fix_tree.cppではfix()、generate.cppではgenerate()という メンバ関数を作って、クラスごとにポリモルフィズムで呼び出しているのでしょうか? オブジェクト指向の教科書にはそう書いてありますが、実際にやってみると クラスごとに細かい制御ができなかったりモデルにロジックが侵食したりして あまりうまくいかない、と経験上思っておりますので。

　fix_treeのところで多少手間取っていますが一応終了。トータルの結合 試験で多分たくさんのがバグが･･･ 　少し長いプログラムを読み込ませるだけで、細かいサイズのメモリーを ７千ぐらい、newとdeleteしているのを見るにつけ、これは結構システムに 負担ではないと思いつつ、区切りが出来たらboostの高速メモリー管理poolに 変えようとかと考えています。一括削除が可能だし。また、メモリー上のトラ ブルが起こったら追うだけでも大変だと思う、今のところそのトラブルには 遭遇していないのが救いです。バグは当たり前のようにありますが･･･ 　ちなみに、test.dkmで最高6800ぐらいnewします。 　特に新しいところがなく日記的なので、不要だったら削除してください。

>Diksam ver.0.4以降だと、ファイルをrequireしておけば、 >呼ぶ際は普通の関数呼び出しですけれど、 そうなんですか、同じものを再発明しそうですね。 >Emacs Lispはダイナミックロードですが、私としては初回呼び出しのタイムラグは >気にならないと思っているので、まあ問題ないと思っているのですけれども。 私の場合、スレッドが必要だと思うほどクリティカルな部分を意識しているので やはり、利用者がコンパイラ起動を意識したほうがいいかなと思っています。 >ということはDVMはひとつでグローバル変数とヒープ領域は共有ですね。 >結構ロックが大変そうな気はします。 　この辺はまだ希望的観測の部分が多いので、実際に作りこんでみないと なんともいえない感じです。 　今現在はfix_tree部分を作っていますが、途中でnew、deleteが頻発するので 思わず。new、deleteに被せて、newのアドレスとサイズをコンテナMAPに総て入れ、 deleteで検証する監視プログラムやサポ－トプログラムばかり作ってて脱線気味 です。目的プログラム70%残り30%は監視やデバックプログラムです･･･ 文字列リテラルも、wchar_tを使ってもポータビリティーが上がらないのでstring に変えてしまったし、diksam言語部分だけでも一通り動くようになるのはまだまだ 先です。

>　言語仕様から見ると、Aプログラムの内部からBファイル内にある関数B1を普通に >コールすることです。当初は、ファイル名.関数名();で起動しようか、関数プロ >タイプ宣言で"ファイル名":関数名();で内部的には普通の関数記述と思いましたが。 Diksam ver.0.4以降だと、ファイルをrequireしておけば、 呼ぶ際は普通の関数呼び出しですけれど、 >いつ重いコンパイラが走るかコントロール出来ないので、 .dkhにシグニチャ宣言だけ書いて.dkmに実装を書くと、関数呼び出し時にコンパイラが 動きますから、状況によって問題になるかもしれません(実装まで.dkhに書いてしまえば いいわけですけど)。 Emacs Lispはダイナミックロードですが、私としては初回呼び出しのタイムラグは 気にならないと思っているので、まあ問題ないと思っているのですけれども。 >スレッド起動の仕様 >普通に関数名(P1,,,Pn);を書くと戻ってくるまでコール元は待ちます。 >start(関数名,起動P,,,Pn);と書くとスレッド起動となります。 ということはDVMはひとつでグローバル変数とヒープ領域は共有ですね。 結構ロックが大変そうな気はします。

>これは、CからDiksamの関数を関数名を指定して呼び出すということですよね。 内部的に見るとそうです。 　言語仕様から見ると、Aプログラムの内部からBファイル内にある関数B1を普通に コールすることです。当初は、ファイル名.関数名();で起動しようか、関数プロ タイプ宣言で"ファイル名":関数名();で内部的には普通の関数記述と思いましたが。 いつ重いコンパイラが走るかコントロール出来ないので、プログラムファイル読込 み関数と破棄関数(中間コードリソースの破棄)を作ることにしました。 　この仕様でVMの変更が発生します。それは、1ファイル内の関数コールはコンパ イラで関数アドレスを生成しますが。ファイル外の場合、関数アドレスではなく関 数名を持って、実行時リンクして関数コールする仕様が追加になります。 （最外枠ブロックの実行構文はなくなり、ファイル名起動ではmain()が実行） 中間コードの構造は。 親　ファイル１　　ﾌｧｲﾙ親ー＞子　　　　ファイルｎ ↓　　　｜－－－－－－－－－－￢　　　　｜－－－－－－－－－－￢ 子　　　関数１　・・・・・・　関数ｎ　　関数１　・・・・・・　関数ｎ 　の様に、階層構造の親子関係で関数置きに分離した中間コードになる予定です。 この、ファイルｎの部分が必要時にコンパイルされ中間コードに追加される感じです。 　この構造はちょうど関数単位のマルチスレッドに適応できます。 スレッド起動の仕様 普通に関数名(P1,,,Pn);を書くと戻ってくるまでコール元は待ちます。 start(関数名,起動P,,,Pn);と書くとスレッド起動となります。 例 　　thread_ID1 = start(fnc1,,,); 　　thread_ID2 = start(fnc1,,,); 　　thread_ID3 = start(fnc1,,,); と書くとメインスレッドと3つのfnc1スレッドが同時に動きます。 関数については、この様な仕様を組込みたいと考えています。 また、グローバルシステム変数とスレッド起動された関数は一般的なCのグローバ ル変数やスレッドとは、かなり性格が違ったものになります。でも、この点は実物 のめどが出来そうなときにでも、評価していただければ嬉しいと思っています。

訂正します。 >と思って見ていたらbaseが初期化されていない >ことに気付きました。またバグです。すみません (_o_) いくらなんでもこれじゃ動かないよな、と思ってよく考えると baseはローカル変数の参照に使うので関数内でしか使用されず、 関数を読んだ際にセットされるので問題ありませんでした。

>追加したい機能 >・関数指定起動、スクリプトファイル名と関数名を指定して起動 >　（スクリプトファイル間の連携したプログラミングのために） これは、CからDiksamの関数を関数名を指定して呼び出すということですよね。 特定の関数を実行するには、dvm/execute.cのexecute()関数を、 http://kmaebashi.com/programmer/devlang/diksam_src_0_2/S/18.html#544 ・事前にdvmのcurrent_executableとcurrent_functionとpcを設定して 　(プログラムカウンタは関数ごとなのでpcは0に設定)、 ・execute()関数を、適切な引数で呼び出す ことで可能なはずです。 ただ、実際にはDiksamからネイティブ関数を呼び出して そのネイティブ関数からさらにDiksamの関数を呼び出す、というケースも あるので、スタックポインタを設定の上、execute()関数のローカル変数 baseも引数で渡してやらないと… と思って見ていたらbaseが初期化されていない ことに気付きました。またバグです。すみません (_o_) gccの-Wallでは当てにならないですし、山さんがされたようにVisual Studioでも コンパイルしたいのですがなかなか時間が取れない状態です。明日からは連休ですが、 連休は連休でまた色々と… 編集さんはゲラを発送されたとのことですし(ん?) >その結果、diksam0.2.0の系譜をもつ別の言語になってしまいます。 >なので、言語名は別のものになります。そこでお聞きしたいので >す。diksam0.2.0の系譜をもつ別のものを作ることになりましたが、 >ここでお話しすることは可能でしょうか？ まったく問題ありません。 >　ぶちゃけて言います。気分を害したりしませんか？＞＜ それはないです(^^) Diksamベースで新しい言語ができるのであれば、 どこをどう直されるのか興味深いです。

　各種機能を追加しようとdiksam0.2.0を解析修正をトライしていましたが、メモリ破壊トラブル に数回遭遇しメモリーダンプ解析を行う状態になってしまいました。さすがにこれは私の手に負え る状態ではないと感じ、diksam0.2.0を元にＯＯで新たに言語を作るほうが早いと思い、現在作成し ています。今は構文解析ツリーの生成まで終了しています。 ちなみに、yaccはkmyaccを使用、lex部分は自作です。 追加したい機能 ・グローバルシステム変数への透過的アクセス ・関数指定起動、スクリプトファイル名と関数名を指定して起動 　（スクリプトファイル間の連携したプログラミングのために） ・関数単位でのスレッドセーフなマルチスレッド起動 ・関数単位でのスレッドセーフな通信 ・#define構文の追加（別名定義のみ） 　等の、APとして必要な要件を組み込む必要がありました。その結果、diksam0.2.0の系譜をもつ 別の言語になってしまいます。なので、言語名は別のものになります。そこでお聞きしたいので す。diksam0.2.0の系譜をもつ別のものを作ることになりましたが、ここでお話しすることは可能 でしょうか？ 　ぶちゃけて言います。気分を害したりしませんか？＞＜

>ちなみにlex.zz.cを見ればわかりますが >トークンを漢字に変えると、なでしこのようにすぐになってしまいます。 それだけだと、ぴゅう太の日本語BASICとか http://labs.yaneu.com/20090401/ 年刊Ah!SKI第1号のアレみたいなのになりそうです。 トシがばれますねえ。

>ただ、書くのはともかく、読むほうは「あそこまで日本語化」したほうが >よいというニーズはあるかと思います。 なでしこのHP見に行きましたが、結構すごいことになっていますね。 私のイメージが古かった。ちなみにlex.zz.cを見ればわかりますが トークンを漢字に変えると、なでしこのようにすぐになってしまいます。 それが良いか悪いかは別の話ですが。 　言語の意味合いをもう少し膨らませて、len.zzで「if」と「もし」を同じ 意味にして、プログラムを日本語変換するソフトを作ると･･･ 日本語英語両用自由自在のなでしこをこ･･･　げほんげほん 　今は目的を先に

>なでしこは知っていますが、あそこまで日本語化するのは反対の立場です。 確かに。わかります (^^; ただ、書くのはともかく、読むほうは「あそこまで日本語化」したほうが よいというニーズはあるかと思います。 >>よろしければPXU00211@nifty.ne.jpまで送付ください。 >送りました。内容はメールにて書いています。 受け取りました。ありがとうございます。 さっそく購入以来数度しか使っていないVisual Studio2005でビルドしてみました。 includeパスが絶対指定されていましたが、相対に直したらビルドできました。 >>(例外処理機構がないため)exit()以外に選択肢がなく、実用上問題が出るかも >>しれません。 >この辺が今の課題の一つです、 ver.0.4系だと例外処理機構があるのですが、ビルドが難航しているわけですよね。 >手を着けていないものに、「初期値が設定されていない変数が使われています」が >数十出ています。 これがそんなに出るようではいけないわけですが… こちらでも調べてみたほうがよさそうです。 >コンパイラも何かあるとexitで落ちてしまいます。 ダイナミックリンクである以上確かにこれも問題です。 実用に使い始める前にコンパイルエラーぐらいは取ってくれるだろう、と思うので、 優先度は下げているのですけれども。

ご返答ありがとうございます。 　う～～ん、ある程度予測をして、場所を下に移すも等いろいろやってはいたのですが･･･ 　うまく動かずにここに書き込みました。しかし、いまだにdiksam4.0.3はトラブル で落ちてしまいます。VC++への移植にミスがあると思うのですが。エラーが数百近く 出たのを端からつぶしていったのに問題があるのかもしれません、いまだにワーニン グエラーはたくさん残っています。手を着けていないものに、「初期値が設定されて いない変数が使われています」が数十出ています。対処しないといけないのですがい まだにそこまでは。 　やはり、4.0は一時保留にして、いまは2.0で問題なく動いています。2.0ソースの 拡張子を.cから.cppに総て変えて、ワーニングも総てつぶして、diksam内部からclass を扱えるようにしました。私が使用しているデバッククラスも使えるようになったの で、多少楽になりました。

>１．argcの中身は初期化されていません。 これは明らかにおかしいですね。ご指摘ありがとうございます。 argcによる判定は、parse_parameter()実行後に行うべきことです。 今までは偶然動いてしまっていたようです…… >２．GetCommandLine();は何もやっていない･･･ GetCommandLine()はコマンドライン引数を取得するWindowsの関数です。 http://msdn.microsoft.com/ja-jp/library/cc429108.aspx これの戻り値はワイド文字列なので、 >３．DVM_wcstombs(command_line_wc);のcommand_line_wcはアドレスなのですが･･･ DVM_wcstombs()により、マルチバイト文字列に変換し、parse_parameter()で 引数列に分解しています。

再度、diksam0.4.03のコンパイルを試していますが。 どう見てもWinmMainがおかしいように思います。 WINAPI WinMain(HINSTANCE hInstance , HINSTANCE hPrevInstance , PSTR lpCmdLine , int nCmdShow ) { DKC_Compiler *compiler; FILE *fp; DVM_ExecutableList *list; DVM_VirtualMachine *dvm; int argc; char **argv; DVM_Char *command_line_wc; char *command_line_mb; if (argc < 2) { fprintf(stderr, "usage:%s filename arg1, arg2, ...", argv[0]); exit(1); } command_line_wc = GetCommandLine(); command_line_mb = DVM_wcstombs(command_line_wc); argv = parse_parameter(command_line_mb, &argc); MEM_free(command_line_mb); １．argcの中身は初期化されていません。 ２．GetCommandLine();は何もやっていない･･･ ３．DVM_wcstombs(command_line_wc);のcommand_line_wcはアドレスなのですが･･･ やはり、私には手に余りそうです。何をしたいのかわからないので対処が出来そうに ありません。

追記、ソースはタブ4スペースできれいに見えます。タブ８だとがたがたに･･･ 上に出したソースもがたがただった。

>ご存知かと思いますが、日本語プログラミング言語としては「なでしこ」が有名です。 >http://nadesi.com/ なでしこは知っていますが、あそこまで日本語化するのは反対の立場です。わざと やっているのではないかと思うぐらい読みづらいです。日本語の中にも和製英語が かなりたくさん入っています。それが当たり前に使われている現状を考えてみるに、- なでしこは、古文を読むような感じで現代的では有りません。日本語プログラミン グにおいても、和英混合で問題がないと私は思っています。 >よろしければPXU00211@nifty.ne.jpまで送付ください。 送りました。内容はメールにて書いています。 >http://kmaebashi.com/programmer/devlang/diksam_src_0_1_01/S/20.html ありがとうございます。意外と簡単に組み込めそうです。 >(例外処理機構がないため)exit()以外に選択肢がなく、実用上問題が出るかも >しれません。 この辺が今の課題の一つです、コンパイラも何かあるとexitで落ちてしまいます。 堅牢なシステムを作る予定なのでこの改善が必要です。

>うわぁ、これはなかなか破壊力がありますね。ずっと半角英数でプログラムを書いてきた >ロートルな私などからするとかなり違和感がありますが、メールとかで「Ｗinｄｏｗs」 >みたいに書くおじさんは実際いましたから、需要はあるかもしれません。 >ていうかプロポーショナルフォントのおかげで全角と半角の区別がつきにくくなったのは >よいことなのか悪いことなのか… 投稿後にちょっと考えたのですが、 私の世代の感覚からすると、全角英数字と半角英数字の区別がつかないのは コンピュータリテラシの欠けたおっさんであり、そもそも全角英数字なんか いらんだろ、ぐらいに思っているのですが、 そんなふうに思うこと自体、端境期のおっさんの戯言かもしれませんねえ。 http://onisci.com/802.html

>　下記のような半角全角入り混じったようなプログラムも意味的に言語仕様と有って >いれば動くようになりました。 うわぁ、これはなかなか破壊力がありますね。ずっと半角英数でプログラムを書いてきた ロートルな私などからするとかなり違和感がありますが、メールとかで「Ｗinｄｏｗs」 みたいに書くおじさんは実際いましたから、需要はあるかもしれません。 ていうかプロポーショナルフォントのおかげで全角と半角の区別がつきにくくなったのは よいことなのか悪いことなのか… そういえば、失敗プロジェクトとして名高い「Σプロジェクト」はUNIXベースのOSだった のですが、全角で「ｌｓ」とか書いても通ったという話を聞いたことがあります。 裏は取っていませんが。 なお、せっかくの(数少ない)Diskamユーザをなくしたくはないですし有名なので ご存知かと思いますが、日本語プログラミング言語としては「なでしこ」が有名です。 http://nadesi.com/ >ソース必要でしたらVCのソリューションごと送りましょうか？ 私はロートルプログラマなので本体に取り込むことはないと思いますが、 一般公開してよいものでしたら、興味を持つ方がいるかもしれません。 よろしければPXU00211@nifty.ne.jpまで送付ください。 >　次は関数の組み込みおよびVMのスレッドセーフ化かな。関数の組み込みの仕方を >習得したら、本格的にdiksamを組み込んだアプリケーションの作成に入れます。 ネイティブ関数の自作についてであれば、dvm/native.cが参考になるかと思います。 http://kmaebashi.com/programmer/devlang/diksam_src_0_1_01/S/20.html ただ、ver.0.1ベースだと、引数に変な値が渡されたりしたときに (例外処理機構がないため)exit()以外に選択肢がなく、実用上問題が出るかも しれません。

　下記のような半角全角入り混じったようなプログラムも意味的に言語仕様と有って いれば動くようになりました。もちろん総て全角で書いても動きます。付属の test.dkmも問題なく動作しました。 ------------------------------------------------- int print (string str); string　今時； ｉｎｔ　時間； 　今時＝"朝";　挨拶(今時); 　今時＝"昼";　挨拶(今時); 　今時＝"夜";　挨拶(今時); 　今時＝"わからん";　挨拶(今時); int 挨拶(ｓｔｒｉｎｇ　今　) { print("パラメータ　今＝"　+　今　＋　"\n"); ｉｆ(今＝＝"朝") 　{　print("------ おはようございます\n"); }elsif(今＝="昼") 　{　print("------ こんにちは\n"); }eｌｓif(今=="夜") 　{　print(”------ こんばんは￥ｎ”); }else 　{　ｐｒｉｎｔ　（　"------ おいすー\n"　）　；　 } } ---（注：デバック用に故意に半角全角入り乱れています）------------- lex部分を独自に書くことで問題がないようです。ソース必要でしたらVCのソリュー ションごと送りましょうか？ VC++2005で書かれてSJIS専用になっています。またdiksam1.0対応のみです。 　次は関数の組み込みおよびVMのスレッドセーフ化かな。関数の組み込みの仕方を 習得したら、本格的にdiksamを組み込んだアプリケーションの作成に入れます。

>これなんですが、「誰にとって」簡単であることを目指しているのでしょうか。 　う～～ん、正直言いまして、私の方法論もいいのか悪いのか、わからない結果となりました。やっぱり聞いてみて正解です。したがってアプリがある程度で来た時点で両方を実装して実際に使ってみてから判断がよさそうであると考えました。だいぶ先になるかもしれませんが、実装して使ってみて感想・批評・訂正・修正・駄目押し、ぜひよろしくお願いします。 　この他にも、いろいろ、単純に出来るのではないかと構想しています。なにぶん逆の目から見た発想なので実際に実装してみるまでは評価は難しいのかもしれません。複雑なことを意識せずに複雑な操作をプログラムするアプリケーションなので、お暇がありましたらお付き合いください。特に言語の構造に深くかかわる可能性もあります。よろしくお願いいたします。 　また、現在字句解析が７割ほどかけました。書き終わった後接続試験です。ifもｉｆも10も１０も12３４00も受け付ける字句解析は結構大変です。漢字を受け付ける以上、10と１０は同じ意味なのでやはり数字リテラルとして処理しなければ^^;

>私の目的は、最も簡単な方法だけを提供しそれ以上のことは出来ない、 >知らなくていい、とても初期の段階のプログラミングを想定しています。 これなんですが、「誰にとって」簡単であることを目指しているのでしょうか。 VMを作る山さんの立場からすれば、ネイティブスレッドを相手に共有変数の整合性を 保持しようと思ったら、結局、セマフォというかミューッテクスによるロックが 必要であるように思います。 それにより、個々の変数が任意の時点で正しい値を持つことが保証されるなら、 アプリケーションを作成するユーザの立場からすれば、困らないように思います。 あるいはもし、複数の変数の整合性まで保証しなければならないのであれば (たとえば点の座標をx, yのふたつの共有変数で持つとき、点を(10, 10)から (20, 20)に移動させる際、(10, 20)のようなハンパな状態を見せてはいけないとか)、 これはトランザクションになりますから、トランザクションの終了を宣言する 方法が必要になると思うのですが…… >それは「Diksam言語仕様自体が複雑ではないのか？」と、実は利用者に説明するのは、 >関数と計算式とif,thin,elseif,else,while,continue,break。以外は使わないようにと >説明します。 そうそう、この程度の機能でも、組み込み言語が使えれば便利な局面は多々ありますよね。 Diksamやcrowbarは少なからずこういう用途を想定しているので、使っていただけることは 作者としては嬉しいです。

>新プログラミング言語「BF-BASIC（ここの上カンマ）n」 >上の（ここの上カンマ）の半角記号があると書き込めませんでした。 えっ? ……これはつまりSQLインジェクションが可能なわけで、重大なセキュリティー ホールです。修正しました。ご指摘ありがとうございました。 以下、経緯です。 この掲示板は、↓の注記とか、 http://kmaebashi.com/programmer/bbs_dev/index.html こことかにも書いたとおり、 http://kmaebashi.com/programmer/bbs_dev/newbbs.html PHPのmagic quotesの機能を使用しています。 そして、私が借りているレンタルサーバでは、magic quotesはずっとonに なっていました。 少なくとも今年の1月の時点でシングルクオートを含む投稿に成功しています。 http://kmaebashi.com/bbs/list.php?boardid=kmaebashibbs&from=1195&range=1 これがいつの間にかoffにされていたようです。 http://kmaebashi.com/test.php サーバ業者からのお知らせはなかったと思います。以前、PHPを5に上げるという 連絡はありましたがそれもなんだかうやむやになったような(現に今、4で動いてますし)。 # もちろんそれ自体、私を含めてちょっとどうかという話ではありますが。 magic quotesについては、私自身やり方として間違ってるよなあと思いつつ、 郷に入れば郷に従え精神で利用「してしまった」わけですが、当時の私が無知で バカでアホで軽率であったことは認めるとしても、それを前提としたスクリプトは たくさんあるはずで、告知なしにoffにされてはたまったものではないです。 ここはJoe'sウェブホスティングから借りていて、今までさほど大きな問題は なかったと思うのですが、今回の件で過去最大の不信感を持ちました。 ご指摘ありがとうございました。重ねて御礼いたします > 山さん

SQL障害のため書き込めませんでした、どの部分が問題か調べるために2度のテスト書き込みと削除をしています。お騒がせして申し訳ありません。障害点は下記の部分。 新プログラミング言語「BF-BASIC（ここの上カンマ）n」 上の（ここの上カンマ）の半角記号があると書き込めませんでした。 お騒がせしました。

説明不足で申し訳ありません。 >だとすると、配列やオブジェクトのような参照型ではどうなるのでしょう。 配列やオブジェクトのような参照渡しはしないです。と言うかその点をまったく説明していませんでした。非同期の単一のデーターのみを対象にしていす。複数のデータを渡したい場合は、string変数に、","区切りでと考えていました。申し訳ありません。もちろん、パラメータを簡単に構築分解する関数を用意します。非同期渡しなので、送るほうが３回変数を書き換えても、受けは１回か２回しか読めない場合もあります。もし間違いなく渡したい場合は、スレッドセーフなキューシステムを、完全な同期をしたい場合は、それ様のシステムがいりますが。私の目的は、最も簡単な方法だけを提供しそれ以上のことは出来ない、知らなくていい、とても初期の段階のプログラミングを想定しています。 C++熟練者にとっては、最小高速なセマフォーがあればほぼ何でも出来ます。しかしプログラム間で正しく通信するための必要知識は膨大なものが必要です。（それを補間するために、いろいろなライブラリーが作られているが、それがまた複雑さを･･･） まさに「新プログラミング言語「BF-BASIC n」を作ろう」的な構想のアプリケーションです。だから、スレッドセーフな最小限の一方通行情報伝達だけを意識せずに提供できればいいのではないだろうか？との発想で書いています。これで本当に足りるのかは、アプリがある程度出来てこない事には想像がつきません。 決まり事を極力最小にして、複雑さはシステムで吸収できるよう設計したい。そんな目標が有ります。ここで１つ疑問が沸くと思います。それは「Diksam言語仕様自体が複雑ではないのか？」と、実は利用者に説明するのは、関数と計算式とif,thin,elseif,else,while,continue,break。以外は使わないようにと説明します。それ以外は、トラブルがあっても自分で対処回避できる人のみ「Diksam言語仕様」を見てくださいと言う予定です。 　当初は独自で言語を作りはじめましたが、「俺が作りたいのは言語じゃない！！！」との思いが強くなり。いろいろなコンパイラーやインタープリタを調査した結果、Diksamに当たりました。特にしっかりとした言語仕様とVM部分がいいです。この上で複雑さをどれだけ吸収出来るものが作れるのか、がんばってみたいです。 　まだまだ説明不足な点が多々あると思いますが、懲りずによろしくお願いいたします。 >>もっと簡単にしてグローバルは１VM内でのみ有効であるとして、 >>VM間変数と言う特殊な変数を作って、セマフォー処理をしてもいいと思う。 >山さんの投稿を見て私が最初にイメージしたのはこれだったのですが… はい、これがあれば一般的なプログラミングが可能です。しかし複雑な制御知識が必要になってしまいます。なのであえて上記のようなシステムを考えています。 >「変数の値取得用の関数」 変数の形をした、まさにこれなんです。説明不足申し訳ありません。ただ、関数にしてしまうと何度も読んでしまうミスを防げないので、あえて１回のみとしてシステム側で制限を加えたわけです。なぜこうしたかは、出来るだけ問題点をシステム側で見つけ出せるか？（目標）です。

>４．2回目を読みたい時は、変数更新の関数を呼びまた1回のみ読める。 あ、この「変数更新の関数」を呼んでから、変数を読み出すまでの間、 配布元VMでは変数の変更を禁止する(待つ)、ということでしょうか? だとすれば、余計な処理を間に挟めないように、「変数の値取得用の関数」を 用意したほうがよさそうにも思いますが…

>以下が私の考える見えない排他制御です すみません、いまいちよくわかりません。 まず前提として、山さんの案では、複数のVMが、別々のネイティブスレッドで 動作するんですよね? だとしたら、いずれにせよ共有の変数を読み書きする際は きっちりスレッド間でロックの取り合いをしなければならないわけで、この案で どこが簡素化できるのかがどうもよくわからないです。 >１．システム変数は1つのVMのみ読み書きが出来る、配布元VMとする。 また、この「システム変数」は、ユーザプログラムがこれを利用して同期を取るための ものではなく、まさにユーザプログラムがデータとして共有したいものなんですよね? だとすると、配列やオブジェクトのような参照型ではどうなるのでしょう。 int[] a = {1, 2, 3, 4}; という配列を共有したかったとして、 int[] tmp = a; // aを1回だけ読み出し 以後、tmp経由で配列aの中身は触り放題なわけですが、これでよいのでしょうか? >もっと簡単にしてグローバルは１VM内でのみ有効であるとして、 >VM間変数と言う特殊な変数を作って、セマフォー処理をしてもいいと思う。 山さんの投稿を見て私が最初にイメージしたのはこれだったのですが…