マニュアル執筆中(その69)

現在昨日のコメントで言われた通り関数名を修正中です。
それからWin32comを使ってWordを操作するRTCを試しに作っている所です。
しかしそれをするにはOOoとの共通部分を別ファイルに分けた方が便利なのですが、その作業がかなり面倒ですね。
多分ソフトウェアの更新には3週間ぐらいかかるかなと思っています。



それにしてもソースコードを公開していないのに作品公開のメールを送った人がいるようですが、一体どういう意図なんでしょうね？
何か不測の事態でも生じたのかもしれません。

他の作品のコメントを読んでいて思ったのですが、定量的なデータ等がないからそういう事を書かれるのかな？とは思います。多分予稿原稿には書いてあるのでしょうけど。

この作品のコメントに関してですが画像データを通信するのに時間がかかるのは事実なので共有メモリを使う事自体は間違っていないとは思うのですけど、どの程度効果があるのかがわからないですね。実際画像処理に時間がかかるのであって通信にかかる時間は微々たる時間じゃないかなとは思います。既存のRTCと接続できる利点を捨ててまで共有メモリを使う必要があるのかと言えば怪しいと思います。ちなみに「共有メモリを使う必然性は何なのでしょうか？」の質問の意図としては、リアルタイム制御では時間がかかりやすいプロセス間通信は避けるべきなのですが、あの作品はリアルタイムではないので共有メモリを使用する必要がないかもしれないとかいう事だとは思います。

この作品のコメントに関しては、おそらく制作者側の意図としてはresult_checkというRTCがあらかじめ設定した値より大きなデータが入力されたときに正しいかどうかをユーザーに確認するシステムだと言いたいのだとは思いますが、「動作確実性の向上」と言われれば何か不測の事態が起きた時に自動的に修正するように制御するのかと思ってもおかしくはないですね。
そもそも動作確実性とはなんでしょうか？誤動作の確率が下がるという意味でしょうかね？でもresult_checkというRTCはデータの大小しか判断していないわけで後の確認は人任せなので動作確実性が向上するかどうかはわかりません。まあ単純にタイトルの問題なので個人的にはどうでもいいのですが。


個人的な意見ですが独自のデータ型を使うのは嫌いですし、RTC同士がお互い接続の必要があるにもかかわらず分割するのも好きではありません。
AR.DroneのRTCのページに「何故独自のデータ型をつかうのか？」とコメントして数日たつのですが、まだ返信は無いようです。独自のデータ型についてはこのページに詳しく書いてあるようですが、「オレオレデータ型は作ってはいけません」と書いてあります。正直なところ僕にはこの作品のデータ型が「オレオレデータ型」にしか思えないのでぜひとも意見を聞きたいのですが。MIDIのRTCは独自のデータ型を使うのも仕方ないと思います。他で代用するのは無理だと思うので。
あと地図作成のRTC群はなんでこんなにRTCを分割してしまったのかが謎です。
おそらくGUIはJavaで作りたくて他はC++で作成したかったとかそんな理由だとは思いますが、別にC++でもGUIはプログラミングできるのでそれは制作者側の理由でユーザー側からしたら使いづらいだけです。RTCの設計指針についてはこのページに詳しく書いてありますが、「細かすぎる粒度は再利用性を（間接的にですが）著しく下げます．」と書いてあります。全く同意見です。とりあえずコメントは書いておいたので返信待ちです。










にほんブログ村のロボットのカテゴリから
全然人が来ない・・・