トップ «前の日(03-16) 最新 次の日(03-18)» 追記

Orz日記 by Akio Morita

ToDo:

  • 15 SAD Fit[]回りの障害事例の解析
  • 10 smart pointer版PEGクラスの再実装(Left Recursionまわり)
2006|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|06|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|07|08|09|10|11|12|
2013|01|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|06|07|08|10|12|
2016|01|02|03|05|06|08|10|11|
2017|01|02|03|04|05|06|07|09|10|11|12|
2018|01|02|03|04|06|07|08|09|10|11|12|
2019|01|03|04|05|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|

2006-03-16 tDiary本格運用に向けて予備作業をこそこそ

_ [Admin]Web contents管理用に Subversion repositoryを新設

まずは、CVSで関していた SADの Release Informationページを登録 FTP serverへの uploadをテストしたら、.svnまでうpされた orz

ftpのコマンドラインには rm -rが無かったので一個一個 directoryの中身を消してから rmdirするはめに x_x;

mdeleteが有るんだから、mrmdirが有っても良さそうなのに...

_ [tDiary]tDiaryを Subversion repositoryにインポート

vender dropにインポートした tDiaryでページを再構築し直す

これで、tDiaryがアップデートしたら vender dropへインポートして、差分をマージすることでアップデートできるはず

実際に、組み込みのプラグインをカスタムするのは先ですが(counter.rbはカウンタ置場がイケてないのでいじる予定)

_ [WWW]Webのトップページどうしよう?

昔のコンテンツは古いので捨て捨てで行くとして、コンテンツ管理を考え中.... Emacs html-mode + Subversionも悪くないけど、Wikiも面白いかな

tDiaryとの親和性を考えて RubyベースのWikiを探しているとVikiWikiが、見栄え的には結構よさげ

コンテンツの履歴管理まわりの相性はどうかな? CVS連動のWikiは合ったけど、Subversionと連動する奴はまだ見付けていない

_ [tDiary]昔書いてた、ハイパー日記

書きはじめたばかりなので、とにかくさびしい orz

昔書いてたハイパー日記を変換して載せておくか?


2008-03-16

_ [FreeBSD]openoffice.orgがコンパイルできない件

原因判明

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を一時的に名前を変えてごまかすことに

_ [Fortran]同一ファイルに対するOPEN文の挙動

同一の character device (/dev/null)を開くテスト

     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.1open(11,...)で失敗
Intel Fortran 8.1すべて成功

