開発用に使っているDドライブの空き容量が逼迫している

開発機で開発用に使っているDドライブの空き容量が逼迫している.1月分のバックアップはEドライブに移動したが,まだ赤いままだ.CとEはそれぞれ100GB程度の空き容量があるので,余裕だが… リリースバージョンをEドライブの公式リリースに移動した.まず,ともかくログの読み直しを片付けてしまうことにする.開発を再開した去年の12月まで戻る必要がある.それ以前のログも整理する必要はあるが,そこまでは手が回らないので後日とするしかない.

昨日の「キーワード『秘』でエクスプローラ検索」したときの結果に関しては,マイクロソフトの検閲というより,単純な誤動作(読み間違い)の可能性もある.エクスプローラ検索でファイルコンテンツ検索するときは,プレーンテキストとして読み込んでいる様子で,アプリケーションで生成された複合文書ではデコードに失敗して誤読する可能性は高い.つまり,意味のない結果が表示されているものと見られる.

なぜだろう.要対処項目の入った記事を更新して余分な改行がすべての段落に入ってしまった.要対処項目リストはこのあとも編集が必要なのでその部分だけ切り取って別記事として投稿しておくことにしよう.

一応2021-12-11まで読み戻った.要対処項目は125件ある.これらを対処済みを除いてゼルコバの木関係とコラッツ関係に分類し,さらに,直ちに対処,後日などの対処法によって再区分して今後の作業の段取りを組み立てなくてはならない.当面の目標は「コラッツ銀河高速道路系」のリリースであり,そのためのマニュアル編集だが,その前に片付けなくてはならないことを整理しておく必要がある.⇒要対処項目125件を以下のように整理した.

  1. 外部項目 31件
  2. 改修履歴 1件
  3. 解決済項目 3件
  4. 仕様/マニュアル/テスト項目 29件
  5. ゼルコバの木項目 47件
  6. コラッツ木項目 12件

今後の方針としては,①コラッツ銀河高速道路系を仕上げる,②マニュアルを仕上げる,③ゼルコバの木コラッツ特注版をリリースする,のような展開を予定.着手し易いところから片付けてゆくことにする.

A面で検定中に仮想木モードに切り替えができてしまう⇒B面ではEnableDisableという関数で一括操作しているが,A面はそのようなものを持っていない.⇒対処した.

A面で仮想木を生成中にStopを押して,GoonFlagが落ちていたため,CollatzStreaming ONという理由で停止した.⇒実行中に入力ボックスの内容を変更したためだ.パラメータを変更すると本来停止するようになっているはずだが,停止せずにフラグだけ落としているためと思われる.実行中は入力できないようにした方がよい.⇒対処した.

A面でHideを押して実行が停止してしまう.⇒この動作はかなりおかしい.Hideでは出力枠を不可視にしているだけなのだが…⇒いや,動作はしているが,画面が更新されないため動作していないように見えているだけだ.⇒対処した.

日数の表示をDD.HH:MM:SSではなく,DD,HH:MM:SSとする.ピリオドの代わりにカンマを使う書式はどこかで見たのだが,どこで見たのかは忘れた.ちなみに,検証テストで2^32を仕掛けると70日という予定工期が出る.2ヶ月と10日だ.⇒日付文字列を生成する関数を作って呼び出すようにした.2^32では70日ではなく,170日という数字が出ている.「検証テストが当初より5倍遅くなっている」というのは70日と2週間を比較したものだが,170日だとすれば10倍以上遅くなったということになるのだが…⇒検証テストが遅いという問題は別途調査する.

▲VerifyTest.csvがロック状態になっている.

枝番号リストにInt16を超える数値を入力できてしまう.⇒処理中にチェックして,範囲外の場合はメッセージを出して処理を中断する.実際,そこまで大きい枝番号を与えられても処理しきれない(時間がかかり過ぎる).

▲大きい枝番号を入力すると処理の進行が見えない.カーソルに砂時計を出すという手もあるが…⇒なんらかの方法で処理が続行中であることが見えるようにする必要がある.


「秘」のキーワードでエクスプローラ検索してヒットするドキュメント

あちこち仕掛りになっているが,ともかくログの読み直しを始めた.要対処項目60件を拾い出したところでパスワードリストを秘匿するために仕掛けた検索でヒットしたPDFを読み始めたのはよいが,長文で最後まで読み切る前に眠ってしまった.パスワードリストをPCに残しておくのはよい考えではないが,逆にパスワードリストを紛失すると目も当てられないこともあるので,安全のためにあちこち分散させておくという考え方もある.一応この件に関しては完全に整理がついたのではないかと思うが,その過程で奇妙なことに気づいた.

エクスプローラの検索で「社内秘」ないし「秘」のキーワードで検索すると,ファイル名にもファイルのコンテンツにもそのような文字列が含まれていないドキュメントがヒットする.どうもこれらのドキュメントをマイクロソフトはある種の「機密文書」と推定しているのではないかという懸念だ.つまり,MSは文書を検閲しているのではないか??必ずしもすべてではないが,このようなファイルは別の安全な場所に移動した.ログの読み直しを続けることにしよう.⇒要対処項目のリストアップは分散を避けて昨日のリストで続けることにする.

