lkml(lkml.org)。 いつの間に！？ 大量のメールが嫌でRSSリーダ大好き、という人にはけっこう便利かもしれないな。サマリつきで最新100エントリが配られてます。著者別にはできるみたいだ。 私は追っても疲れるだけだから、読まないけど。

レビュー：Fedora Core 2(linux.com)より。

右に示すスクリーンショットを見ればわかるとおり、[File Open]ダイアログ・ボックスから、ファイル名を入力する場所が消えてしまったからだ。

…あ、ほんとだ。これはヒドいなぁ。 そういう点では、GNOME 1.4(というかGTK 1.2?)のファイルダイアログは傑作だったと思う。bashと同じかそれ以上のファイル名の補完ができる。これ以上はないほど、非常に、使いやすかった。 ファイルダイアログは良くなったってGNOMEのサイトには書いてあって、bookmarkできるとか、いろいろ特徴が増えたと思っていたのだが…あのセンスはどこへ行ったのだろうか。 残念だ。

X用のGNU screenを書こうとした奴はいないのだろうか。あったらあったで、便利だと思うのだが。 ブラウザをdetachしてログアウト、次にまたログインしたときにattach、とか。 すごく遅くなりそうな気がするのは気のせいだ。気のせいに違いない。

UTF-8とEUC-JPとShift_JISとISO-2022-JPが混ざったテキストファイルがあったとして(そんなファイル作るなよって話？)、しかし1行の中ではさすがに文字コードが統一されているとして、Pythonで全部の行に対して例外が出なくなるまでやってみればいいんじゃないか、と思ってみた。 やってみたら、codeconvert.pyとなった。まずまず、そこそこの精度。 EUC-JPだけのファイルにやってみたらUTF-8で例外が出ないことがあって、つまり間違うことはあるものの、まあまあな感じ。とりあえず、こんなもんでいいかな。 このリストにいろいろコードを追加していけばもっといろんなコードや言語に対応できるし、優先順位をいじれば精度が上がるかもしれない。あと精度という話だと、encode()のところの例外を処理して失敗したらguessをやりなおすようにすれば、もっと上がりそうな感じもする。EUC-JPをUTF-8だと思ってしまう場合は、encode()のところで例外が出ることが多い。

Fedora Core 2を昨日入れてみたら、早速gaimのアップデートが出ていた。機会を見て、メインの環境を今のRH8ベースのむちゃくちゃ状態から移行してみようと思う。 絶対ハマると思うけど。 (追記) 2004-05-20 20:10 USB1.1接続のDVDでmplayerを使うと、普通に見れるようになっていた。以前(というかRH9時代)はダメだったはず。たぶんUSBストレージのドライバのせいだったのだが、Kernel 2.6の威力なのかもしれない。思わず見入る。 mplayer、なんか使いにくいな。あとIIIMF+Canna、いいかげんにしてほしいところ。ふつーskkinputだろ？ (追記) 2004-05-20 20:33 でもさー、yumのコード追って$releaseverの由来見ていくと、Fedora Core 1をFedora Core 2にシンプルにアップデートするとき(コンパイルのないmake world相当？)って、まずfedora-release-2*.rpmをインストールして、あとはyum updateだけで終わり？ 果たしてそれだけでいいのか？？

zipext2.py。pyid3lib(sourceforge.net)を使ってMP3のID3タグのエンコードも変換してしまうように変更。これで、 Linux# python zipext2.py -c -m hogehoge.zip で作るとhogehogeディレクトリ以下のファイルはファイル名は全部、そしてMP3のID3タグをEUC-JPにしている人はShift_JISに変換される(Windowsで見える)。 Windows側でzipに入れたMP3は Linux# python zipext2.py -m hogehoge.zip とするとLinux用になるはず。失敗してたらわりいって感じで。-cがzipファイルを作るオプション、-mがMP3の中身を触る、というオプション。 本来はID3タグはtextenc(だっけ？)を1(だっけ？)に設定してUnicodeにするほうが王道のような気もするのだが、仕様もよくわかってないのでShift_JISにしてWindowsで読めればそれでいいじゃん、みたいな感じにしている。 例によってz2hオプションとstringmisc.pyで全角から半角に変換する。ID3タグについても同様。半角から全角に変換するオプションは、ない。 Linuxではファイルシステムやその他いろんなツールがだんだんUnicodeになってしまいつつある。だから、ファイル名のエンコードを変換しながら移行する、というニーズはこれからどんどん増えてくると思う。ファイルシステムを信用せず(？)にアーカイブして、そのおかげでファイル名が化けるというのもバカバカしい話だ。 ID3タグのエンコードについては私だけの問題で、ID3だけの変換はid3encode.pyみたいに分けて使ってもそれなりにいいかな、とも思います。しかしよくわかってないけど、textenc=0ならISO8859-1なはずじゃないのかな。EUC-JPやShift_JIS入れてなぜか読めちゃってるのが悪い？

