2006-09

GNU screen導入(再)

CygwinでGNU screenのインストールに挫折して早二年。再び挑戦してみました。

結論: インストールできた。まずconfigureで一部のテストが失敗する点を誤魔化し (自動生成されたテストプログラムがそのままでは終了しないので強制的に終了させ)、コンパイルでエラーの起きる箇所は無視するようにしたらインストールできました (後で自分のした変更と同じ内容のパッチを発見して少し凹みましたが)。

ただ問題点が一つ。attach/detachで不具合があります。detachは問題なくできるのですが、attachに失敗する場合があります。さらに失敗する場合は後始末ができていないようで、端末がstty raw -echoをしたような状態になります。

自分の試した範囲では、あるセッションを最初にdetachした端末からは二度とそのセッションにattachできません。別の端末からなら問題なくattach/detachを行うことができます。

ちゃんと動作しないのは困るのですが、この程度なら許せるレベルかな。

To vim, or not to vim

最近、エディタをvimから移行するかどうかについて結構悩んでいます。移行を考えるほど不満に感じている点は以下の二つ:

• スクリプト言語が弱い。Ex commandsを発展させた形となっているため煩雑。
• コマンドラインの編集が弱い。通常の編集と異なりモードレスであるため、通常とは別のキーバインディングを用いなければならない (正確に言うとコマンドラインの編集ではcommand-line modeというモードになる)。

どうにかしてこの二つを解決できたら移行しなくて済むのですが、どう考えても解決できそうにありません。前者は根本から書き直さないと無理ですし、後者はー……:cmapを駆使すれば不可能ではないでしょうけど、:mapや:imap等の変更を自動的に反映させることは不可能なので、やはり無理です (これさえ無視できるなら妥協することは可能)。

じゃあ本当に移行するか、となると選択肢はemacsくらいしかありません。しかし、「Escape-Meta-Alt-Control-Shift」というジョークがあるほどのモディファイヤキー押しっぱなしのキーバインドが駄目なのです。そもそも私はそれが嫌になってvi系に移行したというのに。

ああ困った。もうvimと添い遂げるしかないのかなぁ。

GC: finalizerとオブジェクトの回収順序

以前、mark-and-sweep GCの実装をしたのですが、「finalizerを追加したらどうなるだろうか」ということを思いつきました。単純に考えると、オブジェクトの回収直前でそのオブジェクトに関連付けられたfinalizerを起動すればいいだけなのですが、よく考えてみると危険な箇所がちらほら。

あるオブジェクトAが他のオブジェクトBへの参照を含んでいる場合 (Bからの参照はないものとする)

最初にA、次にBの順で回収しなければならない。なぜならAのfinalizerでBが使われるかも知れないから。Bを先に回収するとAからBへの参照がdangling pointerになってしまう。

オブジェクトの参照が循環している場合 (例: AからB、BからC、CからAへの参照がある場合)

どこから回収してもdangling pointerができてしまうため、回収することができない。

プログラム終了後に残ったオブジェクト

依然reachableであるため、回収することができない。

二つ目と三つ目はどうしようもないとして、一つ目のパターンはどうやって回収する順番を決めればいいんでしょうね?

二つ目のパターンについては、循環の中にfinalizerを持たないオブジェクトがあれば、それを利用して回収する順番を決められそうな気がするのですが……いや、やっぱり無理か。finalizerの動作はGC側には一切不明なのだから。

ins/delがブロック要素かインライン要素かの判定

HTMLのins/delは文脈によってブロック要素とインライン要素のどちらにもなり得ます。CSSを書く際に困るのがこの扱い。上手いこと両者のスタイルを分けて指定できないものでしょうか?

<ins class="block">のようにclassで明示する

論外。

XSLT等で自動的に処理するならばあり。でも、できればCSSのみで済ませたい。

両者のどちらでも問題のないようにスタイルを書く

妥協案。ただし本来の目的は達成できず。

全部ブロック要素として扱う (インライン要素として扱われるものは無視)

妥協案その2。このサイトだと基本的にこの案でやり過ごしていましたが、やはり本来の目的は達成できず。

両者を判定するセレクターを考える

これが本題。

しかし正確に判定するとなるとややこしい。「デフォルトでインライン要素として扱い、ブロック要素を含む場合のみブロック要素として扱う」ようにすれば大体において上手くいく (と思う) のですが、CSSのセレクターで「fooを含む」ものは表現できないため、実現不可能です。

取り敢えず「デフォルトでブロック要素として扱い、インライン要素しか現れない文脈でのみインライン要素として扱う」ことで妥協しました (例: p ins)。判定がややこしくなるins/delの使い方は避けることで対処します。頻繁に使う要素ではないのでこれで十分かな。

C: 関数へのポインタとvoid*が相互変換できない理由

Cで関数へのポインタをvoid*に変換しようとするとコンパイラによっては警告が出ます。例えば、以下のプログラムを

#include <stdio.h>

int
main(int ac, char** av)
{
  return printf("%p\n", (void*)main);
}

gccでコンパイルすると、以下の警告が出ます。

$ gcc -pedantic -Wall pointer-test.c
t.c: In function `main':
t.c:6: warning: ISO C forbids conversion of function pointer
to object pointer type
  

前々から何故このような警告が出るのか疑問に思っていました。「指す対象が関数であっても、ポインタであることには変わりないのだから、void*に変換できてもいいのでは」と。

しかし変換できてしまっては困る場合があります。ポインタの種類によってそのサイズが異なる場合があるからです (例: MS-DOSのメモリーモデル。smallだのmediumだのcompactだのlargeだの)。これじゃあ警告が出るのも当然です。

長年の疑問が解決してすっきりしたのですが、別の疑問もでてきました:

• 任意の関数へのポインタはどうやって表せばいい?
• gccでこの警告だけを抑制するにはどうすればいい? (両者のポインタのサイズが同じと仮定して)

Subversion試用開始

いい加減CVSに不満が出てきたので、別のバージョン管理システムに移行しようと思いました。最初はGNU archにしようと思ったのですが、ファイル名とディレクトリ名の長さから色々と問題を招き、私の環境ではまともに使うことができません。

という訳でSubversionに移行することにしました。ある程度試用して納得ができたら、既存のCVSのリポジトリも移行させるつもりです。

取り敢えず基本的な操作は押さえたので、後はブランチ云々かな。