Journal InTime

_ PEG-TH55

やっぱりSONY製品はかっこいいな。 しかし、「エグゼブラック」と「セレブレッド」ってのはどうかと思うけど。

_ マクロ

人が書いたCのコードをいじっていて

if (foo)
    Error("foo");

みたいなコードを入れたら、なぜかfooが真じゃない時まで上記のところで プログラムが止まってしまった。

Errorの定義を見ると、

#define Error(s) printf("E:%s:%d:%s\n",__FILE__,__LINE__,(s));exit(1)

のようになっていた。ぐは、そりゃ止まるよな。

_ Being a end-hater

うわ、マジで返されてしまった。 ごめんなさい、endはダメダメです。

とか言いつつ反論。

まず、生産性。明らかに括弧の方が生産性は高いですね?文字数

も短いし、 end を使う方式で短いイテレータを一行にまとめようと思う

と';'を補わなきゃいけないのも生産性に負のバイアスを与えてると思い

ます。

個人的には、かならずしも、文字数が短ければよいとは思わないんですけど、

if (x) {
}

より

if x
end

の方が短いですね。(まあ、普通はthenがあるんですけど。)

あと、endはシフトを押さなくてもいいという利点と、日本語キーボード と英語キーボードで同じように打てるという利点があります。 (ちょっとくるしいか…)

次に理解のしやすさも括弧の方がわかりやすいです。とくに非

英語文化圏の人間にとっては「英単語和訳」という作業がない分括弧は

理解が簡単。

括弧自体には(ブロックの範囲を特定する以上の)意味はないので「理解 が簡単」というよりも、そもそも理解を必要とするような情報がないだ けじゃないでしょうか? (まあ、endにもたいした意味はないですけど。)

あと、 ruby の場合だと end に対応する単語が一意に定まらな

いので、パッと見ただけで対応が分かりづらいと思います。インデント

してあれば分かりますけど、それは括弧でも同じなんだから差っ引いて

考えるべきですよね

私にとっては、インデントがないと、括弧でも対応関係は見づらいです。 正しいインデント(?)は可読性の高いコードを書く上では必須だと思いま す。(やっぱPythonか。)

ちなみに、Rubyはcaseさえ綺麗に書ければ{ ... }スタイルの文法になっ ていたかもしれないそうですので、まつもとさん的にはendにはそれほど 拘泥はないのかも。 mputさんの説得次第では、Ruby2は{ ... }スタイルになったりして。

_ end

というか、ちょっと仕事がいそがしくて日記見るのさぼってたうちに、 まつもとさんの反応も あったり、さらにmputさんの反応 もあったりしていたらしい。日記界(?)はスピードが早いな。

結果的に他の多くの言語が「end」を避けている

ということだけど、なぜか自分の気に入った言語はたいていendを採用し ているな。CLUとかSatherとか。 どっちも(Pascal的な)beginはないのがポイント。

あ、待てよ、自分の気に入った言語はたいていCLUとかの影響を受けてるっ てだけの話かも。

_ defに対応するendがわからない

というのは、リファクタリングしてメソッド定義が十分短くなれば解決、 とかそういう話ではないですか。 (というかリファクタリングせねば… > 自分)

_ タイプのしやすさと言語のユーザビリティ

そういえば、まつもとさんに「何でcamel caseが嫌いなんですか?」と聞 いた時に理由の一つとして「シフトを押さないといけないから」とあげ られていた。 その時もつっこんだんだけど、実は「_」だってシフトを押さないと打て ないのだ。(しかも一文字増えるし。)

タイプのしやすさって、実は言語のユーザビリティにとってそれほど重 要じゃないのではないだろうか。 (あんまりひどいのも困るけど。全部大文字とか。)

_ Yarv-devel ML

Yarv-develMLに こっそり参加してみた。 どきどき。

_ SL-C860

仕事で買うことになりそう。

個人的にも欲しいけど、基本的に会社と家を往復する人生なので、使い道がないな。 しかし、往々にして、物欲の前にそういう理屈は無力だったりする。

_ プログラミング言語の将来

本日のリンクで気付いたのだが、Yahoo(というかGoogle)で「プログラミング言語の将来」 で検索すると、 C# プログラミング言語の将来の機能 がトップに来るらしい。

_ Konqueror Embedded

起動中のKonqueror Embeddedに指定したURLを開かせる必要があったのだ が、どうもローカルのファイルを開かせることしかできないようだ。

たとえば、

$ qcop QPE/Application/konqueror 'setDocument(QString)' \
    '/home/zaurus/foo.html'

などとすると、そのファイルが存在すれば、ファイル名に'file:'を付加し たURLを開くようになっている。 (ファイルが存在しないと、'file:'というURLを開こうとしてエラーになる。)

しかも毎回新しいビューを作成するので、上記のコマンドを実行するた びにどんどんビューが増えて行ってしまう。

結局、ソースに手を入れることにしたのだが、クロスコンパイル自体が はじめてなので、ただビルドするだけに丸二日もかかってしまった。

ハマったのは以下の三点。

1. なぜかconfigure時にlibqtのリンクのテストに失敗する。

   リンク時に-lqpeが指定されないせいのようだ。 configureの

   LIBS="$LIBS $LIBQT $KDE_MT_LIBS"

   という部分を、

   LIBS="$LIBS $LIBQT $LIB_QPE $KDE_MT_LIBS"

   のように変更したらパスした。

