amory氏への返信

「パフォーマンスを優先」は多分最強だと思います.当方ではドスパラというメーカの廉価な Diginnos ノートPCをメインマシンにしていますが,まだ余裕なのでデフォルトのまま使っています.

わたしのマシンでは「電源オプションの最適化」という項目は見当たりませんが,プロセッサーの稼働率5%というのは論外という気がします.100%でよいのでは?と思いますが,このくらい気温が高くなってくると放熱の問題が出てくるかもしれません.

わたしのスマホはファーウェイです.わたしはこの会社の創業者を尊敬しているし,その娘の孟晩秋のファンでもあるので買い換えるつもりはありません.孟晩秋がパスポートを7枚も持っていたことから推定しても彼女がなんらかのスパイ活動に関わっていたことは確かですが…

真夜中の転送という事象はPCのごく初期のころから何度も経験しています.こういうときは即(PCないしルーターの)電源を落とすしかありません.(最初にこのようなことが起きたのは確かALEXという検索エンジンをインストールしたときのことです)

IMEが中国語に切り替わっていたとしても転送先が中国とは必ずしも断定できません.MS-IMEにはかなり疑問があります.少し使っていると「AI予測変換技術向上のため変換履歴を提供」することを求められるようになりこの動作をどうやっても止めることができないため,日本語入力をグーグルに切り替えたという経緯があります.これを承諾するとすべてのキー入力が盗まれることになり,もちろんパスワードも筒抜けになってしまいます.

多分20年くらい前のことではないかと思いますが,中国・ロシアなどから頻繁にスパムメールが届いていた時期があります.百度(バイドゥ,中国製検索エンジン)がいろいろなソフト製品にバンドルされて付いてきた時代ですが,わたしは絶対にインストールしないようにしていました.(だいぶ以前というのがこの時期のことであるとすれば,それは中国軍のハッカー部隊が活発に活動を開始した時期と見てよいと思います)

ファーウェイはいまのところOSを持っていませんから,ファーウェイ製品にバックドアが付いているというのは明らかなデマだと思います.(もちろんハードウェアにバックドアを仕掛けることはテクニカルには不可能ではありませんが,すぐばれてしまいます)主たるソフトウェア製品(ルーターを含む)にはなんらかの意味で(バックドアはフィードバックの一種と考えれば)バックドアが付いていると考えた方がよいと思います.

カスペルスキーはスイスに「国際的な検証センター」を設けて第三者によるソースコードの検証を可能にしています.もし,信頼できるところが地上に一つも存在しないとしたらネット上で活動することはほとんど不可能です.もちろん,このことはわたしがカスペルスキーを100%信頼しているという意味ではありませんが,少なくも現時点においてはカスペルスキーに一任する以外の選択肢はありません.

たとえば,マカフィーは非常に良心的な信頼できる会社と評価していますが,弱過ぎます.サイトを復活させたときのドタバタはご記憶のことと思いますが,このときのウィルスを検出できたのは(有力ウィルス対策製品5種のうち)カスペルスキーだけでした.

ファーウェイはつい最近「個人情報の取り扱いに関する契約条項の変更」を通知してきました.原文はいま手元にありませんが,「場合によっては個人情報を中国政府に引き渡す場合がある」のような条項です.(このような条項は既存のほとんどのソフトウェア製品の契約文書に含まれています)しかし,行間にはそれに対する抵抗感(可能な限りそれに対抗する意志)がにじんでいるようにわたしには感じられました.

Edmaxってかなり使い易そうですね.フォルダをコピーするだけでバックアップできるというのがいいですね.わたしはずっとOutlookを使っていますが,メールボックスを何度も壊されてそれを復旧するのに四苦八苦しています.Yahooメール→Edmaxという2段シフトという使い方は独創ですね.確かにこれならかなり安全度が高いような気がします.

言語バーが消えるという事象は経験したことがあるような気もしますが,少なくともグーグル日本語入力に切り替えてからは安定動作しています.

最近床の張替えをやりました.既存のフローリングの上にビニール製のシートを貼ってゆくだけで半日くらいで終わりましたが,製品の質には感動しました.東レ製です.(接着剤を含めて)プラスチックスのことを知り尽くしているという印象を持ちました.

アップルのシェアは小さいのでいまのところPC用のOSはUNIX系を除けばマイクロソフトしかありません.グーグルはファーウェイにAndroidを供給しないと通告しファーウェイはその代替品の開発を進めているということなので,将来的には中国製のOSが登場する可能性はありますがそれもあまり歓迎すべきものであるようにも思われません.BTRONが外圧によって潰されたというのは人類史的な損失だったのではないかと思っています.

こちらでも同じ現象が発生します.少し時間をいただくしかなさそうです.

なかなか本調子に戻れませんが,ぼちぼちと.

馬場英治

amory氏から叱責のメール

午前7時起床,晴れ.朝食は冷やしサラダうどん.サイクリングで外に出ただけで他には何もしていないのにこの時間(午後9時)だ.いや,今日はたっぷり昼寝している.ともかく暑かったのでこれは保護装置の作動だろう.カスペルスキーの完全スキャンは99%のところから進んでいない.スタンバイに入るとスキャンが止まってしまうのだろうか?それも考えづらいような気がするのだが…

