LinuxアプリケーションにCLIPSを「固定」する方法

CLIPS(C言語統合生産システム)製品は、1984年にNASAプロジェクトのエキスパートシステムを開発するための環境として登場しました。 このプロジェクトが中断されたという事実にもかかわらず、開発者はこの環境を改善し続けました-最新のアップデートは2006年にリリースされました。



CLIPSは、CとC ++、およびJavaの両方で記述されたさまざまなアプリケーションへの統合を提供します。 興味深いことに、拡張プログラマーズガイドには、Windowsベースのアプリケーションの統合オプションが記載されていますが、Linuxベースのアプリケーションとの統合についての説明はありません。



論文を書く過程で、次の問題が発生しました:エキスパートシステムはLinuxのようなOSで実行する必要があり、エキスパートシステムを使用するメインアプリケーションは純粋なCで作成する必要がありました。 ECLIPSEで作成されました。 おそらく、この経験は誰かに役立つように思えるかもしれません。



まず、CLIPSは次の統合オプションを提供します[1]。



1.オープンソースを使用した統合。

オープンソースが存在するということは、プロジェクト全体を再コンパイルし、そのプロジェクトのすべてのソースファイルを「ピックアップ」する必要があることを意味します。その後、環境のすべての機能に直接アクセスする必要があります。 オプションが削除された理由は エキスパートシステムを接続することに加えて、リアルタイムで入力されたデータを処理することも必要でした。私は、一定の長いコンパイルに時間を費やしたくありませんでした。



2. DLLを使用した統合。

開発者が提供する主なオプションの1つであるマニュアルには、機能とその接続オプションの詳細な説明があります。 Windowsアプリケーションには最適なオプションですが、Linuxでの使用にはまったく適していません。



3.共有オブジェクトを使用した統合。

開発者は、リポジトリで利用可能なlibclips.soライブラリを慎重に収集しましたが、ドキュメントでは完全に忘れていました。 このオプションは実装に採用されましたが、いくつかの点で本当に後悔しました。



メイン関数「環境の作成」の例により、このライブラリをプログラムに接続するための最終アクションは、次のアルゴリズムで説明できます。



1.コマンドnm -D /usr/lib/libclips.so.2.0.0を使用して、ライブラリーにあるすべての関数のリストを取得します。 落とし穴は、このライブラリの一部の関数の名前がヘッダーファイルと一致しないことです。 たとえば、CreateEnvironment関数は__CreateEnvironmentとして記述されます。



2.ヘッダーファイルで、特定の関数の説明を探し、それをプログラムの型として定義します。

typedef void *(* CreateEnvironmentPtr)(void);



3.次に、このタイプの変数が決定されます。

CreateEnvironmentPtr __CreateEnvironment;



4. dlopenコマンドを使用したlibclips.soライブラリの標準接続の後、関数はライブラリからロードされます。

__CreateEnvironment =(CreateEnvironmentPtr)dlsym(dll_handle、 "CreateEnvironment");



5.ポインターが定義されます:

void * theEnv;

CLIPS環境が作成された助けを借りて:

theEnv = __CreateEnvironment();



エキスパートシステムの起動をロードするための標準アクションを実行した後、最終プログラムはエキスパートシステムのメカニズムを完全に使用します。 たとえば、図に示すように:







そのため、Linuxで記述されたアプリケーションでエキスパートシステム(およびエキスパートシステム自体)を作成するための環境を立ち上げました。



PSプログラムでは、CommandLoopコマンドを使用し、システムコマンドラインを実装して、制御を環境に完全に転送できます。



文学



1. CLIPSリファレンスマニュアル。 ボリュームII。 高度なプログラミングガイド。



All Articles