天泣記

2001/05/02

#1: むしょうに泉の精霊の話を検証したくなる。身近に「UNIXプログラミング環境」がないだろうか。
#2: CVSWeb
#3: 枝の根本から枝が生えると、枝から生えたのか幹(ないしは枝が生えている枝)から生えたのか区別できないことに気がつく。
#4: tarball generation は議論を呼ぶなぁ。
#5: 削除の後に(同内容で)復活させても annotate の出力は変わらないことに気がつく。

2001/05/04

ltag lists the symbolic tags appearing anywhere within or below a CVS sandbox directory.

Vmgen generates much of the code for efficient virtual machine (VM) interpreters from simple descriptions of the VM instructions.

#3

唐突に知見を生かして枝の関係を視覚化してみる。 apel, flim, semi, gnus.

たったこれだけ、というべきか、よくもこれだけ、というべきか。

それはそれとして vendor branch の扱いに検討の余地がある気もする...

#4

ひと眠りした後、考え直して再実装。親かも知れないしそうでないかも知れないなどという扱いの厄介な情報を利用するのはやめて、 incremental に木を修正していくのもやめて、祖先-子孫関係全体を DAG として作り上げてから topological sort で親を決定してそれ以外の辺を無視することによって木を構成することにする。 (DAG にならずに cycle が含まれるようになるリポジトリを構成することもできるが... そのような場合でもなにかそれなりな結果が出てくるようなアルゴリズムになっているから気にしないことにしよう。うん)

納得のいく結果になった。うむ。 apel, flim, semi, gnus.

#5

間違えて gif を使ってしまったので他のものにする。

#6

しかし、またも topological sort を実装してしまったわけだな... これで 3つめ(の言語)か。

#7

IDX-chrooted-ssh-cvs allows to setup a very network-secure chrooted CVS server, with SSH access.

2001/05/05

#1: ImageMagick は GraphViz (の dot)を知っていることに気がつく。
#2: 「それなりな結果」が実際にはどのようになるかを確認してみる... 木にならないでやんの。親を一つに限定するだけでは cycle を除去するには足りなくて、その一つは自分自身を含む強連結成分以外から選ばなくてはならないわけだな。
#3: cvs import -b に指定できるものは「1.1.奇数」だけではないことに気がつく。
#4: rlog/rannotate のために cvs client/server protocol が拡張されていることに気がつく。
#5: しかし、gnuplot まであつかうのは(mailcap に image/*; display %s と書いた時に)まずいんじゃないのか? あれは中からコマンドを呼び出せるぞ...
#6: www.graphviz.org
#7: 送る。
#8: ImageMagick が SVG をサポートしていることに気がつく。でもなんかやけに遅い... apel.svg で 30秒近くかかるというのは何事だろう?

2001/05/06

#1: SandWeb is a Web-based Sanbox management client for version control systems such as CVS. It is the next generation CVSWebClient.
#2: もしかして... って、もしかしなくても ViewCVS は早晩 Subversion で管理されるようになるのだろうか。それとも単なるテストで使っているだけだろうか。
#3: おぉ、これは、いろんなところの cvs の commit mail が眺められるではないか。 (着眼点が全然違う...)

2001/05/08

#1: astyle_on_commit - use Artistic Style (astyle) to automatically indent and format source-code when it is commited to a CVS repository.

2001/05/09

#1: Greg が ViewCVS に手をつけはじめた... ってことは Subversion M2 が出来上がったってことか?
#2: rlog が余計な ---------------------------- を出力するのは FreeBSD のせいだったことに気がつく。
#3: 電撃文庫 2/8

2001/05/10

#1: CVSFile-0.2.tar.gz という perl の module を知る。

2001/05/11

#1

ついに、rlog と cvs log のソースまで眺めてかなり頑健な log のパーザを書いてしまう。テストの過程で " や + を tag に使っているケースがあることに気がつく。

#2

rcsfile(5) より

num     ::=  {digit | .}+
digit   ::=  0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
special ::=  $ | , | . | : | ; | @
idchar  ::=  any visible graphic character except special
id      ::=  {num} idchar {idchar | num}*
sym     ::=  {digit}* idchar {idchar | digit}*

idc を定義、idchar を再定義
idc     ::= any visible graphic character except special and digit
idchar  ::= idc | digit