おかしい.メイン画面のワイドスクリーンが消灯してしまった.点いた.電源ボタンは少し下の方離れたところにある.画面が少し明る過ぎるがディスプレィ設定で明るさの調整ができない.明度を下限の-60まで落とした.これでもまだ少しまぶしく感じる.コントラストを下げれば暗くなるがこれ以上下げられない.スキャンはあと1分未満で終わると表示されているが…完了した.一度リブートする必要がある.

初期画面でキャノンのクイックメニューがうるさい.どこで止めたのだろう?たしか,カスペルスキーにあったような気がするが…いや,なかった.CCleanerにはあるはずだが,インストールされていない.設定→アプリ→スタートアップにある.影響小となっている機能はすべてスタートアップから外した.再起動しておこう.インターネットには接続していない.これでノーマルな状態になった.再インストールしてみよう.現在インストールされているのは2019/02/06だ.

これでデバッグを再開できるが,その前に最新の安定版を探しておこう.V2.0.2.143 R2018-08-18というのがあった.amory氏に送った版とどちらが新しいかチェックしたい.Gmailには2010年2月までのメールしか入っていない.メインマシンには残っているはずだが,封印されている.ネットが停止したのが2016年だからamory氏に送ったのはそれ以前のバージョンのはずだ.従って,2018年ならかなり新しいということになる.ダメだ.EXEが実行できない.

アンインストールの「必要な情報を集めています」のところで足踏みしている.なにかシステムに不整合が生じているのだろうか?しばらく動かしていないので錆びついてしまったという感じだ.キャンセルしてもパネルが閉じない.かなり悪い状態だ.一度強制的にリブートして動作を確認してみよう.インストールされているアプリ自体は問題なく起動できる.コントロールパネル→プログラムと機能であっさりアンインストールできた.

前回は設定→アプリ→アプリと機能からアンインストールしようとしたのだが,どうもこの2つ,①プログラムと機能,②アプリと機能はコンパチではないような気がする.安定版をインストールしようとしたが,同じエラーになってしまう.

タイトルなし

原因は分かった.カスペルスキーが実行をブロックしていた.多分EXEでも実行できるはずだ.おかしい.ブロックを解除しても走らない.仕方ない.インストールしてみよう.→ダメだ.OCXの登録で失敗する.タブレットにはZelkova Beta V1.8.3がインストールされているが,ゼルコバの木は載っていない.開発環境を立ち上げるしかなさそうだ.開発環境はVisual Studio 2017.とりあえず,最終版を起こしてみる.

どうも困ったことになってきた.ビルドが通らない.タブレットにはVisual Studio 2019がインストールされているが,メインマシンには2017と2015しか載っていないはずだ.ZELKOVA2019_2019-02-02をクリーンビルドしてみる.ダメだ.エラーが17個,警告が6個出ている.エラーは主にZView.vbで発生している.名前空間の継承で問題が起きているようだ.この辺りはすでにネットには復帰しているのだから,今回作業再開時の更新によって齟齬が発生したと考えるしかないように思われる.Windows 7 のサポート停止というのと関係あるだろうか?

Visual Studio 2017を再インストールすることで復旧することができるだろうか?いまのところそのくらいのことしか思いつかない.今日のところはここで打ち切って明日,少し落ち着いて考えてみることにする.Windows の更新だけやっておこう.いや,そのためにはネットに繋がなくてはならない.この広い世界中に信頼できるOSが一つもないということは悲しむべきことだ.

5ヶ月ぶりに仕事に復帰する

午前8時起床,晴れ.夕刻にわか雨.朝食はバナナ1本.わたしの誕生日当日から今日まで完全に仕事が止まっていた.とりあえずこの期間を総称してBODY REFORM MONTHS としているが,なぜここまで時間を消費してしまうことになったのか?真相は不明だ.「仕事に向かわなくても一日が過ごせる」ようになっている,つまり,「何もしないうちに一日が暮れてしまう」というのは確かな事実だがそれだけでは説明しきれない部分がある.この点に関しては後日検証することとして,ともかく作業復帰を急ぐことにしよう.

カスペルスキーの定義データベースの更新だけで30分近くかかった.

デスクトップにMeasureというフォルダがあったのでEドライブに移動した.これはIHI関係のフォルダだが,なぜこんなものがここにあるのかは不明.カスペルスキーの完全スキャンを開始したが,どうも今日はこれだけで終わってしまいそうだ.

この間テント村をまったく更新していなかったにも関わらず一日約50人くらいのアクセスが入っている.これはどういうことだろう?ときには20人以下という日もあるが,少しむらが大き過ぎるようも気がする.3月ころは精々1日10人以内という感じだったはずだ.この理由もまったく分からない.

mmm… どうもこのカウンターの動作はおかしい.まだ日付が変わっていないのに昨日の来訪者が44人,今日が49人に変化している.いや,そうではないと思う.単純に画面が更新されていなかったため,つまり,キャッシュが表示されていたためだろう.

マイクロソフトアカウントが無効になっている.この状態になった理由もいまいち不明だが,1ヶ月間くらい無効になるという告知があったことは確かだ.これを修正するためにはWindows Hello を導入する必要があるというのだが… Windows Hello では指紋認証ないし顔認証を使うことになっているようだ.Windows Hello を使わないというオプションはないので導入するしかない… いや,実際にはパスワードとPINだけでサインインできた.とりあえずこれでよいということにしておこう.

