おまぬけ活動日誌

● 予算のある町ではこれで除雪をしている。予算のない町は…すべってたのしい。ウニモグを最初に知ったのは「エリア88」だったような気がする。

● 自動的に日誌をカテゴライズするtDiary

ぐうたらな私はセクションタイトルにカテゴリーを書くのが面倒。 日誌の内容を見てソフトウェアが自動的に近い内容の日誌を見つけてくれないかと、 試してみました。

「近い内容」を、 今回は、「namazuのインデックスに共通の単語が登録されている」 と定義してみました。 具体的には、 目的の日と調べてる日に共通する単語のスコアの合計を、 全ての単語のスコアの合計をそれぞれの日について算出したものの積の平方根で、 割りました。 同じ日についてこの値を計算すると 1 に、 共通の単語を持たない日の日記と計算すると 0 になります。

さて、結果は…。

まったく関係のない日の日誌が上位に出てきました。 やっぱりpreについて書いた日誌に近い日誌にもpreのことが書いてあったほしいよね。

そんなわけで実験失敗。敗因は、

• 助詞や助動詞も大量にインデックスされていて、 それらが共通の日誌が上位にきてしまった。
• インデックスが一日単位に作られていて、比較するには話題が多すぎる。

ことくらいでしょうか？今後何ができるか。

• インデックスする単語の品詞を限定する - このホストにchasenの入る場所がないので難しい
• セクション毎にインデックスを作る - namazu側で対処するにはhtmlsplit.plの作りがいまいちだし、 tDiary側で対処するにはhoge_style.rb diary.rhtml squeeze.rb くらいの大改造が必要。
• どこかのSPAMフィルターの記事にあったように、 日誌を書く度に、tDiaryにそれぞれのカテゴリに入る単語を学習させる。 そのうち自動的にカテゴリ分けをしてくれるようになる。 - セクション毎にインデックスを作るよりもっと大変。

と妄想は広がるのですが、本職もあるしこの辺でおひらきということに。 幹にカテゴリ機能がマージされたらzunda_style.rbでも対応するようにしてみよう。 ちゃんちゃん*1。

● 表紙の写真を更新しました

ほぼ二ヶ月振りだ。⊂ななんち⊃復活記念ということで♪記念というほどの写真じゃなくて申し訳ないけど。

● 渡航情報 ミュンヘン（ドイツ）：ミュンヘン安全保障会議

2月7日（金）から9日（日）にかけて、ミュンヘン市内中心部のホテル・バイエリッシャホーフで毎年恒例のミュンヘン安全保障会議が開催されますが、同期間中、特に8日（土）は市内中心部各地で大規模なデモが予定されていますので、デモに巻き込まれないようご注意願います。

とのこと。土曜日に危険なのは、

• 10:00マリエンプラッツ→17:00イザールトア、カールスプラッツ
• 10:30オデオンズプラッツ→14:00ミュンヘナーフライハイト

とのこと。買い物に行きたいんだけどWal★Mart周辺で済ますべきか。

2ch経由、海外安全ホームページより。

● subversionウゴキマセン

いったいどうしろと…

(追記)Googleの検索結果を開きまくると、httpdのlibaprのABIが変わると起きるという例が。確かに手元の.svn/entriesでもprop-timeとtext-timeがおかしな値になっている。subversionはリビルドしたのだけれどhttpdも含めてやってみようか。httpdをリビルド、インストールした後にリビルドしたsubversionは期待通りに動いているようです。

やっぱりGNU archまじめに使ってみようっと。

● 昨日帰るときにボロい方の自動車のウインカーの電球が切れているのに気づいた。今朝は自転車に空気を入れてから出勤しようと思ったら空気入れが壊れた。空気入れは圧力がかかるところの鋳ものがぼろりと折れてしまったので、20分エポキシでくっつけてみた。直るかな。ウインカーの電球は買いにいかなくちゃ。

● 内之浦・ロケット観光ガイド - M-Vの打ち上げを見に行こう!

ASTRO-EII打ち上げの時のレポート。Space Fighter Nowからリンクされていて改めて見た。

(5) 大混雑の打ち上げ当日の動画は必見。いやー、打上げを見学に行きたくなる気持ちがわかりました。

…そしてなぜか「王立宇宙軍」を観たくなる。

しごとしよ。

● dvipsとps2pdfでミルカさんを読む

以前から気になっていた、TeX文書のPDF化の方法について。メールに添付した論文の草稿のPDFファイルがGMailのHTML化機能でかなりちゃんと再現されていたのを見て、またやってみようと決心しました。

