[HOME]  [全部表示 会議室風]  [全部表示 保存用]  [HOME]  [リストへもどる] [リストへもどる]

一括表示


  VTDOS+EMS+VZでの不具合検証 - konno 23/03/21-13:13 No.10682
 ┣ 現状のVTDOSを安全に使用する為の設定 - konno 23/03/21-13:15 No.10683
 ┣ 検証、[ESC]I マクロでとしきさんの生ログデータの情報 - konno 23/03/21-13:18 No.10684
 ┃┃┣ それは1年前の野ざらし言から始まった - konno 23/03/21-22:55 No.10687
 ┃ ┗ Re: 検証、[ESC]I マクロでとしきさんの生ログデータの情報 - 文太 23/03/24-00:06 No.10694
 ┃ ┗ Re^2: 検証、[ESC]I マクロでとしきさんの生ログデータの情報 - konno 23/03/24-20:33 No.10697
 ┃  ┣ Re^3: 検証、[ESC]I マクロでとしきさんの生ログデータの情報 - 文太 23/03/24-22:49 No.10698
 ┃  ┗ Re^3: 検証、[ESC]I マクロでとしきさんの生ログデータの情報 - めざら 23/03/25-10:35 No.10700
 ┃   ┗ Re^4: 検証、[ESC]I マクロでとしきさんの生ログデータの情報 - 文太 23/03/25-11:54 No.10701
 ┃    ┣ Re^5: 検証、[ESC]I マクロでとしきさんの生ログデータの情報 - めざら 23/03/25-13:28 No.10702
 ┃    ┃ ┗ Re^6: 検証、[ESC]I マクロでとしきさんの生ログデータの情報 - としき 23/03/25-14:11 No.10703
 ┃    ┃ ┗ Re^7: 検証、[ESC]I マクロでとしきさんの生ログデータの情報 - めざら 23/03/25-16:07 No.10704
 ┃    ┃  ┗ ゴミ - 文太 23/03/25-16:48 No.10705
 ┃    ┃   ┗ Re: BL8192 は #BでCPズレの可能性 - konno 23/03/25-18:41 No.10707
 ┃    ┗ xc のバグと対策 - konno 23/03/25-18:29 No.10706
 ┃     ┗ Re: xc のバグと対策 - 文太 23/03/26-15:47 No.10713
 ┃      ┗ Re^2: xc のバグと対策 - konno 23/03/26-23:54 No.10717
 ┃       ┗ Re^3: xc のバグと対策 - 文太 23/03/27-00:21 No.10719
 ┗ Re: VTDOS+EMS+VZでの不具合検証 - konno 23/03/24-22:54 No.10699
  ┣ Re^2: 良い知らせ - konno 23/03/25-18:48 No.10708
  ┗ EK+ で BL3072 の時の挙動 - konno 23/03/28-00:41 No.10730

(10682) 10682VTDOS+EMS+VZでの不具合検証  投稿者:konno   2023/03/21(火) 13:13
   コメント数 3

VTDOS+EMS+VZでの不具合検証スレを立てました。
きっかけは #10637 の、めざらさんの不具合報告からです。

> > VTDOS 環境ですが,300KB ほどの比較的大きなファイルをちょうど今編集していて,
> > clppst.exe+clppst.def による [ESC]I 様態(*)の作業を行って気が付きましたが,
> > ラップアラウンドエラーが出る状況になっています。テンポラリファイルエラーも
> > 出ました。現在の版の k07v6h と 前の版の k07v6d で発生を確認しました。

VTDOSのEMS環境ではデータが壊れるのを確認しました。他のVZも同様でした。
ラップアラウンドエラーやテンポラリファイルエラーは出ていません。

> > k07t5 に差し替えると,上記のラップアラウンドエラーは発生しなくなりました。

これは環境による差異と思われます。
VTDOSで EMSを使わない XMS環境ではデータが正常に処理出来ました。他のVZも同様です。
VTDOSで EMSも XMSも使わない環境でもデータが正常に処理出来ました。他のVZも同様。
つまり、テンポラリファイルのみ使用でも問題が出なかったのです。

めざらさんの環境とこのデータの関係については別に検証が必要と思われます。
それはともかく、私はVTDOS+EMS+VZでの不具合は問題と感じて、10#さんにメールで報告してみました。
その結果は予想外でした。

> まず、僕の環境でXMSのみ、EMSのみの環境でテストしてみましたが、
> EMSでは正常に貼り付ける事が出来ました。
> XMSの場合ではマクロが正常に終了せず、CLPPST.TMPがVZに残った
> 状態で中断しました。
> 続いてclppst.defによる貼り付けでは無く、メモ帳に貼り付けて保存した
> ファイルを[ESC]Iで挿入した場合正常に保存されました。

私のテストでも、EMS環境で、BT32 などの場合は正常に処理されたようでした。
めざらさんのデータだけでは検証には不十分なようです。
それで更なる検証のために、としきさんの生ログデータを使わせてもらいました。
それについては次回以降からやります。

      - No.10682 -    このTreeへ           [リストへもどる] soft

(10682) 10683現状のVTDOSを安全に使用する為の設定  投稿者:konno   2023/03/21(火) 13:15
    10682 番 konno さんへのコメント