Windows 10では,近距離共有とアプリを使ったデバイス間の共有というのができるようになっている.これを使うと導入予定の無線HDが不用になる可能性もあるがリスクも高そうな気がするので使わない.

Publish ボタンでNetwork Connection Error が発生したが,再実行して通った.完全スキャンはまだ58%しか進んでいないが,今日はここまでということにしておこう.まぁ,復帰初日だからね…

2019-03-09

午後3時半起床,曇り.朝食は油揚げ入り卵うどん.昨日は業スーで買い出ししてきたので卵や牛乳など「高栄養食品」がふんだんにある.百合が180円という特価で売っていたので,この部屋には似合わないかもと思いながら買ってきた.大輪でもしかしたら「蘭」と呼ぶべきなのかもしれないが,百合と蘭の違いが分からない.今日は散歩の帰りにダイソーに回って歯磨きなどを購入.ともかく朝食を食べてからウォーキングという流れだけは確立できたように思われるが,スマホのアクセス時間は短縮されていない.

今日もまたYoutubeで長いクリップを見てしまった.英語教材は通常は5分~15分,ウォーキングに出るときはそれらを何本かまとめて30分~1時間くらいのストリームに仕立てているのでほぼコントロールできているのではないかと思われるのだが,やはり曲者は「長時間ビデオ」ではないだろうか?今日は長いビデオは1本しか見ていないはずだが,トータルでは10時間くらいになってしまっている.長いビデオは「後で見る」ことにして今後は週末にまとめて見ることにしよう.まぁ,過ぎてしまった時間は取り戻せないのでともかく仕事に入ろう.

サンプルは依然として反例2019-02-26\BUG19-01-27 06-56-47.NONだ.この図面はエラーは出ていないが,いろいろおかしいところがある.一番問題なのは重婚同類グラフが循環していないのに非連結系列が発生しているという点だ.非連結系列は8つある.このうちCU系列だけはPRIME_MARITALタイプだが,それ以外はすべてPRIME_PARENTタイプだ.ただし,優先仮ノードと実ノードが同名になっているのはDN系列だけでそれ以外はすべて別ノードと接合している.これはかなり疑問だ.[系列枠]: #521 odr=6 HM=0 先祖=#223 AL(0)[6] 優先=#736 AJ(1)→#203 AB(0) →主系列#509:AIのケースを見てみよう.

AJは親を一組しか持たないのでPRIME_PARENTは明らかに誤っているように思われる.しかし,結婚も一つしか持っていない.配偶者はABだ.ABもAJとの結婚しか持っていないが,この結婚はABの預かりとなっている.従って,AJは仮ノード消去されなくてはならないのだがそうなっていない.理由を探ってみよう.仮ノード消去はNAMEBOX::EraseGhostNameで処理されているが,この関数では本人ノード→本人ノードのケースしか処理されていない.いや,それは間違いだ.NAMEBOX::IsPossibleRealnodeで実ノード側が弾かれている.理由は

!hidden() && getvisible() && (getmarglink() || getrelation() == REL_ROOTS) && !empty && !getghostbits(DUMMYBOX|EXTRACTDUMMY)

でないためだ.このノードは不可視になっている.かなり疑問だ.どこで不可視になっているのかSWOで探索してみることにしよう.いや,この関係は先行してBTWで処理されているようだ.確かにBTWを先行させるような論理変更が実施されている.AJ(0)はDOUBLYBLESSED|BTWRIGHTSPOUSE属性を持っているが,(1)はBTW属性を何も持っていない.これはかなりおかしい.AJもABも結婚を一つしか持っていないのだから,AJ(0)が左手本人かつ右手配偶者となることはあり得ないと考えられる.

現行では配偶者が左手本人となることを認めているが,それには条件があったはずだ.このBTWはAJ(0)が左手本人となる構成で成立している.仮にそれで良いとしてもそうであるとすれば右手婚が誤っている.NAMEBOX::IfBTWPossibleでこのようなケースを弾くようにした.これで問題は解決したようだ.

image

非連結系列は解消し多重も発生していない.このバージョンを少し走らせてみよう.とりあえず,反例2019-02-26の4本は通った.反例2019-02-02の21本も通った.反例2019-01-28の19本も通った.反例2018-11-09にはまだ解けていないサンプルがある.どこかで無限ループしている.仮検定用サンプル\反例2018-11-09\BUG18-10-30 22-50-03.ZELと思われる.

▲仮検定用サンプル\反例2018-11-09\BUG18-10-30 22-50-03.ZELで無限ループが発生する.MPLCでレッドラインオーバーが起きている.天皇家の派生ファイルで基準ノードは@23 大山守皇子.どうもこのサンプルは相当加工が入っているようなので一旦無名化してから解析することにする.基準ノードのAWは結婚を1つしか持っていないが,その配偶者のNBが複数の結婚を持っていることが問題を複雑なものにしているように思われる.また,家内婚が5つも発生していることも撹乱要因になっている可能性がある.

SUWは可能だが図面はほとんど壊れていて,全体を見ることができない状態になっているが,TRIBEBOX::CheckMargBoxChangedでスラッシングが起きているようだ.障害はTribeRelocationのステージ【5.2】重婚同類グラフ検定の事後処理を行なうの出口で起きている.不良動作に関わる結婚枠は4つある.いや,もっともっと広範で複雑な動作になっている.最終的には大量の不可視結婚枠で「不可視ノード移動」が発生するようになる.

