月: 2019年1月

午前0時起床，晴れ．朝食は薄切りトースト2枚，コロッケ小1個．現行のBTWの機構では解消できない「配偶者多重」を解決するために「三角BTW」という構成を導入する．これは現行の「対BTW」の左手本人となる資格を「左手枠配偶者」まで拡張するというものと言ってよい．BTWという仕組みは「同世代の結婚当事者は必ず接合できる」という原則を実現するための基礎であり，ゼルコバの木系図エンジンのもっとも主要なコンポーネントをなすものであるから，修正もかなり広範囲に及ぶことが予想される．

この修正は「左手枠配偶者を左手本人とするBTW拡張＠20190130」というコンパイルオプションで実施することにする．NAMEBOX::DoublyBlessedOneは以下から呼び出されている．

1. TRIBEBOX::BetweenTwoWomen　TribeRelocaitonのステージ【５.２】重婚同類グラフ検定の事後処理を行なうで実行
2. NAMEBOX::FindDoublyBlessedOne　TOPOLOGY::ReduceMultiCard
3. NAMEBOX::ConvertGhost2BTW　GENEBOX::CheckInverseCycle
4. PAIRLIST::VerifyPairBox　GENELIST::CheckPairBoxCollision，
5. TOPOLOGY::ReduceMultiCard　TribeRelocationのステージ【７.９】仮ノード消去と両手に花を適用して多重カードを削減で実行

三角BTWは必ずしもこれらのすべてをカバーする必要はないと思われるので，ReduceMultiCard→FindDoublyBlessedOneでのみ対応することにしてみよう．YKはReduceMultiCardの中でIsVisibleCardでないという理由で弾かれている．IsVisibleCardは配偶者ノードを除外している．この関数はここでしか使われていない．このブロックではFindDoublyBlessedOneとEraseGhostNameを実行している．後者は本人ノードだけが対象だ．IsVisibleCardの代わりにIsValidNameBoxを使うようにした．この修正だけであとはまったく何も変更せずにBTWが成立した．

！実にすばらしい！多重は完全に解消した．

ただし，基準ノードの脇にはYKしか残っていない．基準ノードの3人の配偶者のうち，UYが外部に出てしまうのはある程度やむを得ないように思われる．というのはこのノードの外部婚は単親婚なのでこのノード以外には子ども枠を保持するノードがいないためだ．この点，YSは外部配偶者を持っているのだから，消去できてもよいはずなのだが親の存在が枷になっているようにも思われる．この図面は「合法的」であると考えられるので「基準ノードの子ども枠はBTW不可とする＠20190129」を復活させてみよう．

これで基準ノードの配偶者はすべて近接位置に戻ってきたが，多重が2件発生した状態になっている．YKは多重にはなっていないが，BTW連結線が欠けている．この描線は未対応なのであとから見ることにしよう．多重カード2件のうち，有夫のYSのケースを追いかけてみる．要点を挙げてみよう．

1. 基準ノードの配偶者の結婚は配偶者の配偶者の預かりとなっている
2. 基準ノードの配偶者は親を持ち，そのポジションで配偶者の配偶者とBTW接合している　このBTWは不可としなくてはならない
3. 多重カードとは本人ポジションにあるカード数に他ならないから，配偶者の親の家にいる配偶者本人を消去しなくてはならない．
4. 配偶者本人を消去できれば配偶者の配偶者ポジションカードの結婚は基準ノードの配偶者を左手本人とするBTWによって消去できる

項目2の禁止事項を実装してみよう．この項目は「基準ノードの配偶者は基準ノードの配偶者ポジションで左手本人となる場合を除き，BTWを組むことはできない」と翻訳される．⇒うまくいったようだ．

多重が1件残っているが，止むを得ないだろう．この配偶者は実家で単親婚を持っている．この子ども枠を保持するためには，このノードは実家に残るしかない．これを避けるためには単親婚を有夫婚に変えればよいというだけだから，回避策は存在する．多重を避けることを優先するか？ないし，明示的に外部婚配偶者氏名を記入することでそれを回避するかは，「当事者の自由」だ．多重の回避措置を取らない場合には最後の手段としてBTWを許可するということも考えられる．

この場合には結婚相手は遠いところに行ってしまうのだが，多重が発現するよりはマシかもしれない．例えば，渋沢栄一の場合で言うと，大内くにの場合がそうだ．くには2度結婚しているが相手の氏名が判明しているから，多分栄一から遠くないところに配置できると思う．従って，規則としては「もし，基準ノードの配偶者が外部に単親婚を持っている場合には左手本人となることを許す」とすべきだろう．⇒！できた！完装した！

これで「妻を寝取られた男の残念な家系図」問題は恒久的に解決したのではないかと思う．下図には多重は残っていない．N氏の三人の配偶者のうちの二人はボックス内に残り，もう一人は単親婚の子どもたちのために実家配置になっている．これでよいと思う．

試みにこの配偶者の単親婚に明示的な夫を与えてみよう．この母親には父親の異なる子どもが2人いる．そのうちの一人に父親を与えたところ，GetAlternativePrimeNodeで例外が発生した．→対処した．

どうもまだ，完全解には至っていないようだ．また，多重が発生してしまった．二人の子どもの父親が同じとすれば多重ゼロで解決する．母親が3つ結婚を持つ場合（うち一つは単親婚）に起きている多重が避けられないものであるのかどうか見ることにしよう．この多重は外部系列で起きている．

午前0時半起床，晴れ．朝食は薄切りチーズトースト2枚，コロッケ小1個．「妻を寝取られた男の残念な家系図」をなんとかしなくてはならない．それが目下喫緊の課題だ．かなり難しい問題だがやるしかない．その前に一つ片付けておかなくてはならないことがある．例のSTOP文だ．STOP文は以下のようなマクロとして定義されている．

#define STOP { __asm int 3 }

これまではプログラム中の任意の箇所にこの「STOP」を挿入するだけで簡単にブレークできていたが，Visual Studio 2017 に移行してからはSTOPで止まることができなくなってしまった．いや，一回だけは停止するのだがそのタイミングでコードが書き換えられ，それ以降は止まらなくなる．仕方ないので「初回停止したときに手操作でブレークポイントを設定する」ということにしたが，これではやはり用に足りない．たとえば，

if (some condition) STOP;

という文があったとすると，この文全体にブレークポイントが掛かってしまうためブレーク文の意味がなくなってしまう．

if (some condition) {
  STOP;
}