同一のregular file(/tmp/fortran.txt)を開くテスト

     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 20080220open(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.1open(11,...)で失敗N/A
Intel Fortran 8.1すべて成功独立

挙動のまとめ

  • gfortran 4.2/4.3と Interl Fortran 7.1は、同一ファイルの同時OPEN禁止
    • libgfortranを読む限り、既にOPEN済みのファイルとパス名とi-node番号が共に一致する場合は、OPENを拒否する
      • 同一パス名での i-node番号が異なる場合は問題ない(古いファイルが一度 unlinkされている場合など)
      • hard linkか VFS経由で同じファイルへ異なるパスでアクセスする場合も検査をすり抜ける
  • g77と Intel Fortran 8.1は、OPEN時に検査を行っていないと思われる
  • g95は、同一ファイルの同時OPENは原則禁止、device specialに関しては規則を緩めている
    • g95の libf95(io/unit.c, unix/unix_io.c)によれば、terminal device(character device)に対しての多重OPENを認めている

調査の範囲では、dup2(2)で上書きするための Logical Unit Numberを 確保するのに/dev/nullを多重OPENするという戦略は移植性が無い。

Intel Fortran 7.1から 8.1への挙動の変化が謎ではあるものの、 g77とことなり Fortran95規格ベースで実装されている gfortran/g95の挙動を 見る限り「同一ファイルへの多重OPENは禁止」は Fortran仕様的に何らかの根拠があると思われる。

_ [Fortran]SCRATCHなOPEN文の挙動

テストコード

     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時書き込み中のファイルが残る

挙動のまとめ

  • 一部の実装は、open(2)後にSCRATCHファイルをunlink(2)しない
  • SIGINT等で実行中断時に、SCRATCHファイルが残留する実装が存在する
    • シグナルハンドラが上書きされてる場合の動作が、不定(signal ->execve(2)な場合とか...)

調査の範囲では、dup2(2)で上書きするための Logical Unit Numberを 確保するのにSCRATCHファイルをOPENするという戦略では、 プロセス中断時に一時ファイルが残留する可能性がある。

つまり、一時ファイルがファイルシステムに残留する可能性や 多重OPEN禁止の実装まで考慮すると... OPEN文にmkstemp(3)とunlink(2)を組み合わせて 自前で実装するしか一般解が無いと言うことに...

_ [Fortran]OPEN文での/dev/nullの扱い

どうやら、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/nullOPENする代わりに regular fileOPENすると挙動が違うことに...

このために、mkstemp(3)とunlink(2)を組み合わせたitopenbuf_の 再実装はうまく動きませんでした。

パス名を新たに生成可能かつ、 isatty(3)が真になる!S_ISREG()が真になる[訂正2008/03/18]というと 使えそうなのは名前付きパイプかな?

とすると、mkdtemp(3) + mkfifo(2) + unlink(2) + rmdir(2)か...

_ [SAD][Fortran]itopenbuf_, itfopen*_の新実装

これまでの分析に基づいて、多重OPENの禁止処理にかからずに dup2(2)での上書き用の Logical Unit Numberを確保するコードを 実際に実装してみる。

有効にするには、sad.confへ以下を追加すること

USE_NEW_FORTRAN_OPEN_SIM=YES

動作は、/tmpopenbuf.で始まる 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を通過するためにシェルが解釈するメタ文字を含む パス名を正しく扱えない問題がありました。 (好き好んで、そんな変態的なパス名を一時ファイルに 使う上位層はいないはずですが...)

_ [LHC]β解析ツールが動かないという話

で呼ばれて、その場で調査してみる...

なんか、Union[]がエラー吐いてる...というか、その前の時点で データが入っていないのはおかしい....

あれ、なんかコードが違うような...って、これ古いコードじゃん Orz

まあ、エラーチャックに若干抜けがあったのも事実なのだが、 古いコードで新機能を呼び出せば動かないのは当たり前


2009-03-16

_ [SAD]FPE on OpenSolaris

コンパイラオプションで、デフォルトのFPE trapを無効化して対応。 一応、script/bench2.sadがそのまま動くようになった...

もっとも、途中でFPEが発生した際に Timing[]関数の戻り値が おかしくなること自体が問題な気もする。

_ [SAD]getfd(3f) on SunStudio

FortranのLogical Unit Numberからunix file descriptorを 取り出す関数が、SunStudioに有ったので有効化する(Rev.2838)

これで、Pipe[]とかが動くようになるはず


2023-03-16

_ [雑記]Ruby2.7 EoL

2023/04/12にRuby2.7系がEoLするので、移行先を考えないといけない

依存しているは、Web Serviceとして運用しているCGI環境tDaiary-4.1と Hiki-1.0で、両者とも色々ローカルパッチを当てている

  • tDiary v4.1
    • 数式環境 - MathJax pluginへ切り替え済み
    • contrib plugin image_ex.rbを組み込み
    • ローカルパッチ
      • misc/plugin/counter.rb - アクセスカウンターの置き場所のカスタマイズ (バックエンドデータの履歴管理用)
    • 移行をサボってきたが開発継続しているので、最新版に移行すれば良いはず
  • Hiki v1.0 (Ruby3.1で、そのまま動かないことは確認済み)
    • 数式環境 - X-Math plugin + MathWiki styleを使用中
    • ローカルパッチ
      • Ruby 2.x環境向けの細かな修正
      • configuration file名の変更 (管理都合)
      • Page Lock Stateの導入
        • 元来ある管理者以外改変禁止状態freezeより若干緩い匿名改変禁止状態lockedの導入
        • 匿名編集可な設定で運用している環境で、一部ページを保護したいが管理者のみにしたく無いために開発
          • spamerによる匿名編集からの保護的にも必要だった
        • 匿名編集を許可しない設定だとそもそも必要無い
      • directory revisionの不一致による svn commitの失敗からの回復処理 (svn working copyを他のものと共有するため)
      • svn commit/delete log形式を変更 (操作ユーザーの追加)
      • page revision処理にコード変換機能の追加 (repository上の古いページデータがUTF-8で無いケースのサポート)
      • @repos_rootでの URI表現のサポート(ReposSvnのinitialize)
      • 添付ファイルアップロードの拡張
        • ページ単位の添付ファイル管理
        • misc/plugin/edit_user.rbによる添付ファイル編集の認証
        • 正規表現による匿名upload可能なページの限定 (its plugin用途)
        • svn repositoryサポート
      • its pluginへのattach_form追加
      • its/comment pluginでのSPAM避け

現行のWiki運用上、重要な拡張機能

  • ユーザー認証
    • ページ編集権限 - adminのみ, 認証済みユーザーのみ(パッチで追加), 制限無し
  • 数式環境 (X-math plugin)
  • 添付ファイル (attach plugin)
    • Issueに関連したファイル類の収録、記事に関連したパッチ類の収録
    • page単位で管理出来る用に拡張している
  • Issue Tracker (ITS plugin)
    • Software関連の観的なバグ報告管理

Wiki移行先の候補

  • Hiki v2.0pre
    • 過去のデータがそのまま移行出来るはず
    • ローカルパッチは吟味の上、移植する必要あり
    • X-Math pluginは、MathJax pluginを作成すべき
    • 大規模改修が成されているので、動作に関しては要検証 (svn backendがきちんと動くかなど…)
  • Gollum
    • Markdownベース
    • バックエンドは、git repository
    • ports/www/rubygem-gollum に収録されている
    • 機能面
      • ユーザー認証 - 含まれていないが、追加は可能
        • 外部公開用のHTTP Proxyで認証する
          • 編集用・閲覧用のGollumを別々に動かして、公開URIで認証の有無を制御する事例有り (ユーザー一人であれば、こちらが簡潔か?)
        • config.rb経由で認証機構を組み込む (編集制御ではなくアクセス制御なので閲覧も制限される?)
          • BASIC認証を組み込む
          • OmniAuthを組み込む omnigollum
      • 数式環境 - --mathjaxでMathJaxがつかえる
      • ファイルアップロード - --allow-uploadsで使える。wiki_optionsのper_page_uploads属性でページ単位に紐付けた管理が出来る模様
      • Issue Tracker - 無いぽぃ (requestは挙がったことがある模様)
        • SAD wiki以外の文書管理には充分使える
  • GitLab
    • Markdownベース
    • Issue Trackerもついてくる
    • 運用環境規模がかなり大きくなる気が…

とりあえず、始めるべき作業

  • tDiaryの掃除
    • アクセスカウンターを外して、標準構成 + contrib pluginだけにする
  • Hiki-1.0の掃除
    • tDiaryのMathJax pluginを参考にプラグインを開発・X-Mathから置き換える
  • lang/ruby27の snapshotを保存する
  • lang/ruby27・ruby31の平行運用モードへ移行する
    • 本番環境の CGI scriptを/usr/local/bin/ruby27を参照する様に書き換える
    • 本番環境の rubyを dual ruby構成に変更する
    • 掃除済みの tDiaryを最新版に更新する

カテゴリー: Admin | Emacs | EPICS | Fortran | FreeBSD | GCC | hgsubversion | IPv6 | KEKB | LHC | Lisp | LLVM | MADX | Ryzen | SAD | samba | tDiary | unix | WWW | YaSAI | お仕事 | イベント | 出張 | 宴会 | 数学 | 艦これ | 買いもの | 追記 | 雑記