なでしこ２のイベントの実行方法の案

[うぇいく]

なでしこ２でのイベントをどうするかちょっと考えてました。

　なでしこ２では、トークンナイズ、パース、コンパイル、ランが、結構明確に分かれていて、機能もそれぞれ順に呼び出すことが可能です。
そこで以下の２つをInterpretorから公開することで、イベント(ユーザ定義関数)を呼び出せないかなぁ　と考えてます。
・指定したコードを実行するMethod(Run_NakoIL相当)
・指定した関数名(ラベル?)のオフセットを取得するMethod。

　実行するコードは、個別にパースさせても良いし、CodeILのコンストラクタで直接生成するのでも良さそうです。
　インタプリタでオフセットの解決可能なラベルは、イベント用として定義した関数だけでも良いかもしれません。
（通常のDLLでいうところの、dllexportしているもののみ　のような）
　引数も簡単に生成できるとよいんですが、なでしこ１でも、イベントの引数はあまり利用されてなかったようなので、無ければないなりに何とかなるかもしれません。
スタックフレームの生成が必要かどうかまでは読み切れませんでした。

あと、イベントで気になるのは、GUI系のイベント実行中(呼び出されたイベント関数の途中)で、Windowsイベントを受信した場合の扱いです。イベントの呼び出しを遅延させて再入禁止にできると使う側は楽な気がします。

余談。
　なでしこ2のWPF版(wnako)は、とりあえず、あまりソースを変更せずに、なでしこ１でも、動くようにしたりして遊んでいます。
なでしこ１なら、グループやらイベントやらでWPFとしてもまとめられそうなのですが、managed/unmanagedを何度も往復するので、実用には耐え無さそうなため、なでしこ２版と同様に、べた命令のイベント無しで仮組した感じです。

[Mineaki SAKATOKU]

クジラ飛行机です。

うぇいくさん、いろいろ見てくださってありがとうございます。

お返事が遅くなりました。

　なでしこ２では、トークンナイズ、パース、コンパイル、ランが、結構明確に分かれていて、機能もそれぞれ順に呼び出すことが可能です。

本来は、EXE自体もコンパイラとインタプリタを分けようと思ったのですが、なかなか、そこまでは出来ていません。

 

そこで以下の２つをInterpretorから公開することで、イベント(ユーザ定義関数)を呼び出せないかなぁ　と考えてます。
・指定したコードを実行するMethod(Run_NakoIL相当)
・指定した関数名(ラベル?)のオフセットを取得するMethod。

そうですね。これらは、早いうちに実装したいですね。

あと、イベントで気になるのは、GUI系のイベント実行中(呼び出されたイベント関数の途中)で、Windowsイベントを受信した場合の扱いです。イベントの呼び出しを遅延させて再入禁止にできると使う側は楽な気がします。

確かに。.NET系では重要になりますね。

　なでしこ2のWPF版(wnako)は、とりあえず、あまりソースを変更せずに、なでしこ１でも、動くようにしたりして遊んでいます。

おぉ、凄いですね−。

そうした成果が特定用途向けであっても、何かに使えるといいですね。

なかなか、進まないなでしこ２ですが、

こうして、何かしら少しずつ進んでいくといいですよね。

皆さんの協力に感謝です！

 

　実行するコードは、個別にパースさせても良いし、CodeILのコンストラクタで直接生成するのでも良さそうです。
　インタプリタでオフセットの解決可能なラベルは、イベント用として定義した関数だけでも良いかもしれません。
（通常のDLLでいうところの、dllexportしているもののみ　のような）
　引数も簡単に生成できるとよいんですが、なでしこ１でも、イベントの引数はあまり利用されてなかったようなので、無ければないなりに何とかなるかもしれません。
スタックフレームの生成が必要かどうかまでは読み切れませんでした。

あと、イベントで気になるのは、GUI系のイベント実行中(呼び出されたイベント関数の途中)で、Windowsイベントを受信した場合の扱いです。イベントの呼び出しを遅延させて再入禁止にできると使う側は楽な気がします。

