天泣記

2001/09/01

#1

RWiki でページの RD を取り出す方法を調べる。

#2

cvs update -d は Entries.Static を消すことに気がつく。

#3

Jam を眺める。

p4 で public depot からソースを取り出して Jam.html を読む... ふむ。HDRSCAN and HDRRULE ねぇ?

#4

ついでに cook も眺め... ようとするが、 リファレンスマニュアルの構成にめげてあきらめる。

#5

make++: A better, safer make implementation

おぉ。 ファイルを作ったときに実行したコマンドを覚えておいて、 コマンドが(Makefile の変更により)変わったときも自動的に実行してくれるようだ。 うむうむ。そうあるべきだよな。

#6

icmake を眺める... これってほんとに make like tool なつもりなのか?

#7

bake を眺める。 それなり、かな?

#8

Sire を眺める。 ふむ。

#9

cake を眺める。 ふむ。source, target が抽象化されているというのは興味深い。

だが... home page はどこだ?

#10

odin

あぅ。依存関係にサイクルがあったら不動点に達するまで繰り返し実行する、だと?

気が向いたら TeX で試すか...

#11

cons

ふむ。QuickScan?

#12

makeme, xmake, dmake, make module for perl, ...

うぅむ。調べつくせる気がしないぞ...

#13

しばらく make++ を使ってみるか。

気が向いたら odin も試そう。

#14

とりあえず、.PHONY をさぼらずに記述するようにはなるな...

2001/09/02

#1

Ruby のリポジトリには自動生成するファイル(lex.c)が入っていることに気がつく。

#2

そーいや、freshmeat を調べていなかった。

iMake, bras, myke, _smake

sourceforge も。

jmk, scons, turtle, buildsafe, jus, bau, Ptah, Sake

#3

もしかして、[a-z]make が揃っていたりする?

amake, bmake, cmake, dmake, dmake, emake, gmake, hmake, hmake, imake, jmake, mmake, mmake, nmake, omake, pmake, qmake, rmake, rmake, smake, tmake, umake, vmake, vmake, wmake, wmake, xmake, zmake

全部とまではいかないか。

#4

昔から、time stamp だけじゃなくて、 実際に中身が変わったかどうかも調べるべきだと思っていたのだが、 そういうことを実装しているツールもそれなりにあるようだ。

まぁ、だれでも思いつくことなわけだな。

#5

もしかしたら事前にすべての依存関係を求めるのは正しくないのかも知れない。

make というのは依存関係を記述してその関係にしたがって処理を実行していくわけであるが、 むしろ、処理を記述してそこから依存関係を求めていく方がいいのかも知れない。

たとえば、C のソースからオブジェクトファイルを作るときには cpp の実行結果を見れば依存関係はすべてわかる。

とすれば、 

cc -c a.c
cc -c b.c
cc -c c.c
cc -o f a.o b.o c.o

と人間に書かせて、 最初に作るときにはそのとおりに実行しつつ依存関係を収集し、 次回からはその依存関係を利用して可能な限り作業を省略する、 というやりかたのほうがいいのではないだろうか。

まぁ、記法は工夫できるだろうし、 大まかな依存関係 - build -> install だの build -> test だの - くらいは人間が書いてもいいかも知れない。

2001/09/03

#1

CVSPLOT: RCS/CVS Archive plotter

#2

An Automatic Make Facility, Ian Holyer, Huseyin Pehlivan

ヒストリから情報を取り出せば Makefile は必要ないって? うぅむ。

#3

mkdep っつーと、 これか。

ふむ。makedepend や gcc -MM と同じく、事前に作るというアプローチみたいですね。 (freshmeat や sourceforge にも同じような系統のがいくつかあった気がする。)

「いつ依存関係を update すべきか、というのが判然としない」のも、 「依存関係の収集が案外高くつく」のも、 結局のところ事前に求めないといけないからだ、という主張(ないしは感想)だったりするんですが。

