SVX日記
2004-11-10(Wed) コンデンサ容量計のケース加工完了
昨晩は仕事が終わるのが遅かったのでホテルで一泊した。今日は通常業務なので朝からYRPを出て自宅に戻る。9:25発の11:30着。ちょっと羽田の辺りで渋滞したが、非常にスムーズに帰ってくることができた。昼から通常業務に戻ることにして、それまでに洗濯をすることにした。3日も連続で出ているとちょっと心細くなってくるんだよね。
で、洗濯の時間を利用して、心も洗濯することにする。私の場合、基板の切断作業がそれに相当する。例の自作簡易丸ノコ(≒ビデオデッキ)を持ち出し、新兵器の作業マスクをして、例の容量計キットの基板を切断する。らんららーん、と。快適かつキレイに切断できた。もうハナクソが妙な色になったりもしないぞ。そのあたりで洗濯完了。残念ながら心の洗濯も完了。ぱぱっと干して職場へ。
職場では出先で修正したコードを、チマチマと自分のリポジトリ内に反映する作業をメインに行う。アマグラマのころは、ほとんどすべてが1台のマシンで完結するから、ファイル管理とか必要なかった。でも、仕事ではファイルのインストールは複数のマシンに及ぶ。テスト、デバッグなどもある程度その状態で行う必要があるので、ファイルの更新管理をシッカリ行うというのは非常に大事な要件だ。ホントはどこからでもネットワークでつないでCVSで管理するのが理想だが、客先から外(インターネット)とつながる環境はありえないので、紙に書いたり、diffを取ったり、ひたすら地味に作業ログを取る……うーむ、なんか工夫できそうな気がしてきたぞ。Perlでそういう特殊環境に特化したインチキCVSでも作ろうかしらん。いや、作るべきだな。そうだ、作ろう。
さて、帰宅してひさびさに工作をする。昼に基板を切断したので、そのまま作業を継続する。とりあえず、製作する容量計の基板サイズに見合うプラケースのストックを漁る。おぉ!! ちょうどいいサイズのケース(タカチのxxxx)があるでないの!! もし合うサイズのケースが見つからなかったら100円ショップのタッパーがケースになっていたところであった。容量計はテスターと同程度に長く利用することになりそうであるから、やっぱりカッコイイケースに入れたいからねぇ(そういう意味ではEX232CPは失敗したなぁ……)。
そしてガリガリ君にチェイング。今回はフタ側を上面として利用することに決定。まずは2枚の基板を固定するためのφ3mmのネジ穴を2つづつあける。すべて皿ネジを利用するので、いつものように「手ドリルグリグリ処理」を行う(10/4の日記参照のこと)。次は5極のセレクタスイッチ用の穴。適当な場所にルータでφ3mmの穴をあけ、リーマでグリグリグリグリグリグリグリグリグリグリと、か〜なりグリグリする。同様にトグルスイッチ用の穴、プッシュスイッチ用(キット添付のモノは基板実装用なので使わず、手元ストックのプッシュスイッチを利用)の穴、ACアダプタのジャック用(これも、オマケにもらったものは基板実装用なので、手元ストックのケース用のジャックを利用)の穴を次々に開ける。あー、ケース加工って、苦しい作業なんだけど、ほんと楽しい作業だよねぇ。最後は3ケタ8SEGをオモテに出すための四角の大きな穴をあけるのだが、これは難しいぞ。こういうときにはハンドニブラが便利なんだろうけど持ってないので、とりあえずルータに丸ノコを装着して小さめに適当な穴をあけて今日の作業は終了。
明日からまたYRPで仕事なので、ヒマがあったら、一晩中ゴリゴリゴリゴリゴリゴリゴリゴリゴリゴリと、か〜なりゴリゴリして穴をちょうどいい大きさに整形するとしよう。とりあえず、仮組みしてみる。うむ。かなり美しく加工できたぞ。我ながら工作の腕前も上達したなぁ。満足じゃ。
2005-11-10(Thu) Linux Kernel Conference 2005
今日はLinux Kernel Conference 2005の日である。青山でLinuxのカーネルに対する講義みたいなのを聴講しに行く。本来は1セッション8,000円という御大臣な講義なのだが、オイラの会社はスポンサー。モロに仕事の一部なので、個人負担はなしである。我ながら、なんとウラやましい。
第1セッションは「Linuxカーネル入門−ブロックI/OとI/Oスケジューラ」。前半は軽くカーネルの役割に触れた後、後半ではブロックI/Oをスケジュールする機構についてのネットリした解説だ。簡単に言えば、ランダムに発生する読み書き要求を、ハードディスクのヘッドが効率よく読み書きできるように並べ替えるのがI/Oスケジューラである、という話。4タイプほどの方式を次々と説明し、なるほどと納得しながら聴き入っていたが、最後の最後で「フラッシュメモリや高度なRAIDなどでは、デバイスに任せたほうが効率がいい」なんて説明が入ってゲンナリ。そんなん言い始めたら、最近はIDEのハードディスクでもたんまりとキャッシュが載っているじゃん。なんだか、すべてが無駄な努力のような気がしてきた。
第2セッションは「組込みLinuxにおけるカーネル2.6の開発とデバッグ」。Linuxは各種のCPUに対応するマルチプラットフォームOSである、なんていう話から始まって、ICEなどを使ったデバッグ方法の話なんかを聞く。ところが、このセッションの後半になって、カーネルソースに含まれているMips用などのIA-32用以外のコードは、まともにコンパイルすらできないということを言い出してガックシ。本人すら「カーネルパッケージに含まれているコードはトカゲのシッポ程度の意味しかない」なんて言い出してズッコケてしまった。つまり、組み込み用途に使われるような、小規模のCPU向けのカーネルコードは、手を入れずにはマトモに動かないってコトだ。なんてこったい。
第3セッションは「Xenによる仮想マシン環境構築」。Xenという仮想OSプラットホームについての特徴説明から始まるが、何しろ話が冗長だ。インストール方法なんてイチイチ説明する必要なんてないだろ。だいたい、coLinuxにハマっているオイラにはLinux on Linuxの意図がいまいち理解できない。特長として1台のマシンを複数台にみせたり、メモリやCPUを効率的に割り当てるなどの流動的な運用が可能であることはわかるが、デモの時に「あー、うまくいってよかった、よくコケるんだね」なんていわれた日には、これまたひっくり返ってしまう。いくら流動的な運用ができても、そんなもん使い物になるかよ!! まぁ、未来に期待するのは悪いことじゃないから、それは否定しないけどさ。
第4セッションは「スピンロックから始めるLinuxカーネル入門」。若手向けのセッションであるため、オイラには参加権がない。ココだけは無料セッションだし、内容がかなりオモシロそうなだけに、参加したい……というか、参加できるものと思って、会場に資料を置いてきてしまった。席に戻る段になって気がついたので「会場に忘れ物をしまして……」なんていいつつ、そのまま聴講してしまった。あひゃひゃ。でも、内容は一番有意義だったかな。CPUのキャッシュの話から始まって、CPU間のロックの例を交えつつ、カーネルのスピンロックのコードをその場で仕上げていくかのような構成。ロックをトイレの個室のカギに例えたりして笑いを取りつつ、この構成力には舌を巻いた。すげぇ、オモシロかった。しかし、複数のCPUのキャッシュって、ハード的に排他機能が付いているのね。今まで、他のCPUのキャッシュの内容を知らずにどうやってマルチCPUで動いているのかとても不思議だったんだよね。そりゃ、ハード的な排他機構が必要だよな。もしかしたら、排他機構が付いている=マルチプロセッサ対応CPUというコトなのかな。別途、最近になって知ったMMUのページングの仕組みと合わせて、ちょっと近代CPUに詳しくなって嬉しいぞ。なにせ、この仕事を始めるまで、オイラの中の最新CPUはMC680EC30だったからねぇ……。
2015-11-10(Tue) アイ・キャント・オープン・スタック
Fedora23が出たし、コンピュートノードを別にしたいし、ということで、Fedora23でopenstackを入れなおすことにした。先日「どうせ何度か入れなおすことになるだろうから」などとは書いたが……
……というくらい、すんなりと入らない。フタをあけてみれば、packstackが呼んでいるpuppetが呼んでいるhieraのバグだったのだが、puppetもhieraも触ったことがなかったので、問題の追い方すら手探り状態でエラく回り道してしまった。
Error: Evaluation Error: Error while evaluating a Function Call, undefined method `unsafe_load_file' for Psych:Module at /var/tmp/packstack/xxxx/manifests/xx.xx.xx.xx_prescript.pp:2:22 on node pute0.itline.jpこれはhieraのバグで、Bugzillaに報告がある。そして、それに関連する別のBugzillaに……
# dnf --enablerepo=updates-testing update hiera……という「最新のhiera-1.3.4-3.fc23から、テスト中のhiera-3.0.1-1.fc23に更新する」対処っぽいものがあるので、それをやっちまう……と状況によっては、また別の問題にハマるのだ。
Error: Evaluation Error: Error while evaluating a Function Call, Could not find data item CONFIG_USE_SUBNETS in any Hiera data file and no default supplied at /var/tmp/packstack/xxxx/manifests/xx.xx.xx.xx_prescript.pp:2:22 on node pute0.itline.jphiera-3.0.1-1.fc23では、ナゼか/etc/hiera.yamlのdefaultsの定義がcommonに変わっており、packstackが用意したdefaults.yamlが読まれなくなってしまう。その結果「CONFIG_USE_SUBNETSが未定義」となってしまうのだ。
# vi /usr/share/ruby/vendor_ruby/hiera/config.rb
< YAML.unsafe_load_file(source)
> YAML.load_file(source)# packstack --answer-file=answer_file --install-hosts=172.24.0.172,172.24.0.173……などとやったのだが、そうすると、せっかく編集したanswer_fileが無視されてしまうのだ。answer-fileを利用する場合、ホスト指定もanswer_file内で行い、--install-hostsオプションを使ってはいけないようだ。
さらに、ストレージを供給するcinderとswiftだが、特に指定をしないと適当な領域が確保されてしまうので、ここは最初から意図したところを指定したいところなのだが、cinderはcinder-volumesという名前のLVMのボリュームグループを、swiftはフォーマット済みの領域を、各々準備しておく必要がある。
最後に、すんなりと入ってしまえば問題ないのだが、不思議なことにpackstackは、途中でエラーが起こると、最後に関連ログをサックリと消して終了し、証拠の隠滅を図ろうとするので、それをヤメさせるパッチを当てる。
# vi /usr/lib/python2.7/site-packages/packstack/installer/run_setup.py
< server.append('rm -rf %s' % host_dir)
> server.append('#rm -rf %s' % host_dir)2023-11-10(Fri) CoffeeScript2にてMixinを試す
ここのところ、ものスゴい学習欲と、それを越えるほどの課題が湧き上がってきて頭を休める間もない。WebAssemblyからSIMD命令(MMX/SSE/AVX)、浮動小数点演算、CPUキャッシュに飛び火し、なぜか線形代数の学び直しから、3DCG、AIに至るまで。
しかし最終的にアニメーションさせたいなら、以前に作ったシューティングゲームの既存のフレームを使ったほうがいい、ということになり、久々に引っ張り出してくると……動かねぇ。
どこが引っかかっているのかと思ったらMixinだ。なぜか以前に書いたMixinの仕組みが動かない。まぁJavaScriptとしても、CoffeeScriptとしても、Mixinが正式な言語仕様として組み込まれているわけではないからな、と思いつつ、調べていくと意外と根が深い。
そもそもJavaScriptにはクラスが存在しない。いや、最近まで存在しなかった。CoffeeScriptで書いていたので気づかなかったが、クラスが正式な言語仕様として組み込まれているわけではないところに、prototypeとかいう仕組みを通じてCoffeeScriptによりコネあげられていたのだ。ところが、最近になってJavaScriptにクラスの仕組みが組み込まれたので、CoffeeScript2からはコネあげをやめ、その仕組みをそのまま利用するようになった。
それだけならよかったのだが、クラスでメソッドを定義するとprototypeに登録されないようなのだ。先のMixinの仕組みはprototypeを通じてコネあげられていたので、それができなくなってしまった、と。
// コネあげ版クラス(JavaScript)
const Animal = (function() {
function Animal(name) {
this.name = name;
}
Animal.prototype.walk = function() {
console.log(this.name, 'walking.');
};
return Animal;
})();// ネィティブクラス(JavaScript)
const Animal = class Animal {
constructor(name) {
this.name = name;
}
walk() {
console.log(this.name, 'walking.');
}
};// どちらも同様に動くのだが
console.log(Animal.prototype);
const pochi = new Animal('Pochi');
pochi.walk();// コネあげ版クラスだとprototypeにwalkがあるのに
$ node diff_func.js
Animal { walk: [Function] }
Pochi walking.// ネィティブクラスだとprototypeがカラ
$ node diff_class.js
Animal {}
Pochi walking.const Flying = (base) => class extends base {
fly() {
console.log(this.name, 'flying.');
}
}
class Bird extends Flying(Animal) {};以前は「mixOf base, mixin」という以下のような書き方だったが「Flying(Animal)」って書き方も悪くはないなぁ。従来のmixOf関数の定義は必要なくなる。上記の定義自体がMixinを行う関数になっている。
class Bird extends mixOf Animal, Flying'use strict'
class Animal
constructor: (name) ->
@name = name
walk: ->
console.log(@name, 'walking.')
class Human extends Animal
talk: ->
console.log(@name, 'talking.')
Flying = (base) -> class extends base
fly: ->
console.log(@name, 'flying.')
Ejecting = (base) -> class extends base
eject: ->
console.log(@name, 'ejecting.')
class Bird extends Flying(Animal)
class Pilot extends Ejecting(Flying(Human))
pochi = new Animal('Pochi')
pochi.walk()
taro = new Human('Taro')
taro.walk()
taro.talk()
pichan = new Bird('Pi-chan')
pichan.walk()
pichan.fly()
tom = new Pilot('Tom')
tom.walk()
tom.talk()
tom.fly()
tom.eject()$ node mixin.js
Pochi walking.
Taro walking.
Taro talking.
Pi-chan walking.
Pi-chan flying.
Tom walking.
Tom talking.
Tom flying.
Tom ejecting.