余談。
　なでしこ2のWPF版(wnako)は、とりあえず、あまりソースを変更せずに、なでしこ１でも、動くようにしたりして遊んでいます。
なでしこ１なら、グループやらイベントやらでWPFとしてもまとめられそうなのですが、managed/unmanagedを何度も往復するので、実用には耐え無さそうなため、なでしこ２版と同様に、べた命令のイベント無しで仮組した感じです。

--
このメールは Google グループのグループ「日本語プログラミング言語「なでしこ」開発」に登録しているユーザーに送られています。
このグループから退会し、グループからのメールの配信を停止するには nadesiko-dev...@googlegroups.com にメールを送信してください。
その他のオプションについては https://groups.google.com/d/optout にアクセスしてください。

--
-----------------------------------------
Mineaki SAKATOKU (酒徳峰章 - クジラ飛行机)
mailto: w...@kujirahand.com
website: http://kujirahand.com/

[うぇいく]

関数をイベントとして実行時に動的に呼び出しそうとする場合、ILコードに関数名-オフセットの一覧も付けてしまうほうが良い気がしてきました。.実行コード＋Exprtしたシンボルの一覧という構成になるので、立ち位置的には、.objのような感じでしょうか。
（そして、今の実行は、.comふぁいるみたいなもの　と）
この考えを進めると、コンパイル済みILコードを相互に呼び出すこともできるのかもしれません（「取り込む」とはちょっと方向ですが）でも、これにはコンパイル時に未解決のシンボルもテーブルに要りますね・・・

2014年7月7日月曜日 17時24分33秒 UTC+9 酒徳峰章:

[うぇいく]

手元で、とりあえず以下のようにしてみました。
・Compilerから関数のエントリポイント(関数名とIP)の一覧を取得するpropertyを追加。
・interpreterにそれをセットするpropertyを追加。
・InterpretorにRunEvent(String)というMehodから関数(引数なし、復帰値無し)を呼び出せるように追加。
そして、WPFのイベントからRunEventを使ってイベントが戻るようにしてみました。
綺麗ではないけど、とりあえず呼べる　と。
（cnakoではイベントを使いようが無いので、現時点のプロジェクトに組み込む意味は薄いです）

2014年8月7日木曜日 0時01分24秒 UTC+9 うぇいく:

[うぇいく]

