[thread display] [new arrival display] [word search] [past log] [管理用]
| Subject | ： amorita branchの変更予定 |
| Date | ： 2008/01/11(Fri) 03:23:11 |
| Contributor | ： AKio Morita |
amorita branchでの変更予定や検討中or検討すべき開発項目などを掲示してみる
o SAD本体側に取り込んだ各種 framework用の header fileを dynamic loading module
コンパイル時に参照できるように、mk/sad.module.mkをアップデートする
- USE_FRAMEWORK/FRAMEWORK_HEADERS変数を導入予定
- mk/sad.framework.mkを新設か？
o 拡張モジュール等で実装している機能毎の version番号を検査する機構を実装する
- feature_provide(name, version)、feature_version(name)の実装(C用の framework)
- FeatureQ[]の実装(SADScript側からの検査関数)
- Version番号は uint32_t型、0は未実装と定義
- extensions/RandomMT/Framework等に feature_provide()を入れる
o extensions/RandomMT/Frameworkにて、カット無しのガウス分布をサポートする
- 各種Pluginも更新する
- Framework versionを上げる
o 既存の Date[], ToDate[], FromDate[], DateString[], FromDateString[], Day[]を外す
- DateTAI拡張モジュールを SAD本体に取り込む予定
- 閏秒をサポートする場合には、FromDate[]の返り値(SAD epoch表現)に互換性が
なくなるので要注意
o extensions/RandomMT/Frameworkを SAD本体に取り込む
- SeedRandom[]の返り値がスカラーからリスト型に変化するので要注意
- SEED/$SEEDに関しては本質的に解決不能っぽいので、旧来の SEED/$SEEDを
使ったコードは動かなくなる予定
- inline展開された線形合同法を根絶する
- array generationなAPIを使って書き直さないと、確実に遅くなる
- 疑似乱数発生器の実装隠蔽か、保守性のためには必要
o Beam Line Elementの動的定義(low priority)
- On the flyで、Beam Line Elementの定義を追加する(2nd SAD Workshopでリクエストがあった)
- 要するに、ExternalMap[]なことが Element Type名付きで出来るやつ
- 可能なら、動的に定義したElementと組み込み Elementは同格とすべき
o SPAC系のコードの動的定義(low priority)
- tturnにある SPAC系コードのif-then-elseは格好悪い
- SPAC系のエンジンを増設・交換しても tturn側を変更せずにすむのが理想
- SPAC系のコードを差し込む汎用のホックを埋めておいて、差し込む関数ポインタを動的に書き換える？
- Data Sampling用のホック(粒子分布の読みだし)
- Kick用のホック(粒子分布を蹴る)
- NPARAの扱いは？(並列プロセス間の同期処理)
o EPICS Channel Accessの再実装(low priority)
- 重複コードの削減や、chid objectの隠蔽のため
- 新しい EPICS Channel Access APIで書き直す
- テスト環境をどの様に構築するか検討中
o 外部関数呼び出し機能の実装(low priority)
- 他の言語で書かれた外部関数を直接呼び出す
- 関数シンボルはdynl_function()で解決可能
- 関数呼び出しに伴うスタック操作を如何に隠蔽するかが鍵
- ffcall, libffiの利用を検討中
- 最悪は、ラッパー関数のソースを動的に生成してCompile&Dynamic Loading