▲開発機にゼルコバの木をインストールして起動したところ,エラーが発生した.TribeBox::ComopleteTribeBoxで発生するエラーが止まらない.⇒開発環境では発生していない.サンプルはCollatzTree  1-3-7 382.ZELだ.⇒この間ずっとデバッグモードでテストしていて,リリース版を一度も起こしたことがなかったのだろう.バージョンを上げてインストーラを作っておこう.Version 2.2.1.004 Release 2022-02-19 とした.⇒新しいバージョンをインストールしたが,アイコンをダブルクリックして起動すると古いバージョンが立ち上がってきた.プログラムと機能で見るとアプリの重複登録は発生していない.⇒一度アンインストールして再インストールで正常動作するようになった.

作業用にOpen Live Writerを2つ立ち上げていたが,気付かないうちにもう一つ開いていた.しかも「真っ赤」だ.

image

このパネルのタイトルバーをつかもうとすると,以下のパネルが出てマイクロソフトにレポートを送ろうとする…

image

タスクマネージャで見ると,確かに同じアプリが3つ走っている.明らかにマイクロソフトからの「警告」であるように見受けられる.他に何ができる訳でもないので,とりあえず閉じておいた.

▲CollatzChain.csvを読み込んでエラーが発生する.Get the Sequenceに129という値を与えたときの出力だ.エラーを無視して描画は可能.とりあえず,シューティングしてみよう.

image

エラーはCheckAtypicalMarriage→AddSameChainで起きている.この関数には「基本世代枠リストの世代別人名リストに登録する」という説明が付いている.⇒デバッグモードではエラーが収まらない…どうもフェーズ操作で誤っているように思われる.いや,ここの論理はかなりおかしい.GENEBOXに空を代入した直後にそのオブジェクトを使っている.しかし,修正を入れてもまだエラーは収まらない.これはちょっと精査が必要なので明日ということにしよう.⇒このエラーは要対処項目の#80に出てくる「GENELIST:AddSameChainで世代枠が空」というエラーとまったく同じだ.ここには「後日デバッグ」と書いてある.

▲検証テストで一般木と仮想木のダンプの内容がまったく異なる.一般木ではダンプしていないのに,仮想木では大量のダンプを出力している.なぜか?また,以前の記録(2022/01/19)では2^32で2週間を要するとなっていて,70日よりも大幅に小さい.5倍遅くなっている…


zelkova-treeとayanetのアカウントでメール送信できないという不具合

昨日はカスペルスキーの「このパスワードは流出しています」に対処するために丸一日潰れてしまった.というか,まだ一部片付いていない,と言うより,新たな問題が発生してしまった.これまで読み書きできていたメールアカウントが使えなくなっている.zelkova-treeとayanetのアカウントだ.どちらも受信はできているようなので,アカウント登録上の問題ではないように思われる.zelkova-tree.netのアカウントからメールを送信すると,「送信しています」の状態のままタイムアウトすらできないという事象が起きている.

ayanetのアカウントからの送信では送信サーバの認証方式の違いによっていろいろな応答が返ってくるが,典型的なものは「コマンドがrejectされました」というものだ.外部接続用に使っているフロントエンド機のOSをクリーンインストールしてThunderBirdを再インストールしているので,なにか見落としがある可能性も考えられるのだが…ayanetのアカウントを復活させたのはつい最近なので,先にzelkova-treeの方を調べてみよう.zelkova-treeのアカウントを復活させた時期のログを再読しようとしてエクスプローラで「検索」を試みたが,ヒットしない.

ログをアップロードするのにOpen Live Writerを使っている最大の理由はファイル検索ができるという点にある.以前は,ファイル名ではなくファイルの内容で検索できたのだが,ある時点からそれができなくなっている.いまでもコンテンツを検索するオプションは存続しているのだが,実質的に動作していない.検索インデックスもフォルダを指定して作り直ししてみたが,結果はCドライブの空き容量がゼロになっただけで何の効果もなかった.Cドライブの空き容量ゼロというのはかなりまずい.というか,これでは何もできない…まず,この問題から解決するしかないのではないか?

ファイル検索ユーティリティというのがある.手始めにGlarysoftというところのQuick Searchを導入してみよう.⇒しかし,そのためにはまずCドライブを空ける必要がある.OneDriveをアンインストールしてインストールできた.このツールはどうもフランス製のようでしかも,追加のソフトウェアを黙ってインストールしようとしたりするので,止めておこう.⇒エクスプローラのファイル検索機能を再確認するために以下のURLをチェックしたところ,どうも外付けドライブ(SDG)ではコンテンツ検索はできないようだ.

https://www.partitionwizard.jp/partitionmagic/file-explorer-search-not-working.html

