emacs-evernote-modeをSnow Leopard に入れてみる
let: Wrong type argument: listp, /System/Library/Frameworks/Ruby\.framework/Versions/1\.8/usr/lib/ruby/1\.8/rubygems/custom_require\.rb:31:in error in process sentinel: enh-command-sentinel: enclient.rb exited abnormally with code 1 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require': no such file to load -- gdbm (LoadError) from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/enclient.rb:32 error in process sentinel: enclient.rb exited abnormally with code 1 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require': no such file to load -- gdbm (LoadError) from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/enclient.rb:32 byte-code: End of buffer [2 times] byte-code: Beginning of buffer [3 times] Loading kmacro...done kmacro-call-macro: No kbd macro has been defined [2 times] Quit [3 times] kmacro-call-macro: No kbd macro has been defined Waiting for the result... let: Wrong type argument: listp, /System/Library/Frameworks/Ruby\.framework/Versions/1\.8/usr/lib/ruby/1\.8/rubygems/custom_require\.rb:31:in error in process sentinel: enh-command-sentinel: enclient.rb exited abnormally with code 1 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require': no such file to load -- gdbm (LoadError) from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/enclient.rb:32 error in process sentinel: enclient.rb exited abnormally with code 1 /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require': no such file to load -- gdbm (LoadError) From /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems/custom_require.rb:31:in `require' from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/enclient.rb:32
あれれ? で，ドキュメントを読んでみると…
Mac OS X に付属の ruby には GDBM バインディングが含まれていません。
がーん．
設計と実装における「動的」
ソフトウェアの論理設計を考えるとき、よく機械や建築の設計図に喩えて説明されます（私も連載最初の方で使いました）。しかし、機械や建築物と性質的にまったく異なるのは、ソフトウェアは”動く”のです。そして、作った構造物（もしくは部品）はいつも同じ動きをするとは限らず、時間や環境などによって、まったく別の動きをすることもあるのです。
これって、実生活のモノにはとても喩えることができない特徴ではないでしょうか。
機械や建築と違うといえば違うのかもしれない．けれども，みんなだいすき " フレデリック・P・ブルックス・Jr"さんは近著「デザインのためのデザイン」で，建築を引き合いに出している．もしかしたら大した違いはないのかもしれない．
- 作者: フレデリック・P・ブルックス Jr.,松田晃一,小沼千絵
- 出版社/メーカー: ピアソン桐原
- 発売日: 2010/12/17
- メディア: 単行本（ソフトカバー）
- 購入: 5人 クリック: 147回
- この商品を含むブログ (24件) を見る
たぶん違いは，設計と実装の各フェーズについてそれぞれにある． むろん，実装を考えない設計なんてのはアリエナイし，設計を無視した実装も同様． 完全に分離するのは無理なのだけれども．それでも視点が大きく異なってくるので，一旦は分離する必要がある．
実装における「動的」
引用元は，"動く"と表現しているので，それに倣う．
機械は，そして建築は，動かないか? 否． 動かない機械なんてのは無いし，近代建築において，可動部のない建築は稀だろう．
ソフトウェアは，"動く"か? これは定義によって大きく異なる．マクロ物理的には動かないといって良いだろう．I/Oポートを介してアクチュエータを動かすことはあるだろうけれど，"動いて"いるのはアクチュエータであってソフトウェアではない．
プログラムカウンタ，各種レジスタ，メモリといった状態遷移はある．これをもって"動く"ということは，慣用的な表現だし，不自然はないだろう．
以上のように考えると，機械または建築と状態遷移に着目した場合のソフトウェアは，共に "動く"．しかしこれらの間には違いがある．
機械または建築の可動部には，"遊び"があり，また他のマクロの物理条件の影響を受けやすい．人が普通に暮らせる範囲の温度や湿度で，ドアが開きづらくなったりする．"完璧な歯車は回らない"というのは機構設計をするかたの基礎知識でもあろう．
一方，状態遷移に着目した場合のソフトウェアは，引用元の主張とは異なる特質を持つと私は考える．
「ソフトウェアの挙動には"遊び"が無く，ほぼ100%の再現性で動作する．」
割り込み禁止かつシングルスレッドの環境を一つ定めた時，下記コードは，確実に同じ動作を行う．
計測誤差を考慮する余地が無い．
for(int i = 0; i < 100; i++) { printf("%d", i); }
現実のソフトウェアシステムでは，物理的な機構が絡まずにはいられない*1ので，"遊び"や誤差を考慮する必要があるのではあるが．
"遊び"が無いということは，言い換えると恐ろしいことになる．
実装が間違えていた場合に，"遊び"によって吸収されることなく，ダイレクトに誤った結果が出るということである．
この点 - ソフトウェアはむしろ定義した通りにしか動かない - が，実装としてのソフトウェアが持つ最も扱いづらい点であると私は考える．
また，ソフトウェアが静的な存在である一方で，外界の物理的存在が動的であることの齟齬が，ソフトウェアの実装を難しくしているとも考える．上記のコード片で例えるなら，割り込み禁止を解いた時点で，標準出力から得られる結果が常に再現されるかは怪しくなる．
設計における「動的」
こちらは私の専門外だし，上記の実装どころではないくらい多岐な視点を取り得るので，省略する．
引用元とは無関係に，ただ一つ指摘しておくならば，世の中でしばしば聞かれる「ソフトウェアの設計仕様はコロコロ変わるから建築より難しい」というのは，眉唾だと思っている．
建築方面の末端*2に携わっていた実父から，「貰った図面が古かったので現物合わせした」という話を何度も聞かされて，私は育った．
というわけで
動的とか静的とかって視点によって変わってしまう難しい概念なのですねー．
スキルマネージメントが大切な本当の理由(たぶん)
それなりにネタはあるはずなのだけれど，NDAだの書籍執筆のネタだのと被ってしまう．素の技術系日記が書けないので notart 系の日記やら twitter やらに走ってしまう．
ダメすぎた気がするので，何か書く．
成績
血縁にある子供がそれなりの年齢になれば，通知表に記載された成績についてヒトコト言わないといけなくなるのが，オトナの務めではある．
私は子の親ではあるので，その急先鋒なのだけれども，いつも憂鬱だ．ブッチャケ言うなら，官僚組織の下部組織が付けた成績なんて，どうでもよいはず．
だって，「経産省の産業分類に組込みソフトウェア業が含まれるようになりましたー」ってESECだかETだかのレセプションで拍手したのは，たぶん至近5年内くらい．現在的なコンピュータゲーム業界が勃興したのは，至近20年くらい．没落した業界をあげつらうほど趣味は悪くないので言わないが，至近20年の間に，産業構造は大きく変わった．
今の小学生がオトナになったときに花形になっている産業は，今の小学生が産まれた頃に勃興したものである可能性が強い．経験値が低い小学生が勃興したばかりの業界への夢を卒業文集に書けるとしたら，周囲がよほどアンテナを張り巡らせているレアケースだろう．この世は移ろいが早すぎる．
こんな速度で遷ろう世の中で，ジャストフィットな教育が施されていると思うオトナがいるはずもない．
しかしまあ"昨日のことは役に立ちません"では立てる竿もなく流されてしまう．移ろいの速度に関係なく，何かと比較しないわけにはいかない．同世代の横の比較が無意識的に禁忌される世界では，過去との比較がお手軽で良いということに落ち着きがちかもしれない．
私事
実母はいい加減だけれど物持ちの良い人で，私の中学校までの通知表をいまだに段ボール箱にしまい込んでいる．
っていうと，「じゃあ勉強しろってお子さんに言えませんね」って反応が大抵返ってくる．
けれども，ごあいにくさまなことに，私は中学生までは(区立を選んだこともあって)割と内申点がよかった．20年近く経った今でも，当時の先生方からその話が出る程度には *1．
当然のことながら親の欲目に対する補正が必要ではあるけれども，長女は(特定の区立小学校の当該学年内では)，割と立派な通知表を持ってくる．次女も，伏兵的に，それなりの通知表を貰ってくる．控え目に言っても偏差値50以上ではあるだろう．
だが，私の通知表には敵わない．もちろん，相対評価であるとか評価者の違いとかはある．けれども，定量化されたものには，意味があろうが無かろうが，相応の重みがある．
スコアリングの本当の意味(たぶん)
子供が親に何か言われて反発するときのツールとして「パパ/ママは，私たちくらいのときどうだったのよ」というのがある．大抵の親はエビデンスを持っていないので，子供としてはこれを突破口とする．私も使った気がする．けれども，私にはエビデンスがあり，子供たちには逃げ道がない．
私は人間ができていないので，最初の頃は"ふあははははwww"．という気分にもなった．実の子に対して．
…のだけれど，しばらくして，スコアリングの本当の意味が，私なりに解ってきた．
通知表に記載されたスコアを取るために，何を{したか|しなかったか}とか，スコアを受け取ったときに，何を{思ったか|思わなかった}とか．そういうことを思い出すことに意味があるのではないかと．
自分の実家に帰ったある日，自分の通知表を開いてみた．自分でもビックリするくらい，当時が鮮明に蘇ってきた．
やたらと私の通知表を覗いてくる私学進学志向のウザい友達のこと．冷めた顔でメダカだったかザリガニだったかに餌をあげている友達のこと．一緒に返してくれる図工の絵をニコニコしながら眺めている友達のこと．
人(特にエンジニア)は経験を積むほどに，"自分よりも経験の浅い人も自分と同程度の能力を持つ"と勘違いしていく．そのくせ，自分以外の誰かを指して，本質的に不適格なのではないかというような判断をする．
これは，古典であるハッカーズ大辞典でも指摘のある傾向なので，おそらく古今東西避けようのない話．
だから
スキルマネージメントに大切なのは，ある時点での試験やその点数ではなくて，試験時点よりも成長した時点での，その点数への振り返りなのかなという気がする．
その時，何を思っていたのか．何に期待して何に不安を持っていたのか．
そして，こういった情報を20年程度のあいだ保持してくれることは，いくつかの例外を除くと，試験業者の方々には期待できない．本エントリで例示したとおり，テスト対象の業種は，10年後でさえ有るかどうか断言できない．
だから，スキルマネージメントが必要な理由があるとすれば，それは1つしかない気がする．
「移ろいゆく技術傾向の中で，ときどき数値化というタグ付を行うことで当時を振りかえやすくし，自らが枯れたときに，傲慢にならず後進へ的確な助言ができるようになるため．」
組込みシステム業界においては，ETSSのようなスキル標準を作った人たち…つまり40〜60歳代の人々には無理なことが一つある． それより若い世代は，試験を受け点数を見ることでその瞬間の自分をタグ付けできる．点数はさておき，そのタグはきっと役に立つ．オッサンになってから．
試験の意味
テスト結果次第で会社から手当や一時金が出るというのは切実なメリット．点数も，それはそれとしてその瞬間には一大事．
それはそれとして，その瞬間に思ったことの記録…ライフログとして試験を受けて結果を覚えておくというのは，将来まで見越すと，成績の如何に関わらず割と大事な話なのかもしれない．
Beagleサンド
荒れまくった机の上にBeagleBoardを裸で置いておくのは破損リスクが高すぎる．
アクリル板のストックがあったので，チャチャッとサンド板を作ってみた．
ゴム足が残っていたので貼ってみた．
こんなのでも小一時間かかっちゃうのよねぇ．
TOPPERSにおけるカーネルの位置づけと，コンフィギュレーションの件
TwitterのTLとか巡回先のコメントとかを見て．ああ，なんというか，伝わっていないなぁというか．
組織として，この手の素朴な疑問についてカジュアルに答えられる人材が育たなかったのは，中長期的に大きく効いてくる気がしますが，それを心配するだけの立場でも無し．淡々と自説展開しますよ．
もしかしたら私だけがワケワカラン解釈をしているのかもしれないので，信じるかどうか，参考にするかどうかは，読者責任．
「RTOSカーネルはCPUのためのデバイスドライバである．」
「RTOSカーネルはCPUのためのデバイスドライバである．」という考え方の妥当性については知りません*1．違う見方もあるでしょう．ただし，この見方は，μITRON4.0仕様ならびにTOPPERSカーネル群の事実上の産みの親である名古屋大学の高田教授が，一時期好んで使っていた表現です．最近はそういう表現を使っている場面に立会いませんが，根底にこの視点がある(もしくはあった)ことは理解する必要があります．
TOPPERSのコンフィギュレータは，略さずに言うと，カーネルコンフィギュレータである
コンフィギュレータって略すから，なんでもしてくれそうな気になります．
μITRON準拠系のTOPPERSカーネルの cfg/ 辺りにあるのは，カーネルコンフィギュレータです．つまり，RTOSと言う名の"CPUのためのデバイスドライバ"のコンフィギュレーションしか考慮されていません．
現に，より抽象度の高いミドルウェアであるTINETは，独自のコンフィギュレータを持っています．理想的/空想的には，全てのデバイスドライバ/ミドルウェアは，独自のコンフィギュレータを持つべきです．現実との折り合いを捨て去ることはできません．しかし少なくとも理念的には，そうなります．これは，μITRON仕様の発展形であるTOPPERS統合仕様で否定されていませんので，同様です．
だから，現状のTOPPERS新世代カーネルにあるコンフィギュレータには問題がない
だって，CPUに極めて近い部分(カーネル)のコンフィギュレーションしか考慮していませんから．
「CPUって，どこまで?」という根源的な問いはμITRON仕様には常に降りかかっていて，割込み周りはCPUではないという*2μITRON4.0仕様に基づきつつも割り込み周りを分離しきれなかったTOPPERS/JSPでは，割り込みベクタが実質的には動的書換不可な環境*3でツールによるhackで辛うじて仕様に準拠しています．
TOPPERS/ASP では，上記のような揺れを排除すべく，割込みに関する標準モデルを打ち立てました．このおかげでターゲット依存部の移植が苦しくなったという意見も耳にします．しかしそれは，ターゲット依存部の移植者が，エンドユーザに丸投げしていた苦しみを自ら引き受けるようになったっていうことです． 進化として諦めて頂くか，JSPを採用してエンドユーザに再び苦しんでいただくほかはないでしょう．
ここで，TOPPERS新世代カーネルでも，タイマと割り込みコントローラをCPUの一部として認めたに過ぎず，その他のペリフェラルはRTOSの範囲外と(暗に)みなしていることに注目する必要があります．
よって，デバイス用(もしくはボード用)のコンフィギュレータが要る
おそらく勘の良い方は気づいていらっしゃるでしょうけれども，TOPPERSカーネルに足りないのは，コンフィギュレータの機能拡張ではありません．コンフィギュレータはフレームワークです．TOPPERSカーネルに標準で付いているのは，フレームワークとしてのコンフィギュレータをカーネルに適用しただけのものです．
カーネル以外でユーザのコンフィギューレションを許すものがあるとするならば，ソフトウェアコンポーネントの単位毎に独自のコンフィギュレーションスキームを，フレームワーク上に構築することが期待されます．先に挙げたTINETのように．(少なくとも理念的には)
で，どうすべきなの?
とは言っても，仮にフレームワークライブラリが存在していても，そのような複雑な環境の構築を，週末の電子工作の範囲で行うのは無理です．仕事でも，有るものを使うのはアリかもしれませんが，デバドラ作る上にこんな作業するのは避けたいところです．
TECSがこれを担うことが期待されましたが，崇高なところに行ってしまい，しばらくは帰ってきそうにありません．
twitter 上では「カーネルオブジェクトが動的IDに対応すれば」という指摘もありました．確かに一定のレイヤで何かを楽にすることはあるかもしれませんが，コンフィギュレーションの問題を解決するものではありません*4．
Webアプリケーション上における JavaScript と CoffeeScript の関係のように，簡単な記述で複雑なコンフィギュレーションファイルを作成できるような環境を作るのは一つの方法でしょう．
また，もっと割りきって，設定情報マクロを含むインクルードファイルを生成するための，UIを簡単に構築するということも有り得るでしょう．Androidアプリ作成における，preferences.xml のようなものがあれば，デバドラ作成者が協力してくれることもあるでしょう．
で，どうなるの?
というわけで，設計思想的にどうなのか，対策として何がありえるのか，私見の範囲で述べました．
「将来的に，どうなるのか」という問いには答えません．コの業界で将来を予測するのは，天才かペテン師，どちらかしか居ませんので．
ボードはボード，CPUはCPU
ASPカーネルのディレクトリ構成が決まった瞬間に立ち会った因果で，触れておく必要がありますかねぇ．
ターゲットとは、「プロジェクト」であって「ボード」ではないのかもしれません。そう考えると、なるほどと思えるんですよね。既存のターゲット依存部を利用するから悪いのであって、毎回プロジェクト用のターゲット依存部を、既存の物をもとに作ればいいのです。
概ね外れてはいませんが，割と違います．
いろいろバリアントがありうるよね，ということで，オブジェクトベース的なディレクトリ配置になっています．
"差分で拡張してください"という点では，ほぼ毎回作ればよいというのは間違いではありません．
ただし，それで全てを済まそうという思想でもないはずです．(もしくは，かつては，なかったはずです．) ボードはボード，CPUはCPUです．プロジェクトではありません．
歴史を振り返ると，当初ASPカーネルとTECSとは同時に公開するタイムラインで"デバドラ辺りはぜんぶTECSに任せてしまいたい"というのが，なんとなくの全体の空気でした．ボードのコンフィギュレーションはTECSで記述すればいいじゃない，と．
ところが，TECSはネット透過にしようとした辺りから肥大化/複雑化し，サグラダファミリアになりかけています．そのため，ASPのターゲットコンフィギュレーションは宙に浮いたままです．
当初の「静的で軽量なコンポーネント組み上げシステム」という位置にTECSがもどってくることは，もはや無いかもしれません．現実的な解として，Linuxにおける make config のようなターゲットコンフィギュレータの枠組みを用意すべき時期にあるのかもしれません．
余談
誰が鈴をつけるの? っていう話は難しいのですけれども．
ツール屋さんの得意分野ではありますが，ここを頑張っても売れるのは(ツールではなく)ボードですから．ではボード屋さんが金を出すかというと，結構難しい．
ユーザから金を取れるかというと，超絶に難しい作業でもないので，価格をつけづらい．
また，TECSに期待が繋がっている限り，売りづらい．無料で純正の競合が産まれるかもしれないわけですから．
趣味か研究で酔狂になって頂ける人の登場を，静かに待つしかないのかもしれません．
gdbproxy からのリセット発行
試していないけれど，UrJTAGの src/cmd/cmd_bfin.c 辺りからつらつらと眺めた感じだと，たぶん大丈夫なはず．
これで、gdbproxyに組み込まれているurjtagから、blackfinに向けてリセットコマンドを発行します。この後、アプリケーションをロードして実行すると、正しく実行されました。まだ短い試験しか行っていませんが、どうやら大丈夫のようです。
BF506 に関してはよくわからないものの，一つ心当たりがあるとするならば，追加引数．
BF506Fに進展があれば！と早速調査。
結果変わらず。orz
リセットはかかってるようなんだけどな。
(KOOP版は本家UrJTAGからのブランチなので，コードが全く同一なのかは調べていないが，本家にはあるので)追加引数として，{core|reset} を与えることができる(はず)．
/* 本家の src/cmd/cmd_bfin.c から抜粋 */
if (num_params == 3)
{
if (!strcmp (params[2], "core"))
reset_what |= 0x1;
else if (!strcmp (params[2], "system"))
reset_what |= 0x2;
else
{
urj_error_set (URJ_ERROR_BFIN, "bad parameter '%s'", params[2]);
return URJ_STATUS_FAIL;
}
}
else if (num_params == 2)
reset_what = 0x1 | 0x2;
else
{
urj_error_set (URJ_ERROR_BFIN,
"'bfin emulation' requires 0 or 1 parameter, not %d",
num_params - 2);
return URJ_STATUS_FAIL;
}
urj_log (URJ_LOG_LEVEL_NORMAL,
_("%s: reseting processor ... "), "bfin");
fflush (stdout);
if (reset_what == 0x3)
software_reset (chain);
else if (reset_what & 0x1)
bfin_core_reset (chain);
else if (reset_what & 0x2)
chain_system_reset (chain);
urj_log (URJ_LOG_LEVEL_NORMAL, _("OK\n"));
return URJ_STATUS_OK;
}リセットの発行順序や間隔が影響しているのであれば，追加引数でなんとかなるのかもしれない(でも試してはいない)．
