2003年12月21日(Sun) 新しいターミナルはわかりにくい
● ミュンヘン空港のルフトハンザは去年から新しいターミナルに発着するようになった。自動車で行ってみると案内がすごおくわかりにくい。空港の周囲を一周しなおしてリトライ。やっぱり地図を見てから行くべきでした。
2004年12月21日(Tue) ジョギングシューズ復活
● サンタさんが自動車を運転してたよ
久しぶりにジョギングに行く。一週間以上サボってるとやっぱり体がなまってるねぇ。などと思いながら走ってると目の端に赤い帽子が。白い髭のサンタさんが自動車を運転してました。僕にもプレゼントちょーだい(おいおい)
2005年12月21日(Wed) 今日も今日とて機動戦士
● 結城さんは情報をちゃんと整理しておられる
結城浩のはてな日記より、
情報を整理するときに大事なのは「想像力」だと思います。つまり、「将来この情報を必要としたときの私は、いったいどこを探そうとするだろうか?」と想像し、未来の自分が探しそうな場所にその情報を置く、ということですね。
え、えらいなぁ…。
僕は整理するのはあきらめて、公開できる情報はここに書いて検索エンジンに探してもらう、メールはGMailかgrep*1に検索してもらう、公開できない情報は仕事場のnamazu*2に検索してもらう、ことになってます。でもこれじゃやっぱり取りこぼすんだよねぇ。ネットワークが無いと記憶喪失同然なのもかなしい。
● あまり面白くない会議に出てマグカップを無くした。あーあ。
● マグカップが帰ってきました。どうもありがとうございました。
2006年12月21日(Thu) やっぱりtDiaryにテスト環境欲しいよな
● 今日のHiki Error
なんだろう。あとでもう一度やってみよう。
● [tDiary] 後日談プラグインも
なきっつらに蜂。(記事を追加した時に起きる。記事を編集しても起きる。)
あー。makerssから呼ばれちゃうのかな。
そうみたい。RSSを更新しないと起きない。
(追記) わかりました。かならずしも、body_enter_proc、section_enter_proc、…と順に呼ばれるわけではないみたいだ。
● [memo] 新しいLinuxでmke2fsしたパーティションを古いLinuxでマウントできない
(追記) 「マウントできない」んじゃなくて「fsckできない」んだな。
同僚が、運用のための計算機のハードディスクを定期的にコピーして、 いざというときにバックアップ側のハードディスクを 運用のための計算機に入れてブートできるようにしようとしている。
バックアップ側の計算機(新しめのLinuxが入っている)で
運用のための計算機(古めのLinuxが入っている)のコピーができて、
ブートローダを入れて(ちゃんとgrub-install
しました:)、
とりあえずバックアップ側の計算機で起動しようとすると、
カーネルがロードされてinitに制御が移って(さすがgrub)、あれ。
みたいなエラーが表示されました。いや、バックアップ側だけ e2fsprogsを更新するわけにもいかないし。
しばらく同僚と検索して、解決方法がわかりました。 fsck.ext2がサポートできるfeatureだけにすればいい。
ext2あるいはext3の現在のfeatureは下記のようにしてわかるようです。
この結果を、運用のための計算機での結果と比較して、多すぎる featureを無効にしました。下記のような感じ。
fsck
が失敗してrootのshellをもらった段階で、
read onlyでマウントされていてもこのコマンドはうまく機能したようです。
● [tDiary] 後日談プラグインがやっと安定してきました
myプラグインで過去の日記へのリンクをつくった時に、過去の日記に、myプラグインのある日記へのリンクをつくるプラグインです。
RSSでご覧のかたは今日の日記が頻繁に更新されるのを見させられたことになると思います。失礼しました。
myプラグインの場所(日付とセクション番号)をちゃんと把握するのは思ったほど単純ではなかったことと、myプラグインが消去された時に過去の日記からのリンクを消去する処理が思ったほど単純ではなかったことが原因で、思ったより手間取りました。
少し運用してみて問題ないようだったら公開します。
● さてー。grub-install読みに戻るぞ。まず寝なくちゃいけないけど。
2009年12月21日(Mon) 雷が鳴ったが雪はあまり積もらなかった
● [Ruby] RubyのSIGSEGVがなんとなく解決した
このサイトのマシンがメモリエラーを出して からOSやRubyをNetBSD 5.0.1やRuby 1.8.7-174に更新していただいて出るようになった、 SIGSEGVを モンキーパッチで回避 していましたが、 OSをNetBSD 4.0.1にしてRuby 1.8.7-174をリビルドしていただいて モンキーパッチが不要になりました。
NetBSD 5.0.1でもらっていたSIGSEGVがRubyによるものなのかどうか検証する機会がありませんでしたが、 とりあえず問題を解決していただいたことになります。
いつもありがとう!smj!
2013年12月21日(Sat) 公園で子どもたちと鬼ごっこ
● [golang] Goのテストツール
GoとC++で作るB木シリーズ。やっとこgo testでB木のテストが動いたので今日はgo testの動作を掘り下げてみた。 go testでは*_test.goのテストケースが実行される。 テストされるコードは、 *.goから読まれたうちの、packageの記述が合っているもののようだ。 そして、テストケース内の名前空間は、 テストされるコードの名前空間と同じみたい
してみると「Go is a tool for managing Go source code.」 サブコマンドとしては、build、clean、…、testなどがあるとのこと。
あー。だからバイナリとかカレントディレクトリには見えなかったのか。
実行される側のソースコードはどういう風になってるんだろう。 普通のGoプログラムは実行を始める場所に package mainを記述してfunc main()を 定義しないといけないようだけれど、btree_test.goにはどちらも無い。 代わりに、package btreeという記述がある。 これは、btree.goというファイル名に対応してるのかな? それともbtree.go内のpackage btreeという記述に対応してるのかな? 試してみる。
最低限packageの行があれば実行はできるようだ。 もう少し何かを実行してもらうには…zunuda_test.goに内容を下記のようにすると
下記のように実行された。 カレントディレクトリには他のファイルは置いていない。
package zundaの行はどのように活用されるのかな。 Pythonみたいにパッケージ名とファイル名を一致させる必要があるのかな。 とりあえずzunda.goにpackage zundaを書いてみる:
packageが一致してると呼び出し元からは指定する必要はないようだ。 zunda_test.goを下記のようにして
go testすると「Hello World」が表示されるが、 Greet()をzunda.Greet()とすると
となる。ではファイル名を変えてみると…
ファイル名は関係なく、 *.goからpackage zundaを頼りにコードを読んでるようだ。
蛇足。importの時はファイル名とpackageとどちらを気にするのかな。 greet.goを用意して:
あれ、8gもgccgoもないよ?gccgoをapt-get installしました。
おや。zundaをimportできるようにするにはどうするんだ? というかpackage mainがカレントディレクトリにあると go testもうまくいかなくなるのだね。
Goのパッケージ?のつくりかたについて勉強する必要がありそうですね。
最近のツッコまれどころ