ToDo:
まずは、CVSで関していた SADの Release Informationページを登録 FTP serverへの uploadをテストしたら、.svnまでうpされた orz
ftpのコマンドラインには rm -rが無かったので一個一個 directoryの中身を消してから rmdirするはめに x_x;
mdeleteが有るんだから、mrmdirが有っても良さそうなのに...
vender dropにインポートした tDiaryでページを再構築し直す
これで、tDiaryがアップデートしたら vender dropへインポートして、差分をマージすることでアップデートできるはず
実際に、組み込みのプラグインをカスタムするのは先ですが(counter.rbはカウンタ置場がイケてないのでいじる予定)
原因判明
openoffice.orgには icu 3.6のソースが組み込まれており 自前でコンパイルして使っているのだが、portsが configure時にCPPFLAGSに渡している -I/usr/local/includeが自前のヘッダーへの パスよりも先に使われているために、 コンパイル時に ports/devel/icuでインストールされている icu 3.8.1のヘッダーが使用され icu 3.6のライブラリーとの リンクに失敗していました。
本来は、Makefile側を修正して-I/usr/local/includeの 優先順位を下げるべき所だが、面倒なので/usr/local/include/layoutと /usr/local/include/unicodeを一時的に名前を変えてごまかすことに
character(len=32) :: fn
fn='/dev/null'
write(*,*)'Open10'
open(10,file=fn,status='UNKNOWN')
write(*,*)'Open11'
open(11,file=fn,status='UNKNOWN')
write(*,*)'Open12'
open(12,file=fn,status='UNKNOWN')
end
| コンパイラ | OPEN動作 |
| g95 0.91 20080220 | すべて成功 |
| g77 3.4.6 | すべて成功 |
| gfortran 4.2.4 20080305(prerelease) | open(11,...)で失敗 |
| gfortran 4.3.1 20080306(prerelease) | open(11,...)で失敗 |
| Intel Fortran 7.1 | open(11,...)で失敗 |
| Intel Fortran 8.1 | すべて成功 |
character(len=32) :: fn
fn='/tmp/fortran.txt'
write(*,*)'Open10'
open(10,file=fn,status='UNKNOWN')
write(*,*)'Open11'
open(11,file=fn,status='UNKNOWN')
write(*,*)'Open12'
open(12,file=fn,status='UNKNOWN')
read(12,'(a)')fn
write(*,*)fn
read(11,'(a)')fn
write(*,*)fn
end
| コンパイラ | OPEN動作 | READ時のファイルポインタ |
| g95 0.91 20080220 | open(11,...)で失敗 | N/A |
| g77 3.4.6 | すべて成功 | 独立 |
| gfortran 4.2.4 20080305(prerelease) | open(11,...)で失敗 | N/A |
| gfortran 4.3.1 20080306(prerelease) | open(11,...)で失敗 | N/A |
| Intel Fortran 7.1 | open(11,...)で失敗 | N/A |
| Intel Fortran 8.1 | すべて成功 | 独立 |
調査の範囲では、dup2(2)で上書きするための Logical Unit Numberを 確保するのに/dev/nullを多重OPENするという戦略は移植性が無い。
Intel Fortran 7.1から 8.1への挙動の変化が謎ではあるものの、 g77とことなり Fortran95規格ベースで実装されている gfortran/g95の挙動を 見る限り「同一ファイルへの多重OPENは禁止」は Fortran仕様的に何らかの根拠があると思われる。
integer :: i
write(*,*)'Open10'
open(10,status='SCRATCH')
write(*,*)'Open11'
open(11,status='SCRATCH')
write(*,*)'Open12'
open(12,status='SCRATCH')
do i=1,1000
write(11,*)'New'
enddo
do i=1,10000000
write(10,*)'Test'
enddo
end
| コンパイラ | SCRATCHファイルの可視性 | SIGINT時の動作 |
| g95 0.91 20080220 | 不可視 | N/A |
| g77 3.4.6 | 可視 | すべてのファイルが消える |
| gfortran 4.2.4 20080305(prerelease) | 不可視 | N/A |
| gfortran 4.3.1 20080306(prerelease) | 不可視 | N/A |
| Intel Fortran 7.1 | 可視 | すべてのファイルが残る |
| Intel Fortran 8.1 | 可視 | SIGINT時書き込み中のファイルが残る |
調査の範囲では、dup2(2)で上書きするための Logical Unit Numberを 確保するのにSCRATCHファイルをOPENするという戦略では、 プロセス中断時に一時ファイルが残留する可能性がある。
つまり、一時ファイルがファイルシステムに残留する可能性や 多重OPEN禁止の実装まで考慮すると... OPEN文にmkstemp(3)とunlink(2)を組み合わせて 自前で実装するしか一般解が無いと言うことに...
どうやら、gfortranに関しては/dev/null(正確にはisatty(3)が真となるもの
stat(2)の結果、!S_ISREG()が真となるもの[訂正2008/03/18])
に対しては、unbufferedspecial_file[訂正2008/03/18]な
取扱いになり、regular fileと異なる振る舞いをする。
従って、dup2(2)で上書きするための Logic Unit Numberを 確保するのに/dev/nullを OPENする代わりに regular fileを OPENすると挙動が違うことに...
このために、mkstemp(3)とunlink(2)を組み合わせたitopenbuf_の 再実装はうまく動きませんでした。
パス名を新たに生成可能かつ、
isatty(3)が真になる!S_ISREG()が真になる[訂正2008/03/18]というと
使えそうなのは名前付きパイプかな？
とすると、mkdtemp(3) + mkfifo(2) + unlink(2) + rmdir(2)か...
これまでの分析に基づいて、多重OPENの禁止処理にかからずに dup2(2)での上書き用の Logical Unit Numberを確保するコードを 実際に実装してみる。
有効にするには、sad.confへ以下を追加すること
USE_NEW_FORTRAN_OPEN_SIM=YES
動作は、/tmpに openbuf.で始まる 0700な一時 directoryを作って(mkdtemp(2))、 その中に名前付きパイプfifoを作成し(mkfifo(2))、 OPEN文で開いた後、 unlink(2)と rmdir(2)で後始末する。 一時ファイルの race conditionに対する安全性は、 mkdtemp(2)が予測不能な名前で ownerしかアクセスできない directoryを作ることに依存しています。
itfopenread_G77.fで実装されているOPEN文での DISP修飾のエミュレーションも unlink(2)で再実装する。 system経由の実装だと、/bin/shと/bin/rmを実行するために fork(2)とexecve(2)が2回づつ呼び出されるという パフォーマンス面での不利もあるが、 /bin/shを通過するためにシェルが解釈するメタ文字を含む パス名を正しく扱えない問題がありました。 (好き好んで、そんな変態的なパス名を一時ファイルに 使う上位層はいないはずですが...)
2023/04/12にRuby2.7系がEoLするので、移行先を考えないといけない
依存しているは、Web Serviceとして運用しているCGI環境tDaiary-4.1と Hiki-1.0で、両者とも色々ローカルパッチを当てている
現行のWiki運用上、重要な拡張機能
Wiki移行先の候補
とりあえず、始めるべき作業
手持ちのMeteor Lake-P (vendor=0x8086 device=0x7d55 subvendor=0x10f7 subdevice=0x8338 on Let'snote FV5)での動作状況まとめ
テスト環境は、stable/14に pull requestに上がっていた linuxkpiパッチを個別に取り込んだ環境
今のところ、Ver 6.8に drm/i915: Disable DSB usage specifically for LUTs当てて、xdmで使う(VT consoleを使わない)が実用上の落としどころか？
カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記