|
．mozilla-0.7 をインストールした。軽いのはいいのだけど、 どうも AAAA が引けるホストだと無条件に IPv6 コネクションを 張りに行っちゃう模様。 gethostbyaddr2 が使えて、AAAA が引けても IPv6 が使えるとは 限らんと思うのだが。よって、うちでは AAAA があるホストのページが ことごとく見れなくなった。というか、最初は localhost の apache が 見えなくて悩んだり。 telnet localhost したら「::1 が reject されたぞ」とか出てきて気づいた。 もちろん、こっちは /etc/hosts を書き換えて対処したけど。 ．こういう場合はどうするのが正しい処理なんだろ。
．ローカルな解決策なら、 「いちいち /etc/hosts に書く」とか「IPv6 環境を整える」という手もあるが、 まあ、とりあえず mozilla を build し直すか。mozilla を直すより libc に kludge 入れたほうが、はるかに時間がかからないのが泣ける。 ．make clean だけで 10 分くらいかかるから、 さいわい make clean せずにいたので、nspr の pripv6.cpp で _pr_ipv6_is_present 変数を強制 FALSE にするようにして make package 。 ．itojun さんによると、getaddrinfo を使うのが正しいらしい。 RFC2553 。結局上記 2 の「IPv6 で失敗したら IPv4 に fallback する」を やるために、socket を開くところまでは IPv6/IPv4 の情報を 全部持っていかないといけないわけなのですが、 man によればそれをアドレスファミリー非依存な形でやるのが getaddrinfo らしい。mozilla では IPv6 で gethostbyname2 できちゃったら、 単純に IPv6 で connect できるもんだと思っちゃってるのよね。 ちなみに、nsprpub/pr/src/misc/prnetdb.c でアドレスひいてるけど、 むちゃくちゃ汚いソースで読みたくないでござる。 |
|
．quirk code を作る前に usbd_bulk_transfer を使うのをやめようとしてハマる。 ．いままではとりあえず出力に usbd_bulk_transfer を使っていたのだが、 こいつは見事に tsleep してくれるので、 EINTR の処理がやりにくいことがわかってたから、 MIDI_PROP_OUT_INTR と callback を使って処理するようにしたわけだ。 ところが、どうも送られてくる MIDI byte がおかしい。 じーっといろんなところ眺めてたら、midi ドライバの critical section の 保護が不十分であることが判明。 でも、それを直してもうまく動かない。 んで、追っかけたら midi ドライバ側の ointr の扱いがおかしいことが判明。 割り込みが来てないのに hw_if->output 呼んだら、 パケット落ちるかあふれるか、いずれにしろ嫌なことになるよな普通。 おかげで umidi 側の queue を破壊してくれていた。 ．つーわけで、いろいろ直して動くようにしたのだが…。 umidi では 1 byte ごとに割り込みかけられるわけじゃないので、 どっちにしろ midi ドライバに手を入れる必要があるから、 そういう変更をしたのだが、でも美しくない。 それに、umidi 変更していいなら usbd_bulk_transfer でも 正しく処理できることに気づく。うーん、どうしようかな…。 変更点が少ないのは後者なのだが…。 ．結局折衷案。usbd_bulk_transfer だと、送出後に wait することになるので、 EINTR で戻ってきたときに最大 4 バイトの MIDI bytes を どう push back すればいいのかよくわからないし、 なんとなく EINTR のタイミングによっては嫌なことになりそうなので、 やっぱり usbd_bulk_transfer だと難しい。 そこで、callback は umidi で用意するのだが、MIDI_PROP_OUT_INTR は 使わずに、hw_if->output の先頭で転送終了してるかどうかを見て umidi ドライバのほうで sleep させる。 で、midi ドライバは EINTR を正しく処理できるようにする。 こうすれば、midi ドライバは EINTR が来たときに 常に 1 byte だけをバッファに push back すれば済むことになるわけだね。 ．って、write で EINTR 食らっちゃうと困るから、 tsleep に PCATCH を付けないで解決。結局 midi 側は手を入れる必要なし。 ．と思ったら、/dev/sequencer では process に裏打ちされてないから tsleep 使えないやんけ…。うーむ、うまくいかない… ．しょうがないから、ointr 使うバージョンに戻してみた。 |
|
．昨日、どうやっても midiplay でオレ SMF を 鳴らすと正しく鳴らない (/dev/rmidi をあたかもシリアルデバイスのように叩く オレ SMF プレイヤーなら鳴る) ので、会社来てから sys/dev/sequencer.c をざっと眺めてみたが、 何かいろいろと変かも…。とりあえず、エラー処理がまともじゃないので、 midi_writebyte から EWOULDBLOCK とか返ってきちゃった時に ．でも、umidi の、 「ointr を使わずに、tsleep のところで オレ spinlock (busy loop ともいう)を使って同期とるバージョン」 と「ointr を使うバージョン」で、 出る音の間違いかたが同じなのが気になるのう。 最後の手段として、 手持ちの Super-MPU/AT を挿して、 mpu ドライバでちゃんと鳴るかどうかの確認をして、 問題の切り分けをするしかないかのう。 |
|
．某 ML に、/tmp のクリーンアップの質問があったので、 それに返事を出したのだけど、シェルスクリプトを secure に 書くのはホント難しい。 ．なにも考えないバージョン: find -d /tmp -mtime +7 -a -type d > /tmp/find.$$ find /tmp -mtime +7 -a \! -type d | xargs rm xargs rmdir < /tmp/find.$$ rm /tmp/find.$$ ．これには、私が気づいただけで 2 つほどセキュリティホールがある。 一つは、/tmp に対して、予測可能なテンポラリファイルを 無条件に使ってること。まともにやるには存在チェックしないと いけないんだが、基本的にアトミックにやる必要があって難しい。 もう一つは、ハイフンで始まるファイルが与えられた時に、 何が起こるかわからんこと。 ．1/23 注記：以降、全然安全じゃなくて危険です→多分、私が better だと思う方法は、 find_tmp=/var/find-tmp if [ -d $find_tmp ]; then find -d /tmp -mtime +7 -a -type d > $find_tmp/$$ find /tmp -mtime +7 -a \! -type d | xargs rm -- xargs rmdir -- < $find_tmp/$$ rm $find_tmp/$$ else echo $find_tmp is not directory. 1>&2 fi ．なのだが、ホントは /var/find-tmp の パーミッションチェックもしたほうがいいし、 それ以外にもまだ穴があるかもしれない。 特に、symlink とか special file のたぐいは怪しいかもしれない。 ちなみに、 /var/find-tmp はあらかじめ作っておくこと。 まあ、素直に ruby か perl に逃げたほうがいいのかもしれんな。 ．どっかに、シェルスクリプトを secure に書く方法、っていうドキュメントは ないのかな… ．白井さんからは、
find /tmp -depth -mtime +90 \
\( -type d -exec echo rmdir --ignore-fail-on-non-empty -- {} \; \
-o -type f -exec echo rm -- {} \; \) \
| sh
．などというものが。なるほど。 ←ここまで危険：注記 1/23 |
|
．昨日家帰ったら(み)の人が既に解析済み。 ．つーわけでできました： uhub1 at uhub0 port 1 uhub1: DreamsComeTrue CO.,LTD HubCot 2Port HUB, class 9/1, rev 1.10/1.00, addr 2 uhub1: 3 ports with 3 removable, self powered utoro0 at uhub1 port 3 configuration 1 interface 0 utoro0: Toro's keyboard. (from "Dokodemo Issho") wskbd1 at utoro0 mux 1 ．やっぱりアレはキーボードだよね、ってことで、wskbd として実装(ぉぃ。 beep すると動くのだ :D ．…ああ、やっぱりこういうおバカなデバイスは楽しいのう。 まだちょいと、beep パラメータの扱いがいまひとつなので、 そこは直さんといかんな。 |
|
．単なる synonym です 。 オペコードは同じ。アセンブラ言語で記述する場合に、 jne は compare の結果等しくないことを期待するセマンティックで使って、 jnz は zero flag = 0 であるということを期待するセマンティックで使う、 ただそれだけですね。 あるいは、前者は符号つき算術比較のジャンプ群の仲間で、 後者は符号なしバイト比較のジャンプ群の仲間、と見てもいいかも。 |
|
．そうか、ひろゆきちゃん(not 2ch)は最近日記らしきものを書いてたのか。 ．ところで、「ミリバール」を Unicode に入れようプロジェクトってどうよ。 |
|
．midi? at utoro* を実現して Leroy Anderson のアレをやろうと思うが、 どうだろう。ついでに、umidi のデモにもなるな。 ．問題は、マシンを誰が用意するのか、ってことかも。 |
|
．ああう、soda さんに指摘されて気づいたが、 大穴を見逃していた。昨日のあれは、 retrieve 中や、リスト作った直後から消されるまでの間の 一瞬(といっても、これはいくらでも引き伸ばせる)を突いて mv → ln -s されると非常に危険です。 ．また、sh に食わせてもいけません。 なぜなら、他のツールの助けを借りずに、 どうやってもすべてのメタキャラクタを正しくエスケープできないから。 たとえば、'...' でくくったとしても、 ファイル名自体が ' を含んでいたら無意味です。 ．あと、こっちはちょっとだけ某 ML にも書いたのだけど、 テンポラリファイルの方は、/tmp に一発ディレクトリを掘って、 その中に作れば平気です。 ただ、Linux の場合、ちょっと前まで mkdir が follow symlink してしまう 大穴が開いていたので、ちゃんと確認しないとダメです。 ．こういうことをやる場合、perl も信用できなくて、 一番信用できるのはやっぱり C かもしれない。 /tmp のクリーンアップでは、chdir するたびに getcwd して、 変なトリックをされてないか調べつつ、 一段一段 chdir してゆく必要があります。 |
|
．やっぱりあと 25 年は著作権上まずいので、やめ。 ．自分で曲を書くか、あるいは、著作権切れてるクラシックの曲で、 マッチしそうな奴を探すかな。 何かいい曲あったらメールかチャットで教えてください。 ．…トルコ行進曲とくるみ割り人形(行進曲)とかどでせう。 |
|
．についていろいろ考察。 ．結論から言ってしまうと、可能です。 つーか、XFree86-4.x はこれに近いことやってるし。 ただし、dynamically linked な場合よりもシンボルの 扱いがシビアなので、厳密に ABI を規定する必要がある。 ．しかしながら、一番現実的な ABI 規定は、 「モジュールは実行ファイル側のシンボルを参照しない」 でしょうな。結果、モジュールはモジュールで libc_pic.a のファイルを リンクすることになる。よって、えてして両方に同じコードが入ることになるし、 同じライブラリルーチンがそれぞれ独立した state を持つことになるけど、 それは使う側がちゃんと考慮する。 もう少しトリッキーにやるのなら、 常に解決できることが保証されているシンボルのセットを 規定することだけども、これは一度も使われないかもしれない 関数がすべての statically linked binary に入るし、 そうでないシンボルはやっぱりモジュールが自分で libc_pic.a のファイルを リンクしなければいけないので、そもそも dlopen を使いたい、 という目的の本質からするといまひとつ。 |
|
．パッチ要求されてやぶへび。 ．んーと、あれだ、そもそも、WITH_RUNE オプションを潰したほうが よさそうな気もしてきたぞ。 ．と思ったが、CPICFLAGS+=-DWITH_RUNE で逃げる模様。この方が、 変に手を入れるよりはまし。 |
|
．midi? at utoro* は昨日ちゃんとできました。しかしながら、 おれリポジトリに -current を sync して、UMIDI ブランチの conflict *1を解決してるうちにどうしても 眠気に堪えられず寝てしまった。 ．公開はもうちょい待ってね。オープンソースまつりには間に合わせるにょ。 |
|
|
．そうそう、 いい逆アセンブラ使いましょう 。 私は これ を愛用。いろいろ小細工してて、しかも UNIX でも ソースの改行コード変えるだけでコンパイルできて便利。 ．最近は、intel.co.jp で日本語のマニュアルも落とせるのがいいのう。 |
|
．残念ながら、アレと思いっきり limit が重なってるので、 仕事中にでも原稿書かん限り引き受けられませんな。 いくらなんでもそれはマズい。 ．GNU make / pmake の使い方とか、Imakefile の書き方は、 暇を見つけて一度 Web でまとめようと思ってたところだから、 原稿に便乗できれば都合がよかったのだが、タイミングが悪かったね。 |
|
．fully agreeeed 。 逆汗そのものはほんの手段に過ぎませんし、 ソースがあればそのほうがずっとよい。 ．逆汗してて楽しいのは、 コンパイル後のコードを読むだけでも、 書いたプログラマのレベルが容易に想像できることだな :D |
|
．市場経済の正義を絶対的価値観として持ちこむ論調はうんざりだね 。 まあ、マイノリティのペシミズムってのもそれはそれでアレなのだけど、 でもどうもマスコミは、自分たちの正義は普遍的な正義と信じて 疑わない傾向があるからなぁ。 私からみれば、正義なんて本質的に宗教の一種だと思うから、 これは天に唾する文章としか読めないんですけど。 いつから、Linux ってのは、市場主義が唯一絶対の正義になったんだろう。 ．よくあるシナリオってのは、みんなが趣味で使ってたものを、 後からやってきた誰かがお金もうけで使いはじめて、 いつのまにやら趣味第一のものをお金儲け第一のものへ誘導してる、って奴ね。 根本的にそういう人間は、 「儲かることこそ正義」「正義こそ正しい」という思想に、 半ば無意識的に毒されてるから質が悪いよな。 Unicode しかり。だいたいにおいて、uni- とか pan- とかいう奴は、 ろくなことがないね。でも、えらい人はそれがわからんのです :-P |
char const month[13][4] = { "...", "Jan", ... , "Dec" };
memcpy(str, month[m], 4);
と等価なので、素直にこう書いたほうがいいでしょう。
．ちなみに、
char const month[13][4] = { "...", "Jan", ... , "Dec" };
と
char const * const month[13] = { "...", "Jan", ... , "Dec" };
は等価でないことに注意ですな。 ．…って、day of week じゃなくて month か。こっそり修正。 |
|
．最近こんな話ばっかだな… ．個人的には、デスクトップマスコットのコアプログラムごときで 金とってる時点で脱力してくるのだが、それだけならいざしらず、 偽に負けそうだからって高圧的な警告文送っちゃ、 技術屋として敗北宣言だよなぁ。 もっとも、偽は偽であからさまにケンカを売ってるわけだから、 第三者的視点からすればどっちもどっちだと思うが。 まあ、何か見てると、「オレより人気あるもん作りやがってけしからん」 っていう嫉妬が根底にあるような気がするから、 ページの名前変えたりしたくらいじゃ納得しないんじゃないかのう。 一回素直に要求を完全に飲んじゃって、そのうえで、 「次回作」ということで、また似たようなデスクトップマスコットを 出すのが、横紙破り対応の基本であるところの、腐れ縁を断ち切る、 という観点からはいいと思うんだな。 ．私は、個人的には偽春はあまり萌えないんだな。ソース見れないから。 いや、別にどっかみたいに、セキュリティうんぬんとか オープンソースマンセイとかいうような崇高なことをいうつもりはなくて、 多くの場合、私はこの手のものは中身にしか興味ない。 つまり、個人的にバイナリ不感症なんだな :D。 本当に興味があるもんなら、それこそ逆汗してでも覗くのだが、 偽春に関してはそこまでの興味はない。 あるいは、ソースがあれば、それこそちょちょいと X 版作っちゃるのだが、 さすがにスクラッチからクローンするほどの暇はないしのう。 ．…秘密に期待(ぉ |
|
．うーん 。 「13 個の要素を持つ char * の配列」っていうスケールだから どっちがいいかは微妙なのだが、私も static にするなぁこの場合。 ．なんでかっていうと、この手の関数の呼び出し頻度はそれなりに 高くなる可能性があるから、そのたびにいちいちスタックフレーム 初期化されてたらたまったもんじゃないから。 それに、てうるさんが誤解してるのは、 結局ね、この配列初期化するコードって、こういう感じ： になるか、あるいは、(実際の gcc だと) なんだわ。char * の配列だから、それぞれの要素値は 単純なアドレス加算では計算できないので、 いずれにしろ、この配列を初期化するための インデックス値がメモり中に永続的に残るのは変わりません。 ．あとは、スタックデータをあまりでかくしたくない、 というのもあるな。スタックは一般的には貴重な資源です。 今の OS のユーザプログラムならいくら増やしても平気ですけど、 たとえばカーネルスタックはそれほど大きくなかったりしますし。 ましてや、MS-DOS あたり(カーネルスタックもそうだが)では スタックあふれると悲惨なことになりますな。 ．まとめると、
という欠点があるので、この場面で static を付けない 積極的な理由は無いでしょう。 ．昨日のもちょっと細かい修正。 ．そういう場合 は、const 修飾子で右と左に分割して、左のものに const が修飾された上で、 その左側全部が右にかかる、と見ればよいです。たとえば、 int const *a; は、const は int を修飾したうえで、それが * にかかって a にかかるので、「int const へのポインタが a」になります。したがって、 a = 0; /* valid */ *a = 0; /* invalid */ ですし、 int * const a; は、const は 「(int の)ポインタ」を修飾したうえで、 それが a にかかるので、「int の const なポインタが a」になります。 したがって、 a = 0; /* invalid */ *a = 0; /* valid */ です。 |
|
．ここで私の名前だけ出て、樋浦さんの名前が出てないのは、 何らかの政治的な動きがあったのだろうか…。オレの名前だと、 単なるオレの妄言としか取られないと思うぞ(苦笑)。 ．実際に出したコメントは、 樋浦さんと相談して書いたもので、 私だけではなくて樋浦さんの名前もあったのだが。 \ ．そうえば、国際化チュートリアルの続きを期待してるんだけどなー。 Xlib-I18N に関しては、himi さんが積極的にやってるようなので、 少し静観。って、NetBSD とかでテストしてあげないといかんな、やっぱり。 |
|
．しばらく時間が取れないのでアレだが、 iconv は早急に用意しないといけないアイテムの一つだな。 ．少なくとも、itojun さんが提案していた、単純に cpp で くっつける方式は、やっぱり今ひとつな気がする。 …気がするのだが、いまの DLRUNE モジュールを拡張しないなら、 そうするしかなさそう。というか、LC_CTYPE も同じだしね、 と言われてしまえばそれまで。LC_CTYPE は圧縮が効くから、 ちょっと事情は違うと思うのだが。 ．せっかくなら、Unicode TR#17 でいうところの、 CES/CEF/CCS モデルで実装したいんだが、itojun さん方式は 実質的にインストールされるデータファイルでは、 変換テーブルを素の CES (の内部表現)のままで持つことになる。 ISO-2022 ハンドラに限って、CEF/CCS レイヤに分割する方法が あるのだが、これではちょっと不十分。 たとえば、SJIS は ISO-2022 ハンドラの管轄じゃないので、 ちょっとトリックを入れないと CCS の共通化はできない。 ．…うーん。この辺をやろうと思うと、 もし、DLRUNE のインターフェースを拡張しないのなら、 iconv 側が rune_t 内部の representation を知ってないといけない、 ということになる。それは美しくないから、やっぱり DLRUNE 側に、 CCS ID と index に分割する何らかの仕組みが必要なんだと思うな。 ．で、そう考えると、DLRUNE と LC_CTYPE データベースが CES (の内部表現)レイヤで 実質的に癒着してる現在の仕組みでは、やりにくい。 DLRUNE と LC_CTYPE を分離して、LC_CTYPE も CCS レイヤで 処理するようにするのが美しいし、それが Citrus の夢だったんだな。 ．まあ、rune で行くのなら、何も考えずに cpp 方式なのかのう…。うーん…。 ．…Unicode TR#17 の CES/CEF/CCS も不十分だよな。 CES と CEF の間に、内部表現のレイヤが必要だと思うのだが。 TR を読むかぎり、 「CCS: 一つのキャラクタセットのインデックスづけされたもの。 CEF: 一つのキャラクタセットの、あるインデックスのエンコーディング表現, CES: 外部表現」 なので、ISO-2022 を rune へマッピングしたものを適切に表す レイヤが存在しないように見える。 つーか、これ、かなり低位のレイヤまで、ワイドキャラクタじゃなくて マルチバイトで処理すること前提のモデルでないかい? ．たぶん、rune 的方法論にあてはめるのなら、 CCS と CES はそのままでいいのだが、CEF が違うんだな。 Internal Encoding Scheme とかいうのを用意して、こっちを経由させる。 |
|
．長い文章読みたくない(し、長い文章が必要なこととも思えない)ので、 まあ斜め読みした感じで。 ．gu4 さんの言ってることは、事実認定という部分ではそんなに 間違ってないんだけど、視点がちょっとずれてるのかな、という気がしますな。 ．まあ、偽春が訴えられてもおかしくない、ってのはそうだろうと思う私も。 ただ、作者の黒衣さんは、パロをやることで本質的に背負わなきゃいけない、 その手のリスクに関して、ちゃんとわかっててやってるように見える。 ここが重要。だから、gu4 さんの言葉に出てくる、 自業自得、とか、危惧、とかいうとちょっと違和感があるわけね。 ．許容範囲は時と場合によって違うけど、 しかしながら本質的に、パロをやっている限りは多かれ少なかれ 作者がそういうリスクを負うのは当然のことなのね。 どんなに穏便にやっていたとしてもね。 だから、「毒を吐いたから訴えられた」とかは、 単なる程度問題の末の結果論でしょう (もちろん、人間関係はそれも大事ですけど)。 ．いやもちろん、パロの形態として他人をこきおろしてるのも事実で、 そこは今ひとつ誉められた行為じゃないんだがね。ただ、本人がわかってて、 変に自分の行為を正当化せずにやってる、という部分は認めていいと思う。 そういう意味で、批判する余地はそれ以上はない。 その上で、良いか悪いかってのは、単なる主観的な善悪判断に 過ぎないでしょうな。その「主観」の尺度は、 「各人の好み」かもしれないし、「社会通念」かもしれないけど。 ．一方で、プに似非側は稚拙なんだよねー。 ガキのケンカを大人の言葉で wrap してるだけ。 ママにいいつけるぞ、が、裁判所にいいつけるぞ、 になってるだけで、訴えてる内容に垣間見える理不尽さは、 さほどガキのケンカの捨て台詞と変わらんし、 結局単なる嫉妬か、単なる憂さ晴らしか、単なる(任意)、 いずれにしろキテ(以下略)なんだろうな、としか思えん。 ．やっぱり、「大人のせかい」という観点ではどっちもどっちだなうん。 で、結局「いぢりがい」という観点では、 「確信犯的なパロ」よりも、 「大の企業のお子様対応」の方に軍配が挙がるのであるな :D ．……… \ ．…ヲレの文章も十分長いな。 |
|
．某氏が保険証を返しに来訪。mrt さんとともに 近くのビストロで飯をおごってもらう。 オフィス探しとか、禁断の呪文話とかの世間話と、 なぜか Unicode 話。DIS10646 たんハァハァ(←やめなさい) |
|
．ううむ、何故か(見知らぬ)女の子と以下略な夢を見たのだが、 妙にリアルなのだ。 吸って舐めたら(←なにをだ)味を感じたり、ふにふにした感触もあったし、 ちゃんと気持ちよかったりするのがアレだ。 うーん、夢でもいろんな感覚がエミュレーションされるのだのう。 ．残念なのは、どうやっても最後まで到達しない、 というシナリオだったところだのう。 エミュレーションの限界か。 もっとも、最後まで行くと、それはそれで起きた後に げんにょりしそうで嫌だが。 まあ、10 代のガキじゃあるまいし、さすがに夢じゃねぇ。 |
|
．そうそう、週末あまり時間が取れなかったのだが、 ソースを kotori に積み込んでおいたので、 少ない時間の断片の積み重ねで umidi をほぼ実装完了。 結局、思いっきり書き直した。昨日は虫取りをしていたのだが、 眠くなって轟沈。 |
|
．公開停止か。 ．あれだな、とりあえず翼とプに似非には、 「金に物をいわせた言いがかりによってフリーソフトを潰した連中」 という烙印を押しといたがな。 ま、あの程度の元フリーソフトをシェアウェアにしちゃうような、 金のためなら恥も外聞も無いようなドキュンな連中だからしょうがないよな。 こういうのがいるから、「フリーソフトは、後から金を取るためのもの」 なんてトンデモな解説を付けちゃうアホとかが出るんだよね。 ．確かに、あれは、誹謗中傷ギリギリなパロディなんで、 そこにクレームするのは当然かもしれんが、 そういう相手の弱点にかこつけて、 どさくさにまぎれて「キャラが翻案だ」なんてヤの字みたいな 言いがかりを付けて「公開停止要求」をセットにするやりかたは、 競合するフリーソフトを潰すための口実、と取られても仕方がないよな。 フリーソフトは個人で作ってるもんだから、 訴訟をちらつかされたら逃げるしかない。やり方が汚えよ。 |