こんにちは。

SADですが、より発展させるためには、利用する人々を増やす、
他のいろいろなソフトウェアとの融合性を高める必要があって、
そのためには、今後、Python/JAVAなど、より利用頻度の高い
プログラム言語からSADを使用できるようにしたほうが
メリットがあると思うのですがいかがでしょうか？

SADをまだ本格的につかったことないので、素人意見ですが、いま、
いろいろなソフトウェア(mathematicaなど)が python を経由して
利用できるようになってきているので、SADソフトウェアも同様に
進展していくのが望ましいような気がします。

長い歴史があるので一筋縄ではいかないと思いますが、
少しづつでも、実現に向けて御一考頂けませんでしょうか？

ご意見のほど、何卒よろしくお願いいたします。

> SADですが、より発展させるためには、利用する人々を増やす、
> 他のいろいろなソフトウェアとの融合性を高める必要があって、
> そのためには、今後、Python/JAVAなど、より利用頻度の高い
> プログラム言語からSADを使用できるようにしたほうが
> メリットがあると思うのですがいかがでしょうか？
>
> SADをまだ本格的につかったことないので、素人意見ですが、いま、
> いろいろなソフトウェア(mathematicaなど)が python を経由して
> 利用できるようになってきているので、SADソフトウェアも同様に
> 進展していくのが望ましいような気がします。
>
> 長い歴史があるので一筋縄ではいかないと思いますが、
> 少しづつでも、実現に向けて御一考頂けませんでしょうか？
>
今でも、外部プロセスとして呼び出すことは出来ますよ

他言語から利用できる方が良いというのは、内部の APIを他の言語に
バインドしたいってことだと思うのですが、SAD開発者間でもきちんとした
内部APIの仕様書が無いというトホホな現状なので他言語にバインドした
ところで、外部のユーザーにはまず使えないと思うのですが？

あと、現状の主要な SADユーザーが SADScriptで満足してるとすると
開発側に需要を持っている人いないことに成る気がする
＃基本的に、少人数の目的ドリブンな開発ですから

P.S.1
歴史的経緯をたどるとその手の構想は、
- PySAD 山本氏による Python上にSADを乗せる構想
- SAD++ 大見氏による SAD + C++な構想
が有ったと思います。
最近だと、SADを JAVAで再実装しようという試みは、J-PARCで
JCEと呼ばれるコードが開発されてましたが、一般公開は無かったような

P.S.2
逆に、SADScript側から外部ライブラリを呼び出す インタフェースを作る
構想はあるのですが、あまり進んでません
問題は、外部ライブラリを呼び出す際に必要なスタック操作コードを
如何に移植性を保ったまま言語の標準仕様の中で実装するかが...
＃Fortran77 + ISO C Standardに入ればいいのだが

オブジェクトファイルの動的な読み込みは可能なので、外部のコンパイラの
助けを借りるという手は有りますが、コンパイラ等の開発環境を持たない
実行環境(商用Unix系など)では、使えないのが問題
＃動的読み込みも Sunが定義した dlopen APIを使っているので
＃厳密には移植性がありません
＃本当は、X.orgのmetrolink object loaderあたりを持ってくるべき？

どうも情報ありがとうございます。

> 今でも、外部プロセスとして呼び出すことは出来ますよ
>
> 他言語から利用できる方が良いというのは、内部の APIを他の言語に
> バインドしたいってことだと思うのですが、SAD開発者間でもきちんとした
> 内部APIの仕様書が無いというトホホな現状なので他言語にバインドした
> ところで、外部のユーザーにはまず使えないと思うのですが？
>
> あと、現状の主要な SADユーザーが SADScriptで満足してるとすると
> 開発側に需要を持っている人いないことに成る気がする
> ＃基本的に、少人数の目的ドリブンな開発ですから

現状をかんがみると、

1) Python/JAVAをベースとし、SADシミュレーションの
Input/OutputはFile I/O で処理してごまかす、

