Orz日記 by Akio Morita

_ [SAD]1.0.10.2.8a

なんか、MAIN trunkに Cygwin用の変更が入っているが、 見るからに uglyなコードですねぇ

mk/sad.tcltk.mk

MacOSX上の VMwareで動かす Cygwin on Windosから MaxOSX上の File Systemを見ると:が%003Aに化けるそうだが、 VMware3の頃と同様にホストOS側とゲストWindowsのFile System共有に SAMBAを使っているのなら SAMBAの HEX codingが原因に思えるのだが...

だとすると、環境側の問題なので取り込むべきでは無いよね

もしも、Cygwin上で展開したFile Name Space上の:文字が 化けるとしたら、File System層のエミュレートにバグがあることになる

WindowsのローカルなNTFSを bin modeで Cygwin側にマウントしている 状況で、Cygwinな bashからecho foo > bar:zooを実行すると barというファイルが出来る。つまり、:から先の PATH名が 無視されている。unix互換じゃないぞ！(2008-07-08追記)

以前、MacOSX上で shellからでは無く GUI付きのMacアプリな展開ツールで tar.gzを展開すると:が別の文字に変換されるという事例に 遭遇したことがある。 MacOSの PATH Separatorは :だが、unix側のAPIを使うと(unix shell等) unix API側で:と/を入れ替える変換を内部的に実施しているが、 昔ながらのMacOS API(おそらく Carbon)ではそのような変換を行わないので アプリ側が変換しているのが原因だった。

.depend

実在しないファイルの依存関係が commitされている

make dependするときは、cleanな source treeで行いましょう

srcまわり

uglyですねぇ...

ucontext_t型

ucontext_tに関しては、SUSv2/POSIX.1-2001辺りに有るらしいし、 sigaction(2)で POSIX SA_SIGINFOなハンドラが使える場合は 第3引数が ucontext_t*なのでその定義が必要で、 SA_SIGINFOマクロが未定義という問題が出ていない以上、 環境依存のucontext_t型を定義するヘッダーは存在しなければならないはず。 したがって、無いのは全面的に Cygwin側が悪いような気がする。

SA_*マクロ

SA_ONSTACK/SA_NOCLDWAITが未定義な際に、 0以外の定数マクロを定義するのは、移植性的に NG。 フラグビットの位置は環境依存だからこそ、マクロで定義している訳で、 これを未定義だからと言って環境を考慮せず 0以外の定数にすると どんな副作用があるか分からない。

そもそも、フラグマクロが未定義ということはサポートされていないと言う ことなので、src/tfProcess_.c側で SA_ONSTACK/SA_NOCLDWAITフラグを 操作するコードを #ifdefで無効化すべきところ

getaddrinfo/getnameinfo/freeaddrinfo関数

IPv6をサポートするための Address Family Independent APIなのですが、 IEEE Std 1003.1-2004(POSIX.1)/RFC 3493らしいので、無いのは Cygwinが悪い。 あと、この手の未実装APIを独自の実装で置き換える場合、 移植性を考えると呼出側に埋め込まずに APIの実装を別ファイルにして リンク時に組み込みを制御すべきところ(置き場的には、src/simの下かな？)

Cygwin/w32api 1.5.25-15 IPv6 extension0.22なんてものが有るらしい。 つまり、Cygwinの libcは IPv6未対応ということ(2008-07-08追記)

_ [LHC]Transfer Matrixの再構築ツール

モデル上でテストした範囲では、軌道残差を共役勾配法で最小化する実装では 収束が遅い、入力される軌道情報の誤差への感度が高いなどの問題が 有るもののアルゴリズムとしては動くようなので、ツールの形に実装開始。