現状のVTDOSを安全に使用する為の設定です。
XMSもEMSもフルで指定した場合、VZは XMS を優先に使用します。XMSを使い切るまで EMSは使われません。
この環境ならまあまあ安定するはずですが、EMSを使用した場合の挙動は保証されません。
メモリ拡張オプションの不具合も、もしかしたら EMSが原因だった可能性もあります。

ということで、今の私のVTDOS.CFG は
TPAEXT=1
TPALOW=1
を復活させました。VZの起動バッチには
$XSET vzsym=NOQ VTDOS
を仕込み、vz.def には

#if VTDOS ; VTDOS
XM1
EM0
SW1
#endif

こうしてEMSを使わず XMS だけにしてコード領域のスワップを止めました。
vwx.com も EMSを使うので、不安なら起動オプションで、Z1 にすれば良いでしょう。
それでも VMAP では

07D6 <-- 1 20944 vwx 1.08b -z1 -v2 -x1 -l6
0E21 <-- 1 222080 vzibmj 1.60v -sw2 -z 00 1B 21 29 3F
445A-E7FE 1 670272 <free>

これだけメモリが空いています。余裕ですね。
コンソールやファイラーでEMSを使いたいなら、EM4 は必要です。
ある程度EMSが欲しいなら、EM128 (2M)くらいならほとんど問題ないかと思います。
オリジナルVZでは、#if VTDOS が効かないので、EM128 は残してあります。

      - No.10683 -    このTreeへ    コメント元:10682 へ [リストへもどる] pre

(10682) 10684検証、[ESC]I マクロでとしきさんの生ログデータの情報  投稿者:konno   2023/03/21(火) 13:18
    10682 番 konno さんへのコメント    コメント数 2

としきさんのデータは今まで色々検証してきているので、プロが見れば特定できる可能性があると思います。
みんなで共有できる共通の検証環境として、10#さんに、としきさんのデータと VZO.DEF を送りました。

添付ファイルは

2022/03/03 01:00 170,335 0007.cgi オープンするファイル
2022/03/02 23:04 132,553 0007.cg [ESC]I で挿入するファイル
2022/03/03 19:11 302,888 0007-i.cgi 正常な結果ファイル(比較用)
2023/03/20 14:45 15,980 vzo.def オリジナルVZ.DEF DS+ に変更

まずは、オリジナルのVZ.DEFを、DS+ と変更し、VZO.DEF とします。
DS+ でファイルサイズが表示されるので、比較するまでもなくテキスト破壊がわかります。
オリジナルは、BT64 BL2048 SW3 で、[ESC]I マクロでは内容破壊、サイズが小さくなります。

BL128 〜 2048 の範囲では、VTDOS+EMS環境だけが異常になります。
SW0 BT32 でも異常になりました。


検証手順は

VZ /vzo  で起動します。(VZは各種VZを任意に指定)

170k の 0007.cgi をオープンする

[ESC]I で132k の 0007.cg を挿入する ファイルサイズは、302,888 になる
この時点でファイルサイズが違っていたら内容が壊れています。

ファイルサイズが同じなら、^QR でカーソルをテキスト先頭に
302k の比較用 0007-i.cgi をオープンして、[F04] で分割して [Shift][F03] で比較する
「一致しました」というメッセージが出たら、正常です。


この検証で興味深いのは、BL の値で結果が変わることです。
BL128 〜 2048 の範囲では、VTDOS+EMS環境だけが異常になります。 ※他のVZ環境では全て正常になる
BL1024*3(3072)のあたりでは、ファイルサイズが変わって致命的なエラー ※VZのバグ
BL1024*8(8192)のあたりでは、CP ズレが起こり、ブロックが入れ替わります。 ※VZのバグ

もしかしたら、1か所のルーチンの不具合でこの3つの不具合が起こっている可能性もあるかもです。

      - No.10684 -    このTreeへ    コメント元:10682 へ [リストへもどる] pre

(10682) 10687それは1年前の野ざらし言から始まった  投稿者:konno   2023/03/21(火) 22:55
    10684 番 konno さんへのコメント

今回の問題が見つかったきっかけは、1年前の野ざらし言の書き込みからでした。
関連しそうなツリーや記事のリンクを張っておきたいと思います。

野ざらし言#4609.ファイルの挿入 - としき 22/02/05-18:33
★ 全てはこのツリーから始まった。非常に長いツリーです。


野ざらし言#4700.ファイルの挿入とオプションの値 - としき 22/05/03-22:43
★ 非常に長いツリーです。

野ざらし言#4753  konno
&t トレースでは ek-, の時 #i の挿入でカーソル位置がズレたように見えたので。

野ざらし言#4784 添付ファイルは konno
2022/03/03 01:00 170,335 0007.cgi オープンするファイル
2022/03/02 23:04 132,553 0007.cg [ESC]I で挿入するファイル
2022/03/03 19:11 302,888 0007-i.cgi 正常な結果ファイル(比較用)

野ざらし言#4800 行ブロックズレはマクロのせい? konno
トレースで見ると、3回目の #i のブロックペースト後が問題です。
Ek- の時カーソル位置更新しますが、その位置が1文字ズレて改行の所になります。
本来なら行頭にくるはずなんですが、1文字ズレることがあるんですね。

野ざらし言#4835 めざら
現象から言えば,確かに #< があることで論理行が入れ替わるということになりますが,不具合の根本的な因子はそこではないと思います。
以前にもちょこと書きましたが,#< にはページングにおける KY (保存されたY位置)を更新する効果があって,ヒトの目線のズレ修正に貢献していると考えているのですが,c.mosさんとしては「美しい動作」というのが脳裏にあって #< を使っていたのではないかと想像しています。(まるきり外してるかも)