検索が必要なのはOpen Live WriterのMy Weblog Postsだけだが,2.40GBある.これをCドライブに移すには相当なファイルを削らなくてはならない.OneDriveをアンインストールして場所を空けた.Draftだけをコピーしてテストしてみた.結果はNo Goodだ.最初だけ少し全文検索をしているように見えたが,そのあとはファイル名の検索に戻ってしまっている.エクスプローラの検索ではフォルダ(ないしドライブ,ないしファイル種別)ごとにコンテンツ検索を指定することができるが,実際の動作は「プレーンテキスト検索」になってしまっているようだ.昔は,ファイルの拡張子とデフォルトアプリを結合させてやると,そのドキュメントをきちんと検索できていたのだが,現在の仕様は完全にその位置から撤退してしまっているように思われる.

全文検索とはUNIXのGREPに相当する機能だが,①エンコード特に日本語のエンコードの解析が難しい,②内部にテキストを含む拡張子を持つファイルはデフォルトアプリでしか読めないため,一般にリリースされている全文検索ツールでは,ごく一部の代表的な拡張子しかサポートされていない.残念ながらOpen Live Writerの*.wpostをサポートしているツールを見つけることはできなかった.Open Live Writerはオープンソースのはずなので,こうなったらソースコードをダウンロードして自前で検索ルーチンを作るしかない.

それ以外の選択肢としては辛うじて,Googleのサイト検索が残っている.昨日試したときはあまり思わしい結果でなかったのだが,見落としていたい可能性もある.Googleのサイト検索はインデックスが生成されていないとヒットしないと言われているが,今日テストしたところでは昨日の投稿をピックアップすることができたので,多分使い物になると思う.2018年末から現在までのログはすべてテント村にあるので,この範囲ならGoogleで検索できるのではないだろうか?⇒この件に関してはそういうこととして,先に進もう.

ちょっと時間つぶしになってしまうが,直近のログを一度読み直しておいた方がよいのではないだろうか?バックログの拾い出しというのは基本ルーチンであるし,12月に作業再開してからもかなりの時間が経過している.その前に無駄な領域を消費しているエクスプローラの検索インデックスを削除しておこう.コントロールパネル→異インデックスのオプションで操作できる.⇒「13個のインデックスが作成されました」に変わった.これ以下にはできないようだ.Cドライブの空き容量は1.23GBになった.不十分だが仕方ない.

余分な情報が飛び込んでくる

ポリシーを変更して,開発機を常時ネット接続しておくようにしているので,いろんな余分な情報が飛び込んでくるようになった.まず,Windows 11がインストールできるようになったという勧奨がマイクロソフトから入ってきた.とりあえずパスしておく.カスペルスキーは103個のパスワードが弱いという点を指摘している.強度の低いパスワードは基本的捨てパスワードなので問題ないとは思うが,それ以外に,セキュリティ上の問題があるパスワード9件というのがある.これらのパスワードは不正流出しているということなので調べてみよう.

  1. entry.uqmobile.jp Yahooメールアカウント ⇒ 回線が混み合って…
  2. My Uqmobile B205011433 ⇒ 現在,回線が混み合っております
  3. bizhint.jp Gmailアカウント ⇒ 退会
  4. Ja-Jp Facebook zekova-treeアカウント ⇒ アカウント不存在
  5. localhost xoops ⇒ 自家サーバが立ち上がっていない
  6. www.parasol.anser.ne.jp Kanimal0522 ⇒ しばらくして,…
  7. com.facebook.katana  Gmailアカウント
  8. com.faceboook.orca   Gmailアカウント
  9. www.parasol.anser.ne.jp Yahooメールアカウント ⇒ しばらく…

UQモバイルに関連するものが2つ,Facebookに関係するものが3つ,parasolに関係するものが2つ,あとは,XOOPSとBizHintだ.BIZHINTからは退会した.XOOPSは自家サーバをインストールしていないためアクセスできないので,当面放置.UQモバイルは現在使っているスマホの最初の契約だと思うが,すでに契約解除してSIMも廃棄しているので実害はないと思われる.UQモバイルの上記2つのサイトにアクセスしてみたが,どちらも「現在混み合っておりますので…」という表示になった.コールセンターならわかるが,ネット接続でアクセス不可能なほど混み合うということがあるのだろうか?あるいは,もしかするとこの流出が原因で問い合わせが殺到している可能性もある.だとしたら,多分ニュースになっていなくてはならないはずだが…

parasol.anserとは何だろう?こんなサービス使ったことがないような気がするが…サイトにアクセスするとこちらも「調整のためお取引の連絡ができなくなりました.しばらくして,あらためてお取引願います.」という表示になった.⇒AnserParaSOLというのはNTTデータの個人向けインターネットバンキングのようだが,使った記憶がない.このURLはフィッシングによく使われているようなので,その可能性もある.このパスワードはすでに廃止して使っていないとは思うが…

残ったのはFacebookの3件だけだ.項目3のzelkova-treeのメールアカウントの流出は前から出ていたような気がする.パスワードはすでに変更してあるはずだが…いや,このメールアカウントは使った記憶がない.Facebookで使うために作ったものだろうか?まず,もう一度このメールアカウントを復活させるところからやらなくてはならない.