依存関係を事前に求めるのをあきらめて、 コンパイル時にコンパイラ(や他のツール)に報告させれば 作ってしまったファイルに関していえば完全な依存関係が得られて、 次回からはその依存関係とファイルを比べれば更新が必要なのかどうかが判明する...

結局、build する前に依存関係を作るのではなく、 作ってしまったファイルの依存関係を記録するというのがアイデアの核なわけです。 (Ant の depend に強く影響されていますね。 あれはクラスファイルがそういう情報を含んでいるからできるわけです。)

むろん、こうすると事前には依存関係がわからないから、 clean build のときの処理内容を指定する必要があるし、 いきなり任意のファイルだけ指定して作るというのは難しいかも知れないという問題はあります。 (引数から生成するファイルが決まってしまうような場合にはどうにかなる? program slice との関連?)

ライブラリについては... まぁ、さまざまな問題が思い浮かんできますが、依存関係とは別の話な気がします。 いや、ライブラリの中の一部に依存しているときに... という話なら依存関係の話になりますか。

#4

[a-z]wm は調べたことがないなぁ。

[a-z]sh についてはShell についてというページがありますね。 なお、同じようなページを私も作っていたりしますが、 名前順ではないですね。

... もしかして投稿も可能なのだろうか?

#5

autodep は... これも makedepend, gcc -MM, mkdep と同じ系統ですね。　 .depend に吐くところは mkdep に一番にてるかな。

#6

知合いに話したら、即座に並列ビルドが難しいのではないかと指摘されてしまった...

#7

そうそう、[a-z]grep は以前調べたんですが全部ありましたね。 bgrep (Boyer-Moore grep - 全然 regular expression じゃないじゃん) とか、 lgrep (ls-lR 専用の grep) といったところが印象に残っています。

2001/09/04

#1

上野さんに Dependency Tracking in Automake というページを教えてもらう。

なかなか。

#2

rtag のときには taginfo の current directory は repository 内のようだ。うぅむ。

#3

面接にいく。

どのようにしてこんな人間になったのかを尋ねられる。 採用とは関係なく、 こういう人間を量産するにはどうしたらいいのか知りたいらしい。

#4

Tetris

2001/09/05

#1

Subversion milestone 3

出ていたか。

2001/09/06

#1

つくばエクスプレス (常磐新線)

2001/09/10

#1

XMLdiff

alphaWorks のとは別物。

"Change detection in hierarchically structured information" by S. Chawathe, A. Rajaraman, H. Garcia-Molina and J. Widom というのを使っているらしい。

#2

他にもあるかと思って探してみる...

xmldiff, xmlrcs: 読めないので内容はわからないが... 想像されるようなものなのだろうか?

DOMMITT Diff and Merge utility for XML

diffmk: Perl の Algorithm::Diff を使っている?

DeltaXML

#3

cvsup-16.1d を build する。

#4

某同人誌の 原稿'

ふと思い出したので掘り出す。結局まだ直していないな...

#5

バイト列から termcap の code を取り出すスクリプトを非バッチ的に動くように refine する... が、またも flex.rb のバグを見つけてしまう。

なんとか避けて動かす。 script -t 0 で生成中の typescript を tail -f で読んでスクリプトに食わせるとなかなかおもしろい。 zsh が最初のコマンドラインの最初の 1byte をいったん消すとかの挙動がよくわかる。

しかし... どんな名前にしたものか。 termcup がいいのではないかと思いつつも なんの略にすればいいのか思いつかないし。

2001/09/11

#1

58個正規表現を与えると core を吐くという flex.rb の問題は報告しておく。

#2

正規表現メーリングリストのメールを掘り出す。

Ruby 方面のひとがけっこういたことに気がつく。

2001/09/12

#1

puf is a download tool for UNIX-like systems.

#2

cmix のサンプルを試してみる。

レイトレーシングのが終わらない...

2001/09/13

#1

一晩たっても終わらないのであきらめる。

#2

