2011年6月28日火曜日

「節電対策」という言葉に違和感を感じる・・・

ニュースなどでも当たり前に使われている「節電対策」という言葉にどうも違和感を感じてならない。

「~対策」と使う場合、「~」に入る部分は通常起こって欲しくない、起こっては困るような事柄が入るべきで、それに対する何らかの方策・対応方法という意味で「~対策」と呼ぶのではないか?例えば、「大雨対策」と聞けば、大雨が降って起きうる洪水とか農作物への被害など望ましくない懸念事項に対する方策という意味ですんなり受け入れられる。

一方で「節電対策」と聞くと、「節電」自体が起こって欲しくない事柄であるように感じられてしまうが、、節電はむしろ(できるのであれば)望まれるべきことだと思う。だから「節電対策」というと、「節電」が起こって欲しくない(したくない)ので、節電しないような何か方法をとるという意味になってしまうのではないだろうか?言うならば「(大規模)停電対策」とか「電気の大量消費対策」とかの方が意味としてスッキリする。
ひねくれた見方をすれば、「暑いのはイヤだから節電したくないという気持ちに対抗するための何らかの方策(悪あがき?)」、という意味ととらえることもできるけど、やっぱり「節電対策」という響きはキモチワルイ。

ちなみにWikipediaによると、


  • 現在では、ある問題や相手の態度に対して取られる方策のことをいう。なお、「省エネルギー対策」といった用法だと「省エネをさせないための対策」という意味になるので誤用である。
と書かれているので、(Wikipediaが常に正しいとは限らないけれど)やはり「節電対策」というのは間違いのような気がする。

2011年6月23日木曜日

Inno Setupにハマる

比較的柔軟な動作設定・定義ができるという点で使っているInno Setupだけれども、アンインストール動作で不穏な動作に遭遇した。結論から言えば、Inno Setup自体は問題なかった(仕様どおりの動作)のだけれども、あまり意識していないとハマる可能性があるので備忘録として残しておくことにした。

というのは、公開しているアプリのバージョンアップなどで、古いバージョンをインストールしたまま同じフォルダに上書きインストールしたときはアンインストール動作にも気を配ろう。
具体的に言うと、古いバージョンのときに指定した[UninstallRun]セクションの内容は、上書きインストールした新しいバージョンの[UninstallRun]セクションとともに、アンインストール情報ファイル"unins???.dat"に両方記録されている、という点である。つまり、上書きインストールを行ったアプリのアンインストール動作としては、

  1. 新バージョンで指定した[UninstallRun]セクション
  2. 旧バージョンで指定した[UninstallRun]セクション

の順で実行されるので、新しいバージョンでインストーラ/アンインストーラ関係のファイルを更新したり、動作を変更したりすると、上の2の動作のときにおかしくなる可能性がある。

これを回避する方法としては、


  1. 新旧バージョンでインストーラ/アンインストーラの動作を変更しないこと
  2. アンインストール動作を変更したとしても、旧形式でのアンインストール動作で不具合を起こさないように注意すること
  3. 新バージョンをインストールする際に、旧バージョンをアンインストールしてから新バージョンをインストールするようにユーザに喚起するか、新インストール側でそういう対策を行うこと
という方法が考えられる。

2011年6月17日金曜日

ドアミラーって・・・

車を普通に運転してたら見ますよね?>ドアミラー

  • いや「私の車はフェンダーミラーだから見ない!」という天の邪鬼な返答は置いといて・・・


今日の通勤途中、ドアミラーをたたんだまま走る車を見かけました。しかも高速道路でです!結構飛ばしていましたし(120km/hくらい出てたかも)、いくら交通量が少ないとはいえ車線変更もバンバンやってました。いったい、どうやって安全確認をしているんだろうか?

ルームミラーである程度後方は確認できるけど左右の斜め後ろには明らかに死角があるし、ドアミラーを使ってもかなり死角は広いと思う。仮に、車が来ていないことをずいぶん前から長い時間ルームミラーを使って後方を確認していたとしても、たま~に恐ろしいくらいのスピードであっという間に近づいてくるベンツやセルシオがいることを考えると、その方法も決して安心はできない。