これを暫定的に止めると最終的に3つないし4つの結婚枠で「不可視枠を移動」ないし「結婚点を一致」が起こるようになる.「結婚点を一致」が起きているのは[結婚枠]:#543:#659 CD(0)+#1427 QY(0)→#4233 CS(2) だが,「不可視枠を移動」を暫定的に停止すると[結婚枠]:#4469:#1247 NL(0)+→#1249 NM(0)で「TYW枠の移動」が発生するようになる.「TYW枠の移動」を止めると今度は4つの結婚枠で「ゴールデンペア」が発生するようになる.

CRUSHCOUNTOVERした結婚枠をすべて排除すると描画まで進むことができるが,多重が5件発生する.これらの多重は世代的にかなり離れた位置で起きている.どうもかなり手に負えない状態になっているように思われる.図面はかなりの改変を受けているように思われるが,全体図を見ると骨格には変化がないようにも思われるので,おそらく改変があったとして局所的なものに留まるように思われる.従って,この図面はどうあっても仕上げられなくてはならない.仮修正する前にバックアップを取っておくべきだった…

今日のところはこれ以上手を付けずに明日に回すことにしよう.

朝のウォーミングアップに要する時間を四時間に制限する

午後4時起床,雨のち曇り.朝食は最後のおせちを水団仕立てにして片付けた.日付けはすでに0時を回って8日になっているが,起床時刻,ログの日付けとバックアップファイル名を統一するというルールに従って,3月7日としておくことにする.当月10日わたしの誕生日は姉夫婦と外食することになっていたのだが,ご亭主の休みが取れなくなってお流れ.2,3日雨模様の日が続いたが,開けたようなので散歩に出た.

今日も8時間くらいネットにアクセスしている.英語音声が聴き取れるようになってきたのでついついあれもこれもと聞いてしまう.ニュースフィードの流入を一部制限するようにしたので,もう少し時間短縮できてもよいはずなのだが,5分,10分のビデオでは短か過ぎて物足りなくなっているため,ついつい長いビデオを聴いてしまう.

ネットアクセスは上限3時間と決めてみたがどうも実態に合わない.すぐ超過してしまうし一度超過してしまうと歯止めが崩れてずるずると止まらなくなってしまう.明日からはむしろ,もう少し現実的に4時間ということにしてみよう.この四時間には朝食とウォーキングが含まれる.朝食はパンないしうどんに限定するということに決める.八枚切り食パンで4食,うどんが3玉で3食とすればきっちり一週間だ.正月のおせちも片付いたし,うどんの滞貨も完全に一掃されたので,今後はきちんとした献立で3食食べられるようになるかもしれない.

この四時間のウォームアップのあと,仕事にストレートに入れるのか?それともその前に昼食が入ることになるのか?はまだ未定だ.時間配分から考えると2時間くらい仕事して切りのよいところで昼食というのがベストという気もする.仕事の取っ掛かりではまず,始業時バックアップを取ってから前日のログの校正が入るので最少でも30分の予備的な作業がある.やはり,この辺りを片付けてその日の仕事の方向性が固まった時点で昼食というのがよいのではないかと思う.調理は必ずしも毎日ではないが,皿洗いは毎日やらなくてはならない.パン食の場合はほとんど食器を使わないので皿洗いをやっている時間がないかもしれないが,その辺りはフレキシブルでよいのではないだろうか?

朝のウォームアップに要する四時間を「朝練」と呼ぶことにしよう.これをそっくり差し引いて正味の仕事時間はどのくらい残るだろう?これまでのパターンでの仕事時間を仮に12時間とすると,今後は8時間くらい仕事ができればよしとするしかないのではないだろうか?去年の今頃はまだ30キロの米袋を担いて部屋を往復したり,チンしている間に軽い筋トレをやったり,部屋の中をぐるぐる歩るき回る「歩行瞑想」の時間などもあったのだが,今年は100%座りきりなので肩の筋肉だけでなく,足腰の筋肉も完全に落ちてしまった.まぁ,毎日歩いていれば足の筋肉は戻ってくるし,食べていればどうしても運動したくなるので上記のようなタイムテーブルが確立すればなんとかなるのではないかと思う.ともかく,この状態から一刻も早く「脱出」しなくてはならない.

おかしい.どこか壊してしまったのだろうか?SAMEGENEMARRIAGEで止まるようになってしまった.バックアップに戻ってみよう.⇒戻った.

重婚同類グラフで循環がないのに非連結になっている

午後4時半起床,曇りのち雨.朝食は薄切り食パントースト2枚,野菜サラダ.ネットアクセス時間を制限するためのタイマーは設定通りに作動したが,リスニングトレーニング中だったのでそのまま続行した結果,また大幅に予定時間を超過してしまった.ネットの閲覧範囲をよほど厳格に制限しないとこのままでは泥沼から抜けることができない.

反例サンプルは一応多重は解消した状態になっているが,果たしてこの修正が本当に正しいのか?収束しているのかどうかを確認する必要がある.仮修正がかなり残っているのでそれらをフィックスする必要があるが,この方向でよいという確証が出るまでは保留せざるを得ない.画面上の瑕疵に関しては一旦目をつぶって,机上の反例だけでもテストしてみることにする.リリース版を起こす段階ではないので,開発環境のリリースモードでテストしてみることにしよう.