野ざらし言#4840 としき
> 異常挿入を起こす0007.cgiの冒頭からの真の最小のファイルサイズ
見つけました。
27932バイトでは異常発生、27931バイトでは正常挿入。

野ざらし言#4892 Blの指定可能な値について めざら
bl 34452 / pq..148==$776A, pq..149==$FDFE
bl 34453 メモリが足りません.
512バイトの緩衝領域+2バイトを前方(最上位メモリ)に確保しさえすれば,大きなラインバッファの「確保」は可能。ただし,正常に使用可能かは不明。

野ざらし言#4883 としき
上記の、異常挿入を起こす最小サイズとしては27932バイトなわけですが、元のファイルではその部分はちょうど2バイト文字の真ん中に当たります。なので、2バイト文字の区切りで1文字増やした27933バイトのファイル、これに0007.cgファイルを挿入しようとすると当然、異常挿入になります。この場合、ファイル末尾は「気」という文字です。
ところが、同様に0007.cgiファイルのこの行の「気」の文字の次に改行を入れたファイルを作り、このファイルを開きなおして0007.cgファイルを挿入しても、正常挿入。ところが、そこにさらにもう1バイト、何でもいいけど半角文字を追加して保存して開きなおし、0007.cgファイルを挿入しようとするとそれは見事に異常挿入。
不思議だ、なぜ2バイトずれる。


野ざらし言#4711.ファイル挿入(1) 1.60製品版 - めざら 22/05/07-21:13
★ 非常に長いツリーです。

野ざらし言#4934 なんというか、なかなか面白い結果となりました。 としき
特に面白いと思ったのは、あとから0007.CGファイルを読み込ませるとき、先に開いて
いたファイルのサイズとBlの値によって、きれいに挙動が変化する部分。すなわち、
以下のところですね。
先に開いていた  Blの値
ファイルのサイズ 8191 8192 8193
27931バイト   正常 正常 異常
27932バイト   正常 異常 異常
27933バイト   異常 異常 異常
また、Blを16384まで大きくすれば常に正常挿入になるかと思ったけどそうはならない、
という部分もなかなか興味深いところ。

野ざらし言#4995 これの続きを試してみました。 としき
先に開いていた  Blの値
ファイルのサイズ 8190 8191 8192 8193 8194
27930バイト 正常 異常
27931バイト    正常 正常 異常
27932バイト    正常 異常 異常
27933バイト   正常 異常 異常 異常
27934バイト 異常

野ざらし言#4997] EM の値で [ESC]i の挙動が変わる konno 2022/09/03(Sat) 18:24
何気なく、EM1024 を、EM12 とか小さくしてみたら [ESC]i の症状が良くなったみたいです。
それで、EMの値を変えて色々試してみました。
EM1017 を超えるとNG で、EM1010 ならほとんどのVZ環境で問題改善するようです。
今まで同じVTDOSでも私の環境で [ESC]i の挙動が良くなかった原因が分かった気がします。

★ EM1024-1017=7 16k*7=112k つまり、XMSは112kでそれ以上はEMSが使われて異常が出たと考えられる
★ EM1024-1010=14 16k*14=224k つまり、XMSは224kでそれ以上はEMSが使われる
★ この時点で、VTDOSのEMSの挙動に気づかなかったのが悔しいです。

      - No.10687 -    このTreeへ    コメント元:10684 へ [リストへもどる] pre

(10682) 10694Re: 検証、[ESC]I マクロでとしきさんの生ログデータの情報  投稿者:文太   2023/03/24(金) 00:06
    10684 番 konno さんへのコメント    コメント数 1

 我々(僕以外の我々)が追っていたものとは関係ないだろうと思います。
 ま、しっかし、偉いなぁ、皆さま

 SVCのログです。

>03472/03472 xxxxxxxx tanosan ちょっとしたバグなど(やや長文)
>( 2) 94/01/05 15:48
>
> ◎「カーソル位置へ挿入」マクロで、挿入するファイルの最後の行長が
> wd の整数倍で、末尾に改行がないとき(つまり、#_ でジャンプした
> 先が ct==0 && lh!=0 のとき)、その行が読み込まれません。次の修
> 正でOK。
>
> #b #_ (ct)?{ #> #m #x }
> ↓ #x は不要
> #b #_ (ct|lh)?{ #> #m }

 もちろん偶然です。グレップすらしていません。
 [ESC]I って、ほんと色々あったのねぇ。上村さんのinsfile.defを『強化書』
の頃から(たぶん)、使っているから、えー、そういうのあったんだ、程度の認識
なのですが。

 ただ、filter.defは、似たようなことをしてたわけですよ。


      - No.10694 -    このTreeへ    コメント元:10684 へ [リストへもどる] pre

(10682) 10697Re^2: 検証、[ESC]I マクロでとしきさんの生ログデータの情報  投稿者:konno   2023/03/24(金) 20:33
    10694 番 文太 さんへのコメント    コメント数 2

> > ◎「カーソル位置へ挿入」マクロで、挿入するファイルの最後の行長が 
> > wd の整数倍で、末尾に改行がないとき(つまり、#_ でジャンプした
> > 先が ct==0 && lh!=0 のとき)、その行が読み込まれません。次の修
> > 正でOK。
> >
> > #b #_ (ct)?{ #> #m #x }
> > ↓ #x は不要
> > #b #_ (ct|lh)?{ #> #m }