ありがたいことに、ミルカさんとコンボリューションでTeXのソースが公開されています。これをいただいてきて展開し、奥村さんのスタイルファイルも同じディレクトリに展開して、下記のようにPDFファイルを作成しました。

これをgpdfで見るとこのとおり。一見うまくいったように見えますが、実は再描画すると以前と同じくガタガタの表示になってしまいました。

ツールのバージョンは下記のとおり。

やっぱりxpdfだと問題ないんだけどなあ…。

● LaTeX2HTMLでミルカさんを読む

調子に乗ってLaTeX2HTMLも使ってみました。あまりメンテしていないマシンのものなので古いです。WWWブラウザに表示された内容を縮小してあります。

この絵だと画像ファイルとして表現されている式に下線がついてしまっているけれど、まじめに環境設定すればもう少しきれいに出力されるはずです。まじめに環境設定しなきゃいけないところが問題だけれど、最新版だとだいぶ改善されてるのかな。

● ポンプはエポキシではなおらない

昼休みに空気を入れてみたら空気漏れてました。だめかー。電球は買ってきたので自動車で仕事場に。

● [run] CSO延長29分28秒

久しぶりなのに調子がよかった。走りはじめにゆっくりするのが重要か。

● gettextで得られる文字列を入れるバッファの大きさはどうやって決めるんだろう？

@ITに、「ロケールの問題でプログラムが正常に動作しない場合には」という記事が載っていた。gripというプログラムを例に採って、LANG=Cで使えるプログラムが日本語ロケール(ってFC6ならja_JP.UTF-8なのかな？)で使えない場合にどうやって修正するのか解説してある。曰く、char versionbuf[20];をchar versionbuf[22];にしろ、とのこと。えぇーっ？「ここで挙げた対処方法は、あくまで暫定的な措置なので自己責任の下で作業していただきたい」と断り書きがあるにせよ、これはさすがにまずそうだと感じる。きっと他のロケールで落ちる。

興味が湧いてきたのでコードを覗いてみることにした*1。grip-3.2.0のsrc/grip.cに下記のようなコードがあった。

VERSIONはconfig.hで定義されるマクロだろう。

この場合、versionbufに必要な大きさは実行時まで不明ということになるのかな。なら、malloc(3)でメモリ領域を確保するべきなんだろう。C99ならsnprintf(3)で必要なバイト数を測るか、C99が仮定できない場合にはprintf(3)のmanページにあるコードでメモリ領域を確保しつつ文字列を作ることになりそう。

さて、こうやってmalloc(3)で確保された領域の文字列をgtk_label_new()に渡した場合はこの領域はいつまで確保しとかないといけないか…ちょっと探しただけではわかませんでした。GUIは難しいね…結論はそれか？

● [memo] Debian:i18n (ukai.org)

gettextについていろいろ探している過程で、「i18nについて世界のdeveloperにたいして言わなければいけない時に忘れてはいけないポイント」の書いてあるページをみつけました。もし国際化するべきプログラムを書く時があれば参考になりそうだ。i18nについて自分にたいして言わなければならないポイント。

● Citrixのウインドウを画面の端にドラッグして離したらメニューバーにアクセスできなくなった。もう用済みなので閉じたいのですが。ローカルのWindowsからはウインドウが選択されていないように見えるようで、Alt+F4でも閉じられないし、Alt+Space-Mでも移動できない。ネットワークが切れる(そのうち必ず切れる)のを待とうかとも思ったけれど、スタートメニューの横にならんでるアイコンを右クリックしてCloseを選んだら閉じられた。しかしデータベースとやりとりするのにデータベースサーバのウインドウを持って来ちゃうってのは斬新な発想だよねえ…。

● オモコンマシン死亡

ハードディスクの問題じゃなかったか…。 フリーズ時のtopは下記のような感じ。gccを作り中でした。 やっぱりファイルの操作時に不安定になるみたい。

kernel-2.6.20に行ってみるか？ハードウェアの問題か？泥沼か？うーん…

(追記) 8日に古い方のハードディスクを物理的にはずして再挑戦。

で目の前で止まってしまいました T_T マザーボードか電源か…。嗚呼。

● parse error, unexpected $, expecting kEND (SyntaxError)

そういえば昨日職場でPythonのスクリプトを書いていた。

● 久しぶりに青空。真っ白な山頂がちらっと見えた。自動車の窓を開けて走って中を乾かす。気持ちいいあぁ、と思ってたら午後になってまた天気悪くなってきましたよ。

● [Android] x86_64に開発環境を作ってみる (失敗編)