机上の反例サンプルを集めたら9000本を超える大きなフォルダになった.どうもどこかでハングしている気配だ.画面も相当崩れていてかなりデグレードしているような気がする.障害は山のように発生している.反例2019-02-26という一番新しい反例に絞ってテストしてみることにする.このフォルダには4本しか入っていないが,すべてでエラーが起きた.いや,直近のサンプルでも「非連結」が残っている.重婚同類グラフで循環がないのに非連結になっているというのはかなりおかしい.やはりまずこれをフィックスすることが先決だろう.

始系列は[系列枠]: #501 odr=1 先祖=#327 CL(0)[1] 優先=#325 CK(0)だが,始系列を直接参照している系列がない.これはかなりおかしい.というか,これでは解けない.TribeRelocationのステージ【5.1】絶対世代番号に基づいてカードシフトでは始系列を参照している系列が3つある.

  1. #509 odr=3 HM=1 先祖=#217 AI(0)[3] 優先=#728 AA(1)→#201 AA(0)
  2. #541 odr=7 HM=1 先祖=#341 CS(0)[7] 優先=#737 AA(2)→#201 AA(0) →主系列#501:CL
  3. #549 odr=9 HM=0 先祖=#471 FK(0)[9] 優先=#740 AA(3)→#201 AA(0) →主系列#501:CL

いや検定出口でも状況は同じだ.いずれも参照実ノードはAA(0)になっている.判定関数がBTWの仕様変更に対応していないのではないだろうか?

スマホ依存症から脱出するためにタイマーを仕掛ける

午後3時半起床,曇り.朝食は食パン薄切りトースト2枚,コロッケ,白菜のサラダ.大分遊んでしまった.いまさらネットを遮断するなどのことはできないが,ともかくネットにアクセスする時間を削減しない限りここで沈没してしまう.ほっておくと毎日チェックするページのボリュウムが再現なく増えてしまう.最近はかなりヒアリング力が付いてきたのでそれがおもしろくて配信される英語教材ビデオを端から視聴しているので,それだけでも優に3時間を超えてしまう.

英語教材を視聴している間は基本的にワイヤレスイヤホンを使っているので,そのバッテリが切れるまでという上限を設定することは可能だが,多分4時間くらいは実稼働するのではないだろうか?スマホにアクセス時間制限機能が付いていると便利だと思うのだが?そのくらいのものはあっても良さそうな気がするので探してみよう.あるある!ただし,子ども用だ.子供をスマホ依存症から守るために「アプリに時間制限」をかける方法

しかし,これは一日のある時間帯をロックするというものなのでわたしのように生活時間不定の場合にはあまり向いていない.むしろ,朝起きたときにアラームを仕掛けておくというのが適当なのではないだろうか?「時計」アプリは時差を見るために常時使っているが,「時計」というくらいなのだからそれくらいの機能は付いているだろう.①アラーム,②ストップウォッチ,③タイマーの3つの機能がある.使うとすれば①か③だ.

アラームというのはおそらく「目覚まし時計」のことだろう.むしろ,タイマーを仕掛けるというのが一番使い易そうだが,タイムアップしたときにアラームが鳴るようにできるだろうか?当然そうなっている.サウンドも選択できる.Ringing Alarm という昔の電話のベルのようなのもあるが,Alarm Rooster という雄鶏が時を作る聲というのがあるのでこれを使ってみよう.これでともかく時間制限ができるようになった.

設定時間をどのくらいにすればよいか?妥当な線としては3時間ではないだろうか?この3時間には,①メールとニューズフィードのチェック,②英語ヒヤリング用ビデオの視聴と閲覧,③フェースブック,G+などSNSのチェックが含まれる.現状では一日20時間くらいアクセスしていると推定されるので3時間まで削減できれば仕事もできるだろう.仮に4時間まで延長されたとしてもまだ十分な時間を確保できるものと思われる.このタイマーは画面を消してもバックグラウンドで走っているようだ.

さて,仕事に戻ることにしよう.現在チェックに使っているサンプルは反例2019-02-26\BUG19-01-27 06-56-47.NONだ.すでに基準ノードの配偶者ポジションにはAA(0)が表示され,残る多重はCR(0)の配偶者ポジションにあるAA(2)だけになっている.なぜCR+AAのBTWが成立していないのか?その理由を見ることにしよう.そもそも BetweenTwoWomenで呼び出しが掛かってきていない.おそらく「 セグメント先頭枠だけ処理する@2017-10-25」で弾かれているのではないかと思う.いや,この結婚はAAの下にあるのだからそれは無関係であるように思われる.

BetweenTwoWomenはすべての結婚枠を検査してその結婚枠が右手婚となるかどうかをチェックしているが,左手本人はあくまで本人ポジションのカードに限定している.この制限を緩和してIfBTWPossibleを使うようにしたところ再び基準ノードの配偶者が消えてしまった.以下の仮修正を入れて収まった.

  1. NAMEBOX::IfBTWPossible HaveSingleFatherBox 呼び出しを後方に移動
  2. NAMEBOX::IfBTWPossible 左手本人が基準ノードであるときの特殊処理を無条件で実行するように変更
  3. NAMEBOX::IfBTWPossible 「基準ノードの配偶者が単親婚を持っている場合」の検査関数をSingleFatherBoxからHaveSingleFatherBoxに変更
  4. NAMEBOX::HaveSingleFatherBox 配偶者の場合は無条件で偽を返すように変更