あるいは、妥協して、

2) SADをベースとし、Python/JAVA などのクラスを SAD用クラスに
変換して用いる、

というあたりが実現可能な解であるように察します。
(SADで押し通す 2) のほうがストレートフォワードでしょうが)

1), まだは 2) でやるとしても、使いやすくなるようなインターフェース
ができてくると嬉しいです。

> 現状をかんがみると、
>
> 1) Python/JAVAをベースとし、SADシミュレーションの
> Input/OutputはFile I/O で処理してごまかす、
>
> あるいは、妥協して、
>
> 2) SADをベースとし、Python/JAVA などのクラスを SAD用クラスに
> 変換して用いる、
>
> というあたりが実現可能な解であるように察します。
> (SADで押し通す 2) のほうがストレートフォワードでしょうが)
>
> 1), まだは 2) でやるとしても、使いやすくなるようなインターフェース
> ができてくると嬉しいです。
>
外部の処理系との連携機能を実装出来る出来ないという点では実装可能です
(SAD/Tkinterや EPICS Channel Access自体が外部ライブラリの呼び出しですし)
が、一般ユーザーが直感的に操作できるインターフェースを任意の処理系に対して
無矛盾かつ可搬的に構築するのは困難だと思います
＃ってか、誰がそんなすごいコードを書くんだ？

1)は、JCEでやってるという話を聞きました(シミュレーションエンジンが未実装のため)
というか加速器制御ではよくやってる(制御系から BATCH的に MADを呼び出すとか)と思います

2)の場合、実装を作る上での懸念材料は
o 設計思想の違う処理系間でのライブラリを外部呼び出しすると運用上の制限が多くなる
低レベルAPIをマップする場合は、それほどひどいことに成らないはずですが、移植先に無い
データ型をどう表現するかが腕の見せ所です
> ポインタの概念が無い言語に、Cのポインタを使った未知の関数をどうマップするかとか
o 設計思想の違う処理系からコードを移植すると、移植先の実装が歪なものになりやすい
> 手続き言語に関数言語の高階関数を使ったライブラリを素直に移植するのは難しい
> ISO Cスタンダードだけだと、関数言語で使う「関数のカリー化」はたぶん実装できない
o 持ってくるコードベースによってはライセンスが問題になる場合がある
特に GPLやCreative Commons等のコピーレフトとSAD本体のライセンスが共存できないため
ライブラリの形でリンクするとライセンスを満たせなくなります
（再実装の場合、クリーンルーム開発でないと、派生物扱いでオリジナルライセンスに縛られる恐れが）

実現する上では、設計・実装上のトレードオフがいろいろ有るわけで
開発者は自分の思想や美意識の中で美しくかつ実用的なものを目指すので、
内部の実装を理解してるものにとって使いやすいインターフェースが
一般にユーザーに分かりやすいかどうかは疑問があります。
したがって、一番重要なことは
「真にユーザーに使いやすいインターフェースを作るには
実際に使うユーザーが開発にかかわる必要がある 」
ということでは無いでしょうか？

ありがとうございます。

> したがって、一番重要なことは
> 「真にユーザーに使いやすいインターフェースを作るには
> 実際に使うユーザーが開発にかかわる必要がある 」
> ということでは無いでしょうか？

そうですね。なにかフィードバック(or 救援要請？）できるような
状況になったら、またご連絡さしあげます。

> > したがって、一番重要なことは
> > 「真にユーザーに使いやすいインターフェースを作るには
> > 実際に使うユーザーが開発にかかわる必要がある 」
> > ということでは無いでしょうか？
>
> そうですね。なにかフィードバック(or 救援要請？）できるような
> 状況になったら、またご連絡さしあげます。

思いつきですが、SADと Python/JAVA等を連携するために
EPICS I/O が使えそうです。少し考えてみます。　
(Re^2 の 1) に沿ったアイデアです。
EPICS I/OはSADシミュレーションのI/Oに使います)