とすれば条件が成立したときだけ止めるようにすることはできるだが，簡潔さに欠ける．マクロの中でSTOPマクロを使っているような場合などにはお手上げだ．このような状況で，一度は Visual Studio 2005 まで戻ってしまおうか？とさえ考えたのだが，それもあまりに退行的と思われたのでいろいろ試みた末，下記のような代替構文を考案した．

#define STOP { try { __asm { int 0} } catch (…) {} }

__asm int 0 というのはあきらかにイレギュラーなステートメントだが，余分なメッセージを出さずにブレークできるので __asm int 3 とほぼ等価な動作になる．ただし，これは「割り込み」ではなく「例外」なので例外ハンドラーでキャッチする．少なくとも外観的にはこれで完全に int 3を代替することができる．いや，完全に同じではない．STOPでブレークするときには下記のようなパネルすら表示されなかった．まぁ，この程度のことは仕方ない．中断/継続ボタンで動作を選択することができる．

「中断」すれば，ブレークした正確なソースコードの行番号が分かる．変数などを調べてからまた「続行」することができるし，「継続」でただちに続行することもできる．これでようやく Visual Studio 2005 で慣れ親しんだ開発環境に戻ることができた．この「STOP文」は馬場研究所の「三種の（プログラム開発用）神器のうちの一つ」とも言うべき大事な「資産」であり，これがなくては手も足も出ない．今後はこれを「草薙のデバッグブレーク文」と呼ぶことにしよう．

ざっくり修正して多少動くようになった．３段階の措置が必要となっている．

1. MARGBOX::IsPrimeboxOrNotで「基準ノードの配偶者の配偶者で展開」に切り替える　基準ノードの配偶者の配偶者は「単身先祖配偶者」の立場から「本人ポジション」を得て外部系列先祖ノードとなる
2. DecidePrimaryNode で外部系列の優先ノードを先祖ノードからその配偶者に切り替える　decidePrimaryNode では優先ノードが決定できない場合にはTRIBEBOX::GetAlternativePrimeNode を呼び出して代替候補を探す
3. これにより外部系列に属する「基準ノードの配偶者」は「配偶者ポジション」に配置されるが，多重カード状態を解消するためにはこのあとでBTWを組まなくてはならない．

ステップ2まで消化した段階では多少のエラーを無視して下図が出力される．

基準ノードは配偶者を3持っているが，うち2つは外部系列内で配偶者ポジションに配置されている．ここで「基準ノードの子ども枠はBTW不可とする」という制限を外すと基準ノードの配偶者は一人を残して外に出てしまう．この動作はかなり奇妙だ．確かに「基準ノードの子ども枠はBTW不可とする」という規則は「基準ノードの子ども枠はBTWの右枠としない」ことを意味するから，少なくとも外に出てゆく動作はそれに適ったものと言えるが，なぜ一つだけ残るのかその理由が分からない．これは「別の問題」ではあるが，まずこちらから見ることにする．

｜｜

いや，少し考え違いしていたかもしれない．この図面では基準ノードN氏の配偶者であるYKの出現は2つあるが，どちらも配偶者だ．少なくとも現行ではこのような構図をBTWによって解決することはできない．なぜか？「そうなっていないから」と言えばそれまでだが，BTWが成立するためには少なくとも2人の本人当事者が必要だ．これをA，BとすればAはBと結婚していることが前提となる．このような条件の元で配偶者ポジションのBを消去して多重解消するというのがBTWの仕組みだ．今の場合はA，Bという本人の他にCという配偶者が存在し，AとC，BとCが婚姻しているという構図になっている．

このような状況に対処するためには，BTWの構成を大幅に拡張しなくてはならない．また，それが実現できないといま追求している「残念な家系図」を改善することもできないだろう．というのは，上記したような補正によって発生する図式は明らかにA，B，Cの3つ巴の関係式になるからだ．現行のBTWは Between Two Women と言いながら実際に扱っているのは「遠隔の対関係」であり，三角関係にはなっていない．Cが本人ポジションを持っていれば，2つのBTWを組み合わせることで「両手に花」状態を演出することが可能だが，Cの出現がすべて配偶者ポジションになっている場合には適用不可能だ．

これまでは「多重カードがすべて配偶者ポジションのカードのみの場合には『不可避の多重』として無視する」というルールになっていたが，上記の三角関係BTWが実装されれば，このような「配偶者多重」の問題を解消することが可能になる．これは画期的な進歩であり，もしこれが実現できれば「重婚同類グラフで循環がなければ多重カードは発生しない」という原則を「例外なし」に確立することができる．つまり，系図作図上の最大の課題である「多重カードの極小化」の完全解ないし最適解を得ることができる．

事例では「配偶者多重」が起きているのはほとんど女性の場合に限定されていたので，これを「あちこちに男のいる多情な女が多重になるのはどうしようもない」と解釈して（割り切って）いたが，この判断には「性差に関するある種の偏見」つまり，「男性優位の見方」が影響していたように思われる．「残念な家系図」がクローズアップされたことでようやくこれが「節操のない女の問題」ではなく，一般的な三角関係問題の一部であることが認識されたと言える．

現行のBTWをアレンジするだけでこのような場合に対処することは可能だろうか？現行方式ではBTWの要素は以下に限定される．

1. BTW左手本人
2. BTW右手本人
3. BTW右手枠

BTW左手本人とBTW右手本人はBTW連結線によって結合される．これをBTW対関係と呼ぶとすれば，BTW三角関係は以下の4要素からなると考えられる．

1. BTW左手本人
2. BTW右手本人
3. BTW左手枠　配偶者存続枠
4. BTW右手枠　配偶者抹消枠

BTW連結線はBTW右手本人とBTW左手枠配偶者を連結するものとなる．この操作によってはBTW左手枠はまったく改変を受けないと考えられるから，無視することができるとすれば，下記のようになる．

1. BTW左手本人＝BTW左手枠配偶者
2. BTW右手本人
3. BTW右手枠　配偶者抹消枠

これなら現行のBTW論理とほとんど相似形と言ってもよいトポロジーになりそうだ．BTWは通常BTW左手本人から発案されることになっているので，その資格を「BTW左手枠配偶者」まで拡張すれば何とかなりそうな感じだ．いずれにしてもかなり大掛かりな修正になることは間違いないので，まず，バックアップを取ってから始めるのが適当だ．

午前1時起床，晴れ．「家内婚は左手本人預かり」とは，MARGBOX::IsPrimeboxOrNotの動作の問題だ．この関数自体を廃止するという考え方もある．IsPrimeboxOrNotの主要論理はMARGBOX::IsPrimeboxの中で実施しているが，この関数は実際には「系列参照関係を変化させない」ように注意深くチューニングしてある．一方「家内婚は左手本人預かり」に関わる措置はIsPrimeboxに先行して実施されているため，系列参照関係を破壊するような動作になっている．