こ、これは・・・
確か、[ESC]i マクロの不具合の件で、野ざらし言に書き込んでいたと思います。
「#x は不要」で検索したら、過去ログにありました。
野ざらし言#4612 から、野ざらし言#4617 で 2022/02/13 の発言で

> この元ネタを探してみたんですが見つけられませんでした。
> 私の思い込みで勝手に変えちゃったのかもしれません。
> T.Tanomura さん、不確かなもので名前を挙げてしまいすみませんでした。m(__)m

探せなくて、こう書いていたんですが、SVC でしたか・・・
この会議室は、バグ報告の宝庫ですねぇ、この発言だけでも他に
-------------------------------------------------------------------
 ◎FD からの子プロ起動時に !Open がトレースモードに入る現象ですが、
必ず、!Open の最初のキーワードを実行し、2番目のキーワードの実
行に入るところでトレースモードになるようです。1.6 の標準 DEF で
は「?ts=」で止まります。こうした事情から考えられる原因はありま
せんか?

 ◎常駐-解放-常駐を行うと、解放したはずの VZ が居座っていることが
あります(再現条件不明)。これは VZ 側の問題でしょうか、それと
も用法に問題があるのでしょうか?

   2536 <-- 1 96800 vz 1.60 -em30 -z
   3CD9 <-- 1 3840 vz 1.60 -em30 -z 06 21 29
   3DCA-A000 1 402272 <free>

 ◎ファイル名入力窓で、すでにファイル名+スペースを入力した状態で
ヒストリーをさかのぼると、「->17EE」のようなものまで単独で再現
されてしまいます。

 ○ファイル名入力窓のための仕様だと思いますが、カーソルの直前がス
ペースのとき、文字列ヒストリー中のすべての文字列が再現されてし
まいます。コマンドラインも文字列入力窓も共通。この動作を、ファ
イル名入力窓に限定することはむずかしいですか?

 ○Ds+ で表示される文字コードが、^M で 0D0Ah になります。ちなみに、
0ah のときは問題ありません。

 ○^M が[EOF]に‘吸収’されてしまいます。例えば、ファイルを新規に
