[thread display] [new arrival display] [word search] [past log] [管理用]
| Subject | ： Re: SADのPython/JAVA等からの利用について |
| Date | ： 2007/10/02(Tue) 17:03:55 |
| Contributor | ： AKio Morita |
> 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あたりを持ってくるべき？