これにより非連結要素のない下記のような図面が出力できるようになった.

image

ただし,この図面には,①不用な結婚点があちこちに散らばっている,②BTW連結線が引かれていないところがあるなどあちこちに瑕疵がある.また,主選択カードを切り替えようとしてTREEVIEW::PrimarySelectionで「主選択人名枠不在」エラーが発生した.再現手順は不明.

基準ノードの配偶者で多重が起きる問題

午前11時起床,曇り.朝食はネギ入りとんこつラーメン,ほうれん草と青菜のお浸し.結局ステファニーの Connect & Communicate コースを取ることにした.コースは12週で$497のところ,$397.分割すると150ドルx3回になる.通常割賦では200ドルx3なので150ドルの節約だ.ディスカウントの締め切りが迫っていたので急遽決断した.English Full:Time 24/7 のコースは10コースあるが,短いクリップの寄せ集めなので1日1コースは履修可能に思われる.

Connect & Communicate コースの方は週に一度の配信なのでダブルブッキングでもこなせると判断した.と言っても C & C コースにもすでに相当量の既存教材が蓄積されているので,うかうかすると仕事しているヒマがなくなってしまうかもしれない.今日はともかく打ち切って仕事に入ることにしたのだが… ネットで遊んでいるといくら時間があっても足りなくなる.昨日の続きに戻ろう.

現状における問題点はAAが多重になってしまっているという点だ.AA(0)は基準ノードの配偶者だが,このノードは可視で正しい位置に配置されている.AAの仮ノードは現在以下のような状態になっている.

  1. (0) 基準ノードの配偶者,可視の左手本人
  2. (1) 可視の本人ノード
  3. (2) 可視の配偶者ノード
  4. (3) 配偶者ノード 不可視の右手婚配偶者

問題は(1)の本人ノードと(2)の配偶者ノードだ.(1)は仮ノード消去されなくてはならないので,そうなっていない理由を調べる必要がある. (2)では(3)のケースと同様に(0)とBTWを組まなくてはならないのにそうなっていない理由を調べる必要がある.まず,(1)から見てみよう.おかしい.動作が変わってしまった.どこか壊してしまったのだろうか?見当が付かないので一旦バックアップに戻ろう.いや,バックアップに戻しても同じ障害が起きる.

エラーが起きているのはIsMukoYoshiだが,このエラーはNAMEBOX::UnErasableでcheckをオンにしただけで起きるようになる.どうも検査用コードで実動作が起きているようだ.checkブロックでIsMukoYoshiを実行している.この関数は「家内婚の左手本人であるか否かを判定」するためのものだ.対象ノードは#731AE(1).この関数は拡張枠全体を検査している.結婚枠の中に対象ノードを配偶者とするノードが存在する場合には「家内婚」と認定し,さらに検査を行う.

対象ノードはBTW右手本人属性と左手本人属性を持っている.これに対し例外が起きているノードはBTW右手本人だ.家内婚はBTWとして処理されているはずだから,対象ノードが左手本人,障害ノードが右手本人という関係になっているものと推定される.家内婚左手本人とは結婚枠の中で下流に位置するノードと定義されているはずだが,現行では多分家内婚は左手本人預かりとなっているはずだ.「家内婚は左手本人預かりとする@20190126」というオプションはオンだ.

この関数の論理ではBTW右手本人を家内婚左手本人としているように思われる.これでよいのかどうかは別途調べる必要があるが,今の場合は候補ノードはBTW右手本人なので家内婚左手本人と断定しようとしているようだ.IsValidNameBoxではBTW右手本人をIsValidNameBoxで取り出そうとしているが明らかに誤っている.このノードはBTW右手配偶者なのだから当然不可視で空の状態になっている.⇒IsValidNameBoxに代えてIsNameBoxAppearを使うようにした.これでcheckブロック内の障害は片付いた.

NAMEBOX::CheckUnerasableには「本人カードがこのノードだけで同世代の配偶者ノードが2つ以上ある場合は消去不可 @@2017-02-27」という判定条件が入っている.現行では原理的に配偶者多重を防止するようになっているはずだから,このロジックは不用と思われる.この条件変更は「左手枠配偶者を左手本人とするBTW拡張@20190130」によると考えて間違いないだろうか?多分それでよいはずだ.これで問題の一つは片付いた.

多重も2枚だけになった.これは仮ノード消去の参照先としてAA(2)が選択されているためと考えられる.ここではやはり,基準ノードの配偶者を特殊扱いするための属性を与えておくことにしよう.これは「基準ノードの配偶者」というだけでよいのだろうか?だとすれば属性ではなく特性関数でもよいような気はするのだが… 2月10日のログ「基準ノードの配偶者が枠外に出てしまう問題」で「検査関数」を導入するとしているのがそれに当たる.実装したかどうかやや不明だが,作ってしまった方が早いかもしれない.

IsBaseNodeSpouseとHasBaseNodeSpouseという2つの関数が作られているので使うことにしよう.これらの関数は実装されてはいるが使われていない.HasBaseNodeSpouseは「同名仮ノードのうちに基準ノードの配偶者が含まれているか否かを判定し,基準ノードの直近配偶者を返す」という関数だ.NAMEBOX::IsPossibleRealnodeで使ってみることにしよう.

