再開発版のバージョンを確定する

現在「再開発スタート版候補」として以下の4種が上がっている．

1. ZELKOVA2019_2019-03-10★2.1.017　ほぼ最終版
2. ZELKOVA2019_2019-08-09★2.1.020　最良版候補
3. ZELKOVA2018_2019-08-14★2.0.2229　VS2017移行仕掛り版
4. ZELKOVA_2020-10-12★2.1.012　現行仕掛り版

いずれもVS2017で開けることは確認してあるので，それぞれをビルドしてパフォーマンスを比較してみることにする．以下ではこれらをそれぞれ①ほぼ最終版，②最良版候補 ，③移行仕掛り版，④現行仕掛り版と呼ぶことにする．まず，①から試してみることにしよう．これはビルド日付が去年のわたしの誕生日に当たっているので幸先がよい．

ビルドできた．タモリんちは正規形で表示できている．⇒残念！バグが出ている．天皇家で「多重カード」が発生してしまった．かなり致命的というより最低だ．これは一応残して別の候補を見ることにしよう．②の最良版候補はどうだろう？⇒リリース版を作ってしまった．⇒天皇家は問題なく開けた．天智天皇から上が上方にY字に拡がっているというパターンだ．タモリんちも正規形で開ける．

もう少しテスト用サンプルを探さなくてはならない．テストキットのようなものがどこかに保存されていなくてはならないのだが…このサンプルキットそれ自体かなり貴重なものなのでどこかになくてはならないのだが，ちょっと見たところ見当たらない．デスクトップ 2020-02-11というフォルダがあった．多分これはこの時期デスクトップ上にあったサンプルを網羅していると思う．サンプルファイルだけで112,428本．まずい！この版（最良版候補）にも重大な欠陥がある．Ancestryがシンメトリックに描画できない！これはかなり由々しき事態だ．

軸線図ならこのような図式になる可能性もあるが，設定はデフォルトの軸線なしだ．これを「最良版」とみなすことはできない…③移行仕掛り版を見てみよう．⇒「”ADODB” のラッパー アセンブリが見つかりません。」が出た．プロジェクト→参照の追加でMADO 2.5 Libraryから6.1 Libraryに切り替えてエラーは解消した．いや，このエラーは通ったが別のエラーが噴き出してきた．エラーの一つのタイプは

error BC40000: ‘Public Function FontChangeSize(CurrentFont As Font, Size As Single) As Font’ は廃止されています: ‘Microsoft.VisualBasic.Compatibility.* classes are obsolete and supported within 32 bit processes only. http://go.microsoft.com/fwlink/?

というもので，もうひとつは

error BC30311: 型 ‘CheckBox()’ の値を ‘ISupportInitialize’ に変換できません。

というタイプのものだ．

error BC30451: ‘address_Leave’ は宣言されていません。アクセスできない保護レベルになっています。

というタイプのエラーもある．もう一つのタイプは

error BC30456: ‘Item’ は ‘TextBox()’ のメンバーではありません。

というものだ．ビルドのターゲットはAny CPUになっていたが，これをWIN32ないしx86に切り替えても同じだ．おそらくこの版では64ビット版への移行を狙っていたのではないかという気もするが，このシステムはアンマネージドなネイティブコードがベースになっているので64ビットにストレートに移行することは少なくとも現時点では現実的ではない．「オブジェクト配列の廃止」という修正がまだ収束していないということも考えられるが，それだけでもなさそうだ．他のパッケージと比較してここまで動作が変わるという理由がよくわからない．とりあえず，この版は再開発のコースからは一時的にであれ外すしかない．

現行仕掛り版の動作はすでに見ているが，一応再確認しておこう．⇒この版では天皇家も問題なく開ける．ややのけぞったような形態にはなっているが，本質的な問題ではない．タモリんちでバランスが崩れるというのが最大の問題だ．ここまでを整理すると：