まず，これをIsPrimeboxの中に落とし込んでみよう．反例はN一族2.zelだ．このサンプルで家内婚の再配置ができなければ意味がない．⇒「家内婚は左手本人預かり」処理をIsPrimeboxに組み込み，さらに判定の優先順位を変更して「左手本人預かり」の動作になるようにしたが，再配置されていない．IsPrimeboxOrNotの冒頭でこの処理を実施するようにすれば予定したような動作になる．かなり奇妙だ．これはおそらく，IsPrimeboxの判定のあとで別途後処理をやっているためではないかと思われる．これはかなり問題の多い論理だ．IsPrimeboxの論理は最終的なものでなくてはならない．

この後処理は系列優先仮ノードに関わるものなので，IsPrimeboxの中で先行処理するようにした．これで一通り整理が付いたものと思われる．循環が発生するような反例で動作を確認してみよう．BUG19-01-21 08-52-58.ZELの場合は「左手本人預かり」で処理されたようだ．もう一つの反例を見てみよう．BUG18-10-07 17-11.ZELも解けた．このサンプルでは「左手本人預かり」は実施されていないはずだ．問題ないようだ．

これでこの件は一応一件落着としてよい．バックアップを取って仮修正を一掃しておこう．BUG19-01-21 08-52-58.ZELでは家内婚が検出され，系列優先ノードの付け替えが実施されている．これでよいのだろうか？このケースの場合 IsPrimeBoxではこの状況をかわすことができなかったと見られるが，たまたまうまく解決できたという見方もできる．このようなケースまで完全に排除する必要があるのか？さらなる研究課題として残る．

このサンプルではAFTERMARGSAMEGENEフェーズでも事後的に主系列が変化している．この付替えの理由は分からないが，家内婚の問題というより複数の親を持っていることに関わりがあるのではないかという気がする．家内婚の再配置を実施する前に系列優先ノードの付け替えが発生することを「事前予測」することは可能だろうか？かなり難しいように思われるが，そうした結果少なくとも循環が発生しないことを保証しなくてはならない．できるだろうか？これもまたかなり難易度の高い問題であるような気がする．

ともかく，一度リリース版を起こしてもう少し走らせてみることにしよう．⇒思った通りというか，またSUWが出た．まだこの論理は収束していないものと見られる．SUWを出したあと，ハングしている．⇒ダメだ！再現できない．反例サンプルは机上に生成されているが，開けてしまう．かなりまずい．15点サンプルで実質的にBUG19-01-21 08-52-58.ZELと同じではないかと思われる．⇒なぜだろう？BUG19-01-21 08-52-58.ZELが開けなくなっている．ただし，開発環境のデバッグモードでは問題なく開ける．

何かデバッグ用のコードによって障害を回避しているように思われる．どうもかなりまずい．開発環境ではリリースモードでも再現できない．リリース版を作り直してみた．またインストール前にアンインストールを実行した．もしかすると前回は管理者権限で起動していなかった可能性があるが，それが関係しているような気もする．今度は問題なく走っている．問題は解決している．

気になるのは頻繁に「垂線のゴミ」が散らばっていることだ．爪楊枝をばら撒いたような状況になっている．完了した．

どうも早いと思ったが，サンプルが2608本しか入っていない．どうしたのだろう？サイズは2.77GBあるが，確かに本数は2,675しかない．いや，FB1のオリジナルで見てもそんなものだ．記録で見ると2018-10-27で2,603本，所要時間54分12秒だ．ただし，2018-10-14には5,733本をテストしている．テストサンプルは4万7千本くらい，NONサンプルが1万4千本くらいあるが，障害サンプル集は5, 6千本というところだ．

障害サンプル集の所要時間は5時間以上掛かっていた時期もあるが，2018-10-14には5,733本のときでも2時間32分だ．今回は32分59秒なので倍速とまではいかないが，1.6倍速くらいにはなっている．これは主にCPUの能力差だろう．しかし，一番の問題は障害が457本も出ているという点だ．まず，これを見なくてはならない．どうもこれは「非連結」という問題であるように思われる．デバッグモードでは非連結で停止しないので，エラーの所在が分からないが，リリースモードではパネルが表示される．

▲検定2019-01-28\障害サンプル\BUG02-42 14-02-06.ZELを開いて，非連結系列が2件発生する．[系列枠]: #730 odr=8 HM=0 先祖=#518 常陸介(0)[8] 優先=#518 常陸介(0)→#955 常陸介(1) →主系列#702:右大臣（明石）と#738 odr=10 HM=0 先祖=#558 大臣（橋姫）(0)[10] 優先=#558 大臣（橋姫）(0)→#961 大臣（橋姫）(1) →主系列#702:右大臣（明石）だ．いずれも先祖ノードが多重カードになっている．これらは承香殿女御 （朱雀院の）と婚姻関係があるので，BTWで接続できるはずなのだが，成立していない．なぜだろう？

「基準ノードの子ども枠はBTW不可とする」というダンプが出ているので，これだろう．ここでBTWを組むと基準ノードの配偶者が外に出てしまうためだ．つまり，基準ノードの配偶者は必ず基準ノードの近辺に表示するという例外規則が効いているためだ．この現象はやはりN一族家系図の反省からもたらされたものだ．人の図面なら気にならないところが，自分の図面となるとそういう訳にはゆかなくなる．一般には「多重ゼロ・非連結系列ゼロ」という目標は至上命令だが，自分の系図となるとそれでは済まなくなる．

つまり，自分の配偶者が外に結婚を持っていてBTW接合によって自分とはわずか一本の連結線で接続するだけという状態を許容できない．これでは「妻を寝取られてしまった男の残念な家系図」をさらすことになってしまう！これはおそらくわたし個人の感情ではなく，普遍的に言えることではないかと考えられるので，Ｎ一族で出てきた「基準ノードの配偶者はBTW接合できない」という例外規則は確立されなくてはならないと考える．

ただし，このような場合であっても，配偶者の外部ポジションが配偶者である場合にはBTW接合によって基準ノードの近接距離に留まることは可能だから，そのような場合を除く必要がある．現在のサンプルはその事例にはならないが，多分N一族ではそのようなシチュエーションが起きていると考えられるので，チェックしてみよう．N氏の場合，配偶者を3人持っているが，そのいずれも外部に別の結婚を持っている．