com.facebook.katanaというのはFacebookのモバイルアプリのようだ.com.facebook.orcaというのはやはりモバイルアプリでfacebookのメッセンジャーに相当するもののように思われる.スマホにはこのパスワードが残っている.使われているのだろうか?FacebookアプリとMessengerアプリを再インストールしてみよう.多分コンテンツは削除されずに復活できたはずだ.⇒削除ではアンインストールにならないのだろうか?アプリストアでは更新と表示された.⇒更新ボタンを押したが,保留中から抜けてこない.povo1.0で24時間使い放題を購入したが状態変化なしだ.通常は即座にスピードアップしていたのだが…⇒アンインストールして再インストールしたが,やはり保留中の状態が続いている…スマホでFacebookが使えないとかなり痛い.

不要なアプリや動画,巨大ファイルなどを削除して空き容量6GBを確保したが,まだ「保留中」から抜け出せない.⇒このアプリはWiFi接続がないとダウンロードできないのではないだろうか?Facebook Liteというのも試みてみたが,同じだ.⇒インストールできた.Google で設定→ネットワーク設定→アプリのダウンロード設定→ネットワークの指定なしに設定,同様に,アプリの自動更新もネットワークの指定なし,動画の自動再生もいつでも動画を自動再生に切り替え.⇒これで保留中のダウンロードが一掃された.Facebookに関しては2つのアプリを再インストールしたのでパスワード上の問題は存在しないはずだ.もう一つ,zekova-treeのメールアカウントが流出している件に関しては,このアカウントをもう一度復活させて確認しておこう.存在しないアカウントを悪用することは原理的に不可能だとは思うが…

2^11コラッツ亡霊木をインポートできない

2^11の検証テストを実施して出力したCSVをゼルコバの木にインポートできない.リリースモードではエラーを無視して最終的にShowUnderWearまで進むが,画面は真っ白で何も見えない.デバッグモードではそれ以前にほとんどハング状態になってしまう.昨夜デバッグモードで走らせた状態で放置しておいた開発機では,衝突検定ループカウントオーバーを長時間反復したあと,三極検定レッドラインオーバーで停止している.ゼルコバの木の標準仕様では最大カード数1000点というところを6000点まで増量しているので,キャパ的にすでに限界という感じではあるが,なんとかこのくらいまではクリアしておきたい.

描画に要する作業域のサイズには制限がある.この制限はおおむねInt32の上限程度と見られるが,それを超える場合には生描画に切り替わることになっている.もう一つの対処法としてズーム倍率を下げることが考えられる.実際,「このサンプルはxx%以上に拡大することができません」のような表示が出る場合もある.xx%というのは100%より小さい数字だ.コラッツ亡霊木のような巨大木を描画するための特例として最初からズーム倍率を下げておくということも考えられる.それによって動作に変化が見られるかどうかは未定だが,効果を確認しておきたい.

デフォルトズーム倍率を導入して1.0以下のズーム倍率で初期表示できるようにしてみたが,これまで開けていた2^10が開けなくなった.衝突検定でループしている.⇒CheckMargPointでエラーを無視していた.⇒動作するようになった.2^10ではD=6, H=66だが,2^11ではD=6, H=87になる.現在ズーム倍率1%に設定しているので,十分開けるサイズだ.結婚点不一致のエラーはまだ出てこない.この不良は描画領域サイズに関係していた可能性もある.BuildSameGeneMarriageGraphで時間を空費しているようだ.まだ描画フェーズまで達していない.

サンプルは単純な木なのだから,重婚検定などはパスできるのではないか?少なくともこのサンプルには重婚者は存在しないのだから,重婚グラフ検定自体無用と思われる…⇒すでにメインループは抜けて出口検査にかかっているようだ.これがあとどのくらい続くのかはわからない…プロセスメモリは500MBを使い切っている.再起実行される部分もあるので,スタックもぎりぎりで動いているようだ.⇒いや,スタックオーバーフローが出ている.⇒スタックサイズを1GBまで増加させたが,またスタックオーバーフローになった.⇒描画できた.

コラッツ亡霊 3236

お化け柳と呼ぶに相応しい風情だ.このサンプルはD=8, H=96,3236点だ.もう一つ上の2^12に挑戦してみたところ,また「インデックスが配列の境界外です」になった.⇒データ数が6510になっている.カード数上限を7000まで上げてみよう.


AYANETの冷たい森へのアクセスが復活した

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をインポートすると,「インデックスが配列の境界外です」というエラーになる.

image

エラーが発生した時点で抜けるようにすると,今度は描画領域空というエラーになる.⇒エラーの根本原因はVBの最大カード数が古い値のままになっていたという点にあるが,処理を打ち切っても描画できないというのは問題だ.デバッグモードでは重婚グラフ検定に嵌って抜けてこない.リリースモードでは先に進んでいるようだが,Bobject::originateでエラーが発生する.このエラーからは回復できない.

