Orz日記 by Akio Morita

_ [雑記]寒いと思ったら

雪が降り出しました。また積もるのかな...

_ [SAD]未使用シンボルのみから構成されるファイルの削除

要するに誰も使用しない関数のみで構成されるファイルの一斉処分

一応、処分前に保守状況を調査(このまえ作った 調査用 Subversionレポジトリが活躍してくれました)

1995/09/13の CVS repositoryへのインポート以後に保守されていないもの

保守が必要でないであろう行列操作の基本関数等を除いて、 ある程度以上の複雑さを備えたコードが一度も保守されていないということは 1995年当時から実質死んでいたと思われる

• src/MADD2.f
• src/append.f
• src/data2.f
• src/matadd.f
• src/matclr.f
• src/matcpy.f
• src/matmax.f
• src/matmin.f
• src/matrst.f
• src/matsqu.f
• src/matsub.f
• src/matswp.f
• src/msort2.f
• src/naiseki.f
• src/p0bym.f
• src/pclrp.f
• src/petdif.f
• src/petdifa.f
• src/petmcut.f
• src/petsub.f
• src/pettime.f
• src/plssvd.f
• src/pltrng.f
• src/pmov.f
• src/poplst.f
• src/psvbk.f
• src/psvd.f
• src/qbthin.f
• src/spldrw.f
• src/tdnrm.f
• src/tprofo.f
• src/tpwght.f
• src/wexp.f
• src/wsolvi.f
• src/wsolvs.f

1996/07/26 longer ( 32bytes length ) symbol support

1回コミットされているコード。 修正内容は、implicit文や変数の型宣言の機械的な修正のように見える 前後数ヶ月のコミットログから察するに HP-UXへのポーティング作業に 付随する修正と思われる。(コンパイルエラー等の解消目的だとすると コードが実際には利用されていなかった可能性がある)

• src/drwln.f
• src/drwxbx.f
• src/iscan.f
• src/matmul.f

その他のコード

• src/ltype.f
  • 2008/02/16に V1.0.10.2.3bの名目でコミット(修正内容は、初期値の宣言をdata文に分離する修正。おそらく、時期的に考えてg95対応作業の一環で、機械的にコンパイルエラーを修正したものと思われる。)

• src/monact.f
  • 2000/07/04に V1.0.8.5.4aの名目でコミット(codcorコモンブロックの内部のアライメント修正)

• src/packpim.f
  • 2000/07/04に V1.0.8.5.4aの名目でコミット(codcorコモンブロックの内部のアライメント修正)

• src/pltelm.f
  • 1999/09/29に V1.0.8.1.6a3の名目でコミット(fstrlenをlenwへ置換)
  • 2008/02/16に V1.0.10.2.3bの名目でコミット(修正内容は、初期値の宣言をdata文に分離する修正。おそらく、時期的に考えてg95対応作業の一環で、機械的にコンパイルエラーを修正したものと思われる。)

• src/psolvg.f
  • 2007/11/04に、私が 使用されていないsrc/pgauss.fを廃止したさいにコメントアウトされた pgauss()の呼び出しを削除した。

• src/putstr.f
  • 1999/09/29に V1.0.8.1.6a3の名目でコミット(fstrlenをlenwへ置換)

• src/qquads.f
  • 2006/09/12に MAIN trunkへ amorita branchを合流させた際にコミット(RCS Idタグの更新のみ)
  • 2006/08/14に V1.0.8.23bの名目でコミット(beamの配列長変更)
  • 2000/08/19に V1.0.8.6aの名目でコミット(implicit文と変数宣言の保守)
  • 1996/09/30に qbendsサブルーチンが追加
  • 1996/02/21に qquadsサブルーチンから、call tsetirad(6)と cod(5)=0.d0が削除
  • 1996/02/10に qquadsサブルーチンから、call tclr(trans1(1,7),36)と call tclr(beam,21)がコメントアウト

CVS repositoryが導入された 1995〜96年代にかけて実際に TWISSの計算に 使われていたいたが、途中から使用されなくなったものと思われる。 また、2000/08/19の段階で、呼び出し元は存在していない。

• src/radlos.f
  • 2006/09/12に MAIN trunkへ amorita branchを合流させた際にコミット(gfortran対応のためのfunction定義時の型宣言の修正)

• src/savcod.f
  • 2006/09/12に MAIN trunkへ amorita branchを合流させた際にコミット(.or.式の評価順序に依存して発生する segmentation faultを解消するための、if文の分割)

• src/tdout.f
  • 2008/03/08に V1.0.10.2.4bの名目でコミット(format文の修正)

_ [雑記]昨日の余震は久々に大きかった

原発関連施設で、電源系統の遮断等のトラブルが起きたらしいが、 深刻な事態になってなければよいのですが...

_ [Admin]Video Server更新

Windows VISTA + AthlonIIx4 605e + ASUS M4A785-M な環境から Windows 7 + Core i5 4670S + Gigabyte H97M-D3H へ更新実施

流石に半導体の世代差が大きく、アイドル時の消費電力は 55~65Wから 25Wへとほぼ半減した。多分、フルロード時の消費電力も下がってUPSへの負荷が軽減出来たはず。

一方、表示系のDVI-D接続は AMD 785Gの2560x1440からCore i5 4670Sの1980x1080へと退化してしまった。

予約録画待機中のスタンバイ状態で、電源ランプが点滅しなくなったので、状態把握的にはマイナスか？ (OSの標準動作の差異か？)

追記(2017.04.11)

旧Video Server購入時の伝票が発掘された！

ケース含めた部材一式が2009.11.28購入なので、運用投入は 2010年1月新番組からだから、7年3ヶ月の長期運用でした。

途中、HDDの予防交換を1回のみで、大きな問題なく運用をまっとうした模様

_ [SAD]乱雑な数値リストの構成速度

乱数列からなるリストをToStringで文字列化したものと、Sharedによるシリアル化したものから再構成する時間を測ってみた

Stringのパースはシリアル化された符号列からの再構成に対して、400倍遅いことが判明

したがって、KEKBLogからの大規模読み出し時の処理のかなりの部分が、パースに費やされていることになるので、高速化にはバックトラック無しで読み出せる専用フォーマットと受け取りようの専用デコーダの実装が必要の模様

Sharedのシリアル化エンジンは、タグ等の符号化効率は目指していない＆整数型が未サポートなので、KEKBLogのデータを載せるならもう少し符号化効率を改善したデザインが必要

KEKBLogの格納データを前提とするなら、以下のデータの効率的な符号化をサポートすべき

• 16bit int
• 32bit int
• float
• 32文字未満のString型
• timestampの効率的な符号化
  • timestampの基準定義・差分表現
• 将来の拡張に向けた 64bit intのサポート予約
• 8bit int (int型の縮約結果)

_ [FreeBSD]13.1 RELENG

順調にRC2まで来たぽぃ

ports側は、2022/04/02で 13.1-releaseタグが打たれてるので、emacs 28は入らないのかな？

_ [Emacs]Emacs 28

elispまわりの警告が色々でるのでメモ

(interactive-p)

(called-interactively-p 'interactive)

に書き換える

(string-as-unibyte foo)

fooのunibyte表現を返す

fooが文字列リテラルなら、

(encode-coding-string foo 'utf-8))

が同等ぽぃ(UTF-8 encodingでmultibyte文字をシリアライズした表現)

(delete-backward-char foo)

(delete-char -foo)

か？(負の引数で、backwardにdeleteする)