これらの配偶者の外部婚は単身婚ではなく，有配偶者婚なので上記の条件を満たしている（正確にはうち一つは単身婚だが要すれば配偶者を追加できる）．ただし，実際にはこれらの配偶者は外部婚では本人ポジションにあるので，もし上記のような補正を行うとしたら，まずそれら外部婚のポジションを変えなくてはならない．かなり難しい話になってきたような気がする．これに関係するノードはおそらくほとんどがその所属系列の優先ノードになっているはずであり，上記で述べていることから推測しても，単純にポジション変更を行うことは難しいように思われる．

ともかく，ポジションの入れ替えを「結婚枠の取り合い」と解釈して実装してみることにしよう．「基準ノードの子ども枠はBTW不可」とする条件には左右本人の距離も考慮されているが，ここでは距離の問題は無視して考えることにする．条件を挙げてみよう．

1. 基準ノードの配偶者はつねに基準ノードの近接位置（同一ボックス内）に配置される
2. 基準ノードの配偶者が外部に有配偶者婚を持っている場合には，その結婚は基準ノードの配偶者の配偶者側で展開される
3. 基準ノードの結婚は項目2が成立するとき以外にはBTW接合することはできない　
4. 別の言い方をすれば，基準ノードの配偶者が外部に有配偶者婚を持っている場合にはその結婚の本人ノードを右手本人とするBTWを組むことができる

結婚を夫と妻のどちらで展開するかを決める関数MARGBOX::IsPrimeboxOrNotに上記論理を組み込むのは難しくないが，案じた通りの不良が発生した．先祖ノード不在がTRIBEBOX::GetMajorTribChainで発生している．解決できるだろうか？

午前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] 優先=大蔵名不詳．以下のような問題がある．

1. TRIBELIST::MakeUpTreeで系列優先実ノード不在の非始系列が発生する
2. TRIBEBOX::getPrimarynodeでは関数中で系列優先ノードが変化する場合があり，この関数を呼び出しているTRIBEBOX::GetRealnodeでフローの混乱が発生する
3. TRIBEBOX::getPrimeNodeで(!oyalink && Ancestor != Primary)となる場合がある
4. TRIBEBOX::GetAlternativePrimeNodeで主系列上に実ノードが存在しない場合がある
5. TRIBEBOX::GetMajorTribeChainで主系列チェーンが途切れる場合があり，これを強制的に延長すると循環が発生する

このような事象を回避するためには主系列参照関係が確立している必要があるが，それを生成している時点では回避操作が成立しない．「家内婚は左手本人預かり」とする処理を組み込むと系列参照関係に影響が及び，それによって回復不能な参照関係の破綻が生じる．つまり，言い換えると系列参照関係木が構築できない状態になる

午前3時起床，晴れ．朝食は雑炊の残りとサバ水煮缶．タブレットのディスク容量が逼迫してきたので，Windows.old を丸ごとメインマシンにコピーする深夜作業を仕掛けておいたのだが，止まっていた．タブレット側がスタンバイに入ってしまったためだろう．残り10%くらいだが，あと一時間くらいは掛かりそうだ．タブレットのドライブは32GBしかない．何か外部ストレージを増設するということも考えられるが，当面はメインマシンのEドライブをバックアップ用に使うことで間に合わせておこう．無線ドライブという選択肢もあるが，先送り．

仕掛りの反例サンプルの不具合の原因が2018-11-09に実施した「家内婚は左手本人預かりとする」という仕様変更にあることが分かったので，あとはそれに対処して系列優先ノードの付け替え処理を追加するだけだ．この時点ではまだYリストは生成されていないので，探索はすべてカードリンクベースで行わなくてはならない．まずはルーチンの始業時バックアップから始めよう．

Windowsoldのファイル転送は完了したが，サイズ・ファイル数などがかなり違う．原本が3.94GB，31,909本，3,607フォルダに対し複製は3.87GB，31,841本，3349フォルダでかなり少ない．完全にバックアップできていないということになるのだが，どうしたものだろう？実際問題としてバックアップからシステムを復元するというのは手続き的に難しいと思われるので，このまま進むことにしよう．通知画面で「削除」ボタンを押しただけでは自動的には削除されない．手動で削除しようとすると「このフォルダを変更するにはSYSTEMからアクセス許可を得る必要があります」となって先に進まない．

フォルダの移動はできた．Windows.old フォルダ全体を削除するではなく，その下の階層のフォルダを個別削除するようにしてある程度動き始めたが，ところどころ削除できないファイルが発生する．これらを「スキップ」してほぼ大きな部分を削除することができた．最終的にこのフォルダは完全に削除された．Cドライブの空領域は9.56GB．できれば，これをつねに10GB以上に維持したい…

TRIBEBOX::GetAlternativePrimeNodeという関数を新設して，系列優先仮ノードの切り替えを実施することにした．選別論理はほぼ動作するようになったのであとは結婚リンクを整えるだけになった．以下の2つを決定する必要がある．

1. MARGLINK *Marglink　主系列に属する優先実ノードの親の結婚リンクへの参照
2. MARGLINK *Oyalink　従系列に属する優先仮ノードの親の結婚リンクへの参照

！できた！

昨日の作図とは微妙に異なる点がある．どこが違うのか見てみよう．大きな相違点は昨日の図ではＡＢ＋ＡＣがＡＤの直下にあったのに対し，今日の図ではＡＥ＋ＡＣの下に移動しているという点だ．これは結局，この結婚がどこで展開されるか？というところに相違点があると言える．並べて比較してみることにしよう．

左が今回の出力つまり「家内婚を左手本人預かり」とした図，右は従来通りの出力図面だ．相違点は左図ではＡＦの優先ノードがＡＧとなっているのに対し，右図ではＡＩになっているという点だ．この図面で「家内婚」と呼ばれているのはＡＢ＋ＡＣ→ＡＡのことであり，この子ども枠は右図でも左図でも等しくＡＢ＋ＡＣ直下のゴールド婚になっているので，「右手本人預かり」であるか，「左手本人預かり」であるかは図面には影響していないように見えるのだが…

左右の相違は家内婚には直接関係せず，むしろ「系列分解」の方に影響しているように見える．実際，右図では左辺のノードはほとんどＡＦ系列所属となっているのに，左図ではわずかにＡＦ→ＡＤを確保しているに過ぎない．なぜこのようなところに差異が現れるのだろう？系列分解というのは先行処理であり，一般には系列優先ノードを決定した時点で確定すると考えられるのだが…

この図面を複雑なものにしている要因としては，ＡＢ＋ＡＣという家内婚の存在だけでなく，ＡＢとＡＩがともに複数の親を持っているという点にあると考えられる．ＡＢが婿養子，ＡＩも同様の事態が想定されるが，この程度の複雑さは世の中にはざらにある．この問題は一応これで最終解決したものと考えてよいと思われるが，2018-11-09の仕様変更の意味をもう一度考えておこう．