NAMEBOX::DoublyBlessedOneの中でChangeRealRefferenceを使ってノード対の付け替えを実施している.暫定的に止めることでAA(0)を参照できるようになった.ただし,参照実ノードが2つ発生しているところから見てChangeRealRefferenceには何か不良があるように思われるので一度元に戻して調べて見ることにする.

中断地点から作業を再開する

午前10時起床,晴れ.朝食は納豆うどん.フェースブックではメーセージ交換が始まると相手のアイコンが画面上に表示されるようになる.そのことを知らなかったので昨日は知り合ったばかりのとびきりの美人から「いい加減にしてよ,一晩中寝かさないつもりなの?」と怒られてしまった.結局指を2本使ってアイコンを消す方法が見つかったのだが… まだ怒っているだろうか?

開発環境を立ち上げたら,Visual Studio の無料試用期間が完了したという表示が出ている.mmm… すっかり払い込み済と思っていたが,まだ入金していなかったかもしれない.これは多分マイクロソフト本社の直販と思われるが,確かに外国送金した記憶はない.楽天カードでは送金していないし,そのあとのデビッドカードを作ったのはつい最近でステファイーのコースの10ドルくらいしか送っていない.

マイクロソフトアカウント自体が無効になっているのでまずこれを有効化するところから始めなくてはならない.マイクロソフトアカウントは多重認証になっていたような気がするが,スマホのAuthenticator は捨ててしまった.どうもうまくゆかない.このアカウントを削除してしまった方が早いのではないだろうか?いや,もしかすると少し早まってしまったかもしれない.そもそもインターネットに接続していなかった.

メールアカウントは活きていた.アカウントは活きていたが,メールの受信にやけに時間が掛かる.どうしたのだろう?outlook.jpのメールはクラウド上にあると考えられるが,同期が取れていないようだ.ライセンスは更新できた.どうやって送金したのだろう?楽天カードはすでに失効していたはずなのだが… 完全にボケている!Visual Studio 2017 はとっくに無料化されていたのをころっと忘れていた.

スマホで「Messengerが電力を消費中」というメッセージが出る.これは昨日「アイコンが消えない」という騒動が起きてからだ.今日はアイコンはまったく出ていないのだが…いや,出ている.English Vocabulary だ.このアプリは一旦止めておいたのだが… 今日の出題は「onomatopoeia の同義語はどちらか?」というものだ.やはり,止めておくことにしよう.

一番最後の反例は BUG19-01-27 06-56-47.NON と思われるのでここから再開することにしよう.現状の論理は仕掛りになっているが,そのまま走らせるとSUWが発生する.さて,どうしたものだろう?一度修正前の版に戻った方が早いような気もするのだが…. ともかく,もう少し追いかけてみることにする.MoveWedlock で例外が発生している.SUWをスローしているのはGetUpperNodeだ.「親ノードが親パス上にない」というエラーが発生している.

続行して描画は可能だが,かなり崩れている.やはり一度バックアップに戻った方がよさそうな気がする.かなり問題だ.ZELKOVA2019_2019-02-10では同じ位置で例外が発生する.その前の版と言えばZELKOVA2019_2019-02-7しかない.とりあえずこれを使ってみよう.この版なら開ける.ログと突き合わせてみよう.日付から見て2月6日の修正は完全に入っているものと思われるが…

2月6日の最終修正の反例は反例2019-01-28\BUG19-01-27 06-56-47.ZELだ.開くことはできた.ただし,一箇所検査で停止するところがある.どうもこの部分は未解決のまま進んでしまったような形跡がある.TribeRelocationで「BetweenTwoWomenを先行実行する@20190206」という修正は入っている.IsAliveの「削除ノードがShadowedの場合にはLIFEは空にならない@20190206」という修正も入っている.この修正を入れた時点でバックアップを取っているのが,この版ではないか?

ここから先はもう一度デバッグし直すしかないようだ.IsPossibleBTWLeftHandでightwife->IsLeftHandBoxのときゼロ復帰すると多重が発生する.これはログの記述通りだ.従ってこのエラーは無視してよいと思われるがそれを正当化できるだろうか?つまり「左手枠配偶者を左手本人とするBTW拡張@20190130の場合はBTW右手配偶者が左手本人となる場合があり得る」ということなのだが… もう一箇所停止するところがある.

TRIBEBOX::SetMinorTribeで (primary->getrelation() == REL_SPOUSE) という理由で停止している.これは「系列優先仮オードの関係属性が不正」というエラーだ.この系列の接合タイプは「PRIME_BTWLEFT,  BTW左接続関係:両手に花左手本人→右手本人」となっている.これは置いてあとで見ることにする.出力図面で見るとMN(0)は配偶者ノードだが,右手婚配偶者属性と左手本人属性の両方を持っている.実際の図面を見てみることにしよう.

このサンプルを無名化したものが上のNONファイルなので以下ではNONファイルを使って解析することにする.AAは(0)~(3)の4つの仮ノードを持っている.AA(0)は不可視の配偶者ノードで右手婚配偶者と左手本人の属性を持っている.(1)は不可視の消去された仮ノード,(2)は可視の配偶者ノードで左手本人,(3)は不可視の配偶者ノードで右手婚配偶者属性を持っている.