エラーを無視して走らせたら,「結婚点一致検定ループカウントオーバー」で停止した.続行するとShowUnderWearになるが,画面は真っ白のままだ.ゼルコバの木の限界が露呈したという感じになっているが,なにか打つ手はあるだろうか?⇒デバッグでヒープサイズに1GBを割り当ててみたが変化は見られない.コミットサイズも増量してみたが影響しない.CheckMargPointのエラーを無視するようにしたら,今度はheapBranchで停止するようになった.

マシーン2台のOSをクリーンインストール

2日続けてマシーン2台でOSをクリーンインストールした.有償のウィルスチェッカーが使えない時期にはOSの再インストールは日常茶飯事だった.最近はしばらくやっていなかったのでかなりのストレスを覚えたが,なんとかこなして作業完了した.ゼロトラストの時代,OSの再インストールは完全ルーチン化して,毎日の部屋掃除の感覚で片付けられるようにしなくてはならない.開発機と予備機は用途も性格も異なるので,再配置するアプリもほとんど重複しない.開発機では個人データは温存したが,サブ機では累積していたゴミを一掃することを目的に完全にサラの状態に戻した.何点かつまづいたところを書き留めておこう.

  1. 開発機にはVS2017とVS2019をインストールした.VS2017はゼルコバの木開発用,VS2019は銀河高速開発用だ.VS2017にはインストーラ開発用の拡張機能を別途インストールする必要がある.また,Visual C++ MFCも追加インストールが必要になった.
  2. サブ機のインストールでは英語キーボードになってしまって,日本語キーボードがしばらく使えなかった.これを切り替えるためには,設定→時刻と言語→言語→日本語→オプション→ハードウェア キーボードレイアウト→レイアウトを変更するで日本語キーボード(106/109キー)を選択する ここで,日本語→オプションが出てこないので苦労した.
  3. サブ機ではデバイスマネージャ→キーボードにHIDキーボードデバイスというのが5つ入っている.また,ほかのデバイスというところにも不明なデバイスが5つ出ているのも気になる
  4. ThunderBirdの登録アカウントをあらかじめエクスポートしておくべきだった.⇒エクスポートという手続きはないが,C\Users\<ユーザー名>\AppData\Roaming\Thunderbird\profilesにあるファイルをバックアップ→復元で移行できる.
  5. AYANETのメールサーバーへの接続でエラーが出る.SSLはしないとなっているが,証明書は発行されているようだ.STARTTLSとなっていたので,SSL/TLSにしてみよう.⇒通ったようだ.⇒いや,通っていない.やはり「なし」にしないとダメなようだ.しかし…
  6. zelkova-tree.netの2つのアカウントの登録でエラーが出ていた.実際受信でタイムアウトになる.これまで動作していたし,設定には間違いはないと思うのだが…⇒漏れがあった.認証方式が設定されていなかった.⇒受信できるようになった.
  7. Yahooから過去メールが2千通くらい入ってきた⇒Yahooはpopで取っているが,ダウンロード後2週間はサーバーに残すという設定になっているため,2週間分のメールが入ってきたものと思われる.
  8. アプリ20本以上をダウンロード→インストールしているが,ダウンロードしたセットアップファイルを保存しておいて次回使い回すことができる.更新はアプリを導入してからでもできる.
  9. CCleanerをインストールしたついでに,CCleaner Browserもインストールしてみた.かなり速そうな感触はあるが…
  10. プリンタ周りはまだインストールしていない.
  11. Open Live Writer 最初のころのレイアウトが復活した.前回はもしかしたらマイクロソフトサイトからダウンロードしていたのかもしれない.
  12. サブ機のドライブの空き領域は現在2.13GBしかない.結局,大して拡げることはできなかった.多分これ以上アプリをインストールなどのことはないとは思われるが…かなり窮屈だ.


image

「証明書の表示」をクリックすると,https://sectigo.com/legal にジャンプする.


image

ある範囲の奇数ノードを含む極小のコラッツ木を生成できるようになった

昨日開発機に仕掛けた2^24の検証テストはすでに完了しているが,制御が戻ってこない状態が続いている.多分ゼルコバの木にエクスポートするためのファイルの整形に時間が掛かっているためと思われるが,少しかかり過ぎのような気もする.テスト自体は7時間10分掛かっている.⇒デバッグ用のダンプ出力を止めることでほぼ妥当な時間で完了できるようになっていたはずなのだが,その前の版を使っているのだろうか?いや,開発環境から直接走らせているのでこれが最新版だ.

デバッグの一時停止も効かない状態だ.「デバッガー操作に予想以上に時間が掛かっています」を表示したままのハング状態だ.デバッグ中止ボタンも効かない.アプリを強制終了するしかなさそうだ.パネルが隠れていてOKボタンを押せなかったためかもしれない.すでにアプリを落としてしまったのでどうしようもないが…エクスポートファイルのサイズが大き過ぎる.22.9GBもある.これでは時間が掛かっても当然だ.VerifyTest.CSVは読めないので一旦捨てるしかない.

コラッツ銀河高速道路系に含まれる5機能すべてで隣接リストのCSV出力とゼルコバの木へのエクスポートができるようになった.特に,検証テストの結果をゼルコバの木にインポートできるようになったというのが目玉だ.これまでの出力はすべて正則木だったが,検証テストではある範囲の奇数ノードを含む極小のコラッツ木を生成できる.たとえば,1~511までの奇数を含むコラッツ木は以下のようなものになる.