この問題はN一族家系図の補充・整理というフェーズで発生している．この作業はある意味でまだ未完結だ．実際「2018-11-08 N一族系図で問題が多発している」では終わりの方に16項目もの不具合ないし要対処項目がリストアップされている．ログは一旦ここで途切れて次に再開されるのは11月20日だが，このあとは例の「大量メール配信事件」に巻き込まれほとんど仕事になっていない．

現状どうなっているのか？このサンプルを開いてみよう．いや，その前に一度バックアップを取って仮修正をフィックスしておいた方がよい．仮修正は34行ある．かなり古いもの（去年の10月頃）が含まれている．

1. 「先祖並び自動ではバランス配置方式と単方向移動方式を併用する＠20181106」に含まれる→このオプションを現状でフィックス
2. 「先祖並び自動で直属系列の場合を除く＠20181021」に含まれる→このオプションを現状でフィックス
3. TRIBEBOX::Approximation　出口検査のTRIBEBOX::Approximation　⇒　現状でフィックス
4. MakeBugReport　GetOSDisplayStringの呼び出し　⇒　保留
5. TOPOLOGY::CheckPairList　RETRYラベル　⇒　現状でフィックス
6. NAMEBOX::GetLeftContact　「長い尻尾の場合はLeftContactMargTreeを使わない＠20181023」⇒　現状でフィックス
7. COUPLING::InitCoupling　冒頭でinitializeを実行　⇒　現状でフィックス
8. NAMEBOX::setCritical　「異世代多重でチャンネルエラー」⇒　復活
9. TRIBEBOX::ChangeBelongingTribe　出口検査：優先仮ノード不在で停止　⇒　現状でフィックス
10. TRIBEBOX::checktribesenzo　コメント「＠20190124 Yリスト未生成時には人名リンクを参照する」　⇒　現状でフィックス
11. TRIBEBOX::checktribesenzo　先祖仮ノード不在時の措置　⇒　現状でフィックス
12. CARDLINK::markupDownRoute　checkmarkの廃止　⇒　現状でフィックス
13. MARGBOX::IsPrimeboxOrNot　「家内婚は左手本人預かりとする＠20181108」⇒　現状でフィックス
14. NAMEBOX::RetrieveGhost　GetYoungerTail呼び出し　⇒　現状でフィックス
15. NAMEBOX::UnErasable　「家内婚左手本人は消去不可」⇒　現状でフィックス
16. TRIBEBOX::getPrimeNode　始系列で系列優先仮ノード不在は停止する　⇒　現状でフィックス
17. TRIBEBOX::getPrimeNode　優先ノードの所属系列不一致のときGetAlternativePrimeNodeを実行する　⇒　現状でフィックス
18. BUNSFILE::open　例外発生s時：パネルを出さない　⇒　現状でフィックス
19. COUPLING::SerializeHeader　「タイトル履歴サイズ不一致の場合はバッファを廃棄する＠20181030」⇒　現状でフィックス
20. COUPLING::SerializeHeader　例外処理でエラー復帰する　⇒　現状でフィックス
21. MakeUnderwear　GetOSDisplayString呼び出し　⇒　保留
22. NAMEBOX::getYoungerTail　TYW婚不一致のときはつねに停止　⇒　現状でフィックス
23. MARGBOX::ResetTooYoungWife　TYW婚でない場合は復帰する　⇒　現状でフィックス
24. TRIBEBOX::IsConnected　「系列優先ノード不在が起きることはあり得る＠20180903」⇒　現状でフィックス
25. TRIBEBOX::DoesMajorTribePathExist　GetStartTribeが空で始系列ではない場合がある　⇒　現状でフィックス
26. TOPOLOGY::TribeDecomposition　デバッグ用ダンプ　⇒　checkで判定する
27. TRIBELIST::TribeRelocation　CheckBrotherCrushを実行しない　⇒　現状でフィックス
28. TOPOLOGY::CheckAbsorbMarriage　事後にConfirmGoldenCoupleを実行する　⇒　現状でフィックス
29. nodule.h STOPマクロの定義　⇒　現状でフィックス

GetOSDisplayStringは保留してあとで見直すこととした．⇒かなり修正したのでもう一度バックアップを取っておこう．N一族では多重カードが出ているが，これは避けられないのだろうか？多分，基準ノードの配偶者は仮ノード消去できないというルールがどこかで導入されているはずだが，多重を極小化することは系図作図上の最優先項目であると思われるのだが…. この図面にはそれ以外にもいろいろありそうだ．「始系列参照パスが途切れている系列」というのが複数出ている．これもかなり問題がある．

おそらく，N一族家系図はゼルコバの木正式版をリリースするための最後の関門になるのではないかという気がする．それほど難しい図面ではないのだが…しかし，これに掛かる前に全般的なバグのクリアランスを片付けておきたい．一応動き始めたところで，一度障害サンプル集のオープンテストを走らせてみることにする．WordPressの書き込みでまたエラーが出始めた．

マウスも不調だ．古いマウスの方がまだましな感じだが，マウスホイールが使えない．

午後10時起床，晴れ．__asm int 3  が NOP に書き換えられてしまうという問題についてもう少し食い下がってみる．VS 2017 を起動するとき，「管理者権限で起動」しないようにすれば書き換えできないのではないか？と考えてやってみたが効果なかった．昨日のログでは，①バックアップに戻してから，②ipchのフォールバック位置を設定したあとにノーマルな状態に戻っているので，この操作を試してみる．⇒何の効果もない．

STOPに相当する関数__debugbreakを見つけたが，動作はまったく同じだ．つまり，一度ヒットすると0xCCの位置に0x90が書き込まれてしまう．結局#define STOP __asm int 3 とまったく同じ動作になる．これ以上粘っても仕方ないだろう．これを受け入れるしかない．STOPで停止したところに手操作でブレークポイントを設定することにした．

ASSERT_NEVER などの場合はマクロの中にマクロがネストしているので多少厄介だが，ASSERT_NEVERで停止するということはすでにその時点で検定に失敗していることを意味するのだから，動作を反復テストする必要性はないと考えられる．これでようやく腰を据えてデバッグできる．

エラーを無視して走らせるとSUWになり，以下の図面が表示される．