開いて「123^M456」と入力しても「123456[EOF]」としか表示されず、
ファイルには「123456^M」のように順序が狂った形でセーブされてし
まいます。
-------------------------------------------------------------------
これだけあるんだもの。(^^;

> ◎常駐-解放-常駐を行うと、解放したはずの VZ が居座っていることが
> あります(再現条件不明)。これは VZ 側の問題でしょうか、それと
> も用法に問題があるのでしょうか?

この現象、最近 MS-DOS Player + FreeCOM 環境で起こっています。VZの版は関係ないかも。
普通、常駐解除すると、プロンプトカーソルがアンダーラインのようになるのに、そうならない時があるのです。
その時に一度 [ESC] を押すと、^[ と出て、常駐解除出来たのかと思いますがもう一度 [ESC] を押すと、VZの入力窓が出るのです。
割り込みベクタの書き戻しとかが上手くいってないのかなぁ。

>  ただ、filter.defは、似たようなことをしてたわけですよ。

同じかわかりませんが、手持ちの filter.def にはこんなルーチンがありますね。

10: ; overwrite
(fb)? {
ek[+,
#W xc[, #y
#W #^ #< #i #b #_ #y #^ #<
#W #b #i r], (r==-1)? #B
ek],
(0)

なんだか [ESC]i マクロによく似ていますね。
#B も使っているし、もしかして xc[, を r], に戻してその値で #B 使っている?
確か、xc もバグがあったような。
これは怪しいですね。どうでしょ >めざらさん

      - No.10697 -    このTreeへ    コメント元:10694 へ [リストへもどる] pre

(10682) 10698Re^3: 検証、[ESC]I マクロでとしきさんの生ログデータの情報  投稿者:文太   2023/03/24(金) 22:49
    10697 番 konno さんへのコメント

 はい、そうなんです、filter.def。でもね、、、。

http://mezala.la.coocan.jp/vz/notes/vars.html

xc v1.6 ブロック範囲比較変数
値 カーソル位置(cp)と選択開始位置(tblkp)との比較
-1 cp < tblkp
0 cp == tblkp
1 cp > tblkp

※比較はオフセット値で行われるため,常に正しいというわけではない。
64KBの敷居をまたぐ可能性がある時に正確な比較をするためには,
カーソル位置のロングポインタ(マークで使用)を用いる必要がある。
-------------------------------------------------------------------

 少なくともこれに引っかかったとは思えないんですよねぇ。
 そんなに運は悪くないだろうと。処理対象(範囲)が大きくない、が
より客観的で合理的な根拠ですが。
 64KB。またしてもテキストバッファの限界値。
 セグメントの境界だものね。???

 .com ファイルの制限、これも。

vzo.com 57,694 1993-12-06 02:00 ;cmos
vz.com 62,184 2018-10-17 19:11 ;konno 一杯ま近ですよ。


      - No.10698 -    このTreeへ    コメント元:10697 へ [リストへもどる] pre

(10682) 10700Re^3: 検証、[ESC]I マクロでとしきさんの生ログデータの情報  投稿者:めざら   2023/03/25(土) 10:35
参照先:http://mezala.la.coocan.jp/
    10697 番 konno さんへのコメント    コメント数 1

> 確か、xc もバグがあったような。
> これは怪しいですね。どうでしょ >めざらさん

怪しいというわけではないのかと…。xc の件は,バグと言うより仕様だと思いますが,
マニュアルに警告が書いてないのでバグ扱いが妥当かもしれませんけどね。
(一応,cp と tblkp とあるけれど,それだけだとソース読める人とかが対象)

なお,filter.def マニュアルには,「64KBをこえる大きなブロックは扱えません。」と
明記してあるので,ローカル 10: のルーチンが巨大ブロックに対応していなくても
それは仕様であってバグではありません。もちろん VZ のバグとの関係もありません。

#i の戻り値を xc の値で上書きしているのは,その振る舞いを見越しているわけで,
これまた VZ マクロらしい無駄のない動作だと思います。

・ブロック処理は,下から上に向かったブロック(xc==-1)の方が速度的に有利
・その場合でも処理後のカーソル位置をテキスト末尾に移動
…という感じかなぁ…
そのへんは,改造するほど入れ込んでいる文太さんに聞いた方が的確かと。
      - No.10700 -    このTreeへ    コメント元:10697 へ [リストへもどる] soft

(10682) 10701Re^4: 検証、[ESC]I マクロでとしきさんの生ログデータの情報  投稿者:文太   2023/03/25(土) 11:54
    10700 番 めざら さんへのコメント    コメント数 2

 特に何も聞かれてないと思いますが。
 何もできない、ほぼ何も考えられない(知識が足りない)という感じですが。

 (1)原因は、vtdosか、vz.comか、filter.defか。??? どれも可能性あり。
 (2)>filter.def マニュアルには,「64KBをこえる大きなブロックは扱えません」
とあり、
 これは、xcの件。しかし64KBを超えるファイルでテンポラリーファイルとかテキスト
バッファが絡んだら? これは、きっとvz.comがらみの事柄。
 (3)こういう場合、経験とか実体験とか統計的に無意味だろうと思いますが、
それでもいまのところWinMEでは経験していない(と思う)。

 とにかく、(1)としきログ、(2)clppestがらみ、(3)filter.def文太がらみ
では、(3)に圧倒的に発現条件についての情報が足りません。再現できません。
 さらに、この3つがどれだけ重なった、関係した事態なのかも分からない、、、。

 新しい情報みたいにみえて、misleading な事柄でした、おそらく。

 他意はないですが、いちおうお伝えしておくと、(僕の読解力のせいだろうと
思うのですが)、(2)について、僕は何の話だかまったく分かっていません。


      - No.10701 -    このTreeへ    コメント元:10700 へ [リストへもどる] soft

(10682) 10702Re^5: 検証、[ESC]I マクロでとしきさんの生ログデータの情報  投稿者:めざら   2023/03/25(土) 13:28
参照先:http://mezala.la.coocan.jp/
    10701 番 文太 さんへのコメント    コメント数 1

>  とにかく、(1)としきログ、(2)clppstがらみ、(3)filter.def文太がらみ

> (2)について、僕は何の話だかまったく分かっていません。

ごめんなさい。不具合の発生したファイルを提供したので,細かな手順などはすべて
端折ってしまいましたから,わたしと konno さん以外は見えなくて当然です。

せっかくだから補足しますと,自分のコンテンツで「ラジオドラマ資源」なるものが
ありまして,これの一年単位の番組基本情報ページがあるわけです。1950年代は
わりとラジオドラマの放送が多くて,それなりのサイズのテキストになります。
先日のファイルが 300KB 弱で,2,100行強,ラインバッファを超える1行はありません。
この一年分のデータは,スプレッドシートで複写した TSV で,クリップボードに転送。
このとき手作業でファイルに落とすことなく,愛用の clppst を使って貼り付けます。
そして,貼り付けたタイミングでエラーが発生したわけです。300KB 弱ありますから,
当然,巨大ブロックを挿入する [ESC]I と同様のマクロコードが clppst.def にあります。

具体的に,上記の手順でした。
再現条件は EMSを使用,clppst.def 実行,64KBを超えるテキスト,です。
としきファイルと異なるのは,ラインバッファを超える行がないこと。たぶんそのくらい。
(↑ これ,ウソです。としき兄のご指摘(#10703)がありました。)
      - No.10702 -    このTreeへ    コメント元:10701 へ [リストへもどる] soft

(10682) 10703Re^6: 検証、[ESC]I マクロでとしきさんの生ログデータの情報  投稿者:としき   2023/03/25(土) 14:11
参照先:http://toshiki.la.coocan.jp/
    10702 番 めざら さんへのコメント    コメント数 1

> としきファイルと異なるのは,ラインバッファを超える行がないこと。

めざらさんの提供されたファイルの一番長い行って、何バイトくらいですか?
私の提供したファイルでは、確か7000バイトに満たないくらいだったはず。
そして私の場合、Blは8192に設定してあって、ラインバッファを越えていないはず
なのに異常動作が発生したという認識です。
この辺、何か私の認識誤りか確認ミスがあったかな。
いまになってそういったことが発覚したとなると、かなり困ったことです。

      - No.10703 -    このTreeへ    コメント元:10702 へ [リストへもどる] soft

(10682) 10704Re^7: 検証、[ESC]I マクロでとしきさんの生ログデータの情報  投稿者:めざら   2023/03/25(土) 16:07
参照先:http://mezala.la.coocan.jp/
    10703 番 としき さんへのコメント    コメント数 1

あらら,実際のファイルで調べもしないで適当なこと言っちゃいました。
すみません.

わたしのファイルだと,急拵えしたこんなマクロで 1600バイトほどと表示されました。
1 ^\ "" ?.
a-,
#^ #<
:l ; ---- main loop ----
cp[,
#> r=cp-0],
(r>a)?a=r,
#d (r)??>l
&m("%u",a)
:z ; ---- exit ----
&d #] .

うちのラインバッファも 8192 取ってるので,断然余裕ですが。

      - No.10704 -    このTreeへ    コメント元:10703 へ [リストへもどる] pre

(10682) 10705ゴミ  投稿者:文太   2023/03/25(土) 16:48
    10704 番 めざら さんへのコメント    コメント数 1

 awkだとどう書くんだっけ? と。ちゃんと忘れてました。

--- maxlen.awk ---
{ if (maxlen < length) # length()が推奨されているらしい
maxlen=length
}
END { print maxlen }
------------------

C:\>jgawk -f maxlen.awk c:\0etxt\asm\tbook\mast_td.txt
141
 問題まったくないですね。すっかり安全志向。

 ただ、どっかでkonnoさんが、bl の値により、挙動(結果)が違う、
と書かれていたので、それの再検証からいくかな等々、いちおう真剣に
考えてはいます。BL=8192 bytes これには、実用上、問題は何もない
と思っていますが。

 タネをしこんで厨房に立ち、カレーを作り始める(時間がかかる。時間を
かけると美味しい)。そしたら、とらじさんのように、なるへそ、
そう攻めてみるか、とか思いつくのかなぁなんて思ったけど、別に何も
思いつきませんでした。カレー作りに夢中になっただけだった。
 (「どこどこ」開発中の会話より。doko2.defを相当ひさしぶりに動かした。
   いえいえ、キーの格納のされ方もすごいです)

 あ、こういうのゴミ発言って言うんでしたよね。

追伸でなく本題:clppst.defの件、発現条件は分かりました。10#さんからの
回答の意味も少しわかりました。多謝>めざらさん。


      - No.10705 -    このTreeへ    コメント元:10704 へ [リストへもどる] pre

(10682) 10707Re: BL8192 は #BでCPズレの可能性  投稿者:konno   2023/03/25(土) 18:41
    10705 番 文太 さんへのコメント

>  ただ、どっかでkonnoさんが、bl の値により、挙動(結果)が違う、
> と書かれていたので、それの再検証からいくかな等々、いちおう真剣に
> 考えてはいます。BL=8192 bytes これには、実用上、問題は何もない
> と思っていますが。

みなさん BL8192 でお使いのようですね。
過去の [ESC]i マクロでとしきデータの行長は BL8192 以下でしたが、CPズレでブロックが入れ替わったという記憶が。
EK- で #B を繰り返し使うと CP ズレが起こることがある、と私は感じました。
今は BL8192 でも安心できない気がするので、検証を続けているのです。
バグが特定できれば回避して運用するのは可能だと思うので、みなさんの情報が頼りです。

      - No.10707 -    このTreeへ    コメント元:10705 へ [リストへもどる] soft

(10682) 10706xc のバグと対策  投稿者:konno   2023/03/25(土) 18:29
    10701 番 文太 さんへのコメント    コメント数 1

xc のバグといえば、あむのさんの対策を思い出します。
CODEX.DEF で検索しましたが、BL2048 だと CODEX.DEFが起動しない! まいった。(>_<)
BL4096 なら起動できたので、以下に引用します。(^^;

-----------------------------------------------------------
> 06847/06847 xxxxxxxx あむの xc にはご注意!
> (15) 97/07/10 07:56 06827へのコメント

 変数 xc にはよく知られたバグがあります。

(1) 32,767 byte の前後にかかる後ブロック(注)で xc の値が 0 となる

ファイル 32767 65536 65K+32767 (byte)
+------------+----------+--- .... ---+---------- ......
・========* ・====*
blk blk
(*印がカーソル位置)

本来ならば xc == 1 。

(2) 文字境界ブロック (mb==2) 限定のバグ
・ファイル先頭行にブロックがかかること。
・前ブロック(注)であること。
・カーソルカラム数がブロック終端のカラム数(wa..51)より小さい。

この場合、xc の値が 0 となる。(本来はxc == -1)

(例) ファイル先頭
+-------------------------------+
| *===========================|
|======・ blk |
| |
(*印がカーソル位置)

(注) 前ブロック カーソルがブロックの前の場合(xc:-1)
後ブロック カーソルがブロックの後の場合(xc:1)

 ですから、上記バグの条件にあたらないことが明確ならば、xc は有用です
が、それ以外の場合には使わない方が良いかと思います。

* * *

 xcの代替手段としては、マーク機能(&#M(n))をブロック前後で使って、その
マークの値を比較するというのが一般的ですが、これまたちょっと問題を孕ん
でいます^^;。
 というのは、純正Vzには、ロング整数を比較する&Lcという関数にも著名
なバグがあって、使えないのです(榊原さん版Vzは修正されています)。

 というわけで、自力ですると、例えばこんな↓ふうになります。
 FGALPK Mes13 #02168 94/12/17 y.mikome さん ご紹介の方法に若干手抜き
したものです。

=Test
カーソルをブロックの前にする。
マーク#0 wa+126 (wa..63,wa..64)
マーク#1 wa+130 (wa..65,wa..66)
* M
89 ^\ ""
?.(mb)??.
#M #B &#M(1) #B p$8000, ;ブロック前後でマークする(位置は元に)
(wa..64 > wa..66 || (wa..64 == wa..66 && p+wa..63 > p+wa..65) )?#B
*

ここまで -----------------------------------------------------------

私は xc を使ったこともなく、よくわかっていなかったのですが
今このマクロを見ると、なんとなく読める気がします。(気の精)

# 読める! 私にも読めるぞぉ! ララァ

06858番の発言では
-----------------------------------------------------------

 あ、いえ、ブロックのサイズの問題ではないのです。ファイルサイズとブロ
ックの位置の問題なんです。
 百聞は一見に如かず、ということでこの↓マクロを実行して xc の値を確か
めて下さい。

=Test
巨大なファイル(例えばログファイル)上で実行して下さい。
* M
80 ^\ ""
?.mb0,&d
&Im(wa+126,0) wa..63=$7FFF,
#U #< #b #> #d
&m("xc:%d",xc)
*

 また、幸い?なことにバグは xc==0 のときだけのようですから、その時は
実行させず、警告メッセージを出すだけにしても良いかもしれませんね(特に
今回のマクロの場合は、バグでない xc==0 の時も実行させる必要もなさそう
ですから)。

ここまで -----------------------------------------------------------

これを踏まえて、気が向いたら調べてみたいですね。(無責任モード)

      - No.10706 -    このTreeへ    コメント元:10701 へ [リストへもどる] pre

(10682) 10713Re: xc のバグと対策  投稿者:文太   2023/03/26(日) 15:47
    10706 番 konno さんへのコメント    コメント数 1

konnoさん

 情報、ありがとうございます。
 ただ、古いですね。32KB 近辺のバグは除去されていると思しいです。
 で、マーク4バイトX2で対策しようかとも思っているのですが、昨晩
深みにはまってしまい、、、。
 僕以外気にしてない、そして、本当の原因はここじゃない、というあたりで
逃避行動に出ています。

 とにかく、情報多謝です。当たり前でしょうけれど、ロングの比較は、
高橋版(榊原版)から、符号なしに統一されフィックスされているはずです。


      - No.10713 -    このTreeへ    コメント元:10706 へ [リストへもどる] soft

(10682) 10717Re^2: xc のバグと対策  投稿者:konno   2023/03/26(日) 23:54
    10713 番 文太 さんへのコメント    コメント数 1

>  ただ、古いですね。32KB 近辺のバグは除去されていると思しいです。

高橋さんが直してくれてたんですか、ありがたいですね。
あとは、#B を繰り返し使うと CP がズレたりするのではないかと私は疑っています。
#B を使わないようにマクロを修正できれば安心できるのですが。

>  で、マーク4バイトX2で対策しようかとも思っているのですが、昨晩
> 深みにはまってしまい、、、。

すみません、余計なことを言ってしまったようで・・・

      - No.10717 -    このTreeへ    コメント元:10713 へ [リストへもどる] soft

(10682) 10719Re^3: xc のバグと対策  投稿者:文太   2023/03/27(月) 00:21
    10717 番 konno さんへのコメント

konnoさん

 あっちの結果報告を待っています。m(__)m
 ちょっとビックリしたので。

(xc について)
>高橋さんが直してくれてたんですか、ありがたいですね。

(ロング関数について)
--- vzt.doc ---
◎榊原版Vzより移植
●&Lc・&Id のバグ修正。また、全ての long 演算を符号なしに統一しました。
---------------
 少なくともこっちは、榊原さんですね。
 xc については、32KBは初耳で(現象確認できず)、64KBは、めざらさんが
仰っていたとおり、「仕様」でしょう。対策法も確立してるし。
 高橋さんのvzt.docには記載なし。

>あとは、#B を繰り返し使うと CP がズレたりするのではないかと私は疑っています。
 マクロイドとしては、これは困るんですよねぇ。2023年になって、まだこんな
ことを言ってる、、、。としきさん事例ですよね。あれは何なんだろう?

>#B を使わないようにマクロを修正できれば安心できるのですが。
 それは、たぶん、ほぼムリ。本質からずれますが、僕は、ブロックを下からした
ことなんてほぼないのです。すると、ほぼ自動的に、#B する。

>>  で、マーク4バイトX2で対策しようかとも思っているのですが、
>すみません、余計なことを言ってしまったようで・・・

 いえいえ、konnoさんにしては珍しく、他人(ひと)のお尻を叩いている。
 はい、叩かれてるなぁ、という自覚はあります。
 が、暇をみつけて、他のマクロをやってます、、、。オレ、かなり頭が悪いらしい
という自覚がふつふつ。場合分けができない!


      - No.10719 -    このTreeへ    コメント元:10717 へ [リストへもどる] soft

(10682) 10699Re: VTDOS+EMS+VZでの不具合検証  投稿者:konno   2023/03/24(金) 22:54
    10682 番 konno さんへのコメント    コメント数 2

良い知らせと悪い知らせがあります。

10#さんとのやりとりで私が上手く伝えられなくてどうなることかと思いましたが
再現が出来たと朗報がありました。
それとともに、新たなVZのバグが発覚したようです。

メールの返信の内容を貼り付けます。
-----------------------------------------------------------

>試験をやり直した結果再現しました。

おお、再現出来ましたか、よかったです。

>余談になりますが、僕の試験で把握出来た事をお伝えします。
>まずこの現象はEk+では再現されないようですが、この場合は前回僕がお伝えした結果になります。
>それから、試験をパスした(一致した)状態で窓替え(F2)を行ってすぐ比較を行うと相違が出ます。
>これはMS-DOS上のオリジナル版でも出ます。

試験をパスした(一致した)状態で窓替え(F2)を行ってすぐ比較を行うと相違が出るのですか。
この現象は知りませんでした。やはり検証不足だったようです。

MS-DOS Player や DOSVAXJ3 でも同じ現象になりました。
[F02]の後の比較マクロで6か所文字化けが出ますが、これは VZ のバグだと思われます。

思い当たるルーチンが有るので修正したVZで試してみました。
MS-DOS Player や DOSVAXJ3 では、文字化けが無くなり、正常になりました。
VTDOS では、やはり内容が変わっています。
10#さんのおかげで、一歩前進出来たみたいです。ありがとうございます。

>この事を踏まえ調査を行うつもりです。

よろしくお願いいたします。
私ももっと検証を進めたいと思います。

-----------------------------------------------------------

ということで、調査をしていただけるのはうれしい知らせですが
比較で一致しても直後に[F02]窓替えで再比較すると文字化けが出るという新たなVZのバグが発覚しました。
これは、BL1024 か BL2048 の時だと思われるので、BLの影響で長い行の途中に改行が入るのではないかと想像しました。

過去記事の
#10322:Bl3072 の大穴が塞がったかも  投稿者:konno   2022/10/11(火) 21:59

> Bl3072 では 3700bytes を超えるところで改行が入っていました。
> ソースに改行を挿入するところがあるはずだと当たりをつけて
> 「,LF」で検索すると、それらしいところが TEXT.ASM にありました。
>
> fread proc
> 中略 410行目
> cmp si,di
> jne read3
> mov byte ptr [si-1],LF
> _break
> read3: cmp byte ptr [si-1],LF
> _until e
> clz
> ret
> read9: stz
> read_x: ret
>
>
> ここの
> mov byte ptr [si-1],LF
> があやしいと思い、色々試したところ
>
> cmp si,di
> jne read3
> stc ;★##k 221011 キャリーをセット
> jmps read9x ;★ ゼロフラグをクリアしてリターン
> ; mov byte ptr [si-1],LF ;★ Bl3072 の時 3700bytesで強制改行(実行しない)
> _break
> read3: cmp byte ptr [si-1],LF
> _until e
> read9x: clz ;★ ゼロフラグをクリアしてリターン
> ret
> read9: stz
> read_x: ret
>
>
> このように変更したら、Bl3072 で改行文字化けが無くなりました。

これを思い出し

cmp si,di
jne read3
jmps read9x ;★ ゼロフラグをクリアしてリターンへ
mov byte ptr [si-1],LF
_break
read3: cmp byte ptr [si-1],LF
_until e
; clz
read9x: clz ; or sp,sp = zf0 cf0
ret

このようにシンプルに修正したVZでは、文字化けも無く正常処理出来ました。
今までは余計なところまで弄ってエンバグしていたようです。
正常動作するVZは、だいぶ前に戻ってしまいました。
今まで積み上げてきたものが全部崩れてしまった感じです。(^^;


# まるで賽の河原で石積みをしているような・・・ だって私、VZの亡者ですから。

      - No.10699 -    このTreeへ    コメント元:10682 へ [リストへもどる] pre

(10682) 10708Re^2: 良い知らせ  投稿者:konno   2023/03/25(土) 18:48
    10699 番 konno さんへのコメント

VTDOS BBS で、10#さんからのお知らせがありました。

> 原因が判明したので遠からず修正可能です。
> リリースまでもう少し頂きます。

うれしいです。\(^^)/ ヤッタ-
ありがとうございます。
気長にお待ちしています。

      - No.10708 -    このTreeへ    コメント元:10699 へ [リストへもどる] soft

(10682) 10730EK+ で BL3072 の時の挙動  投稿者:konno   2023/03/28(火) 00:41
    10699 番 konno さんへのコメント

[ESC]i マクロの検証では、EK- で BL3072 の時は、全ての環境で NG になりました。
EK+ で BL3072 の時の挙動を確認したら、10#さんの環境が再現出来たようです。

VTDOS+高橋版VZで EMS環境で EK+, BL3072 の時、正常処理されました。
[F02]の後の比較マクロで6か所相違が出ます。修正VZでは一致します。
これは、XMS環境でも同じでした。

オリジナルVZでは、EMS環境でも XMS環境でもラップアラウンドエラーで、VZが落ちます。

MS-DOS Player と DOSVAXJ3 では、EMS環境でも XMS環境でも NG になりました。
試した全てのVZでファイルサイズが増える同じ壊れ方でした。

EK+ で BL3072 の時 VTDOS だけが正常処理されるとは、ビックリです! (゚゚;)


# このあたりに時空の歪みの境界があるのでしょうか。(@.@)

      - No.10730 -    このTreeへ    コメント元:10699 へ [リストへもどる] soft