ハッキリ言って、こんな人には車の運転をしてもらいたくない。ちょっと怒り心頭です!
ここでナンバーをババーンと晒してやろうかとも思うけどさすがにちょっと問題がありそうなので一部伏せ字で・・・

横浜 501 ま 5○○1 の 白いシルビア

この車を運転している人!ちゃんとドアミラーも(もちろん目視も)使って左右斜め後ろの安全確認をしてください。

2011年6月10日金曜日

TOPPERSを触ってみる

以前から気になっているTOPPERSプロジェクト。以前にも少し触ってみたことはあるのだけれど、コンフィグレータがどうとか、静的APIがどうとか、初めて触るにはちょっとややこしいor面倒な部分が多くて挫折していた。う~ん、きっとコンフィグレータは後々良さが分かってくるんだろうけど、これまでになかった新しい何かを身につける・・・いや少なくとも乗り越えるにはちょっとしたパワーが要るんだなぁ。その点、FreeRTOSはカーネルソースコードも含めてコンパイル&リンクするだけでOSに必要な機能が使えたから簡単に取り組めたんだけどなぁ。ま、新しいものを素直に受け止められないのはオジサンになった証拠か。

でも今回はごにょごにょ言わずに何とか先に進めてみた。
ターゲットはcortex-m3(stellaris)だ。幸いcortex-m3向けの機種依存部分を提供してくださっている方がいたのでありがたくダウンロードさせていただいて、当面の評価を行おうと思う。

まず、TOPPER/ASPの最新版をダウンロードして展開。更に、cortex-m3依存部分も同じディレクトリに展開。doc/user.txtによると、やはりコンフィグレータcfgが必要らしい。が、ASPのフルパッケージに何故か入っていない。仕方ないので、またHPから探すと、今回はcfgのwindows向けバイナリが置いてあった。ソースも置いてあったけれど、目的はstellarisでtoppersを動かすことであって、コンフィグレータをビルドする方法とかはどうでもいい。で、ダウンロードしたcfg.exeはどこに置けばいいんだ?
とりあえず先に進むことにした。なるほど、他のオープンソース系と同じようにターゲットにあわせたconfigureスクリプトとmakeを行うのか。そして、configureスクリプトの実行はperlだと。そうか、shスクリプトはlinux系ユーザにはおなじみだけど、windowsユーザを考慮してまだ導入しやすいActivePerlなんかで対応できるようにしてるんだな、と勝手な推測。とりあえず、ActivePerlの最新版をダウンロードしてきてインストール、パスを通した後、コマンドプロンプトからperl ..\configure -T lm3s8962_gcc[ENTER]とタイプイン!何っ?エラー?PWDコマンドがないって?そりゃ、Windowsのcmd.exeにはPWDはありませんよ。ということは、ActivePerlはダメってこと?
う~ん、windows<オンリー>ユーザのためにperlを使うわけではないようだ。仕方ないのでActivePerlはソッコー消して、cygwinのbash上からperl/configureスクリプトを実行して事なきを得た。しかし、結局bash系の環境は必要なら何であえてperlを導入したのか分からない。shスクリプトのままじゃダメなの?perlは文字列処理が得意だから?

まぁ、いいや。とりあえずconfigureスクリプトは成功してmakefileができたようだ。そのままbashからおもむろにmake[ENTER]をバシッと。

またエラーですか。

今度はコンフィグレータcfgが無いと言っているようだ。cfgのあるべきパスは、../cfg/cfg/cfgですか。何ですか、そのパスは?まあよい、今回は素直にそのパスにダウンロードしたビルド済みcfg.exeを置いてみる。そして、再びmake[ENTER]をバシッと。

またまたエラーですか。

今度はTSKCTBXという識別子(たぶん構造体定義)が無いとおっしゃる。ハイハイ、どこか探してきますよ。というわけでソースツリーをgrep。しかし、TSKCTBXを定義している箇所が無い。いや、arch/m68k_gccの中に1つだけ発見した。でもなんかおかしいなぁ。名前から想像するに、TSKCTBXはタスク制御ブロックのようだけれど、その定義を発見したのはarch/以下。つまり、機種依存コードの中。こういう場合、タスク制御ブロックの定義って、機種依存ではなく、カーネル本体に含まれるべきなんでは?