上図を見ると，ＡＩはＡＦの下流に存在しているが，明らかにＡＦの優先ノードはＡＤでなくてはならないように思われる．優先ノードの設定はTribeDecomposition→ MakeTribeBox で実施されている．この論理が誤っているように思われる．先祖リストに列挙されるノードは以下の5つだ．ＡＭ，ＡＮ，ＡＦ，ＡＥ，ＡＯ．ＡＩはＡＭ系列に含まれるので，それがＡＦを先祖とする系列に再登場するという点がおかしい．

いや，それは違う．「結婚」は夫ないし妻のいずれかの「場所」で一度だけ展開されるが，親子関係は必ず「その場所」で展開されるから複数の親を持つ場合には複数の仮ノードが生成されるというのが常態だ．ＡＦからＡＩに至る経路は2つある．ＡＦ→ ＡＤ→ ＡＢ→ ＡＡ→ ＡＩとＡＦ→ ＡＤ→ ＡＧ→ＡＩだ．ＡＥからＡＩに至る経路も2つあり，ＡＥ→ ＡＢ→ ＡＡ→ ＡＩとＡＥ→ ＡＣ→ ＡＡ→ ＡＩだ．

ＡＩは親を二組持っているから，出現は2箇所つまり，ＡＩの仮ノードは2つある．ＡＦはＡＥよりも先に展開されているから，ＡＦの優先ノードがＡＩになるというのは誤りではない．従って，ＡＩ(1)がＡＥ系列に属するという点に誤りがある．ＡＢ＋ＡＣ→ ＡＡがＡＦ系列で処理されていないのが問題だ．ＡＢ＋ＡＣは家内婚になっているが，どうもこの辺りで変則的な動作になっているような気がする．確かにそのようだ．ここでは家内婚を遅延処理するような調整が入っているが，それを外すことで簡単に描画できた．

確かにどこかで，このような調整を行った記憶はある．「家内婚は左手本人預かりとする」という仕様変更を2018-11-08に実施している．しかし，このような遅延処理が不可能ないし矛盾したものであるとは考えられないので，なぜこの論理が通用しないのかを考えてみよう．系列優先ノードは系列分解フェーズで決定されるが，結婚の展開はそれよりあとのGODOWNSTREAMで実施されているためだ．障害が発生するのはさらにそのあとのMAKEUPTREEフェーズ．現行論理では系列優先ノードの付け替えというのは普通にやっているので，それが適用可能かどうかを見ることにしよう．

EstablishMajorTribeChain はそのようなシチュエーションに適用可能な関数と思われる．いや，この関数はあまり完備したものではない．もう一度一から探し直すような処理が必要だ．IsConnectedでは付け替えができない．IsConnectedを適用するためにはYリストが整備されている必要がある．TRIBEBOX::AlternateTribeRealNodeにも包括的な付け替え論理が入っているが，この場合は優先仮ノードは固定で実ノードの代替品を探すという論理になっている．系列枠オブジェクトの右枝に先祖ノードが配置されていないまったくの空白状態から代替優先ノードを探す論理を一から起こすしかない．

Windows の以前のバージョンを削除しますか？という通知が入っている．ディスクスペースが逼迫しているためだ．タブレットには余分なものは一切置かないようにする必要がある．と言ってもユーザ領域は1GBも使っていない．Windows.oldをバックアップして潰すしかないだろう．約4GBだ．

午後8時起床，晴れ．朝食はネギと油揚げの卵うどん．STOPマクロで使っているアセンブラーコードの INT 3 が NOP に書き換えられてしまうという問題にどう対処すればよいか？STOP文の内容は以下のようなものだ．

#define STOP { do{__asm {int 3}} while (0); }

whileループは実際には回らないので実際には __asm {int 3} を一回だけ実施するのと等価だが，歴史的な理由でこのような構文になっている． これを以下のような関数呼び出しに書き換えてみたがうまくゆかない．

void stop(void)
{
     BPTR bp = (BPTR)stop;
     unsigned long offset = *(unsigned long *)(bp + 1);
     bp += offset + 0x4E;
     __asm{ int 3 };
     try {
         *bp = 0xCC;
     }
     catch (…) {}
}

*bp = 0xCC という行が実行できないためだ．「昔」はコードセグメントをダイナミックに書き換えるようなことは普通にやっていたのだが，いまは「遠い昔」だ．対策としては以下が考えられる．

1. マイクロソフトの Assertionで代用する
2. リリースモードのASSERT_NEVER と同等の動作に書き換える．つまり，パネルを出すことによって一時停止するようにする
3. stop() 関数の中で例外をスローし，関数内でキャッチする
4. Visual Studio のブレークポイントをstop()の中に設定する

項目１の難点は継続実行ができないという点だ．２の方法なら継続実行は可能だがパネルが表示されるために，トレースするのに一手間掛かってしまうという難点がある．３の方法もエラーハンドラーで停止するためにはパネルを出すしかないので意味がない．

stop関数の中にブレークポイントを置けば従来方式と実質的に同じ動作になるが，「恒久的にブレークポイントを設定する」ことができないというのが最大の問題だ．馬場研究所のデバッグメソッドでは，一つの問題が片付いたときには「すべてのブレークポイントを削除」するという手順が確立している．stop文にブレークポイントを設定し直せばよいというだけだが，余分なところに注意を振り向けなくてはならない．

次善の策として以下のような方法を採用することにした．「stop文には従来通りINT 3を仕掛けておく．ヒットするとそこで一度だけ停止するので，そのタイミングでブレークポイントを設定する」という方法だ．これまでは何も考えなくてもトレースに集中できていたのだが，これしかないと思う．ともかくこの環境に「慣れ」なくてはならない．

▲アプリ起動時，「Invalid parameter passed to C runtime function」というエラーが発生する．このエラーはCWinApp::GetPrinterDeviceDefaultsde　で起きている．GetPrinterDeviceDefaultsde は外部関数なので対処しようがない… 実害は特にないように思われるので無視とする．

なぜだろう？動作が変化してしまった．INT 3を実行してもNOPに書き換えられるという現象が起こらなくなった．何もしていないつもりなのだが… やったことといえば，ソースファイルをバックアップに戻したこととipchの「フォールバック位置」を設定したというだけだ．「Invalid parameter passed to C runtime function」というエラーは出ているが，これはまぁどうでもよい．

ipchというのはインテリセンスに関係するファイルで大きなファイルになるので，プロジェクトから切り離したというだけで動作に影響するということは考え辛い．シンボルファイルはすべて読み込むという設定になっている．もしこれで動作するのなら，完全に平常復帰したということになる．ともかく，デバッグを続けることにしよう．