リリースされました(redhat.com)。いろんな問題が大丈夫になったのか心配だ。 とりあえずBitTorrentで落とし中。しかし…のっけからupのほうが多いよ(笑) (追記) 2004-05-19 10:12 落とし終わっていたので、焼いた。世の中のため(笑)、しばらくはBitTorrentを上げっぱなしにしておくことにする。 リリースノート見てたけど、VNC経由のインストールとかってのがあるな。画面をVNCに飛ばして、そこからインストーラを操作するってやつみたいだ。フロッピーブートを捨てたのはさすがに暴挙と言うべきかもしれない。

EsounDについて。 EsounDは複数の入力を混ぜられる。複数の曲を混ぜて演奏したり、音楽を聞きながらも別の効果音が出たりするわけだ。実はEsounD以前のLinuxではこれが珍しかった(笑)。使わない間は勝手に消えてくれたりといった小技も含めつつ。 EsounDが使えるバックエンド(ドライバ側)にはALSAやOSS、AIX/IRIX/HPUX/Solaris等のサウンドデバイスがあり、アプリ側からはデバイスを意識せずに同じインタフェースで使える。ネットワークにも対応していて、別マシンに音声を飛ばして鳴らすようにできたりする。いくつかのユーティリティが附属していて、演奏やら録音やらボリューム制御やらその他ができる。 私としてはALSAとOSSが並び立っているLinuxで、両方に対応したEsounDのバイナリを作っておいて、設定で切り替えられるのではないかと、思っていた。ALSAはOSS互換にもなるので、OSS→ALSAのOSS互換→ALSAという移行ルートがあるわけだ。私はいまだにOSSでやっているのだが、実際使うときはどうせEsounDが吸収するしなぁ、と。 で、ALSAのヘッダとかを用意してEsounDをコンパイルし直して、OSSで動かそうとして…それができないことが判明。ソースを見るとaudio.cの#includeで#elif #elifで切っていた。ありがちだ。

zipfile.pyを使って変なものを作ってみました。必要な局面もあるでしょう。zipext.py。~/lib/以下にstringmisc.pyを置いておくと、-z(–z2h)オプションが動くようになります。ヘルプ等はまだ書いてませんが、大したオプションはないので。文字コードの指定とかその程度で。 Windowsユーザがくれるzipファイルは中のファイル名の文字コードがShift_JISだったりするのですが、Linuxでそのまま展開するとファイル名がぐちゃぐちゃなのです。またそのファイルは往々にして全角半角にも無頓着だったりするのですが、それを半角に統一してもらおうという、そういう話です。自分のファイル名の文字コードがEUC-JPなのでデフォルトをEUC-JPにしてあります。FedoraとかだったらUTF-8にすればうまくいくのかな？？ まだ書きかけで、いろいろ不満な点もありますがとりあえずえいやと公開。後悔？ TarFileCompatってtar.gzとかtar.bz2とかの圧縮した形式は扱えないのだろうか。なんかエラーが出るんで.tarのみを判別している。

速度の変化の話の続き。いま起こってます。xmmsでの演奏1分が実時間では55秒でした。音程はさほど外れてないような気がするけど、言われてみると少し上にずれてるかもしれないなと思う。テンポの早い曲だと違和感が増える。 おもしれー…って話じゃなくて、なんでだろう。xmmsのせいか？ esdとかLinuxの問題なのかもしれないなぁ。 (追記) 2004-05-11 11:29 esdを殺して起こし直したら直った。 # killall esd; esd -nobeeps & (追記) 2004-05-12 13:55 あー、またなったよ。どうなってんだ。やっぱちょっと音程も上がってんな。