2. make時にlibjpeg.soのリンクに失敗する。 どうも、libtoolが/usr/lib/libjpeg.so(こいつは当然x86用のバイ ナリ)をリンクしようとしてしまうようだ。

   面倒なので、

   # ln -s /opt/Qtopia/sharp/lib/libjpeg.so.62 /usr/lib/libjpeg.so

   としてしまった。

3. 実行ファイルを生成する時点で、なぜかundefined symbolの嵐。 どうも一部のオブジェクトファイルがうまくリンクされないらしい。

   automake-1.4を使っていたのだが、automake-1.7にしたら解決した。 たまたまかもしれない。

これでビルドはできたのだが、どうも動作がおかしい(スタイラス操作 に反応しなくなったりする)。 zaurus-jaのバイナリはうまく動作するので、同じ日付のものをcvsから 取って来た(-D '2002-12-15'付きでupdate)らうまく動作した。

で、結局起動中のKonquerorに指定したURLを開かせるには、

diff -u -r1.22 mainwindow_qpe.cc
--- konq-embed/src/mainwindow_qpe.cc	24 Jul 2001 16:46:41 -0000	1.22
+++ konq-embed/src/mainwindow_qpe.cc	20 Feb 2004 15:46:15 -0000
@@ -110,8 +110,7 @@

 void MainWindowQPE::setDocument( const QString &document )
 {
-    DocLnk lnk( document );
-    createNewView( lnk.file().prepend( "file:" ) );
+    urlEntered( document );
 }

 #include "mainwindow_qpe.moc"

のような変更でよいようだ。

$ qcop QPE/Application/konqueror 'setDocument(QString)' \
    'http://shugo.net/'

で、それまでさんざん苦労したわりに、あっさり動いた。

_ 果報は寝て待て

昨日apt-get dist-upgradeしたらnautilusが起動時にSEGVするようになっ て困っていたのだが、今日apt-get dist-upgradeしたら直っていた。 nautilus自体の問題ではなかったようだ。何だったんだろ。

やっぱり納期前にapt-get dist-upgradeしちゃだめだな。

_ uim-primeでt-code

やまださんの日記 を見てずっとやろうと思っていたのだが、skkinputを捨てて、uim-prime でt-codeを使ってみることに。 交ぜ書き変換とか、ちょっと使い勝手が違うのだが、結構いい感じっぽい。

ただ、今のモード(直接入力かt-codeか)が表示されないのがちょっと使 いにくい。たぶん何か設定があるんだろうな。 uim-applet-gnomeを入れて見たけど、常に「p」しか表示されないようだ。 うーむ。

_ OSD準拠ソフトウェアはオープンソースソフトウェアか

何でみんなOSDと関係ない文脈で「オープンソース」という言葉を使いた がるんだろう。個人的にはそんなに魅力的に言葉には思えないんだけど。 (ビジネス的には、何となく受けがいいとかいうことはあるかもしれない。 あ、塩崎さん自身は「呼ばれたくない」のか。)

たしかに、 八田さんが書いている ように「オープンソース」という言い方が誤解を招きやすいということ はあるかもしれない。 けれど、それが不都合なのは、どちらかというと、OSD準拠なソフトウェ アを広めたい人々の側にとって、だと思う。

これがラテン語だったらあんまり批判されないんだろうな。

_ PEG-TH55

何かだんだん物欲が高まって来ている。 冷静にならねば…。

_ uim-primeで「メ」が打てない

uim-prime(tcode)で「メ」(,x)が打てないようだ。 ストロークに「,」が入るのがうまくないのかなあ。

Emacsだと大丈夫みたい。

_ SL-C860納品

というわけで、SL-C860とお別れ。

Linuxが使えるのは面白いけど、7万近くするのはちょっと高いなあ。

_ 理屈は物欲の後をついてきます

まさにその通りで、

• そもそも自分にPDAなんか必要なのか。
• CFスロットもbluetoothもないぞ。
• 子供二人もいるんだし貯金せねば。
• きっと次のモデルの方が実用的なはずだ。
• とにかく冷静になれ。

といった理屈は、物欲によって、

• 家でちょっとwebみたりメールみたりするのにきっと便利だ。 C404Sと違ってMP3も再生できるし。
• ほとんど家と会社で過ごすんだから、無線LAN内蔵でええやん。 bluetoothとかついてたってどうせ使わねえよ。
• 今月床屋に行くのを我慢すれば、毎月の小遣いからちょっとずつ貯め たお金で何とか…。
• 自慢できるのはファーストモデルだよね。
• とにかく欲しい。

のように歪められていくのです。

だめだ、落ち着けってば。

_ BREEの財布

そういえばこいつもずっと欲しいんだよな。

このメーカの鞄を愛用しているんだけど、ヌメ革なので使い込むにつれ て味が出て来て、なかなか具合がよいのです。 比較的雨に強いのも、雨の多い松江ではうれしい。

_ helium down

heliumがdisk fullで落ちていた。 原因は私が/usr/srcに残していたカーネルソースでした。 ごめんなさい。ごめんなさい。ごめんなさい。

ビルドした時はまだぎりぎり大丈夫だったのだが、その後であふれたら しい。

それはそれとしてNFSの負荷がえらく高いようなので、NFSをやめるため にディスクの増設を検討中。