Mouse without Border でマウス共有を実現しているが，かなりリスクがある．マウスから手を話しているときひじなどが触れてマウスが別PCのウィンドウに移動し，キー入力がそちらに入ってしまうことがある．編集中の画面ではキーが入らないので打ち直しして進めていると，別画面のソースファイルが壊れていたりする現象が発生する．

これを避けるためにはPCの位置関係を逆転させて左のPCの左から出て，右のPCの右に入るようにするというのが効果があるが，慣れるまで少し時間が掛かる．しかし，ソースファイルを壊すよりはましなのでそうすることにしよう．しかし，この歳になると「環境に慣れる」のが大変だね．ツールバーのアイコンは今までより小さく見える上，自分好みに移動しても元に戻ってしまう．諦めてあるがままの状態に慣れることにしたのだが…さて，ようやくデバッグの本番だ．

ＡＩの親はＡＬ＋ＡＧとＡＦで，ＡＥ系列ということはあり得ないと考えられるので，ＡＩ(1)の所属系列がＡＥになるというところで誤っているものと考えられる．この操作はGoDownStreamで実施されている．GoDownStream ではＡｆ系列はＡＥ系列より先に処理されているにも関わらず，ＡＩが処理されていない．これはかなりおかしい．ＡＧの結婚が処理されていない．ＡＧは妻帯で子ども2人を持っている．この結婚が処理済みになっている．

ＡＬは始系列ＡＭに属しているため，ここで処理されている．ということは，ＡＦ系列でＡＩを優先ノードに指定していること自体が誤りということになる．しかし，ＡＦ系列に入っているのは，もう一人の親であるＡＡだ．このノードが処理されていないのではないか？いや，ちょっと読み損なっている．ＡＡはＡＥ系列と思われる．つまり，ＡＩとＡＦはまったく繋がりがない．従って，ＡＩがＡＦの優先ノードになっている時点で誤りということになる．

Windows の更新が入った．「再起動が必要」ということらしい．メインマシンには更新が入ったが，タブレットには通知が入ってこない．同時ということはないにしても，精々タイムラグは精々一日程度と考えられる．更新をチェックしてみよう．確かに更新はあるようだ．「アクティブ時間」というのを設定したことはないが，この値が違うのかもしれない．

系列優先ノードの変更はTRIBEBOX::setprimaryで実施しているが，どうもこの関数が呼び出されていないように思われる．ではどこで書き換えているのか？いや，書き換えにはこの関数が必ず使われている．ダメだ．やはりINT 3の書き換えは実施されている．仕方ない．冒頭で決めたような方式でかわすことにしよう．逆アセンブルで見ると，「27ミリ秒経過」とあるので，INT 3を実行後一定時間が経過するとNOPに書き換えるという動作が入るようになっているようだ．なぜ，こんな込み入ったことをする必要があるのか？その真意が分からない…

ＡＦ系列の優先ノード設定はTOPOLOGY::TribeDecomposition⇒TRIBELIST::MakeTribeBoxで実行されている．TribeDecompositionが誤っているのではないだろうか？そもそもＡＩとＡＦは繋がっていないはずなのだが…

午後3時半起床，晴れ．朝食は薄切り食パン2枚のチーズトースト，コロッケ小1個．グーグルアカウントへのログインを二段階認証からスマホを使ったログインに切り替えたところ，マイクロソフトアカウントで起きていたのと同じ問題が発生するようになった．メールアカウントでログインできないという問題だ．この解決法はマイクロソフトの場合と同じく，「アプリケーションパスワード」というのを使うしかない．

「アプリケーションパスワード」を設定する画面が見つからない．カスペルスキーのアプリロックを解除したところ，この通知は出なくなった．ついでに，グーグル開発者チームアプリを「無効」に設定した．この操作で開発者チームアプリは一旦アンインストールされたが，そのあと「工場出荷時」の状態にリセットされた．また，Visual StudioのフォントをUI Meiryo11ポイントに切り替えた．

開発環境ではまだ，outlookのエラーが続いている．この不良を調整するためにはマイクロソフトアカウントを「Windows Hello」に対応させる必要があると言う．Windows Hello というのは「指紋または顔認証」を使ったサインインのことだ．すでにスマホにはMicrosoft Authenticator を導入済みなのだが…. Windows Hello を設定したが，outlookのエラーは止まらない．メールだけを同期させるようにしてとりあえず解消．

ＡＩの上流系をダンプしてみた．

CARDLINK:#119 ＠121Ａ Ｉ
     父：CARDLINK:#125 ＠149Ａ Ｌ
         父：CARDLINK:#127 ＠159Ａ Ｍ
         母：CARDLINK:#129 ＠715Ａ Ｎ
     母：CARDLINK:#115 ＠80Ａ Ｇ
         父：CARDLINK:#109 ＠19Ａ Ｄ
             父：CARDLINK:#113 ＠77Ａ Ｆ
     父：CARDLINK:#103 ＠1Ａ Ａ
         父：CARDLINK:#105 ＠2Ａ Ｂ
             父：CARDLINK:#111 ＠20Ａ Ｅ
             母：CARDLINK:#131 ＠822Ａ Ｏ
             父：CARDLINK:#109 ＠19Ａ Ｄ
                 父：CARDLINK:#113 ＠77Ａ Ｆ
         母：CARDLINK:#107 ＠18Ａ Ｃ
             父：CARDLINK:#111 ＠20Ａ Ｅ
             母：CARDLINK:#131 ＠822Ａ Ｏ

ＡＩは基準ノードで父母を2組持っているが，どちらの系統にもＡＦ は出てこない．つまり，ＡＦ系列でＡＩが優先ノードになるということはあり得ないと考えられる．どうもおかしい．ＡＦ系列のPrimaryには確かにＡＩが入っているが，それを設定している時点が見つからない．どうもブレークポイントの効き方が悪くなっているような気がする．

STOP文で使っている「int 3」というアセンブラーコードがNOPに書き換えられている．一度だけは停止するが，その時点でint 3の0xCCの代わりに0x90を書き込むような動作になっている．マイクロソフトも随分余計なことをしてくれたものだ．「新しく導入されたヘルパー」などと言っているが，ブレークするたびに余計なパネルを出すなどどれも余分なことばかりだ．使い辛くて仕方ない．

マイクロソフトが提供しているAssertionマクロに相当するものとして，我々は独自にASSERT_NEVER というマクロを使っている．どちらも関数の入り口付近に置き設定した条件によって停止するというものだが，使い勝手は断然ASSERT_NEVER の方が勝る．