image

  1. (0) 不可視の配偶者ノード 右手婚配偶者+(3)の左手本人
  2. (1) 不可視の消去された仮ノード
  3. (2) 可視の配偶者ノード (1)の実ノード,(0)の左手本人
  4. (3) 不可視の配偶者ノード 右手婚配偶者

この図面は多重は存在しないが,いくつか問題がある.①左手本人が不可視になっている,②基準ノードの配偶者が不可視になっている,右手婚配偶者かつ左手本人というのは矛盾がある.これらの矛盾はすべて(0)に集中していると言える.上の停止箇所と突き合わせてみよう.以下の2点だ.

  • rightwife->IsLeftHandBox 右手婚配偶者=左手本人
  • primary->getrelation == REL_SPOUSE 系列優先仮ノード=配偶者

最初の項目は規定通りエラーとしなくてはならないだろう.2番目の項目はこの系列がBTW左接続関係となっているためだが,まずこの系列を特定しておこう.[系列枠]: #541 odr=7 HM=1 先祖=#341 CS(0)[7] 優先=#737 AA(2)→#201 AA(0) →主系列#501:CLだ.この参照は左手本人から右手配偶者に向かうためBTW左接続関係とされる.しかし,「左手枠配偶者を左手本人とするBTW拡張」では配偶者が左手本人となる場合があるのでこれは合法だ.これでようやくスタート地点に戻ったのではないだろうか?

仕掛りの論理では「右手婚配偶者=左手本人」を無視して処理を続行した結果一応多重のない図面が得られてるが,やはり問題があると言えるだろう.今日は仕事再開の初日なのでこの程度で眠ることにしよう.おまけ:

Natalya VinogradovaYour left hand amuses yourself fingering your long hairs while your right hand that holds a pencil is writing something on the notebook on the upper side of your thighs.

とびきりの美人とお友だちになってしまった

午前9時半起床,朝食はtamo2さんから送られてきた「即席鹿児島ラーメン亭 とんこつ味」をネギだくで頂く.タブレットはまだ長机上にあるが,そろそろ仕事に戻ることにしよう.ここに来てフェイスブックの「友達」が一挙に11人に増えた.いや,実際はもっと多いような気もするのだがリストでは11人となっている.ほとんどはステファニーの The Fluency Breakthrough 24-Hour Challenge で知り合った仲間だ.

昨日のログでは「10ドルで提供するというディスカウント」と書いているが間違っていた.実際には正価の497ドルから100ドルディスカウントだったが,延長されて3月3日締切ということになったようだ.フェイスブックでチャットした仲間もまだ決めかねているようで3月3日までに決めると言っていたが,わたしはすでに1ヶ月10ドルの English 24/7 というコースに払い込んでいるのでしばらくはこれを続けるつもりだ.

全10コースで1日1コースづつ片付ければ10日でクリアできそうだが,何回か反復トレーニングする必要があるので最低1ヶ月はかかりそうだ.会話練習はやろうと思えば知り合った仲間とボイスチャットすることも不可能ではない.ひょっとして数ヶ月後には英語がペラペラになっている可能性はゼロではないが,おそらくそのときには日本語をすっかり忘れているのではないかと思う.

とびきりの美人とお友だちになったよ.

Karina Akhtyamova

「今日はもう眠れない」と言ったら,「なんで?」と尋ねるので「いや~それは(君には)言えない」と答えておいた.いや,最後に「Oyasumi」と言ってくれたので「これでぐっすり眠れる」って言えたけど… ちなみに彼女は日本に何度も来たことがあるそうで,かなりの日本びいきだ.わたしの生涯で出会った最高の美人かも…

さて,そろそろタブレットを仕事机に戻すことにしよう.(英語学習を含めて)遊びと仕事を切り離さなくてはならないが,English 24/7 はヒヤリングだけでは少し無理でどうしてもテキストを見ながらということになる.これをスマホでできるだろうか?問題なさそうだ.問題は外に持ち出したときスマホの画面がほとんど読めないという点だが,ウォーキングのときは何かヒヤリングに適した教材を選べばよいだろう.

最大の問題はいかにネットアクセスのトータル時間を削減するか?だ.朝のメールチェックで約1時間(これには配信されたニュースのチェックも含まれる),ウォーキングが30分~(歩行中のヒアリングトレーニングを含む),ウォーキングに出る前に朝食を摂らなくてはならない.パン食や麺なら20分程度,皿洗いは10分で済むとしても調理となれば1時間は掛かる.ワイアレスイヤホンで調理しながらヒヤリングというのは可能だから英語学習は「ながら」でやるしかないかもしれない.となると,メールチェックは食卓についてからということになる.これしかないのではないだろうか?

Y!パートナーはもう打ち切ってもよいかもね.「みんなの近況」というのは結構読ませるので毎日チェックしてた.一度だけマッチングしたけど相手は28歳!さくらでないとしたら,ミスクリックとしか考えられない.入会早々数百人から「いいね」をもらっているというのだから,単純に「あり得ない話」だ.大体ここは50代前ならほぼセフレ探し,それ以上なら真剣に結婚相手探しと見て概ね間違いないと思われるけど,結婚相手の条件は少なくとも「経済的に安定していること」だからね.素敵なガールフレンドもできたことだし,この際後腐れのないようにアプリを廃棄しておこう.実際言ってわたしは「有料会員」になるつもりはなかったし.