_ 所用で埼玉まで。セミが鳴いていましたよ。 流石に都会だけあって、道はゴミだらけ。 それにしても都会は電車の乗り方が難しくて大変です。 さらに、電車を乗りつぐたびに階段を登り降りさせられるので、 普段の1ヶ月分くらいは踏み段昇降しましたよ(普段、階段登らないスギ)。
_ 米沢の某でんでんネットだが、来月末 10月31日でサービス終了らしい。 理由がファイアウォール導入のためというのがちとトホホだが。 ついでに「最終芋煮オフ」をやるらしい。 流石にもう宿泊バッファはロクにないだろうなぁ…。
_ ~/.elmo/cache 以下に、かつて届いた sircam なメールが残っていて、ファイルサイズでかくてうざいんだが elmo-cache-expire-size で expire する閾値ってどこで決めるんだろう…。
_ 上のリンク先の swap の増量と言えば、 内部のデータ構造が最大のスワップパーティションの 4 倍に調節されるので swap パーティションの大きさが派手に不揃いだと不利だとか読んだんだがどうしたもんかね。
一瞬、200MB のパーティションを 2 分割して 64+64+100+100 にするかと思ったのは秘密(笑)。
_ 流行っているらしい＞
うまそう
つーか、大元のスレをすきっ腹かかえて読み通してしまった。
俺的にはむしろ、野菜のウマイ喰い方が知りたい…。
_ 急に 1 時間で一席ぶたされることになってかなり鬱。 ドクターの発表の内容なんてそろそろ忘れた上に、 新しい分についてはこれから作るのか？ つーか鬱だと思うといよいよ作業を始める気になんないよ…。 間に合うのか？っつーか、そう考えるといよいよ鬱。
_ ひさしぶりに NetBSD の src の更新が完了して (朝の4時に始めたのが終ったのは12時過ぎだけど…(--;;;)、 ファイルシステムの performance と robustness が improving だというので すぐさま飛びつくとこれが lfs に書き込むと即座に DB> に落るというカーネルになってましたことよ……(T_T)
CVSweb 見ると、一連のその修正に交じって二つ程、 10数時間前のタイムスタンプを持つものを発見。 微妙に src を取得しているタイミングにひっかかっているので、 bug 修正だがタイミング悪く取得しそこねたってパターンだと救われるんだがなぁ…。
ってんで手動で src の update。だが例によって時間がかかりすぎる。 なので cvs をステて、 cvsup でリポジトリを拾って local で checkout することにする。 だが cvsup は COMPAT_14 と COMPAT_13 なカーネルを必要とする。っつーか
つーわけで cvsup しながら trafshow で転送レート見てたんだが 最高でも 50 〜 80 KBytes/sec しか出ない…(T_T)。トホホすぎ。 あげくに途中で abort して頭から舐め直して3回りくらいしたあげくに 肝心の syssrc の途中で filesystem full くらって死にましたよ…(屍)。 syssrc が最後なのがイケてないんじゃーー。 因みに、生じたログが 12M……(合掌)。
_ つーわけでがりがりやってるのを見ていての感想。
_ つーわけでファイルシステムが溢れて make もできないので、 lfs だった場所を暫定的に ffs にして mount して リポジトリを移送。そこから co して build することに。 って lfs じゃなくした時点で修正の必要も失せたんじゃないかと思うがどうよ(爆)
_ 今朝、夢うつつの中で思いついた言葉、「猫の小判」。 猫が持っている小判なのか、猫の絵でも描いてある小判なのか…。 それにしても、脈絡のない超大作3部作だった……。
13:41 <#うにっくす:uzura> ああーゆぴししょうがー 13:42 <#うにっくす:|Simon|> ゆっぴぃさがどうした > うずら 13:42 <#うにっくす:doggiee> 青色 LED って高いんかな。 13:42 <#うにっくす:uzura> うなぎ.... 13:42 <#うにっくす:|Simon|> ぐは (略) 13:44 <#うにっくす:Yuppy> /t uzura> ああーゆぴししょうがー uzura> うなぎ.... 13:44 <#うにっくす:uzura> ユピシ生姜 13:44 <#うにっくす:Yuppy> (ノ__)ノ
「ゆぴ師匠はうなぎで生姜だった？！」
_ 密かに LaTeX2e 版の JPSJ のスタイルファイルなんてできていた…。
_ yahtml の
(turn-on-auto-fill) ;Sorry, this is prerequisite
ってツラいな…。ついでに莫迦な indentation も邪魔スギ。
_ いずこも同じだと思うが、 冷房って噴き出すのを浴びる位置にいると辛いよね。 なもんで、うちの研究室でもそのような位置の学生が冷房の設定をいじったらしく、 今日の設定温度はなんと27℃……(--;;; 今から暖房かけるつもりか…。
外気温より設定温度が高いというのも問題だが、 熱を出す計算機 (古い SMP (FreeBSD-3.5) の Pentium Pro とか常時計算し続けてる Pentium III とか) が密集している俺の机は冷気の届きにくい処らしい。 下に書いたように debug してたんだが、 どうにも自分の机で仕事してると暑苦しくって集中できなかったんだがこの所為だな (--;;;;。
_ うーむ、ひそかに
9月9日問題 (10億秒問題, second 1 G problem) にひっかかってたようだ…。
自分で書いた本業の方のコードなんだが、
何故か junk pointer 突きまくってて一日中 debug するハメになってたのよね…。
道理で毎回 bug る訳だ。
原型は Knuth 先生の乱数のコード [1] なんだが、
毎回、手で seed を入力するのが面倒なんで
(header file を読み込むと generator も使えるようにしてあって、
include の都合でこいつまで読み込まれたが乱数は使わないぞとかいう
状況もありえて、手入力を回避したかった)
constructor で seed に time(&nowtime) を突っ込んでいたのよね…。
で、この乱数って (0, 1000000000l] の間で値を回すことで一様乱数を維持していた
その初期値で range check を考えてなかった、と(汗)。
つーか、 long の範囲全部使ってると思ってて、 [0,1) 乱数を得る計算 間違えてるんじゃないかな、って思い出して check したのも今日だと言うのは 秘密だッ。
[1] D. E. Knuth, SEMINUMERICAL ALGORITHMS / Random Number, in "The Art of Computer Programing Volume II (2nd ed.)", ed. by Donald E. Knuth, Maple Press, Manchester, Pennsylvania (1980)
_ うごご…筋肉痛が酷い……。
重いスチールケースの AT を持ち上げたり運んだりひっくりかえしたり、
立ったり屈んだり狭い処に這いずり込んだりした分だな…。
_ うーむ、この建物がぶら下ってる FDDI のループが死んでるくさいぞ…。学内にすらアクセスできねーや。 つーか FDDI のクセに死ぬなや。
_ 夏みたいに暑いくせに、やたらと風の強かった日。 布団干して大学行って涼んでたら、布団が砂だらけになってしまった…。 しくしく。
_ 秋の花粉アレルギーなのか、くしゃみばっかりでてて すげー不自由(x_x;;;。
_ 朝ひととおりシャットダウンして、帰って飯食って
洗濯して布団欲して掃除。
んでまた大学に戻ってきて、サーバを引っぱり出して掃除。
このサーバ押し込んでるあたりって停電でもして
計算機止めないと掃除できないや…。
停電でもで思い出して計算機の中も掃除。うごご…汚すぎ…。
停電で室内が暗いので、建物の入口まで引っ張って行って掃除。
かなりマヌケだ…。
_ とか建物の入口に店を開いてたら、
いちど通り過ぎた電気整備の
どーでもいいけど、俺、相手の顔を見なかったらしく 「兄ちゃん」だったのか「おっちゃん」だったのか、実は判ってない。
_ 電源の復旧を待ってファンの動作チェックをしてみたら、 案の定不調。 完全に動かなくなっていた ISA bus に挿したファン付ダクトのファンは、 撤去してダクトだけ煙突がわりに残しておく。 ファンを撤去した穴は実験室からキムワイプを持ってきてシール。 気流は CPU 2 の下方から流入して電源と 3.5" ベイの排気ファンから出て行く流れになった。 CPU 2 の CPU ファンが LP レコードかと見紛うノロさで回るのには焦ったが、 しばらくするとちゃんと回っているようだったので放置。 っつーか、今ドキ何処で socket8 の CPU ファンを探せと？
_ わしは行かないんだが、ある学会のプログラムを見ていて、 水商売で有名な人の名前を発見。 内容にも興味があるぞ。
_ う〜む、 new toolchain 環境に移行できても build のたびに TOOLDIR=ほげ USE_NEW_TOOLCHAIN=yes してやらんといかんのか…。 イケてなさスギ。 do-gnu-lib では停まらないけどね。
_ 明日は停電。シャトダウンの順番どうだったかな？ それより、ちゃんと起動するんだろな (boot しない lilo のフロッピとか突込んでないだろうな)。
_ ぁ〜ぅ〜、chroot 内で build するときに old toolchain に戻しちゃったい……(;_;)。阿呆だ…。
_ うーん、 build は 最後まで終ってるなぁ…。 でも面白そうだから、 src tree 更新してしばらくこの上で build してよう。
_ うーん、今日 update した src tree でも問題なく build が通ってるなぁ…。 chroot の外から make distribution しようかな？
_ 今日はまじめに、
do-gnu-lib のあいだだけ /etc/mk.conf に .include ほげを書いて
DESTDIR=/altroot で build して、 src tree もコピーしてやって
chroot /altroot して再 build にチャレンジ。
これで通ってたら入れ替えるかなぁ？
それとも面白いんでしばらくこうやって遊んでるかなぁ？
_ 自己訂正。
「どんと
_ syncdir が owner/group を保存しないのは問題がある (root で backup を取っていると、新しいファイルの backup は root が所有することになってユーザ権限で読み出せなくなったりする) ので、 backup 先が NFS で mount されていることを利用して rsync を cp -Rp 式に使うことにする。
オプションは -v -u -a --delete くらいだろうか？ ディレクトリ指定が微妙に晦渋なので shell script を書いてごにょごにょ…。 なんかイマイチだなぁ…。
_ 散髪
_ NetBSD の new toolchain ってホントに移行できるん だろか？っつー疑念の元に、 TOOLDIR の new toolchain で build ができるものか試してみる。
先ず、 TOOLDIR を /etc/mk.conf に書いて tools で MKTOOLS=yes で build。 で、 .include "/usr/src/tools/Makefile.tools" を /etc/mk.conf に書いて、 USE_NEW_TOOLCHAIN=yes で build してやると bin/cat で早速 コケるんですけど……。
dependall ===> bin/cat /home11/temp/bin/mkdep -a -nostdinc -idirafter /home12/altroot/usr/include cat.c /home11/temp/bin/i386--netbsdelf-gcc -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized -Wreturn-type -Wcast-qual -Wpointer-arith -Wwrite-strings -Wswitch -Wshadow -Werror -nostdinc -idirafter /home12/altroot/usr/include -c cat.c /home11/temp/bin/i386--netbsdelf-gcc -static -o cat -nostdlib -Wl,-rpath-link,/home12/altroot/usr/lib /home12/altroot/usr/lib/crt0.o /home12/altroot/usr/lib/crtbegin.o cat.o -L/home12/altroot/usr/lib -lgcc -lc -lgcc /home12/altroot/usr/lib/crtend.o cat.o: In function `raw_args': cat.o(.text+0x7e6): undefined reference to `open' cat.o(.text+0x7fc): undefined reference to `__fstat13' cat.o(.text+0x80d): undefined reference to `close' cat.o(.text+0x82c): undefined reference to `close' cat.o(.text+0x849): undefined reference to `open' cat.o(.text+0x89a): undefined reference to `close' (以下略)
要するに、 TOOLDIR の new toolchain で compile した libgcc を TOOLDIR の new toolchain で link しようとするとコケる…？。 これって、うまいこと new toolchain を導入できたとして /usr/bin/gcc が置き換わっても大丈夫なのか？
どーでもいいけど、 src/Makefile の冒頭で
.if defined(USE_NEW_TOOLCHAIN)
.include "${.CURDIR}/tools/Makefile.tools"
.endif
しているのが理解できないのよね…。 Makefile.tools の内容は CC なんかに TOOLDIR のものを使わせるルールばっかで、 下位の make をぶっ叩くだけの src/Makefile には全く無用なんだが… (いずれは make も new toolchain のを使う布石？)。 まさかとは思うが、子プロセスに渡ると勘違いしたんじゃないよね？ (http://mail-index.netbsd.org/current-users/2001/08/17/0006.html で指摘されてる) HEADSUP の書き方も判りにくかったし、どうも作業してる奴を疑っちゃうな…。 (new toolchain じゃないと libgcc で止るのは http://mail-index.netbsd.org/current-users/2001/08/18/0007.html で指摘されてる。 どっちも作業してる当人からその問題は認識した言うフォローがついてるんだが なんでまだ放置かな…。)
_ 空が高い。 こないだのコースを散歩。 同じ猫だろうか、寄って来て撫でさせてもらえたのでらっきー。
_ アパートの鳥の巣の下に 雛の死骸が落ちてた……。まだ毛も生えてない。 雀と言えば、1羽、アパートの前の家の屋根や電線でチチチチチと鳴き続けてる のがいる。しばらく見てると他の雀がわらわらと集まって来るんだよね…。 子雀の学校かしら？
_ すっかり風が涼しい。っつーかときどき肌寒い。 なんともたまらん。これで冷たい雨でも降った日にゃこたえられんな。