困りました。TSKCTBX構造体を自力で定義せにゃならんのですか?と思っていたところ、偶然発見した。「CTBXはTSKCTBXに名前が変更されました。」

なんじゃそりゃ?

でCTBXで検索してみるとありました!やはり、機種依存部分のarch/arm_m_gcc/prc_config.hにありました。勝手にTSKCTBXに書き換えて、今度こそmake[ENTER]でサクッとコンパイル!

出ました。またエラーです。

今度は、hw_ints.hが見つからないと。この名前は見覚えがある。StellarisWareに含まれているヘッダファイルのようだ。includeサーチパスを見ると"LuminaryMicro_Driver"とか含まれてる。LuminaryはTIに買収されちまったよぉ~、StellarisWareに変わってパスも変更されたんだよぉ~。というわけで、makefileからインクルードパスの設定を変更して、などなど・・・。

どうやらダウンロードしたcortex-m3向け機種依存コードは、かなり古いもののようだ。実際、最終更新が2008年となっている。カーネル部分の更新について行けてないのか・・・。あきらめ半分でmake[ENTER]ポチっと。

お約束のエラーです。

今度は、INHINIB構造体にint_entryというメンバは存在しない、EXCINIB構造体にexc_entryというメンバは存在しない、という2つのエラー。INHINIB/EXCINIB構造体の定義を探してみると、いやint_entryとexc_entryはちゃんとFP型で宣言してある。FP型も定義してある。もしかしてこの部分はコンパイル時に読み込まれない(#if~#endifではじかれている?)可能性もあると思って、#errorとか適当なものを埋め込んでみるとちゃんとコンパイル時に#errorが報告されるのでこの定義を通っているようだ。では何故?・・・

分かりました。機種依存コードの中でint_entryとexc_entryを#defineで_kernel_int_entry/_kernel_exc_entryにリネームしてある。そうだ!思い出したゾ。

以前TOPPERSに取り組んでみてイヤになったのは、この#defineによるリネームのせいだ。コイツのせいで今回のようなコンパイルエラーが出て困ったんだった。こういうリネームをやられると、どの名前が本当の名前で、どこで定義されているのが実際に使われる名前なのかがまったく分からなくなる。しかも、int_entryのような単純な名前を入れ替えられると、今回のようにたまたま構造体のなかで使ったメンバに同名のものがあると、それもリネームされたり、されなかったりで、何が本当なのか訳が分からない。
どうしてこういう実装にしたのだろうか?結果的にこれがもっともスマートな解決方法なのかもしれないけど、私のように事情をよく知らない者がメンテなりポーティングする段になると、非常にメンテナンス性が悪くなると思うし、思わぬ不具合をはらみかねないと思うのだが。少なくとも#defineで名前の置き換えがされることを前提にしているシンボルなり関数があるのなら、その名前は置き換えられることがもっと区別しやすいような名前にすべきだと思う。今回のようにint_entryのようなありがちな名前だと、グローバル関数としてのvoid int_entry(void)をリネームしたいのか、INHINIB構造体中のint_entryメンバをリネームしたいのか判断できない。

で、結局この部分をどう解決すべきか?本当に手がかかるなぁ、ブツブツ・・・


[2011/6/10 18:45加筆]

その後の調査で分かったこと。

○#defineによる関数名のリネームは、ユーザが書くアプリケーション側の関数名との競合を避けるためらしい・・・
>>それなら敢えてリネームしなくても、ユーザー側が競合を回避すればいいだけではないか?
>>または、ユーザー側で使いそうな名前の関数をTOPPERS側で使わない方がよいのでは?実際、doc/user.txtにはtoppers_接頭辞を予約していると書いてあるんだから、一目でTOPPERSの「内部関数だな!」と分かる名前をつけることは、ソースコードの可読性を挙げるためにもむしろ有効な手法ではないか?
>>今回の場合は、Stellaris用の機種依存コード側でint_entryという名前をつけたこと自体が失敗だったのではないかと思われる(成果をダウンロードさせてもらっておきながら、なんとも勝手な言い分だろう>私)

で、とりあえず上に書いたint_entryとexc_entryの妙なリネームを回避するとサンプルをビルドすることができた!