lock, unlock, optimistic, pessimistic, signal, exception, cache, consistency, optimal, がー。
まぁ、たしかに main trunk では -j では日付指定が出来ないような気がしますね。 (branch ならできるのだが...)
それはともかく、tag なんてつけなくても cvs diff -D "9/29/2000 JST" |patch -R で済むような気がしますが。
とある working directory には復旧作業編が書きかけで放り出してあったりする。
そこには... いきなり cvs admin -o と cvs admin -b とか書いてあるな。
唐突に 1.1 が存在しない場合の import の挙動について調べる。 1.2 とかから始まって 1.1 を追加不能な場合に失敗するのは予想通りであるが、 0.x しかなくて、1.1 を作れる場合でも失敗するんだな。
ひさしぶりに、_cvs に手を入れる。
sed programming. 13行。
1.1.1 に複数の vendor branch tag がついているものが(けっこう)存在することに気がつく。 (cvs import module <TAB> でわかる。)
ひどいコードを書く自覚はあるのですこし反省。
例: doodle の automata.el のとある行のインデントは 77カラムもあるとか...
とはいえ、 最近「リファクタリング: プログラミングの体質改善テクニック」を読んで いろいろと思うところがあったこともあり、 まともなコードにしようとは思っているのだが。
(CVSsuck のコードが結構修正されている割に、 ぜんぜん機能が増えないのはそのためなんだな。)
doodle のコードで厄介なものとしては、automata.el の他に mel-q-ccl.el がある。 ちなみにこちらは FLIM 本体に採用されている。
まぁ、こんな長い CCL プログラムになっているのには(automata.el とは違って)それなりの理由があるが、 CCL の partial evaluator もどきをでっちあげればもう少しましなコードになったかも知れないとも思う。
SourceForge のリポジトリの取得の効率改善... をするために、とりあえず tarball 更新時刻の調査をはじめる。
以前設定したときに大雑把にやったのだがいつのまにかずれていた模様。 適応的に動作させるべきか?
どーせほぼ 24時間毎に更新されるので、 (取得済みの) tarball の mtime から 23時間経過していなければ実際の取得を行なわないようにすればよかろう。 たぶん。
それはそれとして... wget -N が If-Modified-Since を使わないのは納得がいかない。
最近調査してないけれど、他のツールの状況はどうなんだろうか。
(Sometimes I wonder how you find things like these...)
といわれたらどう返答すべきか。まぁ、返答しなくてもいいか。
うぅむ。停電があると調査の連続性に問題が出る... ことはないか。 ghostscript も zsh も bbdb も日本時間の夜から深夜にかけて更新されるから、 停電の時間とは重ならない、と。 ghostscript は 20時とか 21時だから微妙かもしれないか。 zsh と bbdb は 1時とか 2時だから間違いなく復電しているであろう。
とってきた tarball を展開したら permission がきつすぎて他の人が読めない。 とくに、drwxrws--- というのはまずい。
どうやったら他人でも読めるようにできるか?
2回 traverse するなら簡単(find, xargs chmod をそれぞれ 2回)であるが、 1回ですませることができるだろうか? directory 以外の file の x bit は変えずに。
ghostscript には間に合わなかった...
ファンタジア文庫の残り一つ(ザ・サード)をやっと見つける。
ドラゴンマガジンが出た直後に出るのではなかったのか?
CVSsuck のページを作りかけてみる。
cvschroot に細工をして cvsroot を CVS ディレクトリ内に記録してみる。 補完のために。
手元での設定の変更をリポジトリに吐き出す。
しかし、LANG のうまい設定法はあるのだろうか...
いちおう、0.1 としてみる。
GILT: the text oriented vector drawing program
今日のスクリプト: sourceforge-id
#!/bin/sh
cat <<End |socket sourceforge.net 80|awk -F/ '/^Location:/ {print $3}'
HEAD /project/?group_id=$1 HTTP/1.0\^M
Host: sourceforge.net\^M
\^M
End
(vis 済み)
現時点で 12528 が最大らしい... top page の Hosted Projects: 9776 よりも大幅に多いのは途中に割り当てられていない id があるためか?
で、
% for i in {1..200}
do
proj="`./sourceforge-id ${i}`"
[ -z "$proj" ] && continue
echo -n "$i $proj\^I"
print -l "HEAD /cvstarballs/$proj-cvsroot.tar.gz HTTP/1.0\^M" "Host: cvs.sourceforge.net\^M" "\^M"|socket cvs.sourceforge.net 80|grep Last-Modified
done
(vis -t 済み)
うぅむ。id 順というわけでもないのか。さりとて、名前順というわけでもなく... どんなふうに作っているのだろう?
Metaver: Better Free Version Management
WEBRCS を ちゃんと checkout できるひとはあまりいないような気がする。
Subversion の Milestone 1 は順調に 遅れている模様。
cvschroot の補完を refine. CVS/.cvsroot-list にではなく、~/.cvsroot-list に全部の情報を記録する。
prolog で書きたくなるところであるが、我慢して awk programming. 55行。
cvschroot cvsroot と実行することは、 コマンドラインで指定した cvsroot と CVS/Root に記述された cvsroot の CVS/Repository に記述されたモジュールが等価だという言明と解釈できる。 で、推移律と、モジュールが等価であればそのサブモジュールも等価であるというルールを 足せばできあがりなはずである。 これは prolog で書きたくもなる。 まぁ、推移律は少し厄介かも知れないが...
推移律を簡単に扱うには完備化してしまえばいいのかもしれない... prolog ではできないかも知れないが。
~/.cvs* が増え過ぎな気がする。 ~/.cvs{pass,rc,root,root-list,root-list.bak,rsh}
補完しにくい。
考えてみると、どちらかというと問題なのは推移律じゃなくて交換律なんだよな。 (ちなみに反射律は問題ない。)
例示を膨らませて等価関係を構成するところに問題があるのは変わらないのだが。
SourceForge のリポジトリをたくさんとってくると ローカルにリポジトリが増え過ぎて、気に食わない。
とゆーわけで、sourceforge というリポジトリを作って その中に放り込むことにする。
が、しかし、すると、SorceForge とローカルのリポジトリで module が変わる (ローカルでは project 名が前置される)ことになる。 cvschroot はこれを書き換えられない。 cvsrepo に乗り換えるべきか? でも、cvsrepo は module 名が必須なのがまた気に食わない。
それに cvschroot のほうが(cvs_chroot や cvsrepo よりも) directory の traverse がまとも(とゆーか cvs 流)だし。
cvs import の vendor tag ってのは 1.1.1 につける名前で、 release tag ってのは 1.1.1.x につける名前です。
とゆーのはわかっている人にしかわからない説明だよな... 嘘は書いていないと思うけれど。
cvs commit -r2.0 とすれば 2.0 を使えます。お勧めはしませんが。 さらにいえば、(新しく追加するファイルには) 0.x も使えます。
まぁ、default branch に気がつかないうちは何が起きているのか腑に落ちないと思う。
-e が、 という以前に test さえない Bourne shell もありますが。というかもともとそうだったというか。
sodipodi: General vector illustrating application for GNOME environment. It uses W3C SVG as native file and in-memory image format and can do many neat things.
[ は SunOS 5.6 ですでになかったですね。 それ以前はちょっと確認できないです。
しかし、csh では [ が builtin ではないので困ったことになったはずなんですが、 気にした人はいないんでしょうかねぇ。
[ がなくなったといえば、shellutils もそうです。 消えたタイミングが automake 化された時点なので、 Makefile に(対になっていない) [ を書けなくてあきらめたのではなかろうかと以前から想像しているのですが、 だれか事情を知りませんかね?
ふむ。1.1.1 は 1.1.0.1 にはならんのだな... 魔法がかからないというか。
ってゆーか、普通の枝に魔法がかかる理由も良くわからないのだが。
日曜日に停電があるのだが、間の悪いことに土曜から一週間お出かけである。
復電時にちゃんと自動復旧すればいいのだが...
停電は日曜ではなく土曜であることが判明。
とりあえず、/etc/init.d/halt から -p を削除。
pipestatus/PIPESTATUS ってのははじめて知ったね。
hardware clock を JST のままにして、 default の timezone を CDT6CST にするにはどうしたらいいのだろうか?
とりあえず、TZ=CDT6CST で済ませたが、 環境変数ではなく、/etc のどこかを書き換えて、というわけにはいかないのだろうか?
internet access が提供されていないなんて思いもしなかったね...
今日の shell script:
#!/bin/sh sleep `expr 86400 - \( \`date +%s\` - 971607600 \) % 86400` while : do echo -n \\a sleep 1 done
internet に接続する。
www module の中身が増えていることに驚く。
mail を読んで zsh-3.1.9-dev-7 が出ていたことを知るが、 cvs repository はまだ更新されていなくて悲しい。
Monty Python の Holy Grail を見る。 やはり字幕がないとよくわからない。
internet に接続する。
mail を読む... cvs.m17n.org のメンテナンス(ユーザ管理)の仕方を文書化していなかったことをすこし後悔する。
きっと流儀がわからなくて root 権限で無理矢理書き換えたに違いない。
帰りつく。
うぅむ。SorceForge のリポジトリの tarball が update されていない...
diff-patch なためではありません。 それは嘘です。実際、LF な世界では -ko でも問題ありません。
HOME を設定しない inetd もあります。
cvs に rcs は必要ありません。 少なくとも 1.10 以降では。
permission が基本、という見解もあります。
CVSROOT が空でも checkout はできることに気がついて驚く。
test suite があったら欲しいというので、 とりあえず EOF BLOCK に関するものを作る。
テストフレームワークが欲しくなったので、簡単なものを作ってみる。 elunit.el という名前にしようかとも思ったが、名前負けしていると恥ずかしいのでとりあえず eltest.el とする。
それはともかく、なんか 21 のみならず 20.7 でもずいぶんと壊れている気が... ってわけでもないか。
書類を書くたびに今年が平成何年だったか忘れていることに気がつく。 西暦のほうも似たようなものだが、こちらは date コマンドでかたがつく。
ぬー。Solaris の cat -un はぜんぜん -u になってないぞ。
微妙な Attic 問題を調整する。 まったくなんで HEAD が dead でないのが Attic に入っているのか。 (どーせ直接 mv したに違いない... 邪推だが。)
まぁ、ともかくこれでまともに co できるようになった。
CVSupd の認証を調べる。 ぬぅ。一部の collection だけ認証することはできない、のか?
unibyte を書き出す時にはコード変換が抑制されることを知る。
で、process-send-string の引数が multibyte から unibyte に切り替わるたびに coding system が flush されて EOF BLOCK が動くというのは面白過ぎる。
なお、UTF-8 でも unibyte から multibyte に切り替わるたびに signature が出ると推測される。
ついに ASCII のみの場合でも、multibyteness を気にする必要が出てきたか、となかなか感慨深いものがある。
*scratch* で、
(setq o1 (make-overlay 1 2)) (setq o2 (make-overlay 2 3)) (overlay-put o1 'after-string "abc") (overlay-put o2 'after-string "def") (overlay-put o1 'invisible t) (overlay-put o2 'invisible t)
で、abc が出ない...
うぅむ。いつのまにか $CVSROOT には port や password を含めるようになっていたのか...
$CVSROOT の path 部分を可能な限り自由に設定できるようにするにはどんな directory 構成がいいだろうか?
複製するときにはやっぱ複製先に合わせると便利なこともあるだろうし... (他人が古い cvs で checkout した working directory で cvs diff ができるとか。)
まぁ、/etc とか /dev は使えなくてもいいかも知れない。
今日の elisp script:
(defadvice modify-frame-parameters (before resolv-color activate)
(ad-set-arg
1
(mapcar
(lambda (p)
(if (memq (car p)
'(background-color
foreground-color
cursor-color
mouse-color
border-color))
(cons
(car p)
(resolv-color (cdr p)))
p))
(ad-get-arg 1))))
(defun resolv-color (c)
(if (string= c "蘇芳")
"CIExyY:0.3812/0.3105/0.06555"
c))
byte compile 時に obarray を作って実行時に使うことはできるんだろうか?
とあるメールをきっかけとして、つい、作ってしまった。 munsell.el
M-x set-background-color で「さくら」と入力できて嬉しい人がどの程度いるかは知らないが。
無彩色を xyY で表すと x, y はどうなるのだろう? C の x, y はなんか色みがかっているし... (D65 はちょっとはましだけど。)
obarray って 扱いが難しいですねぇ。
ChangeLog のことを少し書き足す。
「今の cvs はバリバリに外部コマンドに依存しまくり」って... どこでそんなうそを聞いたんだか。
ジャンプの表紙が... どうみても桃栗みかんの絵に見えるのだが...
gmake の「入ります」「出ます」というあの至極評判の悪い訳が改善可能なように gmake 本体がすでに修正されているらしい。
gtar の bzip2 オプションは -I からさらに変わって -j になっているらしい。
[latest]