cmix をつかって以前の妄想が実現可能かどうか確かめてみようと思い立つ。

とりあえず、Unix From の検出コードを

char *p, *q;
p = q = "From ";
while(*q) {
  if (*q != ch) {
    column = q - p;
    while(p < q)
      fputc(*p++, out);
    break;
  }
  q++;
  ch = getc(in);
}
if (!*q) {
  fputs("=46rom ", out);
  column = strlen("=46rom ");
}

というふうに記述して、

if ((int )'F' != ch) {
  column = 0;
} else {
  ch = getc(in);
  if ((int )'r' != ch) {
    column = 1;
    fputc(70,out);
  } else {
    ch = getc(in);
    if ((int )'o' != ch) {
      column = 2;
      fputc(70,out);
      fputc(114,out);
    } else {
      ch = getc(in);
      if ((int )'m' != ch) {
        column = 3;
        fputc(70,out);
        fputc(114,out);
        fputc(111,out);
      } else {
        ch = getc(in);
        if ((int )' ' != ch) {
          column = 4;
          fputc(70,out);
          fputc(114,out);
          fputc(111,out);
          fputc(109,out);
        } else {
          ch = getc(in);
          fputs((char const *)s46rom_,out);
          column = 7;
        }
      }
    }
  }
}

static char s46rom_[] = "=46rom ";

というコードに変換することはできた。

それ以降の部分はすこし頭をひねる必要がある模様...

#3

ふむ。`=46rom ' よりも `From=20' のほうが美しい気がする... いや、微妙に危ない気もするな。

2001/09/14

#1

diff.rb: Perl の Algoritm::Diff の移植ってことは McIlroy-Hunt のアルゴリズムだな。

McIlroy-Hunt のアルゴリズムってもともとどこで発表されたのだろう... AT&T の technical report なのか。

J. W. Hunt and M. D. McIlroy. An algorithm for differential file comparison. Computer Sciences Report 41, AT&T Bell Laboratories, Murray Hill, New Jersey, 1975.

McIlroy の home page には... タイトルだけか。 Hunt の home page は見つからない。

Unix の diff に使われているのか... うぅむ。けっこう由緒正しいものだったのだな。

ふむ。

J. W. Hunt and T.G. Szymanski, A fast algorithm for computing longest common subsequences Comm. ACM , vol. 20 no. 5, pp. 350-353, 1977.

にも載っているらしい。

図書室にいって入手してくると... 最悪 O(n^2 log n), ある条件下では O(n log n) だそうだ。 ざっと眺めたところでは contours 系な気がする。

#2

#ifdef Considered Harmful, or Portability Experience With C News

#3

GNU diff はまた別のアルゴリズムを使っているわけであるが、 この違いを計測により判断するとしたらどのようにすればいいだろうか?

#4

がーん。バグを見つけてしまった。

(quoted-printable-ccl-encode-string "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaFrom bbb")
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=
From bbb"

quote せねばならん...

入力の行頭ではなく出力の行頭を検査しなければならないのだな。

#5
% print -l bbb 'From aaa' |mmencode -q    
bbb
=46rom aaa
% print -l 'From aaa' |mmencode -q    
From aaa

バグ?

まぁ、報告する気にはなれないな。

2001/09/15

#1

dotfile で条件分岐... 昔、home が NFS なヘテロな(Sun, NEWS, NeXT)環境にいたときに必要になって 以来 shell についてはそうやっているな。 (cvs で管理するようになったのはずいぶん後になってからだけど。)

ただ、最初は素朴に条件分岐していたのだが、 その結果何が起きたかというと... 細かく条件分岐するためか、 shell の起動に数十秒かかるようになってしまったという。 あと、条件判断のために NFS にアクセスすることがあって、 サーバが落ちていると刺さるという問題もあった。

その後、それに懲りて hostname のみによる分岐を目指すも、 よく使う host 以外の設定をする手間が大きすぎて敗退。 (継承して再利用する程度では host 数に比例する手間なのは変わらないのでだめだった... ちょっとうそ。)