1. 2019-03-10★2.1.017　ほぼ最終版　天皇家で多重カード
2. 2019-08-09★2.1.020　最良版候補　Ancestry.ZELが非対称
3. 2019-08-14★2.0.2229　移行仕掛り版　ビルド不能
4. 2020-10-12★2.1.012　現行仕掛り版　タモリんちでバランス不良

③の移行仕掛り版を弾くとすると残り3つになるが，多重カードが発生するというのはかなり致命的なので外すしかないのではないだろうか？残り2つはいずれもバランスの悪い図を描画するという欠陥があるが，どちらの問題も解決策がないという訳ではないので，どちらがより容易に対処可能か？ということになりそうだ．どちらかというとAncestryの非対称の方が扱い難いような気がするので，現行仕掛り版から始めるということになりそうだが，この版の出自をもう一度確認しておこう．もしかすると，この辺りの問題まで解決した版が出てくるかもしれない．

この版のベースはZELKOVA2019_2020-10-11という名前でバックアップしている．SetupのVersionで見ると2.1.010とあるので，3候補の中では一番古いものということになる．DLLのソースコードは2019/01/11修正が最終だ．バージョン番号から見ると，現行仕掛り版（1月11日）→ほぼ最終版（3月10日）→最良版候補（8月10日）ということになる．

ただし，ほぼ最終版と最良版候補はどこかで分岐しているようで，最良版候補は必ずしもほぼ最終版の継承にはなっていない．最良版候補には2019/02/06の修正が入っているのである意味でこれは「基準配偶者配置問題」の修正に入る前の版と考えられる．ほぼ最終版はある意味で間違った方向に進んでしまったと考えられるのでこの意味では

現行仕掛り版（1月11日）→最良版候補（2月6日，8月10日）

ということになるから，むしろ最良版の方がベターなのではないだろうか？最良版候補のベース版を見つけることができるだろうか？ZELKOVA2019_2019-02-10というのがある．その他にも2月26日～3月10日までの間には6個のパッケージが残っている．とりあえず，まず2019-02-10を試してみたい．このあと，2月26日まではかなり長い空白期間になっているのだが…ZELKOVA2019_2019-02-10を起こしてみたが，起動時にエラーが発生した．何が悪いのかよくわからない．⇒リビルドして解消した．この版でもAncestry非対称が起きている．

ZELKOVA2019_2019-02-26を見てみよう．⇒ほぼ同じだ．天皇家の多重は起きていないがAncestry非対称になる．このあと，3月10日のほぼ最終版までの間で天皇家多重が起きるようになるのだろう．次が2月27日でその次の3月5日まで若干の空白がある．ZELKOVA2019_2019-03-05を調べてみよう．⇒動作的にはまったく同じだ．あと残っているパッケージは3つしかない．一つづつ調べてみる．まず，真ん中のZELKOVA2019_2019-03-07から行ってみよう．

この版では天皇家で非連結になる．天皇家はほぼ一系列なので非連結になるというのはほとんど考えられないのだが…タモリんちは逆に完璧な理想形になっている．Ancestryはかなりひどい毀損状態になる．

ZELKOVA2019_2019-03-06も見ておくことにしよう．⇒状況は同じ．結局2019-03-05が屈折点になっているということになる．選択肢としては現行仕掛り版（1月11日）を取るか，ないし最良版候補（2月6日）～3月5日の間を取るということになりそうだ．あるいは，1月11日～2月6日の期間も対象になるのではないか？最良版候補に入っている8月10日の修正というのも気になるところだ．しかし，この日の修正をログから特定するのはかなり難しそうだ．むしろソースコードを比較してしまった方が早いかもしれない．1月11日～2月6日の期間はほぼ1日置きにパッケージが残っている．2019年2月のログを少し読み直してみよう．

2月は17日から仕事を開始しているが，かなりブランクを空けて26日までは大したことはやっていない．3月にはThunderBIrdの導入とサイトメンテナンスに焦点が移ってしまっている．「基準ノード配偶者近接配置」の件は片付いているのだろうか？言及がないところを見ると一応落着したと認定していたのではないだろうか？自分自身は仕掛りという意識でいたのだが…いずれにしてもここをすくい上げることができればほぼ最終版に近いものになると考えられるのでできる限り追求してみたい．バックアップを見ると仕事をしていなかった訳ではなさそうなので，ログで言及されていないということはほぼルーチン的な作業になっていたためではないだろうか？3月5日を過ぎると天皇家で不具合が発生し始めるのでやる気を喪失していたのかもしれない…

2月最後の記事は27日の「基準ノードの配偶者で多重が起きる問題」だが，そこで途絶した状態になっているのでおそらく解決しなかったと考えた方がよいのではないかと思う．2月はほとんど遊んでいたに等しいので，やはりこの修正は一旦戻した方がよいのではないだろうか？2月10日に「基準ノードの配偶者が枠外に出てしまう問題」に取り掛かっている．ある程度までは動作していたはずだが，SUWが出るのを抑えきれなかったというのが真相だろう．この修正をそのまま残してデバッグから入るか？それとももう一度一からやり直すのか？それが問題だ．可能な限り直近のバージョンを取るとすれば，3月5日のバックアップということになる．修正廃棄という方針なら2月6日（最良版候補）になるだろう．2019年1月の状況もチェックしておこう．タイトルを列挙すると：

1. 2019/01/30　トライアングル関係BTWの導入で配偶者多重問題を解決する
2. 2019/01/29　開発三種の神器の一つ「草薙のデバッグブレーク文」が復活した
3. 2019/01/28　妻を奪われた残念な男がせめて家系図上で妻を取り戻すには
4. 2019/01/27　「家内婚は左手本人の預かり」という仕様変更が収束しない
5. 2019/01/25　「家内婚は左手本人預かりとする」という仕様変更
6. 2019/01/24　INT 3→NOPの現象が一時止まったがまた元の状態に
7. 2019/01/22　int 3 のブレークポイントがNOPに書き換えられてしまう
8. 2019/01/21　15点という小さいサンプルで障害が発生している

のような感じでそれほどトリビアルとは言えない問題に対処しているので温存するのが妥当だろう．これを見ると1月28日頃からすでに「配偶者近接問題」に関わっていたことがわかる．この修正を撤回するということもあり得ないのでむしろ中断したところからデバッグするという方が現実的なのではないだろうか？とすると，再開発開始版は2019年3月5日版ということになるはずだ．もう一度この版をチェックしてみよう．3月6日版を起こしてしまった．この版ではAncestryが完全に壊れてしまう．いや，おかしい．3月5日版でもシンメトリが崩れている．

いや，この辺りでは常態としてAncestry非対称が起きている．むしろ，天皇家で垂線がぶつぶつに切れるというのが目立つ．もう少しましな版はなかったろうか？最良版候補（2月6日，8月10日）をもう一度見てみよう．2月6日なら配偶者近接の修正も導入されているのではないか？⇒同じだ．どうせ同じなら日付が近いものの方がよいのではないだろうか？2月6日版のオリジナルを見てみよう．手元の2月10日版を見ることにする．⇒ダメだ．この版では例外が発生する．2月26日版でも状況はほぼ同じ．つまり，Ancestry非対称，天皇家で垂線切れだ．⇒例外の発生はエラーではなくカスペルスキーが実行をブロックしたためと思われる．天皇家で垂線が切れるという事象は現行仕掛り版（1月11日）でも見られるので相当前から発生していたものと見られる．これは独自にデバッグする必要があり，版の選定では無視してよい．

となると，最後の決め手は天皇家でY字型の空白部ができることを許容するか否かという問題に絞り込まれるように思われる．現行仕掛り版ではかなりコンパクトというか，おそらくこれ以上は無理と思われる程度にコンパクトになっているが，1月～2月のどこかで拡がるようになってしまったのではないかと思われる．現行仕掛り版のコンパクトな配置はTYWの作用によるものと思われるので，どこかでその効果を減殺するような論理が組み込まれたのではないかと思う．どこでこの差異が発生するようになったかは突き止めておきたい．

修正が入ったとすれば1月11日から2月10日までの期間と推定される．まず，ZELKOVA2019_2019-01-20から見てみよう．この版ではAncestryは対称，天皇家はまだコンパクトだ．1/30を見てみよう．この版ではAncestryは対称，タモリんちもバランスよく，天皇家もコンパクトという非の打ちどころのない仕上がりになっている．2/4を見てみよう．2/4版では天皇家で「先行系列との接続関係確立に再び失敗」という障害が発生する．このエラーは他のサンプルでも起きる．描画は可能なのでこの時点で初めて設置されたトラップである可能性もある．2/6には問題は起きていない．2/7でAncestryのシンメトリが崩れる．同時に天皇家でも上が開くようになる．これはおそらく同一の機序によるものと考えてよいだろう．2/6と2/7の間に2つパッケージがあるが，いずれも同じ．

結局，2/6というパッケージは2019/02/06の始業時バックアップなのでその後の修正で不具合が紛れ込んだという結論になる．これは何を目的とした修正だったのか？

この日の修正は「冷泉院の切り替え」という問題だが，その内容がよくわからない．2/5のログなく，2/4は「系列優先実ノードが隠蔽リスト上にあるという問題」というタイトルになっている．「冷泉院」の名前は出てこないが，関連した問題である可能性はある．いや，多分関わりはないと思われる．この日の対象サンプルはN一族で「N一族家系図に取り組み初めてすでに3ヶ月経過したが，途中に大きなブランクが生じたためまだ収束にはほど遠い状況で足踏みしている．」という書き込みがある．その後に同じ日付でもう1本ある．こちらが本当の2/4だろう．

課題はやはり，「隠蔽された系列優先実ノードが出現する」という問題だ．系列が優先ノードのBTWで結合されているときには，どちらかのノードは消去されていなくてはならない．このとき，「[系列枠]: #806 優先=桐壷の更衣(0)の優先ノードは桐壷の更衣．桐壷院が基準ノード承香殿女御（朱雀院の）の配偶者であるため，桐壷院＋桐壷の更衣の結婚は桐壷の更衣の系列で展開されている．このため桐壷の更衣の仮ノードは1個しか存在しないので系列優先ノードを桐壷院に切り替える必要がある．エラーを無視して描画した場合には冷泉院に切り替わっているが，実仮ノードで世代差が発生している．」というストーリーなのだが…

対策としては「RIBEBOX::decidePrimaryNodeで優先仮ノードを決定する時点で優先実ノードの存在を確認するようにした．このためにGetRealnode(NAMEBOX*)という関数を新設した．優先実仮ノードの対が得られないときはGetAlternativePrimeNodeが実行され，優先仮ノードの切り替えを実施する．これで桐壷の更衣から桐壷院に切り替えることができたが最終的には冷泉院に切り替わる．」としている．図面を見てもよく飲み込めないが，ともかくそのような問題があったとされる．

2/6にはまず，NODULE::IsAliveという関数が間違っているとして修正し，さらに多分PairBoxGeneChangeを修正してエラーが解消したとしている．ここでリリース版を起こしているのでその存在を確認してみよう．少なくとも公式版ないし安定版としては存在していない．2/6-1が2.1.0.016で2/6-2が2.1.0.017に変わっているのでこの間でリリース版を起こしていると考えられるが，不具合はすでに2/6-1で発生している．

2/6のログには『「基準ノードの配偶者は基準ノードに近接配置」という原則が崩れている』という記述があり，2/4には「N一族家系図に取り組み初めてすでに3ヶ月経過」ともあるので，2018年の末頃にはすでにこのテーマに取り組み始めていたものと推定される．従って，Ancestry非対称と天皇家の弛緩はこのテーマとは直接関わりがない可能性が高い．

2/6版と2/6-1版の差異はソースファイルを直接比較するのが一番早いと思う．いずれにしてもそこから先は「デバッグ」の領域に入ってしまうと思われるのでここでは扱わないことにする．とりあえず，今日のところは2019-02-06まで戻るということで確定ということにしておこう．