先日32ビット環境でやったのと同じことをやったら64ビットではやっぱり動かなかった。

Android SDKのダウンロードと展開。 Download the Android SDKから、 android-sdk_r04-linux_86.tgz をいただいた。 ダウンロードしたファイルは展開して、 android-sdk-linux_86ディレクトリ以下のファイルを $HOME/local/android-sdk/r04にばらまいた。 .bashrcには下記を追加した。

さて。adbの起動。

やっぱりなー…。

● Nexus OneにN810のUSBケーブルを使える

Nexus OneのSDカードの内容をバックアップしようと思って付属のUSBケーブルを持っていないことに気づいた。手元にあったN810のUSBケーブルでマウントしてバックアップできた。どちらもMicro USBだもんね。Nokiaのケーブルはコンパクトにまとめる部品が付いているので持ち運びやすい。これからもこちらを使おう。

しかしOTGにしたりホストにしたりもしたいよな。

● [Walk] 徒歩

33分52秒、平均103 BPM。意識して手を振ると脈拍を上げることもできるかもしれない。

今日はMyTracksで距離も測ってみた。3.19km、5.7km/h。

● [Android] 64ビット版のSDKは作れないことがわかった

64ビット版のMomonga 7ではダウンロードしたSDKが走らないことがわかったので、64ビット版のものを自分で作ってみようとしました。 できませんでした。エミュレータのアセンブラコードが対応してない感じなのでしかたがない。

準備。 Get Android Source CodeによるとPython 2.4、SunのJDK 6 (Gingerbread以上)、Git 1.5.4以上が必要とのこと。 Momonga 7にはPython 2.6.5が入っている。だいじょぶかな→ちゃんと進んでるようだ。

Sun (Oracle)のJDK6は必要だろう。 jdk-6u23-linux-x64-rpm.binというのをいただいてきた。

不要なもの入れられなくて良かった。 別途rpm -Uvh jdk-6u23-linux-amd64.rpmしましたが、 いろいろあって 消しちゃいました。なぜか消すときには、 rpm -e jdk-1.6.0_23-fcs.x86_64。 これも不要だったようだ。

ソースコードをいただいてくる。まずはrepoコマンドの準備。

お、gitの設定の再確認をされますね。

レポジトリの同期。週末がだいたいこれで過ぎさりました。

さてさて。

おー。いっぱい来てる。

Get Android Source Codeの「Verifying Git Tags」に従ってGPG公開鍵もimortしておきました。 ここで読みこまれたのは、

作ってみよう！ そうそう、Command not foundというとで、bisonを入れました。

/usr/include/stdlib.hを眺めると、__WORDSIZEが32なようだ。 ここでエラーが出ているコマンドそのものを見てみたいよね。

して見てみると、下記のコマンドのようです。

g++ -I external/expat/lib -I external/libpng -I external/zlib -I build/libs/host/include -I frameworks/base/tools/aapt -I out/host/linux-x86/obj/EXECUTABLES/aapt_intermediates -I dalvik/libnativehelper/include/nativehelper -I system/core/include -I hardware/libhardware/include -I hardware/libhardware_legacy/include -I hardware/ril/include -I dalvik/libnativehelper/include -I frameworks/base/include -I frameworks/base/opengl/include -I frameworks/base/native/include -I external/skia/include -I tools/include -I out/host/linux-x86/obj/include -c -fno-exceptions -Wno-multichar -m32 -fPIC -include system/core/include/arch/linux-x86/AndroidConfig.h -D_FORTIFY_SOURCE=0 -DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -O2 -g -fno-strict-aliasing -DNDEBUG -UDEBUG -DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -Wsign-promo -DNDEBUG -UDEBUG -Wno-format-y2k -MD -o out/host/linux-x86/obj/EXECUTABLES/aapt_intermediates/AaptAssets.o frameworks/base/tools/aapt/AaptAssets.cpp

やぱ-m32が入ってるな。これが無ければコンパイルは通る。

トピックブランチを作ってファイルを編集してみよう。

まずは、ビルドプロセスの最初の「HOST_ARCH=x86」を変化させてみました。

さあどうだ。

だめか。

じゃあ-m32を強制しているところを削除してみる。

最初さいしょ！

We build everything in 32-bit, because some host tools are 32-bit-only anyway (emulator, acc), ...

読まなかったフリして、zlib-develを入れつつ進みましたが、

あー…。やっぱりダメでした。

というわけで32ビットパッケージを入れる方向に進みます。

● [Ruby][Ubuntu] Ubuntu 14.04でruby2.0を使う

/usr/bin/rubyが新しくならなくなったのな。