現在は、条件分岐した結果を host ごとに dump し、 2回目からはそれを読む、という形に落ち着いている。 (設定ファイルを host について partial evaluation するのだ... ちょっとうそ。) まぁ、設定が変化したときの検出とか、微妙に問題もあるのだが。

この話をすると、 条件分岐をするという段階については共感を得られることが多いのだが、 それ以降の段階については反応がない、というということが多い。

ちなみに、dotfile に関する ML は昔 ALICE というのがあったが、 アーカイブを覗いてみたかぎりでは好みには合わなかった。

#2

ふむ。 cmix 版で試してみるも、なかなかきれいに書くのは難しい。

2001/09/16

#1

C-Mix の manual を眺める。

polyvariant ではないのか... binding time の異なる struct も扱えないし、 あまり高度な奴ではないのだな。

2001/09/18

#1

結局、CCL で partial evaluation のまねごとをする利点は フラグの類にレジスタを消費せずに済むという点が一番大きいのかも知れない。

でも、 レジスタが一つでも使えれば 24個は(簡単に)表現できるんだから、 あまり意味がないのかも。

#2

うぅむ。ssh が通らない...

使えるものは HTTP と DNS だけか。

2001/09/18

#1

Socks via HTTP

2001/09/20

#1

FreeBSD では(4.4BSD では?) TCP の状態を sysctl で入手可能なことに気がつく。

getsockname で ECONNRESET を検出することもできるか。

#2

TCP connection の application gateway で、 half close をちゃんと扱うことは可能なのだろうか?

application gateway が中継点で動いており、 接続元が中継点を通して接続先に接続するとすると、 接続先が half/full close したとき、 中継点は接続元に対して half/full close したように振舞うべきである。

が... half/full close の区別は可能なのだろうか? あるいは、接続先と中継点が区別不能な状況をつくり出せるだろうか?

half close というのは典型的には接続先が shutdown(s, 1) を実行したときのことである。 (shutdown(s, 0) も half close といえるのかも知れないが、動かない気がする。)

それに対して full close というのは shutdown(s, 2) ないしは close(s) のことである。 (exit も。)

さて、接続先が half/full close すると、 接続先が中継点に FIN を送って FIN-ACK が返答され、 接続先は FIN_WAIT_2, 中継点は CLOSE_WAIT になる(と思う)。 このことは half/full close でも変わらない。 そのため、接続先が half close したのか full close したのかを中継点が知ることはできない。

half close と full close の違いが外部から観測されるのは 接続先にデータがさらに送られたときである。 half close されているとデータは受信され、ACK が返答され、 接続先・中継点の(TCP の)状態は FIN_WAIT_2, CLOSE_WAIT のままになる。 しかし、 full close されているとデータは受信されず、RST が返答され、 この RST によって接続先・中継点の状態は CLOSED になる。 そして、CLOSED の状態でもう一回データを送ろうとするとエラーになる。　 通常のプログラムにとってはエラーが出るかどうかが half close と full close の違いである。 TCP の状態を観測すれば CLOSED になった時点で知ることができるが、そのためのポータブルな方法はない。たぶん。

さて、問題は、中継点が CLOSED になった時点で接続元も CLOSED にできるか、ということである。 中継点から接続元に RST を送れればいいような気がするのだが、それは可能だろうか? 普通のユーザ権限で。

root 権限があれば SOCK_RAW でやりたいほうだいなのかもしれないが...

#3

高所恐怖症ぎみなひとにはむかないところだ...

2001/09/21

#1

httptunnel を試す。

ふむ。 htc --stdin-stdout を使って ssh の ProxyCommand から起動するとうまくいかないな。

htc --forward-port 待ち構えてやれば動くが。

それなりな速度で動くな...

#2

Linux ではバッファに溜っているデータを全部読み込まずに close すると RST が発生する模様。 FreeBSD では FIN が発生するのだが。

