Open Live Writer の編集画面のレイアウトが以前の状態に戻ったことは喜ばしい．もとの状態というのはタイトル入力がページの最上部にあるという当たり前の状態だが，なぜか1ブロック下がったところに表示されていた．タイトル行を囲む枠も消えて，ブラウザに表示されるのと同じ体裁に見えるようになっている．
ことのついでに，デフォルトフォントを変えておきたい．Open Live Writerのオプションでは既定フォントを設定する項目は見当たらないが，これまであまり気にしたことがないのはなぜなのか？よくわからない．現在使っている版のデフォルトフォントCalibriが常用しているメイリオと違い過ぎるため目立つようになったのだろうか？
Writer（WindowsLiveEssentials）の既定のフォントを変更する
上記URLの記事によると，テンプレートフォルダにあるStyle.css を変更することで可能になるということなので試してみよう．⇒以下のテンプレートフォルダには小さなフォントの見本画像しか入っていない．
C:\Users\babalabo\AppData\Roaming\OpenLiveWriter\blogtemplates\0d331aae-b391-475d-b40e-8c6213e76f4b
解説記事の書き方ではこのビットマップがフォルダになっているように読めるのだが…サイトのテーマが読み込まれていないのだろうか？確か，インストール時に読み込むようになっていたはずだが，手順をパスしてしまったのかもしれない…Update themeで読み込みはできたが，状況は変わっていない…どうもよくわからないが，この件は後回し．
AYANETからFTPとメールアカウントのパスワード再発行の返信が届いている．AYANETでは自分でパスワードを変更することができない．平文でパスワードを送信しないとパスワード変更ができないというのははなはだ不都合だが，AYANET自体すでに更新が完全に止まって過去の遺物化しているのでいまさら仕様変更も無理だろう．
PHPが使えていればもう少し使っていたかもしれないが，脱皮しない蛇は亡びるとニーチェが言っている．AYANETのメールアカウントを復活させたのは，古い友人たち（数学圏）とのコンタクトを復活させる必要が出てきたためだ．何人と連絡が付くか？いや，一人でも残っていたらおんの字かも知れない．「パスワード再発行のお願い」を出したのが1月30日で，2月2日には応答が返っているのでAYANETとしては最速の応答と言えるが，こちらが対応できる体勢でなかったので今日まで遅延してしまった．ともかく返信しておこう．
AYANETのメールアカウトをSSLなしに設定してエラーは出なくなったはずだが，まだ続いている．いや，おかしい．今度はエラーが出ない．送信サーバーではSTARTTLS, 暗号化されたパスワード認証になっている．受信の方は，接続の保護：なし，認証方式：平文のパスワード認証になっている．暗号化されたパスワード認証で受信できるかどうかやってみよう．⇒問題なく通った．受信をSTARTTLSとするとエラーになる．受信サーバー設定をSSL/TLSにすると送信ファイルを送信済ファイルに保存できなかったというエラーになる．なしにしても同じだ．送信と受信の方式が違うというのはおかしいので，同じ設定で試してみる．STARTTLS 通常のパスワード認証は通った．パスワードの暗号化はできない．これでゆくしかないだろう．
AYANETから送信したメールが迷惑メールに落ちてしまう．これを防止するようにするにはどうしたらよいか？⇒確か，個人用アドレス帳に登録されているアカウントは迷惑メールにしないようになっていたはずだ．やってみよう．⇒動作しない．Outlookではサーバーで迷惑メールに振り分けているのだろう．これは避けることができないような気がする．outlookの設定で操作できる可能性はあるが…
開発機とサブ機の主要2機のOSを再インストールして，今後はクリーン度9…9を維持しようというつもりではいるのだが，ここで一旦ネット接続に関するポリシーを完全に逆転させることを考えてみたい．これまでは，ネット接続はもっぱらサブ機の任務で開発機は箱入り娘のように外部との接触を禁じるというポリシーで運用してきたが，この機会にむしろ開発機をしばらく外部にさらしてみようか？と考えている．OSのクリーンインストールはやり慣れてしまえばそれほどのものではなく（とは言っても，最小丸一日がつぶれることは覚悟しなくてはならない）日常的なハウスクリーニンの一貫として完全にルーチン化できる可能性が見えてきたということもある．
開発機を常時ネットから遮断しておくというのはかなりのストレスで，たとえば，F1でMSDNのオンラインヘルプにジャンプすることもできない．サブ機と開発機は頻繁な情報交換を必要とするが（たとえば，開発機のスクショをログに投稿など），そのたびにLANを切り替えるというのも相当な時間ロスになる．開発機を常時オンライン状態にしておくということは完全に下着で街に出ることに等しいが，それを試してみる必要があるのではないか？まだしばらくは公式リリースの日は遠いと思われるので，所内的には何が起こっても対応できるようにしておくというのがもっとも肝心なポイントだ．早速この新体制に移行してみよう．これが通れば作業のストレスが著しく緩和されることは確かであり，ある意味で理想の開発環境に近いものになると言っても過言ではない．
さて，今日の作業のポイントはゼルコバの木のデバッグだ．大きいCSVをインポートしたときに出るエラーを片付けておきたい．系図ファイルのアイコンをダブルクリックしたときの動作不良も見ておく必要がある．
▲検証テスト完了後，GetTheNumber，TruncatedTreeなどのボタンを押して異常終了してしまう．いや，GetTheNumberは正常動作している．枝番号リストに有効なデータが入っていないので，エラーパネルが出る．⇒対処した．
▲テーマが登録できない．テーマ登録は実行されているが，メニューに表示されないので選択できない．
検証テストで2^4まではエラーなしでインポートできる．カード数は170で，最大奇数は13121だ．2^5になると，CARDTABLE::makelinkのエラーが出るようになる．何度か同じエラーが出したあとは，描画可能になる．⇒なぜだろう？エラーが出なくなってしまった．デバッグモードではエラーが無視されているようだ．⇒STOP文が効かなくなっている．いつからだろう？多分VS2017に移行してからと思われるが，気付かなかった．STOP文は我々のデバッグ用ツールセットの中でも最強のツールなのだが…__debugbreakというのがあるようだ．多分代替物になると思う．<intrin.h>が必要だ
いや，どうも「一時的にStopを抑制する＠20201026」というマクロが効いているのではないか？⇒止まるようになった！
(nod->getpnum() != nod->cardbase.carddata.refnum && nod->cardbase.carddata.refnum <= tablesize)
という理由で停止している．tablesize=6000でrefnum=11だ．
これは，参照番号とテーブルのインデックスが一致しているという標準仕様に基づく動作ではないかと思う．テーブルのインデックス0は使われていないので参照番号が#1のとき，テーブルサイズは2になっているはずだ．しかし，現在読み込んでいるCSVデータでは通番ではなく，ノード番号を直接ノード番号として使っているため，このようなことは当然発生する．どちらでも動作するようになっているのだから，ここでこの検査を実施することは無意味と考えられる．⇒対処した．
ダンプが大量に出ているので，一部を除きほとんど止めてみたが，”CenteringCard Refnum=0” という1行が残ってしまった．おそらくOCXで出しているものと思われるが，切り替えることができない．これについてはあとで見ることにする．
▲ロード後修正されたファイルは保存のプロンプトが出るが，インポートされただけのものは保存プロンプトが出ない．
▲登録カード数1631というのはゼルコバの木的には特大サンプルだが，単系列の単純な木で描画までに3分掛かるというのはおかしいのではないか？
検証テストで2^11を超えるCSVをインポートすると，「インデックスが配列の境界外です」というエラーになる．
エラーが発生した時点で抜けるようにすると，今度は描画領域空というエラーになる．⇒エラーの根本原因はVBの最大カード数が古い値のままになっていたという点にあるが，処理を打ち切っても描画できないというのは問題だ．デバッグモードでは重婚グラフ検定に嵌って抜けてこない．リリースモードでは先に進んでいるようだが，Bobject::originateでエラーが発生する．このエラーからは回復できない．
エラーを無視して走らせたら，「結婚点一致検定ループカウントオーバー」で停止した．続行するとShowUnderWearになるが，画面は真っ白のままだ．ゼルコバの木の限界が露呈したという感じになっているが，なにか打つ手はあるだろうか？⇒デバッグでヒープサイズに1GBを割り当ててみたが変化は見られない．コミットサイズも増量してみたが影響しない．CheckMargPointのエラーを無視するようにしたら，今度はheapBranchで停止するようになった．