id      = {num} idchar {idchar | num}*
        = {{digit | .}+} (idc | digit) {(idc | digit) | {digit | .}+}*
        = {digit | .}* (idc | digit) {idc | digit | {digit | .}+}*
        = {digit | .}* (idc | digit) {idc | digit | .}*
        = {.}* (idc | digit) {idc | digit | .}*
        = {.}* idchar {idchar | .}*

% isomorph =(retofm <<<'((n+d)(n+d)*)*(i+n)(i+n+(n+d)(n+d)*)*'|fmminrev) =(retofm <<<'d*(i+n)(i+n+d)*'|fmminrev)
isomorphic

sym     = {digit}* idchar {idchar | digit}*
        = {digit}* (idc | digit) {idc | digit | digit}*
        = {digit}* (idc | digit) {idc | digit}*
        = {idc | digit}+
        = {idchar}+

% isomorph =(retofm <<<'n*(i+n)(i+n+n)*'|fmminrev) =(retofm <<<'(i+n)(i+n)*'|fmminrev)
isomorphic

なぜ無駄に複雑なのだろう? 構文木が重要、ってわけでもないよなぁ。

#3

etrace: A run-time tracing tool.

2001/05/12

#1

rcs の rcs file scanner を眺める。 ISO-8859-1 だったのか... いきなり non-ASCII なバイトに対して IDCHAR だの UNKN だのといった属性が定義されていることに気がつく。ちなみに sym は scanner には関係ないようだ。

non-ASCII な部分を無視しても、 id として実際に認識するのは {idchar | .}+ (のうち num でないもの)であり、 rcsfile(5) と食い違っていることにも気がつく。

#2

cvs の rcs file scanner はあまりまともではない(本来必要ない空白を要求する)ことに気がつく。出力するツールが限られてるから問題が生じないのであろう。

#3

cvsgraph の rcs file scanner も眺める。 lex を使って rcsfile(5) のとおりにやっている模様。

#4

ViewCVS の rcsparse.py も眺める。うぅむ。これは... なんといって切り出すべきか...

#5

CVSFile.pm の rcs file scanner も眺める。 line oriented だが、比較的妥当だと思う、ような気がしたのは気の迷いか。

#6

Ruby で実装してみる。遅い。 profile をとって少しチューニングしてみてもあまり高速化されない。

予想以上に小さいサイズで fork/exec のコストを scan のコストが均衡するようだ。

支配的とまではいかないが、トークンの認識後にバッファからその部分を削るのに時間がかかっているようだ... けどこれってなくせないんだよなぁ。正規表現を文字列の途中から走らせられるといいのだが。

#7

flex.rb に挑戦。bug 発見。報告。

#8

strscan も試してみる。都合がいい条件の元では (pure Ruby に比較して) 6倍くらいは速くなるか...

それでも rlog に比べると 40倍くらい遅いな。

#9

CVSFile.pm を試してみる。うぅむ。perl って速いんだな... strscan 版のさらに倍以上速い。

書き方によるのかと思って pure Ruby で CVSFile.pm を真似をしてみる... strscan 版の 1.6 倍くらいしか遅くない。 line oriented のほうがいいのかなぁ。

#10

非 line oriented な RCS file として、とある jar のやつで試す。微妙だが逆転するな... strscan 版を追い越すほどではないが。

2001/05/13

#1: line oriented 版におきかえる。
#2: 思い立って(RCS string を読む時に) "@" を terminator にしてみる。 CVSFile.pm に匹敵するほど速くなってしまった...

2001/05/14

#1: shl, the shell layer manager.
#2: cvs には rcsfile(5) の修正が含まれていることに気がつく。
#3: dead な版に rtag で tag をつけたあと、そこから branch を生やす。

2001/05/15

#1

Grail を sparc Solaris 上の gcc version 2.95.2 19991024 (release) でコンパイルできるようにするパッチ。

忘れもしない(というわりにはかなり忘れていたが)去年の某学会の大会で出会った知合いの C++ 使いに教えてもらってその場でコンパイルに成功したものである。

2001/05/16

