start

TOSHIBA MG03ACA300購入

どこかからの放出品なのか、東芝のエンプラ向けHDD MG030ACA300が安かったので買ってみた。例によってCDMの結果を貼り付け。これまた例によってUSB 3.0変換での結果なので参考程度にオナシャス。

5860533167セクタを6時間42分でゼロクリアできたので、平均書き込み速度は118.6MiB/sという結果に。

mg03aca300_cdi.pngmg03aca300_cdi_temperature.png

速度は至って普通だが、ゼロクリア中の最高温度が60℃（室温26.5℃）と最近のHDDにしてはかなり熱め。アイドル状態で1時間放置しても53℃で、使ったケースがスライディング裸族で放熱性が悪いことを差し引いても熱い気がするなぁ。似たような条件でここまで高温になったHDD見たことないし。実運用では放熱をしっかり考慮する必要がありそう。実家の屋根裏サーバに使うつもりだけど、果たして大丈夫か！？

permalink · 2017-02-13 19:31 · Decomo · 0 Comments · Tags:

再配達で他の郵便局窓口での受取指定にした荷物は「送付→保管中」になる

郵便の再配達で「他の郵便局の窓口でお受け取り」を選択した場合、配送履歴は「最寄局・最寄店送付」を経て「保管中」となる。

受け取る事ができるのは保管中になってからである。「送付」は受取指定したところまで配送中という意味なのでお間違えの無きよう…。なお、2017年2月7日現在の情報なので、遠い未来でこのページを見てる人は要注意。

国際書留には追跡番号がついてるのに、再配達は「お知らせ番号」で管理されてるのは何でなんだろう？二重管理で面倒なだけな気がしてならない…。

permalink · 2017-02-07 19:52 · Decomo · 0 Comments · Tags:

portmasterでPHP 5.5をモジュール含め一括でPHP 7.1に更新する

家鯖のPHPを5.5から7.1に更新した。

バージョン毎にportsが分かれているソフトを更新するときは、portmasterの-oオプションを使ってportmaster -o 置き換えるports(新バージョン) 置き換えられるports(旧バージョン)とする。そうしないと「php55-5.5.38 conflits with php71-7.1.1 (installs files into same place)」という具合に怒られる。 

# sudo portmaster -o lang/php71 php56

PHPの場合、付随するモジュールも更新する必要があり、基本的には同じ方法で行う。しかし、1つずつportmaster -oしなきゃならなくて地味に面倒なんすよね(´・ω・｀)。いい方法がないものかとネットを彷徨っていたら（この時間で手作業で更新できた説）、Stack Overflowに素敵な回答を発見。元のスクリプトだとdistfile削除プロンプトの入力待ちが正しく処理できなかったため、ちょっと改造させて貰った。 

$ awk -vPATTERN="55" -vREPLACEMENT="71" \
'BEGIN { while (("pkg query -x %o \"/(mod_)?php" PATTERN "(-|$)\"" \
| getline name) > 0) { oldname = name; sub(PATTERN, REPLACEMENT, name); print "ALWAYS_SCRUB_DISTFILES=dopt portmaster --no-confirm -o " name " " oldname } }' \
| sudo sh

統廃合などで必ずしもモジュールが1対1で対応しなかったり、php-extensionパッケージは上手く扱えなかったりで、エラーなしで一発更新という訳にはいかないのが玉に瑕。でもこのスクリプトで更新作業はかなり楽になるハズ。PATTERNとREPLACEMENTはお使いの環境に応じて書き換えてね(ゝω・)v

参考サイト

permalink · 2017-02-06 13:51 · Decomo · 0 Comments · Tags:

portsnapにautoなるコマンドが実装されてた

portsnapのmanを見ていたら、autoなる見知らぬサブコマンドが目に止まった。普段からportsnapとお戯れになっている人ならコマンド名から挙動の予想がつくと思われるが、portsツリーの状況に応じてサブコマンドをイイ感じに発行してくれるモードのようだ。FreeBSD 11から実装されている模様。

今までは

  • 初回はfetchしてextract
  • 2回目以降はfetchしてupdate
  • cronモードのときはupdateのみ

といった具合に人間様がコマンドを使い分ける必要があったが、これからはとりあえずportsnap autoしておけば良さそう。便利便利。

permalink · 2017-02-02 11:48 · Decomo · 0 Comments · Tags:

FName::GetPlainANSIString()で正しい文字列が取れない事がある

お急ぎのあなたのために、まずは結論。FNameが保持する文字列が必要な時はToString()で生成したFStringを使うべし。GetPlainANSIString()とGetPlainWIDEString()を使うとハマるから止めといた方がいい。

Unreal Engine 4の軽量文字列クラスFName（公式リファレンス）のGetPlainANSIString関数/GetPlainWIDEString関数で取得できる文字列ポインタには、そのFNameインスタンスが本来持っている文字列の一部しか入っていない事がある。恐らく仕様。以下が実証コード。 

TArray<FName> Names;
Names.Add(FName(TEXT("Hoge_")));
Names.Add(FName(TEXT("Hoge_0000")));
Names.Add(FName(TEXT("Hoge_0001")));
Names.Add(FName(TEXT("Hoge_10")));
Names.Add(FName(TEXT("Hoge_1200")));
Names.Add(FName(TEXT("Hoge_1300")));
Names.Add(FName(TEXT("Hoge_9999")));
Names.Add(FName(TEXT("Hoge9999")));
 
for (const auto& Name : Names)
{
	UE_LOG(LogWindows, Log, TEXT("◆%s"), *Name.ToString());
	UE_LOG(LogWindows, Log, TEXT("  PlainAnsiString=%s (%p)"), *FString(Name.GetPlainANSIString()), Name.GetPlainANSIString());
	UE_LOG(LogWindows, Log, TEXT("  [FNameEntry]"));
	UE_LOG(LogWindows, Log, TEXT("    ComparisonIndex=%d"), Name.GetComparisonIndex());
	UE_LOG(LogWindows, Log, TEXT("      [ComparisonEntry]"));
	UE_LOG(LogWindows, Log, TEXT("        Address=%p"), Name.GetComparisonNameEntry());
	UE_LOG(LogWindows, Log, TEXT("        isWide=%d"), Name.GetComparisonNameEntry()->IsWide());
	UE_LOG(LogWindows, Log, TEXT("    DisplayIndex=%d"), Name.GetDisplayIndex());
	UE_LOG(LogWindows, Log, TEXT("      [DisplayEntry]"));
	UE_LOG(LogWindows, Log, TEXT("        Address=%p"), Name.GetDisplayNameEntry());
	UE_LOG(LogWindows, Log, TEXT("        isWide=%d"), Name.GetDisplayNameEntry()->IsWide());
	UE_LOG(LogWindows, Log, TEXT("    Number=%d"), Name.GetNumber());
}

実行結果を見ると、Hoge_10, Hoge_1200, Hoge_1300, Hoge_999で見事に同一のPlainAnsiStringが返ってきているのが分かる（★の部分） 

LogWindows: ◆Hoge_
LogWindows:   PlainAnsiString=Hoge_ (000000021299B988)
LogWindows:   [FNameEntry]
LogWindows:     ComparisonIndex=1029720
LogWindows:       [ComparisonEntry]
LogWindows:         Address=000000021299B978
LogWindows:         isWide=0
LogWindows:     DisplayIndex=1029720
LogWindows:       [DisplayEntry]
LogWindows:         Address=000000021299B978
LogWindows:         isWide=0
LogWindows:     Number=0
LogWindows: ◆Hoge_0000
LogWindows:   PlainAnsiString=Hoge_0000 (000000021299B9A0)
LogWindows:   [FNameEntry]
LogWindows:     ComparisonIndex=1029721
LogWindows:       [ComparisonEntry]
LogWindows:         Address=000000021299B990
LogWindows:         isWide=0
LogWindows:     DisplayIndex=1029721
LogWindows:       [DisplayEntry]
LogWindows:         Address=000000021299B990
LogWindows:         isWide=0
LogWindows:     Number=0
LogWindows: ◆Hoge_0001
LogWindows:   PlainAnsiString=Hoge_0001 (000000021299B9C0)
LogWindows:   [FNameEntry]
LogWindows:     ComparisonIndex=1029722
LogWindows:       [ComparisonEntry]
LogWindows:         Address=000000021299B9B0
LogWindows:         isWide=0
LogWindows:     DisplayIndex=1029722
LogWindows:       [DisplayEntry]
LogWindows:         Address=000000021299B9B0
LogWindows:         isWide=0
LogWindows:     Number=0
LogWindows: ◆Hoge_10
LogWindows:   PlainAnsiString=Hoge (000000021299B9E0)…★
LogWindows:   [FNameEntry]
LogWindows:     ComparisonIndex=1029723
LogWindows:       [ComparisonEntry]
LogWindows:         Address=000000021299B9D0
LogWindows:         isWide=0
LogWindows:     DisplayIndex=1029723
LogWindows:       [DisplayEntry]
LogWindows:         Address=000000021299B9D0
LogWindows:         isWide=0
LogWindows:     Number=11
LogWindows: ◆Hoge_1200
LogWindows:   PlainAnsiString=Hoge (000000021299B9E0)…★
LogWindows:   [FNameEntry]
LogWindows:     ComparisonIndex=1029723
LogWindows:       [ComparisonEntry]
LogWindows:         Address=000000021299B9D0
LogWindows:         isWide=0
LogWindows:     DisplayIndex=1029723
LogWindows:       [DisplayEntry]
LogWindows:         Address=000000021299B9D0
LogWindows:         isWide=0
LogWindows:     Number=1201
LogWindows: ◆Hoge_1300
LogWindows:   PlainAnsiString=Hoge (000000021299B9E0)…★
LogWindows:   [FNameEntry]
LogWindows:     ComparisonIndex=1029723
LogWindows:       [ComparisonEntry]
LogWindows:         Address=000000021299B9D0
LogWindows:         isWide=0
LogWindows:     DisplayIndex=1029723
LogWindows:       [DisplayEntry]
LogWindows:         Address=000000021299B9D0
LogWindows:         isWide=0
LogWindows:     Number=1301
LogWindows: ◆Hoge_9999
LogWindows:   PlainAnsiString=Hoge (000000021299B9E0)…★
LogWindows:   [FNameEntry]
LogWindows:     ComparisonIndex=1029723
LogWindows:       [ComparisonEntry]
LogWindows:         Address=000000021299B9D0
LogWindows:         isWide=0
LogWindows:     DisplayIndex=1029723
LogWindows:       [DisplayEntry]
LogWindows:         Address=000000021299B9D0
LogWindows:         isWide=0
LogWindows:     Number=10000
LogWindows: ◆Hoge9999
LogWindows:   PlainAnsiString=Hoge9999 (000000021299B9F8)
LogWindows:   [FNameEntry]
LogWindows:     ComparisonIndex=1029724
LogWindows:       [ComparisonEntry]
LogWindows:         Address=000000021299B9E8
LogWindows:         isWide=0
LogWindows:     DisplayIndex=1029724
LogWindows:       [DisplayEntry]
LogWindows:         Address=000000021299B9E8
LogWindows:         isWide=0
LogWindows:     Number=0

FNameはハッシュ付き文字列として実装されている。文字列はFNameの共用領域に格納され、各FNameインスタンスはその文字列格納領域へのインデックス＝ハッシュを保持してる。FNameの同士の比較は互いのハッシュの比較、つまり整数の比較に還元されるため、通常の文字列比較より速いって仕掛けなんですな。

ただ、このハッシュ生成方法がちょっと曲者で、文字列がアンダースコア＋ゼロ詰めされていない数値で終わっていたら、その部分を除いた文字列を共用領域に格納し、数値は各FNameインスタンスで保持するという方法なのだ。割と最近のバージョンアンプで変わったらしい（知人曰く4.12あたりで変わった気がすると）。なかなか破壊的な変更をしてくださりやがるな！言葉だと分かりにくいので図を作ってみた。

図を踏まえつつ改めて実行結果を見てみると、条件に合致するHoge_10, Hoge_1200, Hoge_1300, Hoge_999の中身が、その通りになっている事がお分かりいただけよう。Numberが実際の数値+1されているのは、これまた仕様で、数値分割条件を満たさないFNameインスタンス（Number == 0）との区別の為っぽい。

UE4では生成されたオブジェクトのインスタンスに対し、オブジェクト名＋連番の名前を自動付与するため、大規模な開発になるとFName文字列ストアの肥大化が無視できなくなり、保持方法を変更したのだと思われる。

こんな格納の仕方で大丈夫なの！？と思うが、ふつーにFNameを使う分には何の問題もない。や、正確には大丈夫じゃなかったからこの記事書いてる訳だけど、文字列の生ポインタ取ってこねくり回すような事をしなければ大丈夫。FName文字列に対して低レベルな操作を行いたい時は、ToString()関数で生成したFStringに対して行う事をオススメする。エンジンのコードを見てもらうと分かるが、ComparisonIndexの文字列にアンダースコアと数値をくっつけて元の文字列を復元してやがるので（笑）

ちなみに、実行結果内のDisplayIndexというのは、名前の通り表示用の文字列へのインデックス。簡単に言えば、FName生成時に与えられた文字列のインデックスである。FNameは基本的にcase-preserving（内部的には大文字小文字を区別するが対外的には区別せずに扱う）なので、比較用と表示用で別々の文字列を持つ必要がある訳だ。知らずに使ってると、これも地味にハマりポイントかも。 

FName abc(TEXT("abc"));
FName ABC(TEXT("ABC"));
UE_LOG(LogWindows, Log, TEXT("%s %s %s"), *abc.ToString(), (abc == ABC ? TEXT("==") : TEXT("!=")), *ABC.ToString());

念のため上記コードで確認したら、LogWindows: abc == ABCとなった。

掘ってみるとFNameには結構罠があるので注意が必要だ。

permalink · 2017-01-20 20:52 · Decomo · 14 Comments · Tags:
1 2 ... 33 34 35 36 37 38 39 ... 83 84
  • start.txt
  • 最終更新: 2022-07-27 15:26
  • by Decomo