ゼルコバの木最新版をリリースしてインストールしたが,起動時に「パラメータが間違っています」のエラーが出る.最大カード数を6000に増量した版なのだが…とりあえず,アンインストールしてインストールし直してみる.⇒タスクバーに古いバージョンのアイコンが残っていたためと思われる.再インストールして起動するようになった.しかし,動作が少しおかしい.タスクバーのアイコンが白くなっている.アプリのタイトルバーのアイコンやデスクトップ上のアイコンは問題ないのだが…⇒古いアイコンがリンク切れになっためだろう.

image   image   image

もう少し小さいサンプルを取ってみよう.小さいと言ってもこんなものになってしまう.これは1~127までの113点サンプルだ.一番右のサンプルは1~31の53点サンプルで,長い鎖の終端は27という奇数だ.一番左の図などは,「コラッツというゴースト」がどのように見えるかをもっともよく示すものと言える.下図は1-3-4 仮想正則コラッツ木だ.

image

仮想木の場合は,完全正則木を出力することができる.上のコラッツゴースト図と比較するとその差が鮮明にわかると思う.つまり,「コラッツ木というかつて人々を悩ました亡霊」はいまや完全にアンダーコントロール状態にあると言える.

現在ゼルコバの木は最大カード数6000という設定で運用しているが大きいCSVファイルをインポートしようとするとエラーが発生する.まず,これを見ておこう.

検証テストが遅くなるという難題が解決した

検証テストが遅くなるという難題がようやく解決した.この問題をややこしいものにしていた原因の一つは,.NET 5.0が生成するEXEやDLLのファイルサイズがほとんど変化しないということがある.これまでのプログラミングでは一行コードを書き換えればそれが敏感にファイルサイズに反映され,それによって「改ざん」などのリスクを回避することもできていたのだが,ここまでファイルサイズが無変化ということになると,そのリスクはかなり高いものになってしまうような気がする.少なくともカスペルスキーなどでは見落とされてしまう可能性は高い.

検証テストはリリース版で2^13の設定で10秒罹っている.以前は3秒で完了しているので多少遅くなっていることは確かだが,2分近くかかっていたことを考えればおんの字だろう.コラッツ銀河ハイウェイは完成に近づきつつある.あと残っているのは主に表示に関わる修正と,CSV出力だけになった.多少面倒だが,波乱なく進めることができるだろう.

まず,最初にコラッツ木生成で大きなDを与えたとき,Max tree heightやMultiple of 3がほとんど変化しないという問題を片付けよう.Multiple of 3(3の倍数)という用語も今後は”triple”という語で表現したいと思っているので,それも合わせてやっておくことにする.⇒通常 triple number というのは111とか777のような数字の並びを意味しているようなのでちょっとまずいのかもしれない.⇒現状のままとしておこう.⇒対処した.統計情報の更新をすべて子ノードを展開するところで実施するようにしたので,ルートノードだけ別扱いする必要が生じた.仮想木ではノード1のところで発生する無効ノードカウントはここでまとめて処理するようにした.あとは,マニュアルを書く時点で詳細チェックすることにして,最後のCSVファイルへの書き出しに進もう.

Open Live Writer をオープンできない

Open Live Writer をオープンできない.An unexpected error happened というメッセージパネルが出ている.スクリーンショットを取ってJPGで保存しておいたのだが,それを開くこともできない.パネルにはSend MessageとContinueという2つのボタンが付いているが,どちらも作動しない.時間が経つとこのパネルは消えるが,何度やってもOpen Live Writerを起動することはできない.

やむを得ず,もう一度本家サイトからダウンロードしてインストールした.問題はこれで一応解決したのだが,数日前からカスペルスキーでアプリ更新しようとして失敗するという状態が続いていたのと関係あるかもしれない※.アンインストールしないで再インストールしているので,設定などはすべて温存されていたようで,何も言わず黙ってこの画面が開いた.とりあえず,問題なく動作している,ようだ.

※これは勘違い.アップデートできなかったのはLibreOfficeだ.