#1: assertion failure が(無限に)出てくるなぁ。
#2: MJ: プログラミング言語 MJ
#3: バグをとってもらったので再度挑戦。こんどは大体動く。でもまたも問題を見つけたので報告。　ついでにちょいと拡張してみる。やはり他のよりもずっと速い...

2001/05/17

#1: つかまえた。

2001/05/18

#1: 変人に分類されるらしい。
#2: 大和さんの CVSTree とかぶっていることに気がつく。他の名前を考えなければ...
#3: 拡張の必要はなかったようだ。

2001/05/19

#1

しかし、なぜにみんな SKK なのだろう... やはりアイなのだろうか。

#2

rcs -o をつかえば、版がひとつも存在しない RCS ファイルをつくれることに気がつく。しかし... deltatext が残ってるのはなぜだ? ちなみにそのような RCS ファイルに ci するにはロックは必要ないらしい。しようにもする版がないのだから当然だが。

cvs admin -o では... 禁止してるか。

2001/05/21

#1

zsh-dabbrev

「端末出力からの動的単語補完」というのが気になる... script か。

#2

一日で(とゆーか 4時間あまりの間に) 2回 localtime が切り替わる例が存在することに気がつく。

/usr/share/zoneinfo/Asia/Baku  Sat Sep 26 18:59:59 1992 UTC = Sat Sep 26 22:59:59 1992 AZST isdst=1 gmtoff=14400
/usr/share/zoneinfo/Asia/Baku  Sat Sep 26 19:00:00 1992 UTC = Sat Sep 26 22:00:00 1992 AZT isdst=0 gmtoff=10800
/usr/share/zoneinfo/Asia/Baku  Sat Sep 26 22:59:59 1992 UTC = Sun Sep 27 01:59:59 1992 AZT isdst=0 gmtoff=10800
/usr/share/zoneinfo/Asia/Baku  Sat Sep 26 23:00:00 1992 UTC = Sun Sep 27 03:00:00 1992 AZT isdst=0 gmtoff=14400

2001/05/22

#1

CVS & SSL

#2

cvs というディレクトリを cvs で扱うことは可能か?

#3

ncal によれば日本の Last day of Julian calendar は 1918/12/18 らしい。そもそも日本はユリウス歴を使ってはいなかった気が... というのには目をつぶるとしてもグレゴリオ歴に切り替わる日付はこれでいいのだろうか。

サーチしてみると 1872年(明治 5年)という記述がでてくるのだが。

#4

疑問は見当ちがいだった。いつのまにか CVS/CVS というディレクトリができていたり、 CVS/Entries に CVS が記録されていたのが原因だった。しかし、これはこれでどうするとこうなるのかよくわからない。

2001/05/23

#1

非単調な関数でも 2分探索がうまく(確実に)動作する場合があることに気がつく。 (複数の解が存在する場合、そのどれかひとつが見つかればいいとする。) 2分探索がうまく動作する(単調よりも弱い)条件はなんだろう?

#2

プログラミングと暦

探し回ってしまった...

#3

FreeBSD (や NetBSD や OpenBSD)で mktime が失敗することに気がつく。

% TZ=Africa/Monrovia python -c 'import time; time.mktime((1972,5,1,0,44,30,0,0,-1))'
Traceback (most recent call last):
  File "<string>", line 1, in ?
OverflowError: mktime argument out of range

2001/05/24

#1: make-ccl-coding-system を使わないようにするという半田さんとの議論を思い出したので、すこし手を動かす。
#2: BSD の mktime は time_t の中を 2分探索をしている模様。
#3: 富士見ファンタジア文庫 2/8

2001/05/25

#1: 送る。

2001/05/26

#1: うぅむ。ChangeLog にも cvs log にも書いてないんじゃ気がつかないよなぁ。

2001/05/27

#1

localtime は TZ で指定された TZFile を使う。
gmtime は GMT (という TZFile)を使う。
閏秒の情報は個々の TZFile に記録される。

localtime が使う TZFile と GMT のあいだで閏秒の情報に矛盾があったらどうなるか?

2001/05/28

#1: 理科年表を眺める。

2001/05/30

#1: 閏秒が挿入された時の time2posix(A+1) と削除された時の posix2time(B+1) の扱いが異なるのはなぜだろうか。どちらも同じ性質(変換先に対応するものがない)だと思うのだが。

[latest]

田中哲