主な相違点は①Assertionは条件式が偽の場合に停止するのに対し，ASSERT_NEVERは真の場合に停止する．この方が直観的だし，一時的/試験的に挿入していた検査文を恒久的なアサーションに書き換えるときもコードの修正が不要という利点がある．（ややこしい論理式の真偽を反転させる書き換えはリスクがある）②パネルを出さずにソースコード上で停止できる．このため障害の起きている正確な行番号を取得できる．（一行ずれているだけでも判断を誤る可能性がある）

③Assertionは例外処理を使って停止しているため継続実行ができず，アプリ終了してしまう．ASSERT_NEVERはSTOP文の割り込みINT 3で停止している．ASSERT_NEVERは継続実行することを予定していないが，STOP文自体はパネルを出さず，そのまま継続実行することができる．

現在STOP文はコメントアウトしている分を含めて1800箇所に埋め込まれている．ASSERT_NEVERの挿入箇所は2390もある．この仕組みはゼルコバの木が長い年月を掛けて培った「免疫系システム」そのものでありこれが効かなくなったら我々の「ピュアで超クリーンなシステム」は壊滅してしまう．

実際，仕掛りになっている15点という極小な反例サンプルでうろうろしているのも，このSTOP文が無効化されていたためだ．マイクロソフトがこの改変を「悪意」を持って実施したとは思わないが，我々にとっては致命的な改修になっている．「Assertionで代用できる」という意見もネット上には散見されるが，そうじゃないんだよ！

午後7時起床，晴れ．朝食はカスタードクリームパン小5個．平常復帰したとは言え，まだいまいち乗りが悪い… 15点という小さいサンプルで起きている「優先ノードの所属系列不一致」がシューティングできていない．ノードAIの2つの仮ノードはいずれも系列優先ノードになので，AI(1)の所属系列がAFになっているという点に不審がある．

CARDLINK::DownStream で設定されている．誤っているのはCARDLINK::NameBoxの動作と思われる．この関数では親リンクを指定して仮ノードを取り出しているが，すでに所属系列が確定しているノードが取り出されている．AE系列の優先ノードはABであり，nbox->groupでAIが取り出されているという点がおかしい．どこかでABからAIに切り替わっているようだ．

午後10時起床，晴れ．開発環境はほぼ完全に復調したが，開発環境でマイクロソフトアカウントの一部使用が復活し，ネット環境ではマイクロソフトAuthenticatorが導入されたことによって，ネット環境と開発環境を完全にデカップリングするという原則は崩れた．マイクロソフトが無償で提供している Visual Studio 2017 Community を使うためにはマイクロソフトアカウントの取得が必須であるという文言は見ていないが，実質的にそうなっているように思われる．

マイクロソフトアカウントのサインインで二段階認証を使うのとマイクロソフトアカウントを極力使わないようにするのとどちらが比較的に安全か？という点に関してはいまのところまだ結論は出ていないが，しばらくはこれで運用してみることにする．ともかくセキュリティを極限まで高める以外の方策はないので，できる限りのことをやるというのが現時点における我々のスタンスだ．

まだ多少気がかりな点は残っている．

1. スマホで電源スイッチを押したときの画面でカスペルスキーがオフになることがある
2. メインマシンとタブレットをLANで繋いでいるとき，Mouse without Border を起動してエラーになる．実効的にはリンクしている
3. マイクロソフトアカウントで修正を要する点があるという通知が入る　多分Outlookで認証に失敗しているためと考えられる　これはローカルアカウントでログインしているにも関わらず，裏でマイクロソフトアカウントを使おうとしているのではないか？
4. Mouse without Border では画像のコピー・ペーストはできない　Easy PC Remote ではできた　まれにOpen Live Writer でキーが入らなくなることがある

さて，ともかく仕事に復帰しよう．机上に残っている反例サンプルをクリアするところから始める．

▲BUG18-11-23 17-41-29.ZELを開いてBUG18-11-23 17-41-29.ZELで停止する．「優先ノードの所属系列不一致」が起きている．設定はチャンネル数自動=5 先祖並び自動=1 軸線図法=0 父系優先=-1　でカード数15という小さいサンプルだ．この反例が生成された経緯は不明だが，データ不良ということも考えられる．

この障害が発生した2018-11-23というのは，「ブルースクリーンが出た！スーパーセキュリティをインストール，トレンドマイクロでオンラインスキャン」のような事象が起きていた日付であり，かなり悪い状況の中でテストしていたものと推定される．とりあえず，この期間に発生した反例サンプルは凍結しておくことにしよう．

BUG19-01-12 04-20-39.ZELは問題なく開けた．2019-01-12という日付は『タイプ初期化子が例外をスローしました」という不吉なエラー』が出ていた時期で，まだビルドが完全に通っていなかったころと思われる．そのような不安定な環境で起きている事象なのでコード的な問題ではなかった可能性がある．サンプルは源氏6で設定はチャンネル数自動=5 先祖並び自動=1 軸線図法=0 父系優先=-1 長子相続=0，カード数は237という標準的なサンプルだ．

この他に退避用の一時ファイルとしてRESCUETREE.20190117.094555110.$$$が残っているが，単なる「新規ファイル」であるように思われる．これで机上の反例はとりあえず片付いたということにしておこう．このあと，障害サンプル集のランニングテストでかなりの障害が起きていたように思われるので，とりあえずこの場で障害サンプル集のオープンテストをやってみることにする．

このテストは一応リリース版を起こしてインストールしてから実施するのが適当だろう．Version 2.1.0.011 Release 2019-01-21 をリリースした．反例サンプルを机上に1個出漁したあと，ハング状態になっている．ハングしているのは，

C:\Users\babalabo\Desktop\障害サンプル集\FB4反例\FB4検定2017-08-10\修復サンプル\太郎君の直系血族図.NON

と思われる．

▲BUG19-01-21 08-52-58.ZELを開いてTRIBEBOX::getPrimeNodeで「優先ノードの所属系列不一致」が発生する．上でネグレクトした障害とまったく同じだ．カード数も15なので完全に同じ事象が発現したものと思われる．家内婚が検出されていることに関係している可能性もある．この障害はMAKEUPTREEフェーズで起きている．対象系列枠は#159 odr=0 先祖=#114 ＡＦ(0)[0] 優先=ＡＩ．

ノードAIの仮ノードは2つで(0)の所属系列はAM，(1)はAEなので，系列AFに属するAIは存在しない．なぜこんな状態になっているのか？系列枠は7個あり，AIは始系列AMとAF系列の優先ノードになっている．従って，AIが系列AEに属している点に誤りがあるように思われる．どこでそれが起きているのかを見てみよう．障害が起きているのはABで[系列枠]: #269 odr=0 先祖=#218の優先ノードだ．