午前中に本屋で本を買うと、 台車の上から本をとるはめになることが最近多い。 ときにはダンボール箱の中を覗くこともある。
まぁ、平台にポッカリと空いた場所を見て、 そこにおいてあったものが欲しかった本であったかどうか悩むよりはましだが。
Handling Language Interoperability with the Microsoft .NET Framework を読む。
もうすこし詳しい情報はどこにあるのだろう?
ほとんどリモートでしか使っていないにも関わらず、 目の前に display が存在することに気がついたため、 world wide wall paper でも動かす気分になりはじめている。
が、尋ねてみると公開していないそうなので、ちょっと萎えた。
ふと、世の中でどんな tar が使われているのか気になった。
% for f in /usr/ports/distfiles/*.tar.(gz|Z) do echo -n "$f: "; zcat $f|file - done
ViewCVS をいじくる。 branch を正しく選べないのをついに fix して、 tarball generation を実装。
とゆーか逆だけど。branch の tarball を生成できないからしょうがなく fix したというのが正しい。
さらに、diff がすっからかんのところで blame (annotation) が失敗することに気がついたので fix し、 空の directory を抑制し、かつ複数の repository があっても動くように tarball generation を 改良する。 ついでに blame のリンクも複数の repository に対応させる。
XEmacs/nt/installer/Wise/display readme.dlg って cvs でちゃんと扱えてんのかね? すくなくとも cvsweb では リンクがおかしいが。
ちなみに、どうも subversion は (主に)この WebDAV を使うことを意図している みたいなんだな...
一般人には無用な用途、 あまりにあんまりな実装、 現実との齟齬、 CVSconnect、 それは...
cvs repository の directory 構造を調べる (ある directory が与えられた時にその直下の directory のリストを得る) 方法はないだろうか?
server の static 変数を変更せずに(あるいは、変更を回復可能な範囲のみに抑えて)という、条件の元に。
shell script で、daemon のようなものを作るために、 すべての file descriptor を close した。(すべての、っていうのはちょっと嘘だが... まぁ、少なくとも親から受け継がれる pipe などを。cvs はいろんな file descriptor を open したまま exec する傾向があるからな...)
exec </dev/null >/dev/null 2>/dev/null 3>&- 4>&- 5>&- 6>&- 7>&- 8>&- 9>&- 10>&- 11>&- 12>&- 13>&- 14>&- 15>&- 16>&- 17>&- 18>&- 19>&- 20>&-
動かなくなった。 調べてみると、shell が script 自身を読むために使っている file descriptor を close してしまうためだった。
その file descripor 以外すべてを close するにはどうしたらいいのだろう?
あまりにあんまりな実装をそれなりにそれなりな実装に修正する。 現実との齟齬については複数の接続を同時に保持可能とすることによって対処。
とあるところに install されていた UTF-2000 を触ってみる。 latin-jisx0201 な文字に対して what-char-definition すると何も出てこないのはなぜだろう?
文字の配列ではない文字列について議論するには精進が足りない。 あまり精進する気がないのも事実だが。
Emacs 昔話、というほど昔話でもないかもしれない。
physical order で文字列をメモリ内に保持する文字コードがあったとすると、 日本語の縦書きの文書を保持するには、メモリ内に縦に文字を並べるのだろうか。
Unicode のほうがまし、かもねぇ。
「OOP」「昔話」「覚悟」「信仰」
autodetect のための解析は 文字列のもっともらしさを比べるものなので、そういう解析をするという方向性は正しいと思う。 日本語だけなら、ChaSen とかを使えるんでしょうが... でも、多言語でそーいうのって、あるんだろうか? 正確な解析は必要ないと割り切って、単語の集合程度で済ますのがいいのだろうか。 多言語 spell checker というような感じになるのかな。
cvs server の動作の理解が進み、ついに CVSconnect 上で CVSsuck を動かせるようになる。 これで、コネクション 2本で動作できる と思ったのも束の間、しばらく動かしていると
cvs in free(): warning: chunk is already free.
とのたまいつつ落ちてしまう。
grep malloc /usr/ports/devel/*/pkg-descr
ど・れ・に・し・よ・う・か・な。
ちなみに、1本では済まないのも cvs の bug である。
大差はあります。 Word はわからないけど、 RPM なら標準ツールで展開できるという人間がここにいます。
od と tail と gzip と cpio があればできます。 以前、何度かやった時は od と tail のかわりに bin2ascii と vi を使った気がしますが。 今なら、bin2ascii のかわりに vis と unvis を使うかも知れません。
後に、Slackware の rpm2tgz がまさに同じ作業を行なうもので、 私と同様に失敗することもある、ということを知って衝撃を受けたりもしました。 (失敗したらやり直すぶん、rpm2tgz より私の方が高性能だと思うけど。)
でも、いつか Word もわかるようになって、 大差ないですね、と同意できるようになりたい、とほのかに思わないでもないです。
追記: gzip は標準とまではいえないか。SunOS では 5.8 からだっけ?
よーく考えた結果、クライアント側の修正だけで 1本で済むような気がしてきた。
ゾンビになるとすでに busy ではないことに気がつく。
FreeBSD の fifo がいまひとつ挙動不審。 クライアントは生きているはずなのにサーバからクライアントへ書き込む時点で SIGPIPE が来ている。 さらに、SIGPIPE が来たあとに signal handler から書き込むと成功して
E cvs-server [server aborted]: received broken pipe signal
というメッセージがクライアントに届くというのがなかなかに怒りを誘う。 cvs 固有の問題かと思って cvs server と fifo の間に cat を入れたら cat は SIGPIPE の一撃で死んでしまう。 OS を変えてテストした方がいいだろうか。
linux で NFS で mkfifo してはまる。 なぜ普通のファイルになるのだろう?
最初、書き込んだものが何回も出てくるのかと思ったね。
とりあえず、fifo から読みこむ(可能性があるとカーネルが認識する)プロセスを一つ増やしてみる。
sleep 36000 < $s2c &
なんか解決した感じ。 10時間しか動かないが、入力側も同様なのでとりあえず気にしないことにする。 fifo はそのうち捨てて、普通の pipe を unix domain socket でやりとりすることにしよう。 気が向いたら。
なんとか、:fork: なら CVSconnect 上で CVSsuck をまともに動かせるようになったため、 他のを試す。
cvs.m17n.org で試してうまくいってしめしめと思い、 以前うまくいかなかった外のサーバで試す。 しばらくするとサーバから Too many open files と通知されて止まってしまう。がーん。 ファイルディスクリプタがリークしてやがるな。
みんなさっさと cvs-1.11 に version up して欲しい、 といっていてもしかたがないから コネクションの再接続/サーバの再起動をする機能が必要か...
エラーが起きたらとりあえず再接続するようにする。 やっと安定して動作するようになった気がする。
cvs [server aborted]: out of memory; can not allocate 172144 bytes
などといわれることも 1回あったが、気にせず再接続して問題なく元気に動いている模様。
殺されたことを騒ぎたてるのは親であることに今更ながらに気がつく。 考えてみれば通知がいくのは親であって殺した側ではないのだから、 道理でいくら殺す側の口を塞いでもメッセージを抑制できないはずだ。
そもそも、なんで non-interactive shell のくせに ash は騒ぐのか、 というのも疑問だが。
shell と perl (や python や ruby)の中間的な言語はないのだろうか。 パイプを作ったり、プロセス間でのシグナルのやりとりとか、排他制御とかが簡単な奴。 shell だと制限がきついし、perl とかだと面倒だ。
まぁ、ライブラリを作れば済むのかもしれないが...
gnus の lisp/gnus-uu.el は log がとれないことに気がつく。 RCS file 中の diff のどれか(というか少なくとも 4.20 -> 4.19)が壊れている感じがする。
RCS file format の利点というべきか、あるいは欠点というべきか、最新版は何の問題もなく取り出せる。
log -R で、ディレクトリ中のファイルのリストまでは取り出せるが... gnus-uu.el に関しては log ではどうしようもないな。
遊戯としてのハッキングが限定性を求めるのなら、 富豪的プログラミングは ハッキングの遊戯性を低下させるのだろうか。 あるいは、富豪には富豪特有の限定性があるのだろうか。
構造化例外とブロック引数は相性が悪いような気がする。
(gimp の) xcf から png に変換するルールを Makefile に書くにはどうしたらいいのだろうか?
Sourceforge の tarball 生成が復活している...
とりあえずこう書ける模様。
%.png: %.xcf
Xvfb $(XVFB_DISPLAY)& pid=$$!;\
DISPLAY=$(XVFB_DISPLAY); export DISPLAY; \
gimp --no-interface --console-messages -b '\
(let* ((in "$<") (out "$@")\
(im (car (gimp-xcf-load 1 in in)))\
(dr (car (gimp-image-flatten im))))\
(file-png-save 1 im dr out out 0 9 0 0 0 0 0)\
(gimp-quit 0))';\
kill $$pid; \
test -s $@まぁ、multiple value を使えとまではいわないが、 なんで、こうなにもかも(といっても image と drawable しか知らないが)整数なんだ?
が、しかし、xcf には version 依存性があるのか、
gimp: unexpected/unknown image property: 19 (skipping) gimp: unexpected/unknown image property: 20 (skipping) gimp: unexpected/unknown image property: 21 (skipping) gimp: unexpected/unknown image property: 22 (skipping) gimp: unexpected/unknown layer property: 20 (skipping) gimp: unexpected/unknown layer property: 20 (skipping) gimp: unexpected/unknown layer property: 20 (skipping) ...
などといわれて make したいと思っていたマシンではうまく読み込めなかった...
CVSconnect のページを作ってみる。
うぅむ。あまり思い出せない... 読み直すべきかなぁ。
今日の sed script:
sed -n '/むぅ$/{
p
:loop
n
/> みん/{
p
d
}
b loop
}'
不完全過ぎるか...
ミルキーピアのネクストジェネレーション、か...
といーつつ配ってるものは pngcrush だけか... まだ。
xdelbomb は知っていたのだが、こんなものもあったとは。
cvs diff の結果から ChangeLog のテンプレートを作ってくれるツールはないものだろうか?
RCS のホームページがあることに気がつく。
cvs2cl は(ついでにいえば rcs2log もそうですが) commit 時の log から ChangeLog のテンプレートを生成するものですが、 私が欲しいのはソースの変更(diff)を解析して ChangeLog のテンプレートを生成するものです。 とくに ruby でネストしたモジュール中のメソッドの(修飾された)名前をちゃんと検出してくれるととても嬉しい...
ふと「コンサルタントの秘密」に出てきた(ような気がする) NPS を思い出す。
Freshmeat-J か... 全部は訳さないみたいだな。
拡張性とは、ものがならんでいる、ということである。 一列にならんでいるか、木構造にならんでいるか、あるいは他の構造であるかはともかく、 ともかくならんでいる必要がある。 ならんでいれば、ものを加えたり、取り除いたりすることができるのである。
と思う。
patch-to-change-log, C で試しましたがなかなかです。 こーいうものを想像していました。(さらにいうと、diff の hunk が insert されると嬉しい気がする。) いちいち point で変更点を指定しなくても済む add-change-log-entry-other-window というかんじで。
「コーセルテルの竜術士」はいつ単行本になるのだろうか。
タイトルイメージに記述言語の情報を入れようと思ったのだが、貝殻がうまく描けない... 真珠は再利用可能な素材があったのでありがたく使わせてもらう。
原稿を送る。
真珠を自分で描いてみる。
(SysV だけでなく)FreeBSD と OpenBSD のパイプが双方向であることに気がつく。
% sh -c 'read var <&1; echo $var >&2' | sh -c 'echo hello >&0' hello
OpenBSD の pipe(2) に単方向と書いてあるのはとりあえず報告 しておく。
なお、NetBSD 1.4.2 では動かない。
NetBSD と BSD/OS のパイプがソケットであるのに対し、 FreeBSD と OpenBSD のパイプはそうではないことに気がつく。 資料によれば 4.2BSD のパイプは socketpair (と shutdown?)で実装されていたらしいので、 FreeBSD と OpenBSD は作り直したのであろう。
追記: OpenBSD は FreeBSD のを port したらしい。
xdelta は gzip を伸長してから delta を作るのか... まずった。
なんとなく、zsh をすこし改造して、socketpair でパイプを作るようにしてみる。
パイプがソケットならばまず recv を試すように tar 用の gzip wrapper を修正する。
ffcall は FreeBSD では動かないことに気がつく。
[latest]