検証テストの実行速度が極端に落ちている問題を解決しなくてはならない.状況はある程度までつかめたが,ある意味でいよいよわからなくなってきたという感じもある.これまでわかったことを整理しておこう.開発環境はVS2019のVBを用いている.

  1. 異変は「仮想木」を実装して動き始めた時期と重なっている.具体的には2月8日から9日のころで,障害はすでに8日の午後5時ころには発現しているが,それに気付くのはだいぶ時間が経ったあとで,その後も作業を継続していた.
  2. この時期にはすでに,仮想木の実装は一段落してコードの整理に着手していたので作業量が膨大かつ慎重を要するものであったため,8日だけでバックアップを5回,9日には3回バックアップしている.
  3. 9日にはフォルダ名やアセンブリ名をCollatz Milky Highwayに変更.
  4. 当初は,スタックオーバーフローに対処するために開発プロジェクトのポストイベントに組み込んだスタックサイズ変更のためのスクリプトに関係しているのではないかと推定,スタックを大量消費するA面のコラッツ木生成などには影響が出ていないため,この推因は放棄された.
  5. 正常動作している版のバックアップが2つある,一つは8日の午後2時に作ったBACKUP1と午後9時に作ったBACKUP4でそれ以外は全滅.
  6. BACKUP1に残っているリリース版のEXEは正常動作しているが,BACKUP1のコピーをリビルドして生成したEXEでは事象が発生する.
  7. BACKUP1のコピーをリビルドした版をREBUILD1とする.BACKUP1(のコピー)にREBULID1で生成されたモジュールを1個づつ移植して動作チェックしたところ,CollatzMilkyHighway.DLLが不良の原因であることが突き止められた.
  8. この2日間ではソースコードの各処に相当量の修正が入っているが,EXEのサイズは一貫して202,752バイトでまったく変化していない.
  9. WinMergeのバイナリファイル比較検査を通してみると,これらのEXEには数バイト~の相違点があるが,それらを除けばほとんど同一
  10. バックアップをリビルドして生成したCollatzMilkyHighway.DLLのサイズはBACKUP0では218,624で正常動作するDLLと一致しているが,BACKUP1では異なる値217,600になる.このDLLでは事象が発生する.

これらのことから推定されることは,①.NET 5.0ではマネージドコードのみを含むモジュールをEXEとして生成し,それ以外の部分はDLLに吐き出しているものと考えられる.これは効率を最優先するというポリシーによるものと考えられるが,これにより,EXEを見ていただけでは開発状況を把握できないという事態になっている.②EXEのサイズが不変なのでウィルス検査ルーチンはこのようなプログラムの改変を検出できない可能性がある.VBのソースコードである*.VBとEXEのコードは一対一対応しているというのはまったくの思い込みであり,実際には複数のDLLに分散配置されている.

問題はこのような事態にどう対処すればよいのか?ないしどう対処可能か?という点にある.BACKUP0をリビルドした版では正常動作するDLLと同サイズのDLLが生成されているので,まずこれが動作可能かどうかをチェックしてみよう.

ここまでをアップロードしようとして,以下のエラーになった.

image

どうもこのフロントエンド機は恒常的なディスク領域不足状態に陥っている模様だ.プログラムはCドライブに置くしかないので,外部ドライブに移動できるものは限られている.デスクトップ,ドキュメント,ピクチャなどをすべて空にしたが,空き領域はゼロのままだ…一度リブートしてみよう.⇒アップロードは失敗に終わったが,リブートしてここまでの記事は残っていた.Cドライブの空き領域は1.26GBにはなったが,赤い状態だ.もう少し拡げておかないと安定した作業はできない.しかし,もう削れるものはすべて削ってしまった.

どうすればよいか?あとできることは一時ファイルの削除くらいしかない.⇒全部削っても17.9MBしかない.ウィンドウズの更新プログラムのバックアップが削除できると多少は効果があるのだが…逆に累積更新プログラムのダウンロード中になってしまった.かなり無理なところまで削ったが,1.29GBまでだ.このマシンは何度もメーカーに出しているが,HDDもメモリも増設不可ということで対処できなかった.その代わりにSDカード256GBを使っているが,それも満杯になっている.

現在正常動作することが確認されているのは,BACKUP1に含まれるサイス218,264のCollatzMilkyHighway.DLLとサイズ202,752のCollatzMilkyHighway.EXEの組み合わせだけだ.しかし,リビルドして同サイズのDLLとEXEを生成するREBUILD0では症状が出てしまう.これはBACKUP1とREBUILD0に含まれるモジュールに差異があることを意味する.どこが違うのかチェックしてみよう.

  • BouncyCastle.Crypto.dll    3,318,504    3,318,504     ○
  • CollatzMilkyHighway.deps.json 3,669    3,669     ○
  • CollatzMilkyHighway.dll     218,624     218,624     ○
  • CollatzMilkyHighway.exe    202,752    202,752      ○
  • CollatzMilkyHighway.pdb    26,928     26,664     ○
  • CollatzMilkyHighway.runtimeconfig.dev.json 385  385     ○
  • CollatzMilkyHighway.rutimeconfig.json   260    154
  • Mailkit.dll   859,136     859,136     ○
  • Mimekit.dll  1,155,584       1,155,584     ○

サイズで比較すると差異があるのは,rutimeconfig.jsonだけということになる.これを差し替えて動作を見てみよう.⇒変化しない.⇒やはり,原因はCollatzMilkyHighway.dll にあるようだ.WinMergeで比較するとほとんど一致するところがないくらい違うという感じだ.しかし,逆アセンブリで見ると差異はそれほど大きくはないようにも見えなくはない.むしろ,前後のブロックの配置が変化しているのではないか?確かに,ロジックを整理するために前後関係を入れ替えたりなどのことをしていたかもしれない.もっとも肝心な点は正常動作しているときのソースコードを確定することだ.いまのところリビルドして正常動作するバージョンは見つかっていない.

