昨日作った要対処項目リストの整理に失敗してしまった．オリジナルでは92件あったのに，82件に減ってしまっている．行の移動で何度もUNDO/REDOを繰り返しているので何か誤操作ないし誤動作があったのだろう．中間で保存している可能性もあるので読み出してみよう．⇒下書きは残っていない．！偉い！カテゴリ分けした時点で公開している．ここからやり直せばよい．HTMLのリスト形式になっているが，むしろプレーンなテキストエディタで編集したあとリストに仕立て直した方が確実なのではないか？⇒テキストエディタから戻してリストに変換しても改行が無視されてしまう．⇒やむを得ない．どっちみち行番号も消さなくてはならないのだから…
行番号が付くのを避ける方法がある．HTMLで一度リストを解除してやればよい．テキストエディタで一改行入れておくと一発でリストに変換できる可能性がある．⇒あっという間に終わった．1項目を分割しているところがあるので，93項目になった．全93項目のうち，バグ37件，不良20件，改善24件，検証5件，宿題1件，参考6件に分類された．バグは障害の発生事例，不良は仕様的な不具合，改善は改良のための提案，検証は確認を要する事項，宿題はやや長期的な課題，参考はプログラムに直接影響しない情報．この手順で一つだけ問題がある．リンクが切れてしまうという点だ．これは適宜復元するしかないだろう．
すでにフィックスしている項目は対処済み項目リストに移動する．ともかく最初の37件のバグから見てゆくことにしよう．バグ項目には「障害を再現させるための手順」が記録されていることが必須だが，ほとんどの項目はその要件を欠いているので，まずそこから始めるしかない．最初に再現可能か否かを確認するというところから始めよう．再現出来ない項目はとりあえず，後回しとするしかないが，再現可能な項目でも緊急性や難易度の観点から判断して後回しとすることもあるだろう．
いや，その前に机上に反例サンプルが10個あるので確認しておこう．BUG20-10-31というフォルダに収容した．⇒一つだけ開けてみたが再現しない．多分これは広域スプリット検定の反例ではないかと思う．「ファイルオープンテスト」を実行してみる．特に問題なく開けた．多分すでに解消しているのではないかと思う．
▲実親を基準ノードでソートしているのに直下に来ないというのはかなりおかしい
再現できるだろうか？これは軸線図だ．UNDOCHAINでソートしているのだが…この記録は10月23日のものだが，現在のシステム図とは大分違うようだ．ごく初期のモジュール構成図と呼んでいた時期のものと思われる．図柄は多少違うが，確かに出てきた．
UNDOCHAINには父が3人いてそのうちUndoChainは実親，他の2人は養親となっている．この2人が養親子関係であるのにブルー表示されていないというのは，これらの父が祖父undosysの実子であるからだ．つまり，この2人の義父は同時に叔父でもあるため，傍系血族のピンク色になっている．いずれにしても血統軸線図では直系血族が最優先されるはずなのでUndoChainが軸線上にないというのは誤りと考えられる．軸線図関係はJikusen.cppというファイルがあるので少し読んでみよう．
「複数出力枝を持つ」というダンプが出ているが，これは軸線図に関係するもののようだ．このダンプはTOPOLOGY::FindJikusenAncestorのステージ【６.１】父系/母系優先を枝グラフに反映するで出ている．
▲VAIOに最新版をインストールしようとしてエラーになった．
このマシンにはゼルコバの木ベータ２はインストールされているが，ZTはまだインストールされていない．Program Files (x86)のbabalaboにはZelkova Beta2フォルダがあるだけだ．つまり，まだバージンと言ってよい．CPUもOSも64ビットだ．考えられるのは.NETのバージョンくらいだが….NETは3.5が入っている．アプリの必須コンポーネントは.NET 3.5 SP1だ．HRESULT=-2147024770=0x8007007EはDLLNotFoundExceptionだ．いや，OCXの登録に失敗しましたとある．⇒インストールに成功した．必要条件はVisual C++ 2017 Redistributable (x86)がインストールされていることだ．VAIOにはVC++ 2010 Redistributableしかインストールされていなかったため，マイクロソフトサポートからダウンロードしてインストールした．
VBの発行→必須コンポーネントにはVisual C++ “14” Runtime Libraries (x86)が必須となっているが，msiインストーラはこの手続きを踏んで生成されている訳ではないので，不足しているコンポーネントを指摘できないのだろう．「発行」を実行するとデスクトップ上にApplication Filesというフォルダが作られる．これは発行フォルダの場所にデスクトップを指定しているためだ．このApplication Filesというのはネット上のサイトに置くべきもので中に入っているものの大部分は*.deployという拡張子が付いている．どういう使い方をするものなのかはよくわからない．この方法でインストールした場合にはバージョンアップしたときの自動更新などもサポートされるのではないかと思う．いずれにしても，少なくとも64bit OSで64bit CPUならZT 2021をインストールできることが証明された．この後の課題としてVisual Studio 2019への移行というのがあるのだが，それはまた後日．
「複数出力枝を持つ」というダンプが出ているので，このサンプルには何か特殊な問題があるらしいということが察せられる．「枝」と言っているのは「グラフ」の「辺」のことで，このロジックでは抽象グラフ検証系のSIMPLEGRAPHを使っている．グラフはすべてTOPOLOGYが管理しているのだが，何を使っているのだろう？graph2だ．graph1, 2, 3があるが用途が分かるようにJikusenGaphとリネームしておこう．おそらくこの枝グラフは基準ノードから先祖ノードまでの直上経路を探すためのものと思われる．仮に下から上に矢線が向いているとすれば，出力枝とは上向きの枝ということになる．
すでにSIMPLELINKのノードを廃止してしまったが，早まったかなという感じもある．ただのベタ参照とnodule*参照では使い勝手がまったく違う．確かに早まっていたと思う．NODULEではスロットに数値を格納することはまったく不可能という訳ではなかったのだ！昔はそういうこともやっていた．ただし，４バイトのスロットのうち2バイトまでしか使えないので，-32768～32767ないし，0～65535までだ．しかし，一般の用途ならこれで十分なのではないだろうか？Windowsの座標値の範囲も概ねこのくらいだったような気がする．⇒いや，ちょっと勘違いしている．SIMPLENODEのlinkに入るのは数値ではなくアドレスだ．これには4バイトが必要だ．
スロットとベタ参照を両方用意して使い分けることも考えられる．そういうことを意識せずにプログラミングできるところがNODULEの最大のメリットだった…つまらない欲をかいてしまったのだろうか？いくらなんでもベタのアドレスとNODULEのポインタをごしゃまぜにはできない…こうなることは覚悟の上だったはずだが…失ったものはあまりに大きい．やはり，この修正「SIMPLENODEsLINKを廃止＠20201019」はあまりよくなかったと結論付けるしかない．修正箇所は45箇所ある．
もう少し考えてみよう…これまでの仕組みの利点を失わないためには，装置を複線化するしかない．つまり，たとえばlinkとvalueを使い分けるという方式だ．グラフはlinkベースであるか，valueベースであるかのいずれかしかないと考えられるから，グラフにフラグを持たせてそれをSIMPLENODEが参照して切り替えればよい．これは結局対象がNODULEベースであるか？NON-NODULEベースであるかの違いということになる．このフラグを bool monoとする．グラフはデフォルトではmonoだが，生成時ないし動的に値を設定できるものとする．
▲メニューバーの検索ボックスは最初カーソルがボックス中央に出ているが，文字入力すると左端に移動してしまう．最初から左端に出している方が素直だ
システム構成図でsplitlistという名前は2箇所出てくる．TRIBEBOX::splitlistとTRIBELIST::splitlistだ．前者はすでにSplitListとリネームされているがシステムズには反映されていない．プログラムの書き換えとシステム図のメンテナンスを同時並行されるのは至難の業だ．完全に同期させるためにはプログラムのソースコードから自動生成できなくてはならない．
後者の用途は「系列間シンメトリ婚スプリット検定用リストへの参照」となっている．広域スプリット検定ではリストは使っていないはずなのだが…⇒確かに，このオブジェクトは全く参照されていない．⇒いや，使われている．関数の中でクラスメンバー変数をわざわざローカル変数に置き換えているが，意味がないと思う．相手を呼ぶときは固有名詞で呼ぶべきだ．⇒対処した．
TRIBELIST::CheckSymmetricSplitとTRIBEBOX::CheckTribeSplitはほとんど等価なのではないか？どちらもLISTを使っているが，なぜリストが固有データ部を使っているのかという理由も分かる．動機はいま上で問題になっている非monoデータの参照に関係がある．2つのスプリットリストは連結問題をグラフを使わずに解いているが，確かに実際的にはこちらの方が圧倒的に効率的だ．グラフを使った場合には，最初に枝を生成し（頂点集合がすでに生成済みないし，枝を生成するときに同時に生成），次に連結成分分解を実行しなくてはならないが，スプリットリストの方法では最初に頂点集合を作ったあとは頂点集合自体が集結して最終的には連結成分そのものになるという手順になっている．
このようなことが可能になるのは，頂点と連結成分が同種のものと考えられるためだ．つまり，頂点は区間であり，連結成分も区間になる．しかし，通常は連結成分は頂点の集合であり，頂点そのものではない．言い換えると元と元の集合が同じ形式で表現可能ならスプリットリストのような手法が適用できる．少なくともTRIBELISTのスプリットリストとTRIBEBOXのスプリットリストは共通関数によって生成されるようにすべきだろう．多分それほど難しくはないのではないかと思う．グラフを使わずにグラフ問題が解けるというのはある意味おもしろい．
◎全体図という部分図を既定で生成する．