01:24:43 # Life Debian ruby policyを読んだ. TODOになっているままの項目がいくつかある.初めて読む人にはわからない文章もあるのと,古くなっている部分がありそうなかおりがするので, 一通り読んでみてアップデートするような作業が必要だろう.rubyは,すくなくともポリシーを策定したころから2年間たっているのに 何もかわっていないような言語ではないと思う.また,私自身がrubyがわからないのでわからない部分がいくつかある. とりあえず,load-pathを確認する方法というのがよくわからなかったので,rubyの文法を勉強する羽目になった. どうやら,こうやったらできるらしい. ruby1.9 -e '$:.each{|l| print "#{l}\n"}'. 感想,毎回lambdaという意味不明な文字列を書くよりも, ||と書くほうが美しいのかもしれない.
01:57:37 # Life qemu. 0.8でSMPがサポートされたらしい. その数がすごく面白い. 255CPUまでサポートらしい. 試せるか? と思いビルドを試したが,ビルドできずエラーになりあきらめる. なんとなくファイルが足りなさそう.
make: *** i386-softmmu: そのようなファイルやディレクトリはありません. 中止. make: *** [all] エラー 1
07:32:00 # Life kernel-packageデバッグ. kernel-packageがあたらしくなってからいろいろと阿鼻叫喚をきいてきました. アップグレードしてみましたが,全く動かなかったので, amd64でも動くようにとりあえずがしがしとパッチを投げています. 344335, 344341. と思っていたら,夕方には修正版がアップロードされていました. manoj かっこいい.
08:11:19 # Life debconf 2006の投稿. 論文の選考がそろそろ終っている予定の時期になりますが, まだ終了していません,という連絡が来ました. 今年も発表させてもらえるのでしょうか.
11:21:44 # Life Jeff Licquiaが転職したそうです. いままでProgenyだったと思うのですが,Free Standards GroupでフルタイムでLSBに関して働くことになったそうな. 彼のblogより.
22:50:38 # Life pbuilderのメンテナンス. なかなかいろいろと変化があって,リリース. stableリリースがあたらしくなったのと機を同じくして. 変化点が多かったので,修正. pbuilderのregression testには実は experimental distributionへのアップグレードしたりするテストが入っていて, 今のexperimentalにアップグレードする際にだけ発生するバグがあったり.
23:58:11 # Life cogitoがdebianパッケージとして復活. 久しぶりにパッケージをアップグレードしようとしたら,debianのcogitoのバージョンがあがったようですね. 11月18日ころに復活していたようです. ずっと自分でgitレポジトリを取得して,パッケージをビルドしていたので気づいていませんでした.
06:50:29 # Life debconf-team ミーティング. UTC20時は午前5時,という意味でしたか...午前7時くらいに参加してすでにIRCは高速な議論が展開されていてついていけず. もうすでに白熱した話題が展開されており,今 電源の不安定さについて議論中. 大量の人が来る場合は,電圧降下を心配する必要があるので, 一部のカンファレンスでは発電機をチャーターしたこともあるそうな. メキシコシティーへのバスは70$くらい. Gwolfが,70$という場合は,70ペソスのことらしい.700円相当くらいか. 暑い季節なので30度くらいまで気温が上がるらしい.作業部屋にエアコンが無い,との話題が. プールがあるので,プールサイドハッキングが重要,との結論に達した. 防水ノートパソコンを持って行けば英雄になれると見た. toughbook?. Cuernavaca 空港というのがあり,そこが近いそうだ.
外務省のもつメキシコ
の情報は参考になりますな.
時間が何時か,というのを調べるのは,gworldclockのrendezvousオプションが便利.
国際標準時というのが見付からないけど,この季節のイギリスの時間で代理させてみる.
22:18:50 # Life Debian のバックポートパッケージの サイトが更新されました. Debian 3.1 (sarge)リリースがでて早半年が過ぎようとしています. すでに古くなってしまっているので,この機能を使うためには,このパッケージの 新しいバージョンが必要だ,という方もいらっしゃるのではないでしょうか. Debian では,新しいバージョンのパッケージを非公式ながら安定版リリース向けに 作成したものを 「backport package」 と呼びます. 従来はばらばらに行われていることがあったのですが,その努力のかたまりである backport をまとめているサイトがあります. backports.orgです. 3日ほど前に内容がアップデートされて,sarge対象に変更になりました. backports.orgは一時間に一回 katie (dinstall, アーカイブアップデートスクリプト) が実行されていて,アーカイブが更新されているそうです. push mirror(通知によるミラー同期開始)をするので,ミラーしたい人は連絡してください,とのことです. cronで一日一回とかだと古いミラーになってしまうし,一時間に一回ミラーされると負荷が大きすぎるからでしょう.
23:13:34 # Life FSIJ gcc ゆくとしくるとしに参加してきました. こじまさんに,gccの最近の動向について語っていただきました. 個人的には,openmpで,スレッドでどういう処理がなされるのか,今後が気になります. cvsで管理していたレポジトリに関して,タグを付けたりブランチする処理があまりにも時間がかかりすぎるため,svnに切り替わった,というのは衝撃です. svnに急に切り替わったのはきいていましたが,処理上のcvsの限界に到達したとのことです. cvsはブランチさえきらなければ便利なツールなのですが. gccで,リグレッションテストをばりばりやっている話しとかは興味がひかれます. gccは自分で自分をコンパイルして,結果をregression testするテストというのが一番効率良いテストになっているような印象を受けました. ただ,コンパイル時のパフォーマンスの劣化についてはあまりうまく試験できていないようで, その関連のベンチマークが最近でてきて,その結果が反映されるとよいな,ということでした. stage 1,2,3 と開発段階をわけているそうですが,それぞれのステージの切り替わる段階で パッチが怒涛のようにおしよせるタイミングがあり, その時点でのマージ作業に関してはうまく regression test が機能しないのだろう, と推測できます. そういう開発者の行動パターンにうまく合致したテストの手法はないものでしょうか.
23:46:38 # Life UFJの手数料改定の連絡が来た. 合併するので手数料をかえるらしいが,あっさりと値上げしているところに釈然としない. 3週間後から高くなるってことですかね?
00:55:54 # Life coroutine. yieldなどの方法がないので, Cでは,coroutineの実装が難しい. coroutineをマクロで実装してみました,という記事があった. これをながめていると,longjmpとかで実装できそうだなぁ,となんとなく思ってしまう. longjmpのパフォーマンスはどうなんでしょうね. longjmpするくらいだったら,スレッドをつかってもあまりかわらないか?でもロックが不要なのがポイントかも. putty:ssh.cに本当に使っているソースがあります. muアンテナより.
05:42:19 # Life 無敵会議にいってまいりました. 昨日は,秋葉原で開催された無敵会議2005 忘年会議に参加しました. 検索についてのセッションは面白く,最近下に下に向かっている自分にとっても楽しめました. グループワークでは,最近のBuzzwordを従来語に翻訳してくれる Web 1.0 ボタンを提案しましたが, 残念ながら一等にはなれませんでした. いつもながら,実装まで考えてしまうので,発想とプレゼンのしかたが硬いのでしょうかね. 精進が足りない,と.
Passion for the futureに報告blogもアップされていました. 12
23:13:45 # Life epsだけでなく,pngなどのファイルもtexで扱う. platexで画像を作成する際に画像ファイルをpngのままで扱えたらよいのに,と思うときがあります. 実は,その機能はすでに実装されていました. \usepackage[dvipdfm]{graphicx}というようにして, graphicxにdvipdfmオプションを追加しておいてあげると, includegraphics{XXX.png}などとしてpngファイルを指定することができます. ただ,下準備が必要で,ebbコマンドでpngファイルのバウンディングボックスファイルを作成してあげる必要があります.ebb *.pngとかで処理してあげましょう. xdviやadviで画像がプリビューできないのは問題ですが,pdfファイルではきっちり見えます. adviで見れるようにできないのかな?
08:28:58
#
Life
Debconf ミーティング.
12月19日20時UTCに#debconf-teamにてIRCミーティングをするそうです.
日本時間20日午前7時午前5時くらいかな?参加できそうだったら参加してみましょうかね.
08:32:28 # Life dpatchのメンテナンス. 最近チーム制でメンテナンスしていて,絶賛放置中だったパッケージの一つ,dpatchをアップデートしました. とりあえず,wishlistじゃないバグを全部close. wishlistには,むちゃではないけど,メンテナンスするのが面倒そうなパッチが大量にあるので, 気合いの入ったコントリビュータが居ないと追加するのは大変かな.
20:08:04 # Life Perfect Hash Function. Linuxカーネルのソースツリーのscripts/kconfig/以下には, Kconfigを分析するためのツールが入っています. そのソースは,まじめにlex, yacc を利用して構築したツールになっていて,さらに国際化も視野にいれたコードもどうやら入っているようです. そこを眺めていて, gperf というプログラムを使っているのに気づいたのでちょっと調べてみました. gperf は Perfect Hash Function というものを作るためのプログラムだそうです. 文字列で構成された言語を言語処理系プログラムから扱う場合に 文字列として扱うより,一旦トークンとして一意にわかる数値にしたほうが都合がよい場合が多いです. そのような値を取得するためのツールのようです. 最近はXMLが流行しすぎているため, 設定用の言語を一から作り上げることはあまり流行っていないとは思いますが, たまにはその分野のツールをのぞいてみると新しい発見があるかもしれません.
13:58:20 # Life 東京エリアDebian勉強会報告. 12月の第11回Debian勉強会を実施しました. 今回は一年間のDebian勉強会をやってみて,の反省会を主としてやりました. 今回の参加人数は9人でした. 議論された点を以下に紹介します.
今回の会計
(+ ;;資料コピー8人分 -2731 ;;DWNクイズ景品代 -150 ;;会場代 -1500 ;;勉強会費 +4000 ) -381 の赤字.
01:04:03 # Life emacs-snapshotでwysihtmlが動かない件について. 3ヵ月くらいメンテナの方が放置されているので,そのままだと永遠にemacs22が体験できなさそうなので,調査してみました. 325449. まず,elservのelserv.elでエラーが出ているということをインストールログから解析しました. 手動でロードしてみると,elserv-url-decode-string の(push ?\ decoded)というのがエラーを発生させているようです. (push ?\\ decoded)にすればよいっぽいです. と思っていたら,違うようでした. (push ?\ decoded)とすればよいっぽいです. ?\ というのは,バックスラッシュで空白をエスケープしているのですが, その後に空白がないために,emacs22では,エラーが出ていたようです. emacs-snapshot と emacs21で挙動が違いますな. このコードは,muse-elと,emacs-wiki.elにあるcgi.elと同じため,cgi.elも動かなくなってそう.
19:12:54 # Life CACert assurer. Japan Debian Miniconfの後処理の一貫として, CACertのassuranceをしました. ご確認ください. もう一月以上たちますね. また,gpg keysignについてはバックログがかなりあるので, 今後逐次バックログを解消しようと思っています.
08:45:07 # Life Vincent Sandersがdebian-devel-announceでARMの評価ボードを安く売る,と宣言していた. なんだか微妙な感じがしなくもないが, Debian-developer一人一台限定で,EB110ATXが2万円くらいで手に入るということなので,悪くは無 い話かもしれない. 特にメモリが256MBのるのと,IDE HDDが させるということなので,組み込みの常識を越えるハードウェア構 成が組めそうですな. メール. kinnekoさんのコメントがあって,組み込みとしては,このメモリ容量はありえないということですが, Debianでセルフ開発をすることを考えると,これでも足りないですね. 特に g++ あたりがメモリをたくさん必要とする印象があります.
22:42:42 # Life debconf のメーリングリスト. Debconf6関連の各種メーリングリストができていますね. lists.debconf.org. ここでDebconf6の議論が展開されているようです. もうすぐ,メキシコです.盛り上がって行きましょう. Joerg Jaspertのblogより
14:57:59 # Life CPU アーキテクチャ名の混乱. amd64(Debianでの呼称, AMDのマーケティングはOpteronが出始めたころにAMD64という呼称に変更してくれ,とあらゆるところに依頼を出した.Debianはそれに従った.), K8(順当にいった場合のコード名), x86-64(Linux カーネル, gcc での呼称,まだシミュレータしか無いころは最初はこういう名前だった), x64(Windowsでの最近はじまった呼称), ia32e(リリース前のIntelの呼称), EM64T(Intelの呼称). この名前は実はすべて同じCPUアーキテクチャをさします. Dave Jonesが愚痴っていました.
19:50:34 # Life cowdancerで,cow-shellを毎回起動されるたびにfindがうごいているのがなんとなく気に入らない. dnotifyとかで監視してファイルの更新があったら更新するようにして, デーモンがファイル一覧の情報をもっていて, その情報をUNIXドメインソケット経由で提供する,というインタフェースが使えないだろうか,と考えてみる. 現在はあらゆるケースで find/xargs/stat を活用していて, fork/execしまくりなので,それを何とかしたい. ただ,そこがボトルネックになっているという事実は全くないので, 実用的にはそんなことをしなくても問題ない.どっちかというと,機能があるからやってみました的なハック価値. 現状.ilist というファイルにi-nodeの一覧を保持しているが,そのファイルをUNIX Domain socketにしてしまって,デーモンがその先に存在するようにしたらどうなるだろうか. dnotifyとunix domain socketについて下調べをしてみる.
dnotifyについて.カーネルソースのfs/dnotify.cにある. Documentation/dnotify.txtにドキュメントがある. cowdancer的には,DN_CREATE DN_DELETE DN_RENAMEが気になる. こいつらを監視すればよさそう. dnotifyのサンプルを動かしてみるといろいろと分かる. ディレクトリを一つ監視するために,ディレクトリをopenで開き,fdに対してfnctlで監視を指定する. 何かイベントが起きた場合には,カーネルが,指定した任意のシグナルを送信してくれ, ディレクトリを開いたときのファイルデスクリプタ番号を送信してくれる. どのディレクトリに変更が発生したのか,というのは,ファイルデスクリプタの番号で確認できる仕組みになっている. サブディレクトリについては,監視できないので, それぞれのディレクトリに関して監視を設定する必要がある. つまり,ディレクトリツリーを監視するには,ディレクトリの数だけファイルデスクリプタを開く必要がある. 例として, Debian の base.tgz を展開した結果を監視する場合,689のファイルデスクリプタが必要になる. dnotify.cを読んでいると,一つのファイルに対して操作が発生した場合に関しても, そのparent inodeを発見するためだけにspinlockをしている. さらに,その親にまで遡及させるにはそれなりに長い処理が必要になるので, なんとなくいやだ. ということを調べていたら,inotifyというのがあるのを思い出した. inotifyのドキュメントはDocumentation/filesystems/inotify.txtにある. dnotifyの反省をいかした内容になっている. ファイルの変更イベントの送信がシグナルではなく,ファイルからのreadだけで実現できているという点がポイント. しかし,dentryのparentを見て,そのinodeが監視対象か,という確認しかしていないので, 全ディレクトリを監視するためには,監視対象に全ディレクトリを指定してあげないといけないというのは同じ.ただ,それぞれのディレクトリに対してファイルデスクリプタをopenにする必要はない. これを実行するには,find相当の処理が必要. 結局,cowdancerの観点から見ると,dnotifyもinotifyも50歩100歩ということが判明した.
Socketについて. UNIX Domain Socketというのを作成すると,指定したファイル名ができ,それ経由でソケット通信ができるようになる. 指定するのは,PF_LOCAL, PF_SOCKET,PF_FILE(全て同じらしい). sockaddr_inの代わりにsockaddr_unという構造体があり,それで実際にファイル名を指定する. その構造体中に謎の固定長のsun_path[108]という配列がある.これは,ファイル名の文字列らしい. 108文字という制限はなぜ存在するのだろう,というコメントがglibc.infoにはあって,確かに謎だ. glibc:socket/sys/un.hにも確かにそう定義されていて, 実際にその制限は存在しているようだ. なんとなくglibcのソースを読んでいたら, なんとなく凄いコードを見付けた.glibc:sysdeps/mach/hurd/bind.c. lispか,と思うようなコード. 一連のコードを{}で囲めば,最後のステートメントの値が{}の結果として評価され,それをそのまま関数の値として利用している,のか?マクロなので,違うのかもしれない.
err = HURD_DPORT_USE (fd, ({ if (err) err = __socket_create_address (port, addr->sun_family, (char *) addr, len, &aport); if (! err) { err = __socket_bind (port, aport); __mach_port_deallocate (__mach_task_self (), aport); } err; }));
まるでlispみたいなコードが書ける. うーむ.盲点だった.だからといってこれがよいコードなわけははないだろう. まず,何がしたいのかよくわからない. もうちょっと読みやすいサンプルを作ってみた. しかし,これがどの場面で便利になのか,という点については疑問. いろいろと調べていると,Linux カーネルの get_user 関数も 同様の構造でマクロを定義していることを発見.悪夢のようだ.
main() { const char *a; printf ("Hello C %s \n", ({ if (1) { a="This is possible"; } else { a="Weird test"; } a; }) ); }
18:26:10 # Life 時代はBinary. Binary 2.0 Conference会場. とりあえず,カーネルソースを展開して,今日解決しようとしている問題を分析してみる. 調べたいのは,powerpcのLinuxカーネルで,ptraceのPTRACE_GETREGSは実装できるのか,という点. 2.6.15系列はpowerpc関連のカーネルツリーがいろいろといじられていて,ファイルの場所が移動しているため,2.6.14を対象にする. なんとなく見てみると,arch/ppc64/kernel/ptrace.c と arch/ppc64/kernel/ptrace32.c というのがあり, sys32_ptraceを見てみると, PPC_PTRACE_GETREGSというのが定義されている. arch/ppc/kernel/ptrace.cには,PPC_PTRACE_GETREGS がない.
やっていることをそのまま移植できるか,確認. child は, find_task_by_pid(pid) を呼んでいる. ppc64では, child->thread.regs というのがあり, その該当スレッドの汎用レジスタの値が返って来る. ppc32では,unsigned long は4バイト.
include/asm-ppc/ptrace.hを見ると, それっぽいPT_R0とかが定義されている. その上に「mklinuxとかの互換性をもたせるために変更できない」というコメントが書いてある.
とかいろいろと調べてみると, PTRACE_GETREGSは実装されていないが, PTRACE_PEEKUSRは実装されているような気がして来た.
必要っぽい部分だけを32ビット版PPCのツリーにコピペして, カーネル側でPPC_PTRACE_GETREGSを処理するようにしてみた. しかし,ユーザ空間からたたいてみようとすると,Bad addressというエラーがかえってくる.なぜだ. glibcでの内容はどうやらここらへんだろう. glibc-2.3.2/sysdeps/unix/sysv/linux/ptrace.c. なんだかありえないくらいifdef __i386__と書いてあり,他のアーキテクチャだったら厳格なチェックをしないで適当に処理しようというスタンスがひしひしと伝わって来る. で,Bad address をかえしそうなのは,CHECK_1のようだ. sysdeps/generic/bp-checks.hで定義.
しかし,ここまで調べたところでBinary 2.0 Conference終了. 時間切れ.
00:54:04 # Life 今月の目標はなんでしょう. できたらいいなぁ,と思っているのは,powerpc32のカーネルハック. 機能がいろいろ足りていないみたいなので,旅行で移動中などにノートパソコンでちょこちょこといじってみるかな. ptraceと,oprofileの機能を追加してあげたい.はたして,実現できるだろうか.
08:23:03 # Life bttv on amd64の修正がカーネルにはいっていた. いつのまに.
commit ed5297a94090d9a9f27b0ce1f9601ebe73561cff tree 00d28144ae949b3f9d566279cb12be0c802f86e6 parent aa1a64ee12ae130706f3fc0007841ce9b0ddf9c2 author Hugh Dickins <hugh@veritas.com> 2005年 11月 21日 月曜日 21:32:11 UTC committer Linus Torvalds <torvalds@g5.osdl.org> 2005年 11月 22日 火曜日 09:13:41 [PATCH] unpaged: get_user_pages VM_RESERVED The PageReserved removal in 2.6.15-rc1 prohibited get_user_pages on the area flagged VM_RESERVED in place of PageReserved. That is correct in theory - w ought not to interfere with struct pages in such a reserved area; but in practice it broke BTTV for one. So revert to prohibiting only on VM_IO: if someone gets into trouble with get_user_pages on VM_RESERVED, it'll just be a "don't do that". You can argue that videobuf_mmap_mapper shouldn't set VM_RESERVED in the fir place, but now's not the time for breaking drivers without notice.
09:13:12 # Life カーネルをアップデートしたら音が出なくなった. ALSAデバイスがbusyといってくる. せっかくbttvが復活したのだが. Linux dancer64 2.6.15-rc3dancer-g346f7dbb #1 Thu Dec 1 08:08:45 JST 2005 x86_64 GNU/Linux リブートしてみると,動作した.うーむ.不安だ.
$Id: 200512.html.ja,v 1.46 2005/12/27 04:38:56 dancer Exp $