いや,もしかすると手順を間違えているかもしれない.BUILD0は動作しているようだ.もう一度作り直してみよう.⇒いや,やはりできていない.スタックサイズが違う.DLLのスタックサイズは設定していないのだが,合わせてみた.⇒結果は同じだ.というか,BUILD0としているのは実際にはBUILD4のあとなのではないか?BACKUP1の直前はCollatzProject 2022-02-07-1なのではないだろうか?まず,先に2022-02-08-1をもう一度リビルドしてみよう.

ようやく,リビルドで高速動作する版を見つけた.CollatzProject 2022-02-07だ.この一つあとの2022-02-07-1では実行時にエラーが発生してしまうため,テストできない.ともかく,ここまで戻って何が実行速度に影響しているのかを確認しなくてはならない.2022-02-07-1はエラーが出るので,2022-02-07と2022-02-08-1を比較することにしよう.⇒無数と言ってよいくらいの差異があるが,本質的な点がどこにあるのか探る必要がある.

  1. MAXDUMPTEXT 4096 ← 2048
  2. Truncate Truncate ← Trancate
  3. CutTextBuffer 新設
  4. RichTextのスクロールを抑制
  5. EnabelDisable関数 新設
  6. Hideボタン 新設
  7. 枝番号リストチェック チェックの場合はループ内で転記する

検証テストに関わる部分に限定すれば,時間に影響しそうなところと言えば枝番号リストの転記だけのように思われる.⇒確かにそのようだ.これで最新版まで戻ることができる.⇒動いた.以前は3秒で完了していたところ,11秒かかっているが,まぁ妥当なところだろう.これで難題は解決した.一旦バックアップを取って次に掛かることにしよう.もうほとんど出荷できるレベルに達している.あとはブラッシュアップするだけだ.一度ログを読み直しておこう.

枝番号リストを更新するような変更が入ったのは,巨大数のコラッツ数列を求めるとき,枝番号リストが処理終了まで空白になってしまうのを避けるためだ.検証テストのときに更新するのは時間のムダだが,コラッツ数列のときはむしろ表示した方がよいと思う.

GetTheSequenceでダンプを止めていると画面がフリーズして何も変化しない状態になる.これはTree heightを更新していないためで,最大数から下降しているため,数字が変化しない.このため,開始も終了もわからないような状態になっている.最大高を与える番号は確定しているが,高さは変化するようにした方がよい.仮想木では現在もそうなっている.⇒対処した.

一般木でMax degreeを与えるノード番号がかなりおかしい.これはおそらく個別検査時に更新しているためと思われる.検証テスト中はUpdate以外での更新は認められない.⇒戻るところを間違えていた.もう一つ新しいバージョンがある.やり直しだ.CollatzMilkyway 2022-02-09と2022-02-09 BADがあるが,後者は捨ててもよいだろう.

どこかやりそこなったのだろうか?ValidNumberとWXの不一致が発生して停止する.⇒WXをローカル変数に変えているためだ.この値はグローバルでなくてはならない.⇒再帰関数の呼び出して参照渡しするようにした.

現在の実装では枝数と高さはUlongで取っているが,さすがに大き過ぎるのではないか?マニュアルではInt16<=32767としているのだが,この辺りが妥当な線なのではないだろうか?実際問題として,最大枝数が8桁にもなると,べき乗の計算ですら抜けてこなくなってしまう.⇒Int16では少し小さ過ぎるような気がする.枝数列をInt16範囲内い抑えても,中間の計算でオーバーフローしてしまう.CountValidPostでInt16を超えているようだ.⇒Uintに変更した.設定はInt16のままとする.

▲A面では検定中に仮想木モードに切り替えができてしまう.⇒B面と同じようにアクセス不可としておくのがよいのではないか?それが一番簡単だ.

▲GoボタンがStopに切り替わらない.⇒動作しているが,応答が遅れているため入らないように見えている.⇒仮想木モードでは停止しないかもしれない.

一般木で樹高800を設定してスタックオーバーフローが発生する.少し早過ぎるような気がするのだが…高さ425で発生している.⇒CollatzTreeStructureで使っているローカル変数をグローバルに戻したが,効果なし.以前はheight=11111でオーバーフローしているので,800というのはまったくの番外だ.いや,開発環境では同レベルで発生していたようだ.あ,なるほどわかった.デバッグモードではスタックサイズの変更を実施していない.⇒マクロでDebugを指定することはできるが,実行されていないだけでなく,その文字列自体消去されてしまう.固定した文字列しか受け付けていないようだ.まぁ,この件に関してはこれで仕方ないものとしておくことにする.

▲DとHをそれぞれ最大値の32767に設定して走らせて,計算は進んではいるが,表示がまったく更新されない.これは,そのノードの現物を処理するまでは表示を更新していないためだが,子ノードを出力した時点で更新するようにした方がよい.H=3267ではボトムに達するまで何も表示が更新されない状態が続いてしまう.D=32767,H=1でも同じだ.有効ノードが1に変わる以外何の変化もない.