イベント実装しても、あまりパッとしなかったのですが、その後、TextBoxを実装したら、なにかいろいろできそうな気がしていました（たぶん、気のせい）
なので、edit.nako相当を動かすというのをターゲットにして試行錯誤中です。
（test_editor.nako がそれです）
各GUI環境にて、TEditor相当のような部品を探すのが大変そう(WPFは、avaronEditがよいっぽい）

いまのところ、いかが課題です。
・エラーの補足。
　OSからのコールバックからイベントを呼んだ場合、イベント処理中のエラーは、コールバック関数を抜ける前に処理する必要があるっぽい。
　今は何もしていないため、アプリケーションエラーで落ちてしまい、エラーの詳細が分からない。
・「開く」にて、エンコーディングの"Auto"がうまくゆかない？Auto以外を指定しても、Autoがわたってしまっている？
　test_editor.nakoが、この理由でうまくゆかない・・・が、原因がよくわからない。

参考までに現時点でのソースを以下の置いておきます。

なでしこ２を展開したフォルダにwnako.exeを置いて、さらに、libnako.dllとnakoplugin.dllを上書きすると、実行できます。
（イベント実行のための改造部分を含むソースについては、該当ファイルのみ一緒に入れてあります）
//weyk.la.coocan.jp/files/wnako.zip

2014年8月7日木曜日 23時19分17秒 UTC+9 うぇいく:

[shige pon]

しげぽんです。うぇいくさん、なかなかイベント実行部を見れていないのですが、とても興味があります。

cnakoみたいなコンソールで動くものの場合も、ファイル変更を監視したい場合とかイベントがあるといいなと思うケースはあります。

＞・「開く」にて、エンコーディングの"Auto"がうまくゆかない？Auto以外を指定しても、Autoがわたってしまっている？

の件は昨日直してみましたので、再度お試し頂ければありがたいです。

2014年8月21日木曜日 23時24分13秒 UTC+9 うぇいく:

[うぇいく]

　wnako側のちまちま直していた部分を含めて、ファイルを差し替えました。
　いくつか、使えるコンポーネントが増えています。
　これ以上命令を増やすと収拾がつかなくなりそうな気もするので、GUI部品の扱いは難しいところです。
　なお、wxWidgetsとgtkとtcl/tkも様子をうかがってみたのですが、割とコンセプトが違うようで、同じ命令で切り替えたら動く　は無理っぽそうでした。
（特に、レイアウトマネージャー関係が違う。GUIのライブラリは絶対座標で用いて、レイアウト関連をなでしこ側で行うなら可能？）

イベントの処理部分ですが、いまのところ、関数の呼び出しと同じ構造をとっているため、必ず内側の呼び出しから解決してゆく必要があります。
また、他の命令の実行中ということは考慮していません（GUIの場合、単一のキューでのイベント駆動型となるため）
ちゃんと考えるなら、コールバックされるイベントごとに、独立した実行環境を持つ必要がありそうだなぁ　と思うのですが、そこまでくるとマルチスレッド対応と変わらなくなってしまうのでわきに置いといてます。

2014年9月30日火曜日 14時45分11秒 UTC+9 shige pon:

[うぇいく]

gtk#と、wx.NETで、edit.nako2が動く最低限の部分だけ実装してみました。
//weyk.la.coocan.jp/files/wnako2_gtk.zip
//weyk.la.coocan.jp/files/wnako2_wx.zip

どちらも、ボタン、メインメニュー、メモぐらいしかありません。
（gtkはレイアウト系のパネル(Box)がある。wxは該当するSizerは未実装）
また、それぞれのライブラリをインストールしたうえで、必要な設定(パスとか)を行う必要があります。

gtk#の方は、メモ部品の出来がちょっと及第点に届いていない感じです（Windowsだから？）
wx.NETの方は、wxPsotやWxSendが無く、wxTimerもないのでシングルスレッドでしか動かせず片手落ちというか、実用上は両手落ちな感じです。

gtk#は、gtk+自身がLinuxMaineなところが原因でMS-Windowsは貧弱なようです。
wx.NETについては、ベースとなるwxWidgetsはしっかりしているようなのですが、wx.NETが実験色の強いプロジェクトで一通りに実装が終わったところで開発も終了してしまっているようです。

GUIまで考えると、java+SWTや、C++ + wxWidgetsや、 Lazarus(FreePascal+LCL)という選択肢もありなのかもしれません。
（C++は、標準となるクラスライブラリが弱いので使いずらいのと、開発者向けにヘッダファイルを提供しないといけないのがわずらわしいですが）
C++とした場合、LinuxではGTK+もつかえるのですが、MS-WindowsではWPFが使えない(※)というデメリットもあります。
※MS-Wiindowsだけで考えるなら、C++/CLIという手がある。ただし、遅くなる。

2014年10月6日月曜日 1時07分40秒 UTC+9 うぇいく:

[うぇいく]

GUIについて、そこそこ動けばよいと考えた場合、最初に除外したWinFormsも選択肢に入ってくることに気が付きました。
（LinuxでのWinFormsの評判はわりと散々のようなので、除外してました）

そこで、とりあえず、edit.nako2だけ動くようにという必要最低限の部分だけ実装してみました。
//weyk.la.coocan.jp/files/wnako2_wf.zip

WinFormsは、レイアウト関連が、VCLに近い感じがしますね。MS-Windows上で試す限り、「ふつう」という感じです。
（Win32APIを直接使う場合のWindowsに１番近いはずなのであたりまえかとは思いますが）

どの環境でも,NETもしくはmonoがあれば追加のGUIランタイムがいらないというメリットを考えると、基本はWinFormsで良いのかもしれません。
Linuxでどんなもんなのか気になるところです。

2014年10月27日月曜日 22時16分27秒 UTC+9 うぇいく: