午前2時半起床，晴れ．朝食は残りもののうどん．「WordPressへの投稿で xmlrpc.php 403 forbidden エラーが起きる」という問題が起きていたが，解決した．ウェブサーバーの WAF(Web Application Firewall) が効いていたためだ．ロリポップのユーザ専用ページにログインしてセキュリティ→ WAF設定 → ログ参照からシグネーチャを取り出し，WordPressのダッシュボード→ SiteGurd→ WAFチューイングサポート でシグネーチャを設定することで動作するようになった．
一つ問題がある．Open Live Writer のフォルダで全文検索が効かない．ファイルのタイトルに含まれない文字列は検索できない．前にも同様の事象は起きたことがあったが，どう対処したのか？忘れてしまった．Windows Live Writer はインストールされているので，リストアップされたファイルを開くことはできる．⇒エクスプローラの検索→ 詳細オプション→ インデックスが生成されていない場所→ ファイルコンテンツをチェック．これで全文検索ができるようになった．
今度はVSでビルドエラーが出るようになってしまった．管理者権限で起動し直してリビルドしてみる．⇒今度はエラーなしで完了した．タスクマネージャでマカフィーのインスタンスが無数に走っている．リアルタイムスキャンがオンになっていた．止めてから再起動してみたが，変化なしだ．アンインストールした方がよいのではないか？⇒アンインストールした．契約は有効で最初にインストールしたときのメールアカウントで再インストールすることができる．
作業に入る前に始業時バックアップを取っておこう．ipch がまだコピーされている．⇒「つねにフォールバック位置を使用」オプションが落ちていた．リリース版を起こして障害サンプル集のオープンテストを開始した．どうも見たところ，かなり描画上の問題が発生しているように見える．余分な垂線があちこちに出ている．描画上のタイミングの問題ならよいのだが，もしそうでないとしたらどこかで相当デグレードしていることになる．⇒画面がフリーズしてしまった．どこかでハングしている模様だ．
応答なしになっているのは，C:\Users\babalabo\Desktop\障害サンプル集\FB4反例\FB4検定2017-08-10\修復サンプル\太郎君の直系血族図.NONだが，このファイルはアイコンのダブルクリックで問題なく開ける．表示されているのはカード数20点のファイルで基準ノードＡＡ，ズーム倍率100%にしては図面が大き過ぎる．
おかしい．VSが起動されなくなってしまった．管理者として起動でなければ開くことは可能だ．開発環境上でリリースモードでオープンテストを開始しただけで例外が発生している．デバッグモードでテストしてみよう．
▲障害サンプル集\FB2反例\FB2反例2018-10-07\BUG18-10-07 17-11.ZELを開いてTRIBEBOX::getPrimeNodeで(!oyalink && Ancestor != Primary)で停止した．障害が起きているのは[系列枠]: #2951 odr=0 先祖=#1882 初代蒲田 （名不詳）(0)[0] 優先=四女武部幸子．昨日導入したTRIBEBOX::GetAlternativePrimeNodeが実行されているので，昨日の修正に関係している可能性もある．
確かに「優先ノードの所属系列不一致」が起きているのは問題の系列だ．ということはGetAlternativePrimeNodeに不備があるという可能性が高い．つまり，11月8日頃の修正がまだ収束していないということだろう．まず，従来論理に戻してこの問題が解けていることを確認しておこう．⇒確かに問題なく描画できる．もう一度，なぜこの措置が必要になったのかを再確認しておこう．これはN一族家系図描画上の問題から来ている．
シンは配偶者を2人持ち，どちらにも子どもがあるが，最初の配偶者の子孫系が左配置されてしまうのを避けるというのがその理由だ．一般に結婚枠はゴールド婚の場合を除き配偶者の直下に配置するようになっているが，家内婚の場合には本人預かりとなり，本人直下に展開することになっている．家内婚の右手本人と左手本人は必ずしも隣接しているとは限らないため，先行ノードの位置で展開するのが流れとしては自然だ．
これを「名義的」には右手本人位置で展開し，「実質的」には左手本人位置に描画するということは可能だろうか？できないことはないようにも思われるが，かなりの修正が必要になってくるような気がする．このような図面ではできればユーザが任意選択できるようにするのがベストソリューションなのかもしれないが，それはまた明後日の話だ．
家内婚はいずれBTWとして処理されることになるのだから，その時点で決定してもよいのではないだろうか？BTW婚の場合には動的に結婚枠を系列を超えて移動するということをやっているはずだ．多分その方がよりスマートな解決になるのではないかという気がするがそれもまた後日ということにして，ここでは既定路線に従って「家内婚は左手本人の預かりとする」という方針で収束させることを考えてみよう．
またおかしくなってきた．WordPress で投稿エラーがぶり返し．その上Chromeの画面までおかしい．画像の右上をクリックすると「このアカウントを削除しますか」というメッセージが出る．
Chromeをアンインストールして再インストールで回復した．ただし，「データを保存してアンインストール」では状態が変わらなかったので，一旦「すべて削除」した．WordPressはもう一度シグネーチャを取り直して再設定で投稿できるようになった．
どうも「家内婚は左手本人の預かりとする」という仕様変更に対応するのはかなり難しそうだ．代替の優先ノードを見つければよいのだが条件が整わない．始系列は#2763 odr=0 先祖=#1198 大蔵名不詳(0)[0] 優先=大蔵名不詳．以下のような問題がある．
- TRIBELIST::MakeUpTreeで系列優先実ノード不在の非始系列が発生する
- TRIBEBOX::getPrimarynodeでは関数中で系列優先ノードが変化する場合があり，この関数を呼び出しているTRIBEBOX::GetRealnodeでフローの混乱が発生する
- TRIBEBOX::getPrimeNodeで(!oyalink && Ancestor != Primary)となる場合がある
- TRIBEBOX::GetAlternativePrimeNodeで主系列上に実ノードが存在しない場合がある
- TRIBEBOX::GetMajorTribeChainで主系列チェーンが途切れる場合があり，これを強制的に延長すると循環が発生する
このような事象を回避するためには主系列参照関係が確立している必要があるが，それを生成している時点では回避操作が成立しない．「家内婚は左手本人預かり」とする処理を組み込むと系列参照関係に影響が及び，それによって回復不能な参照関係の破綻が生じる．つまり，言い換えると系列参照関係木が構築できない状態になる