Linux だと、MSG_PEEK でバッファから出さずに読みつつ CLOSED になったら close してしまうという手が使えるのか?

#3

ふむ。SO_LINGER が使えるのか?

#4

うぅむ。mod_proxy 経由では httptunnel にはアクセスできないのか?

httptunnel は HTTP の使いかたが怪しい気がする...

#5

ぎょ?

2001/09/22

#1

httptunnel というのはリクエストを(行きと帰りの)2つしか生成しないのか... かなり意外。

#2

mod_proxy に手を入れる。 結局、(ap_b)flush を 4ついれると httptunnel が通るようになった。

htc が /index.html 固定なのはとりあえずソースを書き換えて対処。 本来これは設定可能であるべきであろうが、 /index.html?crap=... というように crap というのがつくので、 これを使えば apache 側でも対処可能かも知れない。 mod_rewrite か?

それはそれとして、httptunnel の FAQ にある

However, a CGI proxy which forwards the requests to a normal hts listening to a port != 80 whould most probably be quite trivial to implement.

というのは嘘であることがわかった。 trivial とはまったくいえない、 とゆーかすくなくとも apache の CGI では不可能。

2001/09/23

#1

htc に手を入れる。送る。

#2

しかし、httptunnel が使えない proxy はそれなりに存在する気がする。 まぁ、squid を通れれば実用上問題ないのか?

#3

もしかしたら、適当な設定をすれば 普通の mod_proxy でも通るのかも知れない。

#4

しかし、一度に一つしかつなげないから公開用途には向かないなぁ。

hts で複数の接続を扱えるようにするというふれこみのパッチもあるようだが... htc は依然として一度に一つしか扱えないし、 ほぼ同時に接続しようとすると片方が失敗して htc が死ぬし...

ついでに、そもそもなぜか扱えるようにならない。なぜ? 簡単なものなら動いている気がするのだが、 ssh が多重化できないのでは話にならない。

#5

GSP: General Server Pages

#6

httptunnel が扱いにくい理由の一つは経路の性質を人間が見抜かなければいけないことだと思う。 自動的に検出することは可能だろうか?

たとえば、GET でサーバからクライアントへデータを送信させるときに、 送信が終了してからクライアントに届き始めるのか、あるいは、 送信が終了していなくても送信したぶんはクライアントに届くのか、 届くとすればどのくらいのバッファがあるのか、など。

httptunnel の都合としてはサーバで出力したものが即座にクライアントに届くと都合がいいわけだが。

#7

手元でいじくる都合上、httptunnel のリポジトリを吸い出す。

vendor branch 上での開発を実践してみよう...

2001/09/24

#1

東京に寄り道して買い逃していた(ないしは入荷していなかった)ものを2冊買う。

2001/09/25

#1

httptunnel は必要なかった。

2001/09/26

#1

今日の Ruby script: hidden channel 

#!/usr/bin/env ruby

require 'timeout'

Thread.new {
  secret = [false, true, false, true, true, false, true, true, false, false, true]

  secret.each {|v|
    if v
      begin
        timeout(1) {loop {}}
      rescue TimeoutError
      end
    else
      sleep 1
    end
  }
}

loop {
  i = 0
  begin
    timeout (0.1) {
      loop { i += 1 }
    }
  rescue TimeoutError
  end
  print i, "\n"
  STDOUT.flush
}

2001/09/27

#1

port forwarder にスレッドはいくつ必要か?

多すぎ? 少なすぎ?

2001/09/28

#1

生?

#2

出発時点で携帯していたのは 3冊。 現時点で 8冊携帯している。

帰りつくときには?

#3

13冊であった。

#4

ビーンズ文庫?

2001/09/29

#1

今まで、角川学園小説大賞関連の作品はことごとく面白くない - ないしは好みに合わない - ものにしか出会えなかったのだが、 ついに例外に出会ったような気がする。

[latest]

田中哲