Vzエディタにおいて、カーソル位置へのファイルの挿入は、製品付属のマクロを使っています。8番マクロというか[ESC]Iとか@Iで起動するヤツです。 このマクロって、何か制限ありましたっけ? あるいは、バグ報告ってあります? 1行の長さとかファイルサイズとか改行コードとかに関係しているのかなぁ。 なにかというと、うちの掲示板の過去ログを復旧していて、妙な挙動が発生していたのですよ。 過去ログのデータは、ご存知のとおり、古いデータの塊が下のほうへと下がる形式です。 そして、古いほうはバックアップが残っていたので、欠落した新しい部分のツリーデータを復旧させて、古いファイルの先頭にファイルを挿入しようとしました。ところが。なぜか、新しいほうのデータの最後から3行目が、古いほうのデータの直前に挿入される形になってしまうのです。 言葉でいってもわからないと思いますが、うまく図に表すこともできそうにない。とりあえず、以下、挿入しようとしている新ファイルの末尾と思ってください。 (前略) 2599.... 2798.... 2795.... [EOF] これを旧ファイルの先頭に挿入しようとしたら、こうなりました。 (前略) 2798.... 2795.... 2599.... (以下、旧ファイル) 最初、一体何がおきているのか分かりませんでした。 ただ、2599データと2798データの間に改行のみの空行を入れてみたところ、今度はその空行が2795データの後ろ、旧ファイルの前に入ってきたことから、状況がわかりました。 考えてみれば、改行コードは関係ないか。 旧ファイルも新ファイルも、作られた環境は全てWindows。 作ったソフトがperlかawkかVzか、という違いはありますが。 ファイルサイズは、旧ファイルも新ファイルも150KB前後。 となると、妖しいのは1行の長さかな。 でも、全く無関係のファイルに新ファイルを挿入しても状況は再現しない。 一方、先頭に挿入しようとしている旧ファイル、挿入するファイルによっては状況が再現することがある。どういうときに再現するかはまだ追いきれていませんが。 これからいろいろと試してみたいところですが、何か情報があればご提供いただけると幸いです。
やっと時間が取れて、ちょっと試しています。 まず、作業ディレクトリはD:\WWW\BBS ここに挿入されるファイルというか、後ろに下がるほうのファイルのファイル名は0006.CGI、100行強、約170KBです。 このファイルの先頭に挿入するファイルのファイル名は0006.CG、約80行、130KBほどです。ファイル名は同一で拡張子で区別しています。 0006.CGIの先頭は以下のようなものです。 2515... 2534... 2554... (後略) そして、挿入する0006.CGの末尾は、前回も書きましたが (前略) 2599.... 2798.... 2795.... [EOF] こうなっています。[EOF]の前には改行が存在しています。 まず、0006.CGIを開きます。そのまま、他に何も操作をせず、カーソルが先頭行の行頭にある状態で[ESC]Iを押下、ファイラーから0006.CGを選択しリターン。すると通常、カーソル位置は変わらないはずなのですが、なぜかカーソルが動く。具体的には、2599から始まる行の行頭、数字の2の上にカーソルがあります。そこで、^[->]で行末に飛んで、さらに一文字分、右にカーソルを動かすと、そこで2515から始まる行の行頭となっているのです。これは表示の問題だけではなく、そのままファイルを保存すると、この結合部分は (前略) 2798... 2795... 2599... 2515... 2534... 2554... (後略) となります。 これは非常に高い確率でこうなるのですが、でも、100%ではない。 たとえば、上記の作業ディレクトリに、さらにひとつディレクトリを掘って、D:\WWW\BBS\TESTというディレクトリで同じことをしたところ、1回だけ、.CGファイルの50行目ぐらいのところが挿入位置の直上に回った、なんてこともありました。ところが、ごくまれに再現することはありますが、非常に再現率が低い。何らかのバッファの問題かな、と思い、例えば作業ディレクトリ名を長くしたり短くしたりしても、ほとんどは上記に記したとおりの、高い確率で起きる事象になります。また、マクロバッファについても、マクロをたくさん搭載していようがほとんど消そうが、ごくまれに発生するという状況は変わらず。 なお、上記の.CGIファイルと.CGファイルの関係を逆にして、.CGファイルの先頭に.CGIファイルを挿入する際も、正しくない挿入が高い頻度で起きます。一方で、これら掲示板ログと関係ないファイルを挿入したりされたりする場合には、このような妙な現象は一切発生していません。これらのことから、掲示板ログ特有の、長すぎる行が存在していることが潜在的な原因のひとつではなかろうか、と、今の所は考えています。でも、念のため行の長さをチェックしたけど、挿入される.CGIファイルで一番長い行でも3800バイトぐらい、.CGファイルで一番長い行は2400バイトくらいなので、これはちょっとハズレかな。 今後の予定。 ファイルサイズを小さくして、どのくらいの行数なら事象が発生するか、発生する場合としない場合の境界となるデータは何か、その行の改行コードは、あるいはファイル全体のサイズとか行数は、といったことを探索していこうと思っています。
遠くにある保健所の応援業務に行っていたのですが,いやはや疲れました。
泊まり込みのホテル療養者支援と連日日帰りの保健所応援とで比べると,身体は後者のほうが疲れそうだけど,前者は精神的にきついかもしれません。
さて,派遣される前日に残業して帰ってきて,遅い時間帯に
#4609 へのコメントを書いたはずだったのですが,寝落ちしたらしく,送信できていませんでした。
翌朝は早いから夜のうちにと思ったのですが,なんとも間の悪いことに,ちょうど更新ダウンロード後の再起動を促されていて電源を切ってしまいました.普段ならいつも休止状態で終了するので,書いている途中でも残っているのですが,完全に電子の藻屑……。
確か,自分は上村さんの insfile.def を愛用していて製品版は長いこと使っていないこと,ek の設定により振る舞いが変わってくる可能性があること,そもそも単一ファイルを挿入するのか複数ファイルなのか不明なこと,……などなど書いていたように思います。発生頻度が高ければ速攻でトレースということになるのでしょうけど,たまに起こることだと別の要因も考えられ VZ の動作にとどまらない可能性もあるのかもしれないな…などとも思いました。
としきさんの2番目のコメントだと,想像するところ……挿入するのは単一ファイルで,挿入するファイルの中身が行単位で撹拌されて貼り付けられる……と読めるのですが,ふつう有り得ない話なので,そういうことではないはずだとアレコレ想像をめぐらせてしまいます。いや,読んだままの話なのでしょうか。
ちょっと謎。
案外,テンポラリファイルの扱いの問題とかあるかもしれないので,VZ そのものの版を替えたり別の環境に変えてテストしてみる必要も出てくるのかな…と思います。
実は,HP200LXの後釜として購入したMicroPCでは,VZ による編集でファイルがひどく破損するという事象を頻繁に経験していて,これはなかなか恐ろしい状況なので毎日記録して蓄積してゆく健康管理関連ファイルを別のアプリケーションで管理しています。(要するにMicroPCを調達した意味がひどくあやふやと言うか,意味がないと断言してしまえる一歩手前の状態。)
[4613 ]
Re^3: MicroPC上のVZ環境は
konno
2022/02/11(Fri) 21:13
[
4611 ]へのコメント
めざらさん> 実は,HP200LXの後釜として購入したMicroPCでは,VZ による編集でファイルがひどく破損するという事象を頻繁に経験していて,これはなかなか恐ろしい状況なので毎日記録して蓄積してゆく健康管理関連ファイルを別のアプリケーションで管理しています。(要するにMicroPCを調達した意味がひどくあやふやと言うか,意味がないと断言してしまえる一歩手前の状態。) VZのバージョンが気になります。(^^; VTDOS環境などでは、マクロがそのまま動かない場合もあります。 私は毎日使っているので、気になります。(^^; 再現性があれば検証してみたいです。
VZの版は,t03k k07t01 でした。 が,そもそも環境がきちんと構築できていないのですよ。(^o^; 入れている DOS(6.3) の command.com が認識されていないのか,VZの子プロセスでプログラムが全然走らない状況なのです。 それどころか(順序が逆かも) dir とかの内部コマンドが実行されない。 当然のことながら clppst.exe や rcp32.exe も実行できないので,他のアプリとの連携もファイルのバックアップもできない状況です。 こんな経験は初めてで,かなり行き詰まっちゃってますね。 dosvaxj3 とか ms-dos player で解決できる気も全然しないので,今のところ試していません。
[4619 ]
Re^5: MicroPC上のVZ環境は
konno
2022/02/13(Sun) 01:31
[
4615 ]へのコメント
> 入れている DOS(6.3) の command.com が認識されていないのか, > VZの子プロセスでプログラムが全然走らない状況なのです。 > それどころか(順序が逆かも) dir とかの内部コマンドが実行されない。 PATH が通っていないような感じですね。 為念ですが Xp以降のPATHの設定とかは、コントロールパネルのシステムの環境変数で システム>詳細タブ>の下のほうに環境変数があります。 Win10では 設定>システム>詳細情報>詳細設定>の下のほうに環境変数があります。 ユーザーとシステムの2つあるので、私は VZDEF の記述は両方に入れてました。 PATH が途中で切れていないか、環境変数が効いているか、 SET で確認してみては。
> PATH が通っていないような感じですね。 うーみゅ,環境変数のことを忘れてるかな……. なにしろ,レガシーコンソールのことも忘れていたくらいだし,可能性大。 仕事から帰ってきたら,アルコール注入しながら確認してみます。 ありがとうございます。
> PATH が途中で切れていないか 以前からそうでしたが,レガシーコンソールでは PATH は常に途中までしか表示されませんけど,konnnoさんの環境ではDOS窓でpathを実行すると,PowerShell での $ENV:path の実行結果と同じ長さまで表示されますか? 常用機(Thinkpad X1c)の場合,VZの子プロセスで何の不自由もないのですが,コマンドプロンプトで path を実行すると途中までしか表示されません。追加のパスはVZの起動バッチで path=%path%;c:\;c:\vz を実行しています。たぶん通ってると思われ。 MicroPC には Thinkpad の環境をそのまま複写して(レガシーコンソールのことは忘れてたのですが…)一見普通に起動できています。ですが,色々と予期せぬ不都合が発生しているというわけなんですね。もう何が何やら。(^_^; そのようなわけで,せっかく入手した MicroPC が依然として活用できていないという具合なのです。近ごろはようやくスマホにも慣れたので,空き時間の時間潰しに困ることはありませんが,あくまでも時間潰しなので,あまり創造的な気分に浸れていないなぁ……再任用期間の満了後は時間も相当ありそうなので,四月から野良仕事だけだとちょっと勿体ないなぁ……なんてね。
[4627 ]
Re^7: MicroPC上のVZ環境は
konno
2022/02/14(Mon) 23:01
[
4625 ]へのコメント
PowerShell は使ってないですが、私のところでも PATH は途中で切れています。 それで、切れたところは DOS で読めていない気がしています。 なので、DOS用の PATH は、先頭に書いていますし、DOS専用にしています。 今は DOS専用の表示になっていますね。 VTDOSの起動BATは $XSET path=c:\vz;c:\ut;c:\;c:\windows;c:\windows\system32; $XSET VZDEF=C:\VZ\VZ.DEF 起動BAT で環境変数セットしても、コマンドラインで反映されていない事もあります。 なので、全てのプラットフォームで環境を揃えるまでは出来てないです。
> それで、切れたところは DOS で読めていない気がしています。 うーむ,そうだったのですね,なるへそ。 試しに path=%path%;c:\vz; の環境で他のディレクトリに移動してから vz ディレクトリにある vmap を実行しようとしたら,確かに通っていませんでした。今の今まで,c:\vz をカレントにしていたから出来てただけだったのか!なんという認識不足……お恥ずかしい限りです。 それで,旧環境のまま vz起動バッチで path=c:\vz;%path%; にしてみてからvzを再起動し,コマンドラインでsetを実行して確認すると目出度くパスが通ったことが確認でしました。しかし,dosコマンドは実行できず。(setとかpathは実行できるのにdirは実行できない。内部コマンドも色々なんですな。いまだにdosもわかっていない。) さて,次の段階として,vtdosの拡張コマンドを試しました。 (実は $XSET の書式が理解できていなくて,使っていませんでした。) VTDOSのautoexec.batに $XSET path=アレコレ を記載して再起動したvzのコマンドラインでパスを確認すると c:\vz; の部分がダブっています。そりゃそうだ。 この段階で dir とか他のコマンドも実行できていませんでした。setで表示されたcomspecはvtdosのディレクトリに置いたcommand.comを指していますが,駄目だったんだなぁ…… 第三段階。vtdosの拡張コマンドでpathを指定する状態にしておき,vz起動バッチの方からpathの指定を削除。パスも通り,ダブりも解消されました。 ここで dir 実行してみると,今度は遂に実行されました。\(^o^)/ vzマクロから呼び出したclppstも実行できるようになり,どうやらMicroPCも他の環境と同様になりつつあります。 いやいや,ほんと,konnoさんのおかげです。 これで他の不具合(編集中に @S などalt+英字にアサインしたコマンドやマクロでテキストが破壊されるというもの)が解消されるといいんだけど。 こっちはちょっと違う気もするなぁ…… alt+英字にアサインしたものを実行すると,Windowsが警告音を鳴らしてくるんですよ。音を出す設定のままのMicroPCで気づいて,他の環境でも全部そうだったと知って,なかなかの衝撃でした。うちだけ…ですよね?
ぅぉ、なんかチェック項目が増えている。
あ、いや、みなさん、いろいろとお気遣いいただき、ありがとうございます。
次にまとまった時間が取れるのは早くて14日の午後なので、きちんとした何かが報告できるのは14日の夜以降となってしまいます。
で、きちんと整理されていないことを、今ここでいくつか書きます。
まず、
#4609 の段階では、同じ入力、すなわち一定の挿入するファイルと挿入されるファイルを使っている限り、同じ結果になりました。なので、マクロが被疑だと思い、既知の事象かどうか質問させていただきました。が、どうやら既知の事象ではなさそう。
その後、ログファイル整理用のディレクトリでいろいろなファイルがごちゃごちゃしているところからスッキリしたディレクトリにファイルを移動したところ、同一の入力であるにもかかわらず、結果が一定にならないことがあることに気がついた。これが
#4610 です。結果が一定にならないということは、バッファの変動に影響を受けているのではないか、というのが今の所の私の妄想。
で、もしかしたら手がかりになるかもしれないことをひとつ、書き漏らしていました。何かファイルを開いてそのままカーソルを動かさずにファイル先頭に別のファイルを挿入した場合、異常動作が発生しないときは、カーソル位置は動かないというか、挿入されるファイルの先頭の行頭のままになりますよね。これはみなさんの所でも同じだと思いますが、もしそうならないというのであればご指摘ください。
これが、うちで異常動作が発生するときは、カーソルが動く。どこに動くというかというと、1論理行上の行頭。つまり、挿入するファイルの、順番が狂ってしまった最終行先頭。これは、異常動作の結果が不定であるにもかかわらず、このカーソル位置が1行上という状況は、少なくとも今の所は常に一定。
と、いうことで、数日後になってしまいますが、可能な範囲でいろいろと網羅的に調べてみたいと思います。結構、案外、やっているうちに事象が再現しなくなってしまった、みたいな事もあるかもしれませんが。
余談。
> 遠くにある保健所の応援業務に行っていたのですが,いやはや疲れました。 お疲れ様です。
なかなか感染症の流行も収まりませんね。
うちの職場では、先週、初めての陽性者が出ました。
100人前後が在籍する職場で、今まで陽性者が出ていなかったのは奇跡に近いかも。家族が感染したとかで濃厚接触者はポコポコ出ていたんですがね。平均年齢が50歳代後半という高齢化した職場なので、みんなそれなりに慎重だったということもあるかもしれません。あと、一応、ワクチン接種率がほぼ100%だったので、それが功を奏したのかもしれません。
[4618 ]
Re^4: ファイルの挿入
konno
2022/02/13(Sun) 00:45
[
4616 ]へのコメント
としきさん 生ログの改行が、LF のみになっているとか無いですかね。 マクロで誤動作の原因になることがあったような気がします。
とりあえず、ここだけ。> 生ログの改行が、LF のみになっているとか無いですかね。 だいたい、0D0Aになっている模様です。全部の行はチェックできていませんが。 挿入するファイル、全部でおよそ80行あって、最初の行と最後の行、それと途中の行を適当に10行ぐらい、伝説のバイナリエディタであるところのBzで確認しました。 一応、大元のファイルの作成がWindows上のPerlであり、さらに行単位の加工を行ったのがやっぱりWindows上のawk、そして最終仕上げの編集がVzエディタなんで、未確認の行もおそらく大丈夫でしょう。
[4631 ]
Re^6: ファイルの挿入
konno
2022/02/15(Tue) 01:58
[
4629 ]へのコメント
> > 生ログの改行が、LF のみになっているとか無いですかね。 > > だいたい、0D0Aになっている模様です。全部の行はチェックできていませんが。 うーん、私の書き方が良くなかったですね。 ファイル中に LF のみの改行が一つでも混在していると、検索で問題が出ることがあると思うのです。 実際にサーバーから戻したファイルなどでトラブったことがありました。> 挿入するファイル、全部でおよそ80行あって、最初の行と最後の行、それと途中の行を適当に10行ぐらい、伝説のバイナリエディタであるところのBzで確認しました。 > 一応、大元のファイルの作成がWindows上のPerlであり、さらに行単位の加工を行ったのがやっぱりWindows上のawk、そして最終仕上げの編集がVzエディタなんで、未確認の行もおそらく大丈夫でしょう。 チェックは目視だったのでしょうか。 私はVZで開いて、"\l" を "\n" に置換することで、LF の数が分かると思っていました。 でも今回は別の原因なのかもしれないですね。
> チェックは目視だったのでしょうか。 そのとおりです。> 私はVZで開いて、"\l" を "\n" に置換することで、LF の数が分かると思っていました。 おぉ、そうだ、そんな方法があった。 と思って、早速試してみましたが、該当ファイルにおいて、LFはひとつもないことが確認できました。 ありがとうございました。
[4634 ]
Re^8: ファイルの挿入
konno
2022/02/17(Thu) 01:27
[
4633 ]へのコメント
> > 私はVZで開いて、"\l" を "\n" に置換することで、LF の数が分かると思っていました。 これ、実際に試してみたら CRLF($0D0A) が ↓ ^MCRLF($0D0D0A) になってしまいました。(>_<) 一度、"\n" を "\l" に全置換してから "\l" を "\n" に全置換しないと駄目なんですね。(^^; その時の置換数の差で、LF の数がわかると。
> 一度、"\n" を "\l" に全置換してから > "\l" を "\n" に全置換しないと駄目なんですね。(^^; もしかして、これか?
なんか、原因の一端というか手がかりがつかめました。
konnoさんのアドバイスのおかげです。
いや、なにかというと、
#4631 でkonnoさんにアドバイスをいただいたとおり、"\l"を"\n"に全置換したら0個を文字列を置換したということだったので、
#4633 でLFはひとつもない、と回答しました。
でも、それではうまくないらしい、ということが
#4634 で判明したので、まず、"\n"を"\l"に全置換しました。結果、挿入されるファイル、挿入するファイルともに80個だとか104個といった数だけ置換されました。ところが次に、"\l"を"\n"に全置換しようとしたところ、いずれも0個完了という結果が出て、あれれ?
これは、通常.defでの結果です。
そこで、製品版.defで試してみたら、"\n"と"\l"の双方向で同じ数字になりました。すなわち、"\l"単独の改行はない、ということが確認できました。が、しかし、なぜこれらの.defの間で相違があるのか。
探索するまでもなく、すぐに判明。
通常.defの場合、検索オプションが OPT:CZX になっているのですよ。
でも、製品版.defの場合、検索オプションは全フラグが倒れている。
そんなに手間でもなかったので総当りで試してみたところ、全角半角同一視のフラグが立っていると、"\l"を"\n"に変換できない模様。
え〜、そんなことあるんだ〜、と思って、念のため、通常.defで検索オプションを変えつつ何回もファイル挿入をやっていたら、検索オプション無しのときに1回だけ、正常に挿入に成功したんですよ。もしやこいつが、と思ったのですが、同じ設定でもその後は失敗、頻繁に起きるタイプの異常挿入となってしまう。
とりあえず、再現性がないので気のせいレベルなんですが、もしかしてこの辺に何かが潜んでいそうな気がしないでもない。
う〜ん、なかなか追いかけがいがあるなぁ。
> ファイル先頭に別のファイルを挿入した場合、(中略) > 挿入されるファイルの先頭の行頭のまま(略) ek(
http://mezala.la.coocan.jp/vz/notes/vars.html#EK ) の設定により異なります。それは「異常動作」ではなく,正常な動作です。ただし,マクロの側でどのように処理されているかによって結果は異なります。製品版[ESC]I の場合は,巨大ブロック対応として,(ek)?? #B という部品が入っています。
ただし,「巨大ブロック」と言っても,常にテキストスタックのサイズを超える場合とは限らないというのがわかりにくいところです。でも,比較的小さなファイル(数KB未満)くらいで「巨大ブロック」扱いになるケースがあるとすれば,異常動作かもしれません。テキストバッファの設定も関連するのかなぁ……。ここはちょっと記憶の外で,簡単にはたどり着けない感じ。
えと、ここ、よくわからない。
記憶が確かなら、ekはゼロです。が、それはさておき。
ekが同一の値であるにもかかわらず、ペースト後のカーソル位置が異なるというのが正常動作ということでよろしいのでしょうか。
ekの挙動であるところの、カーソル位置の更新というのがよくわかっていないんですよ。
あと、
#4609 にも書いたとおり、使っているのは製品版のマクロです。
真っ先に疑ったのがマクロの挙動ということもあり、自分の使っているvz.defと製品版のvz.defを\[F03]で比較しましたし、[ESC]Mで変なマクロをインクルードしていないかはチェックしています。
改行コードについては、頭から信用している部分がありますので、あとで改めてチェックしてみましょう。
> ekが同一の値であるにもかかわらず、ペースト後のカーソル位置が異なるというのが正常動作ということでよろしいのでしょうか。 #4620 は一般的な挙動の話で,それを吸収するために製品版[ESC]I はこうなっている,…という内容です。ek が定まった値であれば,通常は異なるマクロを使っても同一の結果が期待されているのが常識だと思います。結果が異なれば,マクロの仕様というか用途が異なるものでないか確認が必要ですね。
> ekの挙動であるところの、カーソル位置の更新というのがよくわかっていないんですよ。 そりゃもう,ek の値を [ESC]@ とかを使って変更してからブロックを貼り付けてみれば一目瞭然です。ただ,ブロック全体の先頭と末尾の話なので,それほど大きくもないブロックで影響が出るというものではありません。通常は貼り付け後の位置を前提として次の処理が行われると問題が出てくるという話なので,今回の製品版 [ESC]I の場合は関わってくる可能性は低くて,あくまでも念の為の動作の検証用という意味でした。
完全に、自分の頭がこんがらがっている、ということが認識できつつあります。
> #4620 は一般的な挙動の話で,それを吸収するために製品版[ESC]I はこうなっている 読み直してみて、こちらは理解できました。
ごめんなさい。そしてありがとうございます。
でも
> そりゃもう,ek の値を [ESC]@ とかを使って変更してからブロックを貼り付けてみれば一目瞭然 こちらがよくわからない。
おっしゃるとおりにek0とek1を切り替えながら貼り付けているのですが、どこが変化するのか全くわからない。
これ、何か条件があります?
あ、わかった。
単一行の行ブロックで実験していたから変化がないんだ。
複数行で実験して、やっとわかった。
まさか、単一行と複数行で挙動が違うとは思わなかった。
これって、うちの環境のせいなのかな。
それとも、製品版でもそうなっているのかな。
とりあえず、今回問題としているファイルの挿入に当たっては、複数行の挿入にもかかわらず1論理行だけカーソルが上に動くということなので、どちらにしても明らかに違和感のある挙動。これは追求しよう。
ということで、おそらく、午後3時ぐらいからいろいろな実験に着手できそう。
時間的に無理かな。
さて、どんなことになりますやら。
> 単一行の行ブロックで実験していたから変化がないんだ。 いやいや,単一行ブロックでも挙動は同じはずです。 ん?! アレコレ(と言っても,ファイル名の変更とか保存と行末移動だけですが)やっているうちに, VZ(184B) 184B:149A 'REPNE SCASB 命令ラップアラウンド' アプリケーションでエラーが発生しました。VTDOS を復帰します C:\VZ> …などという表示が出ました。 これは一体どういうことだろう? おや,編集画面なのにこれはコマンドラインだぞ,なにこれ。 まるで和生さんの詐術の再現のようになっている……あ,復帰しないや(笑) COMMAND(10C3) 184B:A237 '無効命令 CE' ですって。あ,落ちた。 以上,実況でした。
[4628 ]
Re^9: ファイルの挿入
konno
2022/02/14(Mon) 23:34
[
4626 ]へのコメント
> VZ(184B) 184B:149A 'REPNE SCASB 命令ラップアラウンド' > アプリケーションでエラーが発生しました。VTDOS を復帰します VTDOSでこれが出ると VZは強制終了になっています。 特定のマクロなどでたまに出るんですが、MSDOS Pleyer では動いたりするんですよね。 私も今回の実験で一度出ていました。 [F06] 検索窓に、"\l" LF($0A) を入れて改行の検索すると 上の CRLF($0D0A)にはヒットしますが、下方向にはヒットしませんよね。 これが誤動作の原因にもなりえると思ったので、色々実験してみたのです。 VTDOS環境で 特定の生ログファイルの末尾の改行を削除して、改行を "\n" から、"\l" に全置換すると 半分ほどしか変換できなくて、途中で止まって、[Fn]+[BREAK]で戻ったり(マクロループ?) そのファイルの末尾でカーソルなど動かしていると、"^@" が画面に出てきたり、色々おかしくなったり これらの雑多な実験時に、一度上記のエラーが出たようです。 MSDOS Pleyer ではこの現象は再現しなかったような。 環境が違うので、何がどうとは一概には言えませんが。 そういえば、としきさんは VTDOS なのでしょうか、DOS窓なのでしょうか。
[4644 ]
VTDOSのEMSの不具合?
konno
2022/02/20(Sun) 21:08
[
4628 ]へのコメント
> > VZ(184B) 184B:149A 'REPNE SCASB 命令ラップアラウンド' > > アプリケーションでエラーが発生しました。VTDOS を復帰します > VTDOSでこれが出ると VZは強制終了になっています。 > 特定のマクロなどでたまに出るんですが、MSDOS Pleyer では動いたりするんですよね。 > 私も今回の実験で一度出ていました。 これ、VTDOS.CFG を見たら SCASB_MODE=0 になっていました。 SCASB_MODE=1 にしたら、エラーは出なくなりましたが、動作に異常があります。 挿入ファイルが途中までしか入っていません。改行で区切られてはいますが。 381081byteのファイルに380844byteのファイルを挿入して、761925byte になるはずが 759882byte になっています。2043byte が失われました。 VTDOSでは、試した全てのVZで同じ状態になりました。 MSDOS Player や DOSVAXJ3 は問題ないです。 &t でトレースしてみたら、ブロック移動ループの途中で挿入ブロックが切れてきました。 つまり、ファイル末までブロックがかからなくなってきたということです。 そして、何回目かの #y の行削除でVTDOSが落ちました。 SCASB_MODE=1 にしても、同じ個所までしかファイル挿入されずに終了しています。 その直前の行が、1行で 4551byte ありました。 試しに、EMS無しで、XMSだけでVZ起動してやってみたら正常に終了しました。 試した全てのVZでこのマクロが正常に動作したのです。 これは、VTDOSの EMS とVZの間に問題があるということでしょうか。 この問題は、これ以降は私の掲示板で続けます。 としきさんの場合も何か参考になれば幸いです。
結局、あんまり進捗していないのですが、でも、少しはわかったこともある。 環境は、自宅内のネットワーク接続の関係で、いにしえのWindowsXP32bit。 これのcommand.comです。一応、VTDOS1.22も入っていたのですが、状況は 同じでした。Vzは1.60t03k。 command.comを新しく開き、vzを常駐させ、他の作業を何もしない全く最初にファイルを開き、続いてすぐにファイルを挿入させても事象は再現しました。 ところが、vz.comのバージョンはそのままに、製品版のvzibmj.defとvzfl.defを持ってきて起動させると、異常な事象は発生しません。 ということはつまり、私の常用環境がおかしい、ということ。 とくに、editfileを使っていますから、何らかの影響がありそう。 おそらく、editfileを初期化すれば、当面の問題が解決できそう、かもしれません。でも、何が原因でこのような異常動作が起きるのかというのがトンと見当がつかぬ。 あと、editfileって、バッファをおかしくするようなことってできましたっけ? オプションの状況を変更できるというのは覚えていますけど。 えと、なんだっけ、オプションの一覧を表示するマクロってありましたよね。 とりあえず、今日の所はここまで。 原因不明のまま対応完了でもいいけど、好奇心の強い私としては、可能な範囲で原因を追究してみたいという強い思いは抱いていたりしています。
なんかどうもよくわからない。
> とくに、editfileを使っていますから、何らかの影響がありそう。 editfileが原因、というわけではなさそう。
以下、テストディレクトリをカレントにしての実験。
editfileなしで私の通常使っている.defで、事象は再現。
一方で、1.60t03k + 製品版vzibmj + editfile を使って vz @ で起動した場合には、事象は再現しない。
これ、正しいeditfileを読めているか否かは、ファイルオープンとか検索文字列の履歴で確認しているので、ここに間違いはありません。
ということはすなわち、私の使っている.defが悪いことまで特定。
あとは、.defの中に入っているマクロが悪いのか、それとも何らかのオプションとかバッファが悪いのか、という問題です。
ひとつ確認。
めざらさんやkonnoさんのところでどうなるか教えてほしいことです。
[ESC]Iの挿入マクロの希望される動作としては、すなわち正常動作としては、マクロ終了後のカーソル位置、すなわちファイル挿入完了後のカーソル位置は、起動したところから動かない、ということでよろしいのでしょうか。
それは違います、ということになると、単なる私の空騒ぎですから。
で、まぁ、私の考えていることが仮に正しいとして。
今回の実験では、今のところ、
#4610 でいうところの「非常に高い確率」の事象しか発生していません。具体的にどうなるかというと、
#4610 でいうところの挿入されるファイルの先頭、「2515」から始まる行の行頭にカーソルを置いて[ESC]Iで挿入マクロ起動、ファイルを挿入という手順で、この場合、マクロ終了後のカーソル位置、すなわちファイル挿入完了後のカーソル位置は、やっぱり「2515」から始まる行の行頭であることを期待しています。
つまり、
#4610 の図を利用すると
2515...
2534...
2554...
(後略)
こういうファイルの先頭に
(前略)
2599....
2798....
2795....
[EOF]
こういう風に終わっているファイルを挿入すると
(前略)
2599...
2798...
2795...
2515...
2534...
2554...
(後略)
というファイルになって、カーソル位置は「2515」の行頭にあることを期待しているわけです。ところが実際には
(前略)
2798...
2795...
2599...
2515...
2534...
2554...
(後略)
という並び順になって、カーソル位置は「2599」の行の行頭にある。
これ、カーソル位置から上を見ると、2795とか2798で始まる行が直上にあるという部分は同じなので、ついうっかり、ファイル挿入が正常に終わったような気になる。でも、実際にカーソルが置いてある場所を見ると、希望とは違う結果になっていることがわかるわけですよ。これ、ちょっと怖い。
ということで、editfileがシロということはわかりました。
今後、引き続き、どういうデータだと再現するか、ということを追求して、そこから逆算というか、バッファないしマクロをどうすればいいかというところまで、たどりつけるとイイナー。
> [ESC]Iの挿入マクロの希望される動作としては、すなわち正常動作としては、 ek- 対応で,ブロックのトップ/エンドポインタの処理はしてありますから,実行後のカーソル位置は「見かけ上変わらない」のが正常な実行結果です。 起動したところから「動かない」わけではなく,ek- の場合は挿入した行ブロックの先頭にあったカーソルを末尾に移動しています。 ブロックのエンドポインタはブロックの内部ではなく外側にあるので,元のカーソル位置にとどめられるというのが所期の動作だと思います。 ただし,起動した位置が行の途中の場合は,論理行先頭に移動します。 行の途中に行ブロックを貼り付けることはできないからです。 ところで,としきさんはトレースしてみました? 発生する頻度が高ければ,原因はともかく,どのように動作した結果なのかは特定できますよね。また,「editfile がシロ」の判断は少し早いかも。
> ek- 対応で,ブロックのトップ/エンドポインタの処理はしてありますから,実行後のカーソル位置は「見かけ上変わらない」のが正常な実行結果です。 > 起動したところから「動かない」わけではなく,ek- の場合は挿入した行ブロックの先頭にあったカーソルを末尾に移動しています。 ここがよくわからない。 私の環境というか過去の経験というか、この辺の差異が理解できない。 つまり、ek+のときは何が違うのだろう、ということ。 とりあえず、行ブロックを前提として。 こうすれば違いがわかります、という例を教えてください。> ただし,起動した位置が行の途中の場合は,論理行先頭に移動します。 > 行の途中に行ブロックを貼り付けることはできないからです。 これは理解できました。> ところで,としきさんはトレースしてみました? していません。というか、すっかり忘れていました。 あとで試してみます。> また,「editfile がシロ」の判断は少し早いかも。 これはどういう根拠から? 仮にeditfileがクロだとしたら、editfileを読んでいないときに再現する理由がわからない。原因は2つある、ということかな。 それとも、ヒストリーの再現性からeditfileを読んでいないと判断したわけですが、ヒストリーは再現しないけどeditfileを読んでいるということはありうる、ということでしょうか。
これだけ話がすれ違うということは,前提にしているものが異なると考えるのが妥当だと思いますので,基本的な認識に相違がないか確認させてください。記載したキーに割り当てたコマンドは製品版と同じとします。
■行ブロック
^B(または [F10])によってブロックモードに入った後,【最後に】上か下にカーソルを動かした(あるいは実際にはカーソルは移動しなくても [UP] または [DOWN] キーを押した)状態のブロック(mb==1),もしくは,その状態で ^Y(または [F08])や ^KK(または \[F08])に割り当てたコマンド(
#47 や
#49 )によりテキストスタックに格納され,ブロックタイプ情報(kp.-3)が'1'を示すブロック文字列。(kp はオフセット値のみを用いてのアクセスができない別のセグメントにあるため,通常は特殊関数 &Bm を用いて取得します。)
(製品版 [ESC]I は行ブロックでの挿入を仕様としています。したがって,挿入される位置は必ず起動した行の先頭であり,挿入されるブロックの末尾には必ず \n があります。)
■ek(ブロック貼り付け後のカーソル位置更新)
ek の値はいつでも変更可能で,初期設定値は 0 (- : 無効) です。
ek- 時,貼り付けたブロックの先頭にカーソルが残ります。
ek+ 時,貼り付けたブロックの末尾にカーソル位置を更新(#B実行相当)します。
(ブロックは選択した方向に関係なく,ブロックの先頭から順にテキストスタックに格納され,格納しきれないときは残った部分のブロック指定を解除せず次の命令待ちになります。ブロックの先頭ポインタは残った部分の先頭に移動します。つまり,巨大なブロックを貼り付ける際には,ek-では不都合が生じます。カーソル位置が更新されていないと前へ前へと貼り付けられてしまい,テキストの中身の順序が破壊されるからです。製品版 [ESC]I はそれを回避するために,ek-なら貼り付けた都度カーソル位置の更新を行っています。)
ここまではマクロでなく,手動によるコマンドのみの操作になります。
この前提はよろしいでしょうか。
> > また,「editfile がシロ」の判断は少し早いかも。 > > これはどういう根拠から? 根拠はないので「かも」です。
過去,経験上ですが,テキストが破壊される原因の多くは editfile の異常です。なので,わたしの中では常に「シロ」にはしません。それだけですが。
> これだけ話がすれ違うということは, まず、ここからして不一致、というか。
私自身の認識としては、話がすれ違っている、ではなく、めざらさんが説明されていることを私が一方的に理解できていない、と思っているのですよ。
> 前提にしているものが異なると考えるのが妥当 この部分の認識は一致しています。
で、まぁ、ここから先に進む前に。
私がこのツリーを起こしたのは、
A.私の期待していた挙動
B.実際に発生した挙動
この2つが不一致だった、ということからでした。
ところが、ここまでいろいろとお話を伺って、さらに
C.本当に起こるべき挙動
というのがあり、私はAとCが同一だと思っていたのですが、もしかするとそれが私の認識の誤りなのかもしれない、というところまでは理解できてきました。これが、めざらさんのおっしゃるところの「話のすれ違い」ということなんでしょう。
と、ここまで私の認知の衰えを開示したところで、やっとこの先に進みます。
> ■行ブロック この部分、文字で書かれているところに関しては、認識は一致しています。
ただし、
> (製品版 [ESC]I は (略) 挿入される位置は必ず起動した行の先頭 この挙動は、私の過去の経験に一致しています。
これがまさに、私が
#4632 で確認したかったことでもあります。あと
> 挿入されるブロックの末尾には必ず \n があります。) この部分、知識としては知りませんでした。
過去の経験からなんとなく、そうなんだろうな、とは思っていましたが。
ただ、ひとつ、認識の不一致なのかな、うまく確認が取れていない部分があります。
&Bmで取得できるブロックモード。
これって、テストマクロを書かないと取得できないのですか?
テキストスタックに文字ブロックしか入っていない状態で、[ESC]Mの窓に&Bmとかって放り込んでも、常に'1'しか帰ってこないんですけど。
あと、もうひとつ、私の根本的な疑問からはちょっと外れてしまうのですが、派生した疑問があります。
ブロックモードにしてもしなくてもいいのですが、カーソルを動かさずに[F08]を押すと、カーソルのおいてある論理行が1行、テキストスタックに入りますよね。これも行ブロックの扱いでよろしいのでしょうか。
> ■ek(ブロック貼り付け後のカーソル位置更新) これについては、全く知らなかった部分です。
自分では、意識的にek+にしたことがなかったんだと思います。
実際に試してみて、やっと少し差異がわかりました。
> この前提はよろしいでしょうか。 たぶん、よろしいと思います。あまり自信はない。
でも、いろいろと確認して、やっと少しわかってきました。
お手数をおかけしました。
> テキストが破壊される原因の多くは editfile の異常 そうか、テキストが破壊されているのか。
ここも前提が不一致というか。
テキストが破壊されているという認識がなかったのですよ。
あくまでも、マクロの挙動不審、というところで、おつむが凝り固まっていたようです。
急ぎで1点だけ。> [F08]を押すと、カーソルのおいてある論理行が1行、テキストスタックに ブロック指定がなければ,行ブロックではなく,単なる「行」という扱いです。 ブロックタイプは0です。(行ブロックの方は1。) &Bm を実行してrに戻される値は次の通り。 r = 0:行, 1:行ブロック, 2:文字ブロック, else:矩形ブロック> &Bmで取得できるブロックモード。 > これって、テストマクロを書かないと取得できないのですか? [ESC]@ で確認するなら,【&Bm&m("%d",r)】のように簡易マクロを書けば,一瞬ですが結果を得られると思います。 ん? 製品版の [ESC]@ は&e() ([Eval]:与えた文の評価)を実行するだけなので,もしかすると関数の結果をうまく表示できないかもしれませんが。
> [ESC]@ で確認するなら,【&Bm&m("%d",r)】のように簡易マクロを書けば, instant.defで確認できました。 私、誤解していたんですよ。instant.defなら、関数の戻り値もそのまま表示できるものと。でも、戻り値はrに入ってくるだけなんですね。 なお、製品版の「マクロ文」では、上記の簡易マクロでも表示されないことを確認しました。 さて、夕食後に時間は取れるかな。 もし時間が取れれば、ファイル挿入マクロのトレースに取り掛かります。
> > ところで,としきさんはトレースしてみました? > していません。というか、すっかり忘れていました。 やっとトレースしてみました。 最初にトレースしたとき、これは酔っているせいなのか、と思ってしまいました。確かにそのときはアルコールが入っていたけど。 まず、環境はWinXP32bitとVz1.60t03k。これで command.com + 製品版.def command.com + 常用.def VTDOS1.22 + 常用.def の3つを試してみましたが、結果はいずれも同じでした。 また、いずれもVzは常駐させたのですが、command.com + 常用.defのパターンだけはVz非常駐でも同じ結果でした。 挿入しようとしているファイルは ファイル名:0006.CG、80行、132473バイト 挿入されようとしているファイルというか、ファイル先頭にカーソルを置いてマクロを起動するファイルは ファイル名:0006.CGI、104行、170231バイト これらの数値はコマンドラインからwcコマンドで計測しています。 拡張子が異なります。 以下では区別のため、.CGファイル、または.CGIファイルと表記します。 以下、実況です。 まず、Vzを常駐(または起動)させて、既存の小さなファイルを開いた場合、または新規ファイルとしてnulをオープンして、今回問題になっている妖しい.CGファイルをファイル先頭に挿入。問題は起きません。.CGファイルの最終行が、挿入されたファイルの先頭の直上にきちんと来ます。 次に、.defファイルの&sを&tに書き換えて再度Vz常駐。 既存の、.CGIファイルをオープン。 そして、[ESC]Iで.CGファイルを指定。 リードオンリーで開いて、文末までブロック指定。 1回目のカットで「ブロックが大きすぎます」メッセージが出ます。 続いて、.CGIファイルにペースト。 :Cのラベルのある行の後ろのほうの#Bによりカーソルはブロック末尾にジャンプしますが、行ブロックですから、ブロック末尾の次の行、すなわち.CGIファイルの先頭にカーソルは存在します。 さらに、ウィンドウが切り替わって2回目のカット。再び「ブロックが大きすぎます」メッセージが表示。 ウィンドウが切り替わってペースト、そして#Bで・・・あぁっ。 1回目はブロック末尾の次の行にカーソルがきちんと飛んだんですが、今度はブロック末尾の改行記号の上でカーソルが点滅している。 そして再びウィンドウが切り替わり、3回目にして最後のカット。 .CGIファイルのウィンドウに切り替わり、行末で点滅していたカーソルが、その行の行頭にジャンプ、そしてその上に3回目でカットされた2行がペースト。 そのままマクロ終了。 ということで、なぜか#Bがきちんと機能していないように見えることが、今回のマクロの動作不良の原因のように思えます。 また、上記で事象が再現しなかった小さいファイルのファイル先頭への.CGファイルの挿入も試みてみましたが、3回とも#Bはきちんと機能していました。 念のため、カーソルが点滅していた改行記号について、もう一度バイナリエディタで覗いて見ましたが、普通に0D0Aでした。 この、カーソルが行末で点滅していた行そのものは長さ約2550バイトほど。 この行に何かの問題があるかと、長さを80バイト弱にまで削ってみると、なんと。 カットペースト3回ではなく2回でファイル挿入は正常に完了したのですが、マクロ終了時に、やはりカーソルが正規の位置ではなく、一つ前の行末で点滅している。うむむ。 と、ここまで事象は特定できました。 めざらさんのアドバイスのおかげです。 ん〜、やっぱり使ってもいないeditfileが原因なのかなぁ。 .CGファイルに原因があるのなら、なぜ他のファイルに挿入しようとしたときに事象が再現しないのか。 全くもって、原因でないものを排除というか棄却できない。 まずは、#Bがうまく機能しない条件、というのがあれば教えてください。 あるいは、途中でこの変数を表示してみれば、みたいなデバッグ方法のアドバイスとか。
[4649 ]
サイレントモードでの #_
konno
2022/02/23(Wed) 22:14
[
4648 ]へのコメント
> まずは、#Bがうまく機能しない条件、というのがあれば教えてください。 探してみたら、こんなものがありました。
> 05665/05668 xxxxxxxx Emmett VZBUG(2) サイレントモード関連のバグ > (15) 97/04/15 10:58 > ■ VZバグ大全(2):サイレントモード関連のバグ > (A)サイレントモードでの #k または #y の反復 > サイレントモードで、非ブロックモードでの行記憶またはカット(#k、#y)を連 > 続して実行すると、ある特定の点までくると、テキストスタックに格納される文 > 字列の最後が化けることがあります。 これは非ブロックモードの話なので、今回は違うかもしれませんが
> (B)サイレントモードでの #_ > どうやらサイレントで実行された #_ は、特定の条件下でカーソル位置ポインタを > 算出しまちがえるらしい。 > このトラブルは、 #_ 直後に #? などで最終行を一度表示してやれば回避するこ > とができます。これは #_ 直後でなければ駄目で、#38 のあとでは遅すぎます。 > ・サイレントでの #_ のあとには #? &s > と習慣づけておくといいでしょう。 どうやらこれが関係ありそうです。
高橋版でもこのバグは潰しきれなかったような気がします。
[ESC]I @I "I カーソル位置へ挿入" のマクロを
; #b #_ (ct)?{ #> #m #x }
#b #_ #? &s (ct)?{ #> #m #x }
このようにするか、&s を取ってしまうと、改善がみられました。
前回と同じ条件で実行して、ファイルサイズが一致するようになりました。
ただし、中身はおかしくなっているようです。
これはおそらく VTDOS の EMS がらみの不具合と思われます。
詳細は私の掲示板に上げます。
> > ■ VZバグ大全(2):サイレントモード関連のバグ 大いに関係はありそうです。
が、直接には関係ないはず。
なぜかというに、
#4648 より
> 次に、.defファイルの&sを&tに書き換えて再度Vz常駐。 なので、サイレントモードに入っていないのですよ。
とはいえ
> > 特定の条件下でカーソル位置ポインタを > > 算出しまちがえるらしい。 なんとなく、こういう状況にはまってしまっているらしい。
> [ESC]I @I "I カーソル位置へ挿入" のマクロを > > ; #b #_ (ct)?{ #> #m #x } > #b #_ #? &s (ct)?{ #> #m #x } 私の場合、
:C #y (mb)?{ #W #< #i (ek)?? #B #W >C }
ここの#Bがうまくいっていないので、さてどうするか。
逆に、その「特定の状況」というのが特定できれば回避方法もあるかも。
原因を特定するにはまだ分からないことが多いので,
まずひとつ潰すところからやってみましょうか。
次のマクロは,製品版に相当する機能を持つ自分の常用マクロです。
これは #B を使っていないので,サイレントと非サイレント両方で
実行してみていただけるでしょうか。
なお,シフトキーを押しながら I を押すと元ファイルを削除して
しまいますので,くれぐれもご注意ください。
= t
*m
9 [ESC]I "Insert a File" ; H_ear
?. (mr==$80)?{ &m(36) . }
(tc-wc)??{ &m(6) . }
#if 98
(ks&16)
#else
(ks&4)
#endif
?{ &z("insfile") >* }
k1&ks, c=wc, &m("%s to %s",mg..2..2+5,wa+146)
(wt)?{ #W b=id, } #R #m
:a (s)?{ &c >a } (wc==c)?{ &m("cancel") . }
&s #_ #> #b #^ #< ek[+,
:b #k (mb)?{ #W #< #i #W >b } #C
(wt)?{ &#T(-b) #W } #i ek], &d
(k)?{ #E &?("del %s",wf+$92) #m #[ k=px, }?k"",
&m("ins %4s%s",k,wf+$92)
*
所謂XPモード的なものとエミュレータ上で結果が同じということなので,
環境よりも VZ(高橋版含む)により近い部分から確認してみたいですね。
> この、カーソルが行末で点滅していた行そのものは長さ約2550バイトほど。
念の為,以下の変数(バッファサイズ)の値も確認しておきたいです。
Bl(ラインバッファのサイズ: 初期値=2048 設定範囲=256~8192
Bt(テキストバッファのサイズ(KB)): 初期値=64[KB] 設定範囲=16~64
※BlはBtの指定サイズの128倍の値であること
テキストスタックに複写する際に,テキストバッファサイズの境界付近に
たまたまラインバッファサイズを超える長い行が存在した場合の振る舞い
(結構レア?)に係ることかもしれないですね。「新発見」かも。
> 原因を特定するにはまだ分からないことが多いので, > まずひとつ潰すところからやってみましょうか。 お付き合いいただき、ありがとうございます。
あいにく、この週末は忙しくて、あまり進捗していません。
> これは #B を使っていないので,サイレントと非サイレント両方で > 実行してみていただけるでしょうか。 「サイレントと非サイレント両方」というのができていませんが、とりあえずの現状報告。
#4646 と
#4651 のマクロをそれぞれ、insfile.defおよびt.defという単独のファイルに書き出しました。そして、次の2つの環境で試してみました。
・command.com + 常用.def + 非常駐Vz
・VTDOS1.22 + 常用.def + 常駐Vz
常用.defの場合、Blは8192、Btは64になっています。
まずcommand.comで、Vz常駐させてinsfile.defを\[F11]の外部マクロメニューからファイル選択で読み込むと、何か異常動作となりました。ここは深く追及する時間もなかったので、新たにcommand.comを開きなおし、以下、非常駐Vzで実験。まず真っ先にinsfile.defを読んで^K^でマクロ読み込み、その後にファイル挿入を実施しても異常動作は発生せず。
同様に、t.defも同じようにVz起動後、真っ先に読んで^K^で組み込み、ファイル挿入で異常動作は発生せず。
さらに、VTDOSでも、Vzを常駐させたことを除け以下同文。念のため記述すると、Vz常駐、それぞれのマクロを読んで^K^、その後にファイル挿入で正常動作。
今後の予定。
まず、t.defを書き換えて、サイレントと非サイレントで実行させてどうなるか。
もうひとつ、command.comでVz常駐からのinsfile.def読み込みでの異常動作に再現性があるか、それと、Vz常駐で^K^で組み込んだ場合はどうなるかの確認。
ただ、一体いつできるのか。早ければ明日の夜にはできそうだけど。
やっと、その後の追試ができました。
環境はWinXP32bitとVz1.60t03k。
command.com + 製品版.def
command.com + 常用.def
VTDOS1.22 + 製品版.def
VTDOS1.22 + 常用.def
先の発言で、XPのcommand.comの常駐Vzで外部マクロメニューからinsfile.defを読んだら異常になった、という事象ですが、その後いくら試しても再現しません。ということで、以下、共通項目として、Vzを常駐し、0006.CGIを開いて、ファイル先頭にカーソルを置いた状況で外部マクロメニューからファイル挿入マクロのファイルを読み込む、という手順をとりました。
#4651 のマクロはt.def、それに対しサイレントモードに入らないマクロはt2.defとしました。
結果。
全てのパターンにおいて、外部マクロ読み込みによるファイル挿入では正常なファイル挿入となりました。また、vz.def内のファイル挿入の場合、製品版.defでは正常なファイル挿入でしたが、その他のパターンでは異常なファイル挿入となりました。
konnoさんの考察と合わせて、ここまでの暫定的な推測。
#Bが、何かおかしい。
特定のファイルを開いているときに、別の特定のファイルを挿入する場合だけ、異常動作が起きる。挿入するファイルは同一でも、すでに開いているほうのファイルが異なる場合には事象が発生しないことから、何らかのバッファの使用状況に依存する可能性がある。
ん〜、こんなところかなぁ。
今後の予定。
常用.defと製品版.defでbtなんかの値を入れ替えて再現実験。
[4660 ]
Re^12: ファイルの挿入
konno
2022/03/04(Fri) 23:55
[
4657 ]へのコメント
> 全てのパターンにおいて、外部マクロ読み込みによるファイル挿入では正常なファイル挿入となりました。また、vz.def内のファイル挿入の場合、製品版.defでは正常なファイル挿入でしたが、その他のパターンでは異常なファイル挿入となりました。 同じ環境なら同じ結果が出るはずと思い> VTDOS1.22 + 製品版.def これに合わせて、 VTDOS1.22 + command.com(MSDOS6.2) + Vz1.60t03k + 製品版VZ.def(Bl8192) この環境で実験した結果、ファイルサイズが 1バイト増えて、 78行目から81行目まで行が入れ替わっていて後は一致、となりました。 うーん、メモリの配置位置とかかなぁ? ちょっとでも環境が違うと結果が違うような感じですかね。
> うーん、メモリの配置位置とかかなぁ? 現在、私も、これを疑っています。
なぜかというに、
#4610 に書きましたが、
> 1回だけ、.CGファイルの50行目ぐらいのところが挿入位置の直上に回った、なんてこともありました。ところが、ごくまれに再現することはありますが、非常に再現率が低い。 ということがあったからです。
きちんと調べていませんが、たぶん、1回目のペーストのときにカーソルが前の行の行末に位置していたのでしょう。あるいは、カット&ペーストの回数が3回どころではなく5回に分かれていたとか。それはないか。
このときも、他のファイルを開いてはいませんでしたが、いろいろと他の作業をやったあとのことでしたから、例えば、コンソールファイルのサイズが違ってくることによって何らかのバッファの使用量が変わってしまって、ということがあるのかもしれません。
でも、世間的に、かつてはXPにおいて高橋版は結構な数が使われていたはずで、それにもかかわらず#Bの異常が報告されていないのは不思議。
ということで、めざらさんに賛成、というか、editfileの影響、というところに1票。
> editfileの影響、というところに1票。 自分で言い出しておいて申し訳ないのですが,としきさんが editfile を使われていないということを存じなかったので,いまさらですが editfile は【このケースでは】シロなんじゃないですかねぇ……。 で,位置ポインタが問題になっていると考えて実験をしていたのですが,自分の環境(1.60t03k k07t1)において出ている現象を,他の環境でも確認していただけるでしょうか。マクロではなく,生の編集モードで確認します。 まず,確認に必要な表示オプションを変更しておきます。 Dn(表示行で行番号を表示)の値を有効(+)に変更 We(編集テキストの表示桁数)の値が80(初期値)であることを確認 表示行番号にしておくと確認が面倒になりますが,0007.CG の論理行で3行目行頭に移動します。^[→] [→] ^[→] [→] でその位置になるでしょう。 80桁で表示行番号では,67表示行目と確認できるかと思います。 さて,その位置から,論議行末に移動しようと ^[→] を実行すると…… わたしの環境では,論理行末に飛べない場合が発生します。ただし,常時ではありません。飛べないときは大抵,表示行の1行目のままで,カーソルのX位置はこの論理行の最後の表示行の行末位置と同じです。 この論議行末に飛べないとき,ステータスラインの表示行番号は103とか表示されています。ただし,その位置から再度 ^[→] を実行して論理行末に移動できたとき,表示行番号の103と表示されたままです。[→] で次行頭に移動すると,表示行番号は104と正常に更新されます。 …ということは,生の編集モードであっても行バッファの更新が行われておらず,なんらかの行バッファを更新するアクションがあって「表示」が更新される。つまり,疑似的なサイレント状態にあるわけですね。これは例えば,ページ単位で移動する場合などにページめくりの単位がテキストのトップ/エンドでクリアされない処理に少し似ているように感じます。 そう考えると,サイレントか非サイレントかということは関係がないとは言い切れないけれど,もっと奥深いところ……VZ の動作の美しさを保持するために c.mos さんがこだわったところ……にまで遡る事象なのかもしれないと思い始めています。(あくまでもソースが読めない人間の妄想でしかありませんが……) これは,あくまでも「表示」だけの問題で,実際の位置ポインタと関係がないということも十分考えられるわけですから,まるきり外してるかも。
なんか、またすれ違っている気がする。
> としきさんが editfile を使われていないということを存じなかったので, えと、私、常用.defではeditfileを使っています。Sr39です。
一方、製品版.def(VZIBMJ.DEF)だとSr5ですから、明示的に読み込みを指示してやらないと読まないですよね。なので、この辺のことを
#4632 の冒頭に明記したのですが、わかりにくい記述ですね。ここでめざらさんに誤解させてしまったかも。
ということで、今度は私が誤解しているかもしれませんが、めざらさんが誤解した結果、
> editfile は【このケースでは】シロ と判断しているだけなのではないだろうか、と愚考する次第。
すなわち、めざらさんの誤解が解消されたら「editfile はやっぱりクロ」となるのではなかろうか、ということ。
上記のとおり、これは私の誤解である可能性も高い、という点に留意。
> で,位置ポインタが問題になっていると考えて実験をしていたのですが,自分の環境(1.60t03k k07t1)において出ている現象を,他の環境でも確認していただけるでしょうか。マクロではなく,生の編集モードで確認します。 私の試した環境はWinXP32bitとVz1.60t03k。
command.com + 製品版.def
command.com + 常用.def
VTDOS1.22 + 常用.def
この3つの環境で
> わたしの環境では,論理行末に飛べない場合が発生します。 この挙動は1回も発生しませんでした。
command.comではそれぞれ2〜3回しか試していませんが、VTDOSでは、それこそコマンドラインでいろいろな作業をしたり、VZTOWERで遊んだりしたあとに試しても発生しませんでした。とはいえ、10回までは試していない。せいぜい、5〜6回。
ただ、そういう挙動が発生する、という前提の下では、その後のめざらさんの推論は正鵠を射ているような気がします。
あ,環境によって Sr が変わりますよね。そりゃそうだ。> この挙動は1回も発生しませんでした。 ふむ,そうですか……。 アクセスログファイルとか,1行がひどく長いものだと,うちではちょいちょいあります。同時に読み込んでいるファイルの大きさとか種類とかも,おそらく影響するとも思われるので,今回に限らず気に留めてみてください。 それにしても,原因の特定が難しいですね,今回のケースは……。 Emmett さんみたいにトコトン突き詰めるような人なら,こういうとき対象がぎゅぎゅぎゅっと狭めてゆくのですけど,洞察力に乏しいからなぁ……わたし。 Emmett さんといえば,多言語を扱えるアプリケーションに移行していたということですが,近ごろ視力を重度に失いつつあるということでした。わたしも中心性網膜脈絡膜症で,黄斑変性症になる危険が非常に高いので,他人事ではありません。皆さんも眼を酷使しておられるでしょうから,お互い気を付けましょうね。
> でも、世間的に、かつてはXPにおいて高橋版は結構な数が使われていたはずで、それにもかかわらず#Bの異常が報告されていないのは不思議。 10年前に中古で入手した XP 機を引っ張り出してきて実験を。 (頑丈で有名だった Thinkpad X61s ですが,HDD だかファンだかがブンブンうなっていて,流石にヤバげな状況です。この騒音はちょっと耐えられない。) 環境:Win XP pro v2002 SP3 のMS-DOSプロンプト 版A:1.60t03k (高橋版最終版) 版B:1.60t03k k07t01 (高橋版拡張金野版・安定版) 実験に使用した [ESC]I は製品版のみです。 ek- (#Bが使用される) で実行 版A サイレント=正常, 非サイレント=正常 版B サイレント=正常, 非サイレント=正常 ek+ (#Bは使用されない) で実行 版A サイレント=正常, 非サイレント=正常 版B サイレント=正常, 非サイレント=正常 それぞれ2,3回実行しましたが,すべて正常に終了しました。 実際の実行環境はあまり芳しくなくて,最初に版Aで非サイレント・トレースモードにおいて #i を実行したとき DOS窓が落ちました。その後,裏で0007.CGをリードオンリーで開いていたときなど,切り出した製品版 [ESC]I を保存した test.def を開こうとすると「メモリが足りません」攻撃が始まるなど,XP での環境はあまりよい状況とは言えませんでした。 つまり,現在に至って,わたしの環境では,としきさんが遭遇した不具合は一度も発生していません。見てみたいって興味津々なれど,至極残念なことであります。
[4667 ]
Bt62 が良いかもしれません
konno
2022/03/13(Sun) 15:53
[
4666 ]へのコメント
> つまり,現在に至って,わたしの環境では,としきさんが遭遇した不具合は一度も発生していません。見てみたいって興味津々なれど,至極残念なことであります。 ええっ!? これはビックリです! 環境によって違うのでしょうか。 私も色々試していたのですが、再検討する羽目になりました。 実は古いシンクパッドR40を引っ張り出して、Win2000のNTVDMを試しました。 CPU は、モバイルPentium 4-M 1.9GHz です。 NP2とNP2NT でも試してみましたが、その結果は・・・ Win2000 NTVDM、各種VZ、個人用VZ.DEF、オリジナルVZ.DEF 製品版[ESC]I t.def 170k EMS NG OK 170k XMS NG OK 381k EMS OK OK 381k XMS OK OK NP2-0.82,NP2-x64,NP2-NT、私家版98VZ、個人用VZ.DEF、オリジナルVZ.DEF 製品版[ESC]I t.def 170k EMS NG OK 381k EMS OK OK この結果を見て、NTVDM と VTDOS では、としきさんのデータは必ずNGになると思ったのですが めざらさんの環境ではNGにならないというので、オプションを疑いました。 オプションで真っ先に思うのが、Bt ですね、オリジナルVZDEF は、Bt64 です。 Bt32 にしても、Bt48 にしてもNG でした。もしや 16kの境界で問題が出るのでは それで、思い切って、Bt62 にしてみたら、OK になりました。 今まで試した全ての環境で、Bt62 にするだけで、OK になるんです。 [ESC]@窓で、「Bt62」と入れるだけでも、その後の実行では OK になります。 今までは、としきさんか私のデータのどちらかで必ずNGになっていたのが、全部 OK になったのです! Bt63 でも OK になるみたいですが、Bt61 では、私のデータで、NG でした。 たまたま Bt62と Bt63の数値が2つのデータで問題が出なかっただけかもしれませんが しばらく Bt62 で運用してみようと思います。
いや,何と言うか,konnoさんの柔軟性って凄いですね。 まるでタコのような柔軟性と言うべきでしょうか。 Btの取りうる値を16-64と示されたら,ふつう2の累乗であるべきなんだろうと固定的に考えちゃいますよね。そもそもメモリの潤沢なマシンで64から減らそうなんて思わないでしょうが。う〜ん畏れ入りました。 やっぱりメモリなんですかねぇ。 手元で発生していないと,なんだか腑に落ちないけど。 としきさんとこでは改善しますか?
> としきさんとこでは改善しますか? ごめんなさい、ちょっといろいろあって。 おそらく、次の土曜日までには、まとめていろんなことを書く事になると思います。ということは例によって、無駄に長い文章になりそうな予感。 短い文章で思ったことをぽつぽつと書いていければいいんですけどねぇ。
[4670 ]
Bt62 常用は危険かも
konno
2022/03/15(Tue) 23:46
[
4668 ]へのコメント
> いや,何と言うか,konnoさんの柔軟性って凄いですね。 > まるでタコのような柔軟性と言うべきでしょうか。 いやあ、今は腹がつかえて全然ですよ、って、そっちじゃないって?> Btの取りうる値を16-64と示されたら,ふつう2の累乗であるべきなんだろうと固定的に考えちゃいますよね。そもそもメモリの潤沢なマシンで64から減らそうなんて思わないでしょうが。う〜ん畏れ入りました。 多分、無知で常識が無いからだと思います。(^^; やっぱり、Bt62 は、常用するのは危険があるかもです。 LXSCHD.DEF で、Bt64 で問題あったのが、Bt32 で解決したことがあったので Bt62 で試してみたら、駄目でした。 これの場合は、サイズを増やしていくと、64k の手前で内容がおかしくなるので 64k の境界の問題だと思います。 めざらさんの 環境が良さそうなので、参考にしたいと思います。 OPT_LST.DEF の結果を教えてもらえないでしょうか。 製品版VZ.DEF + Bl8192 での結果も知りたいです。
> 製品版VZ.DEF + Bl8192 での結果も知りたいです。 Bl8192 よりも先にすべて製品版の環境から試してみようと思いました。 ただし,製品版初期値のbm8192の指定は,ラインバッファが8000hのアドレスのメモリをまたいでしまい,別の要因と見誤る可能性があるので bm30000 で起動。 出ました出ました,うちんとこにもついに不具合がっ! .CGI の先頭に .CG を製品版の [ESC]I で挿入してテキスト比較すると…… 55行までは正常に挿入され,次の行は「2843<>」で始まるべきところ,「、ぐちゃぐちゃしていて、頭がいろんなことを考え」のように段落の途中から挿入されています。これは本来どこにあるものかと言うと,32行目の途中ですね。 ……と思ったら,おやおや,正常に元の位置に戻れない。スクロールして元にもどろうとすると,大量のカタツムリ……いやいや,これはヌルだ。一時ファイルが破壊されていますね。再起動しても状況は同じです。 で,ようやくここに来て,大きな記憶違いをしていたことに気付きました。 先般から EDITFILE と言っていたのは,テンポラリファイルの間違いです。 ごめんなさい > としきさん
#4671 のタイトルを変更しました。以下,同様にタイトルを付けます。
前回(#4671)では,bm30000 のみ変更の結果,テンポラリファイル破壊。
> 製品版VZ.DEF + Bl8192 での結果も知りたいです。 今回は,Bl を8192と大きく確保して実行しました。結果,不具合あり。
この段階での不具合は,としきさんの遭遇している状況と類似しています。
1回目のカット&ペースト … 正常(#Bでの位置ずれはない)
2回目 … 異常(#Bで前の行末に移動)
(見た目だけかもしれないが,ステータスの情報でも78行76桁の不正位置。)
3回目 … ペースト直前の#<で78行頭へ移動し,その不正位置にペースト。
終了後比較では78行目と79行目の行スワップを確認。
動作は異常だが,テンポラリファイルの破壊はなかった。
前前回(#4671)では,bm30000 のみ変更の結果,テンポラリファイル破壊。 前回(#4674)では,Bl8192 の変更を加えての結果,#Bに不具合発生。 今回は,ek を+で実行しました。結果,正常終了。 ek でのペースト後位置更新は,何の値を使っているのだろう? 本来は #B と同じ値を使っていると思われるのに。 自分としては,ek+ の方が動作としては格段に自然だと感じるのです。だって,トランプを切るとき,ふたつに分けた山の一方の一部をもう一方の山に乗せたとき,元の山の頂はもう見えないですよね。つまり新しい山の頂は更新されています。それが自然なのではないかと思います。どうして ek- がデフォルトだったのでしょうね。不思議でたまらない。(後付で気付きましたが,メモリの上位ってのはテキストの見ため下なのだけど,概念としては上に積んだわけですし。) 大きく脱線して何が言いたいかって言うと,ブロックペーストしたあと本来の位置ポインタはブロックのの末尾(上位メモリ)に移動しているのに,わざわざ戻しているんじゃない?てこと。マークとポイントの交換って,どういうコードになってるのだろうか……まるっきり外してるかもしれないけど。
第1回(#4671)では,bm30000 のみ変更の結果,テンポラリファイル破壊。 第2回(#4674)では,Bl8192 の変更を加えての結果,#Bに不具合発生。 第3回(#4675)は,ek を+で実行しました。結果,正常終了。 今回は,EMS を2ページだけ使う指定にします。Bl と ek は初期値に戻します。 実行結果は正常終了。 おや……,Bl 関係なくて,メモリ(一時ファイル生成場所か)の問題? EM3 でも結果は同じでした。……ふむ。 逆にわからなくなってきたかも……
第1回(#4671)では,bm30000 のみ変更の結果,テンポラリファイル破壊。 第2回(#4674)では,Bl8192 の変更を加えての結果,#Bに不具合発生。 第3回(#4675)は,ek を+で実行しました。結果,正常終了。 第4回は,EMS を2ページだけ使う指定にしました。Bl と ek は初期値に戻す。結果,正常終了。 めったに不具合に遭遇しないので,最初に戻ってやってみたら,また出た。 .CG を開いたら「メモリが足りません」が出て,一旦すべてのファイルを閉じて再度実行してみると,先頭にいきなり .CGI の1行目があって,こりゃいよいよ変だなと思ってカーソルをびゅぅぅぅぅと動かしたら, 「VZ(18CD) 18CD:09D2 'REP MOVSW 命令ラップアラウンド'」で落ちた……。 メモリの転送を繰り返していたら枠からはみ出し,落ちるのか…… そもそも,挿入前の1行目がそのまま残ってるて何なん?
> で,ようやくここに来て,大きな記憶違いをしていたことに気付きました。 > 先般から EDITFILE と言っていたのは,テンポラリファイルの間違いです。 どひゃ〜!
いま明かされる衝撃の真実!
いや、かなりびっくり。
いろいろと書こうと思っていたことがあらかたすっ飛んでしまいました。
ということで、今回の発言量は事前の想定の約半分です。
ちょっと動揺が隠せないので、まずはひとつ質問。
先般まで、私、製品版.defファイルだとデフォルトではEDITFILEを読まないという認識もあって、EDITFILE使用有無の切り分けを行っていました。で、ここで巻き戻して、テンポラリファイルの使用有無のオプションて一体なんでしたっけ。製品版の.defファイルでは、デフォルトではテンポラリファイルを使いますよね。
次。
ひとつ、konnoさんが私に思い出させてくれたこと。
#4630 で書きましたが
> えと、なんだっけ、オプションの一覧を表示するマクロってありましたよね。 これ、OPT_LST.DEF でしたね。
どっかにしまいこんでありますので、のちほど、私の常用.defの値をお知らせいたします。
で、まぁ、ここまでのまとめ。
今回、ファイル挿入時の挙動から#Bの動きがおかしいと発覚したわけですが、その後、
#4663 でのめざらさんの報告もあわせて愚考するに、カーソル移動に関するポインタ演算がおかしくなることがある、ということが大元の原因のように見えます。ただ、それのトリガは現時点で不明、と。
そこで、めざらさんにお願い、というか。
あのバッファとこのバッファと、あれとこれとそれが同じ領域とか同一のセグメント、みたいな情報って、めざら資源のどこかにあったような記憶がありましたが、掲載されているページを教えてください。なければ、こちらに書いていただきたいかな。テキストバッファと同じ領域にあるバッファの一覧、でもいいですけど。つまり、それらのうちのどれかの値を変えれば挙動が変化するかどうかを確認したい、という意味です。
もうひとつ、
#4663 でカーソル移動の異常動作を認知されているわけですが、例えばこの挙動、ファイルがどの程度まで小さくなっても再現する、というのを追えますか?
例えば、最後の1行を削除するだけでも再現しなくなった、とか、最初の5行しかないファイルでも再現する、とか、なんかのバッファのサイズあたりが境界、とか。
あと、もはや妄想レベルかもしれないけど。
同じバージョンのVzと同じ製品版の.defを使って、さらにOSまで同じ、例えばXpを使ったとしても挙動が一致しないことがあると仮定するなら、そのとき、それぞれの環境の何が違うか。それはまさに環境というか、それこそ環境変数なんかが異なるわけですよね。そういうものに左右されるなら、これはまさに、めったに出会えないような不具合である、と。
今後の予定。
実家のPC-98とVistaのcommand.comでどうなるか、ちょっと試してみたい。
PC-98だと、メモリの使い方が大きく異なると思うので、まず発症しないと思うけど、それの確認。Vistaのほうは、常用.defはほぼ同じとはいえ、長いこと触っていないので、古いバージョンというか、細かいところが違うと思う。それ以外にも、様々な環境が異なるし。でも、めざらさんのところやkonnoさんのところでも発症するぐらいだから、こちらでも発症するかな。
来週あたり、墓参りの関係で実家に1泊する予定なので、時間が取れれば実験してみたい。
> いま明かされる衝撃の真実! えへへへ。面目ない。(^_^;)ゞ
すっかり頭の中でテンポラリファイルがEDITFILEに変換されてました。
> テンポラリファイルの使用有無のオプションて一体なんでしたっけ。 使わないというオプションはありません。ビューモードでファイルをオープンしていればテンポラリファイルを作成しないので,RO- で起動すれば作られないのではないかと思います。
オプションで存在するのは,テンポラリファイルをXMSに作らない XM0 と,EMS に作らない EM0というところですね。ちなみに初期設定では XM は 0 になっています。メモリドライバの品質が影響するので,安全のために XM は 0 にしてあるとマニュアルにも明記されています。
なお,高橋版以降では,いくつもウィンドウを開く可能性を考慮して,テンポラリファイルはID管理になっていたのではなかったかな。ちょっと記憶が曖昧です。
メモリ関係のマップは「スタックセグメントマップ」(cz,dz,gz)
(
http://mezala.la.coocan.jp/vz/notes/segmap.html )だけです。
「あのバッファとこのバッファと、あれとこれとそれが同じ領域とか同一のセグメント、みたいな情報」のような vz,tz,kz それぞれのマップは作っていません。…というか作っても意味なくないですか?
スタックセグメントの中で特定のバッファがどの位置にどのくらいの大きさで配置されているかを知るには,拙作の「csegmap:バッファ配分イメージマップ出力」を使ってみてください。(あくまでもジョークマクロですけど。)
(
http://mezala.la.coocan.jp/vz/workshop/mtool.html#csegmap )
> ファイルがどの程度まで小さくなっても再現する、というのを追えますか? なかなか細かくテストはできないですが,例えば,00007.CGI の4行目は1行が3.7KBあって,先のふるまいが発生しますが,この行を別のファイルに切り出してやると所期の動作になります。単にラインバッファとかのせいではないですね。
> 今後の予定。 > 実家のPC-98とVistaのcommand.comでどうなるか、ちょっと試してみたい。 現在、実家です。 墓参りから戻ってきて、へとへと。 これから自宅に戻るのですが、その前に、忘れる前に、という感じで昨夜から試した結果をいくつか報告。 まず、OPT_LST.DEFが、どこにもないことにびっくり。 昔、PC-98で使った記憶があるのですがね。実家でも自宅でも見つからない。 圧縮ファイルも、それっぽい名前では見つからないということは、ぜんぜん違う名前で保存されているのかな。もう時間切れなので、めざらさんのところから取得している暇もない。とりあえず、自宅に戻ってから、自宅の環境のほうはアップさせていただきます。 次、Vistaのcommand.comで試してみました。 Vzは1.60t03kです。うちの環境はみんなおんなじですね。 結果、ファイル挿入位置が狂う、いわゆるNG事象発生。 へぇ、そうなんだ。なんてこったい。 最後、PC-98での結果。 こちらのVzは1.60t03k d10 k08q2 です。 konnoさんの手が入っているやつですね。 こちらでファイル挿入してみたところ、なんと、挿入位置NG事象発生。 えぇ〜?! ちょっとこれはもしかして、根が深い問題? そして、実はここで初めて、.CGファイルと.CGIファイルを間違えて、.CGファイルの先頭に.CGIファイルを挿入してしまったんですがね。その状況でも、挿入位置NG事象が発生。なんだそりゃ。 この段階で、私が疑ったことが一つ。 大元のファイルの作成はWinNTで行われています。使ったアプリはPerl。 なので、もしかしたら、Vzの処理できない3バイトコードの文字が混ざっているのではなかろうか、と。であれば当然、ポインタの位置は狂いますよね。 そういうのをチェックするツールというのが存在するというのは聞いたことがあるので、あとで探してみようと思います。とりあえず目の前にはPC-98があるわけです。そしてPC-98ではWindowsではなく生DOSですから、変な文字コードがまぎれていればデフォルトで青く表示されるはずです。さらにPC-98にはAT系と異なりスムーズスクロールという機能があるので、これでさ〜っと流してみれば見つかるかな、と思ったのですが、残念ながら2つのファイルのいずれにも、そういった文字は含まれていない感じ。 そして最後、スムーズスクロール後に気がついたことです。 ファイルオープンしてすぐにファイル挿入するのではなく、一旦^QCして^QRしてからファイル挿入すると、正常にファイルが挿入される。なんと! これはなんとなく、テンポラリファイル関係の何かが介在することが疑われる挙動。昔、ちょっと大きめのファイルを開いてテンポラリファイルエラーが出たり出なかったりするような場合に、ファイル終端まで一旦移動するとエラーを抑止できることもある、と聞いたことがあるような。でも今回はそんなに巨大なファイルでもないんだよなぁ。 この、一旦ファイル終端まで行ってからファイル先頭に戻る、ということをしたら、Vistaでも挿入位置NG事象は発生しませんでした。これから自宅に戻ってから、自宅でも試してみたいと思います。 もし可能であれば、konnoさんにもお試しいただければと。 私の今後の実験予定。 上にも書きましたが、全ての文字コードがSJISの範囲に収まっているか調べたい。もしSJIS範囲外の文字が1文字でもあり、その文字を書き換えてやれば事象が収まる、ということであれば、単にVzの仕様どおりというだけの話で終わります。大山鳴動で、私が深く頭を下げて終わる話になります。 それと、長い行をぶちぶちと切断しても事象が発生するか追いかける予定です。改行コードの分、ファイルサイズは増えてしまいますけどね。1行が××バイト以下なら発生しない、とか、1行250バイトぐらいでも発生する、というようなことがわかれば、ラインバッファとかなんだとか、少しは被疑が追い込めるのではないか、と。 あ、そうだ、そういう点でめざらさんにもお願いしたいかな。 行末にカーソルが移動できない、というやつ。 例えば、50キロバイトのファイルだと発生しないけど70キロバイトのファイルなら発生する、ということであればなんとなく64キロバイトのあたりが怪しいよね、ということになりますし。でも、50キロバイトのファイルでも発生する、とか、70キロバイトのファイルでも発生しない、ということであれば、それはそれで謎は深まるばかり、という感じですけど。
ずいぶん昔作った漢字の化けてるとこを見つけたり直したりのマクロです.
まだ使えるかどうかわかりませんが…….
=== kataware.def 漢字片割れ探索 === by H_ear
*m
89 ^^ "" ; 漢字断片を捜して修正支援
?. mp[, ps[=pa, Jd[-, Je[-, &s
:A (ct<2)?{ ss-, #d (r)?>Z &> &s >A }
(ck||ct-3)?{ #d >A }
((cd<$80 || cd>$EA) || (cd>$9F && cd<$E0))?{ #d >A }
&d #d c='@',
:B &o(c)
&m("【発見しました】 [↓]:次候補 [↑]:前候補 [CR]:決定 [ESC]:中止")
:P ep[+, &p ep],
(r==#x)?{ c++, (c>$FC)? c=$40, &01 >B }
(r==#e)?{ c--, (c<$40)? c=$FC, &01 >B }
(r==#[)?{ &01 &m(" 中止しました。") >Z }
(r==#m)?{ &m(" 決定しました。^QL でキャンセルできます。") >Z }
>P
:Z Je], Jd], ps], mp], #?
0: (ly>wy-3)?{ &s ky-, &d }
1: &s #h #F #x #u #m &o(pa.0) &d
;*
;=== k1byte.def === by H_ear = 2バイトコードの1バイト目のみ出力
;*m
89 ^\ ""
?. a=mg.-9, fr+, &j(1) &g("全角1文字",14) &Cr (r==-1)?>Z (r==-2)? >^
&Sn(pw) (r-2)?. &Jk(pw..0) (r)??. &o(pw.0)
:Z (a)?. mg.-9=0, &j(-1)
*
:Z (直前のFEPの状態がON)?. mg.-9=0, &j(-1)
> ちょっとこれはもしかして、根が深い問題?
なんだか,終わりが見えない感じになってきましたね.
どういうテストをしたら原因が特定できるのが判然としないということが一番の問題かも.
ラインバッファとか64kの境界を跨ぐとき…みたいなことだと思うのですがね.
死にかけています。 年度末始にこんなに多忙だったことなんて、全く記憶にない。 ということは二十数年ぶりとか生まれて初めてとかって言うレベル。 年度末始ではなく年末始なら、これに近いレベルは数年に1回くらいあるのですがね。 職場のほうはたかが知れているというか、至急対応の故障修理が日常業務なんで、事務処理とか統計処理が大量に襲って来ようがなんとかなる。とりあえず残っている案件は、締め切りが判然としないものが1件と4月28日が締め切りのもの1件だけ。とは言いつつ、後から後から増えてくるんですけどね。 問題はプライベート。 順次、処理は済ませているのですけど。 3月に届いた郵便物で未開封の封書がまだ3つくらいある。 中身はどうせわかっているから、と後回しにしているのだけど、緊急案件が同封されていたらどうしよう。 3日ほど前に届いた郵便小包、さすがに必要に迫られて、今日これから開封する予定。 その他に締め切りが見えているものとして、4月15日が締め切りのものが1件と4月末締めのものが少なくとも2件、ゴールデンウィーク明けというか5月上旬のものが1件。 あとは、可及的速やか、というカテゴリに入るのですが、ハンカチへのアイロンがけとか、結構どうでもいいものが多数。 これだけ忙しいと、普通なら現実逃避としてVzに向き合ったりするのですが、もはやそんな余裕すらなくなっている。時間の余裕というより、心の余裕ですね。とはいえ、全く何もしていないかというとそうでもなく。 まずは思い出したことから。 先日、実家に行ったとき、実家に構築してあるPC-98の常用環境では実験済みです。が、余裕がなかったせいですっかり忘れていたのですが、実家にはPC-98用の製品版が残っています。次がいつになるかわかりませんが、できればこいつでも試してみたいと思います。 次。> 一旦^QCして^QRしてからファイル挿入する これ、自宅でも試してみました。 Xpのcommand.comだけですけど、確かに、正しく挿入されました。 挿入NG事象は発生しません。 一方で、ファイルオープン直後のファイル挿入では、以前と変わらず挿入NG事象が繰り返される。ということは、ファイル挿入マクロのコードから考えるに、既にオープンしているほうのファイルを操作することにより、次にリードオンリーでオープンするファイルの挙動が変わる、ということ? テンポラリファイルに関係するとしても、これはちょっとなんか直感に反する挙動です。 長い行を分割して試す、というヤツですが、挿入するファイルだけではなく、挿入されるファイルのほうも分割して試す必要があるようです。 そして、文字コードを疑っている件。 めざらさんにもマクロを書き込んでいただきましたが、全く試せていません。 私の記憶では、21世紀になってからですが、ニフティの通信系かテキスト系のフォーラムで、機種依存文字の話題から、ユニコードを含めてテキストをチェックするツールというものに話題が展開していった気がするのですがね。そういうツールは見つからないようなので、どうやら記憶違いだった模様。あるいは、そういうツールがあったらいいね、といった話で、ツールそのものは実在していないとか。
オプションの値を全部出すのもきりがないので,関係の有りそうなメモリ関連とその他のオプションの指定状況です。 Bt64 Bf64 Bo32 EM1 XM0 SW3 RM0 Bm1024*30(起動時オプションで -bm30000 を指定) Ba0 Hs256 Hf256 Hx128 Bl1024*8 Bc1024 Bu256 Bv0 ek+ 平凡だと思いますが……どこか違いますかね。
[4673 ]
Re: メモリ関連のオプション
konno
2022/03/19(Sat) 00:20
[
4672 ]へのコメント
> 平凡だと思いますが……どこか違いますかね。 う、うーん、製品版VZ.DEF のオプションとほとんど違わないですね。 製品版VZ.DEF を、これに合わせてみましたが、やっぱり駄目でした。 STKHLPのMiyataさん版SHD によると、Sk+ にもバグがあるようです。 Sk - DOSコマンド実行前にテキストスタックをクリア ※ Sk+ で常駐直後にコマンドラインでコマンドを実行後、 編集モードでカット&ペーストをすると、テキストスタックが 破壊される。 (Ver1.6 のバグ) でも、私も Sk- なんですよね。これも関係ないか。 今わかっているのは、VTDOS と NTVDM において 1.#B を使わなければ不具合が出ない 2.EMSを使わず、XMSだけなら不具合が出ない 3.私ととしきさんのデータに限ると、Bt62 で不具合が出ない うーん、64k と、EMSの16k の境界があやしいんですがねぇ。 テキストスタックかなぁ。 あとは、CP のポインタ位置とか。
とりあえず、ここにつけます。
様々なものが遅々として進んでいませんが、とりあえず、最初に症状が顕在化した
WinXPのcommand.comのオプションの一覧を、やっと取得できました。
めざらさんのようにメモリ関係だけ抜粋するべきなんでしょうが、そういう手間も
かけていられないので、option.lstをそのまま貼り付けます。
---------- option.lst --------------------- 2022/04/17 (Sun) 18:52 --------
DOSV VZt z+ St- vw- zk-
Bt64 Bf4096 Bo32768 EM128 XM2048 Bm6456 Ba2 Hs4096
Hf4096 Hx4096 Ha128 Hw64 Bl8192 Bc1024 Bu512 Bv0
SW4 TC30 WD80 We80 PG0 RS3 Ta8 Tb4 Ci0 Co3 WL0
LC24 VM0 CA48 Sr39 Qt1800Qc100 Qw1000RM0
An$0F Ac$0B Al$0A Ah$B0 As$F0 Ao$E0 Ar$B0 Am$0E Ab$0B At$0B
Aw$0F Af$0E Ai$F0 Aj$0E Ak$0E Ag$01 Au$4F Ae$12 Ay$00 vs$00
vy$00 Ad$0F
Dl- Dc+ Dt- De+ Ds- Db- Dn- Du- Df- Dp- Dh- Dg+ Dr+ Dj- Dv+
FM58 FW2048 FV1 FS4 FO3
Ei+ Es+ Ez- Eb- Eu- Et+ Eh- Ew- Ec+ Ex- En- Ev- Ek- Ea+ RO-
Ej+ Eo+ El-
RX+ ZH+ Sx+ Se+ Sd+ Sk- Sy+ YN- Sn+ Sq- FP+ FR- FK+ FQ+ Sz-
Sc- Nd- Vb- Sv- Tv- YM- CH- Hp- Hp- lf- Is- Da- Nf-
Ce0 ml mc Ys$0F Yo$0D Yr$0E
---------- End of option.lst ----------------------------------------------
なんか、妖しそうなところってあります?
あと、関連して、めざらさんに頼みたいことがひとつ。
補完計画のほうからこのマクロを取得しようとしたのですが、なんかリンクが
切れているっぽい。
確認ならびに修正方、よろしくお願いいたします。
参考までに,メモリ関係を並べてみますので,ざっと比較してみてください。
上段がとしき環境で下段がめざら環境です。
> Bt64 Bf4096 Bo32768 EM128 XM2048 Bm6456 Ba2 Hs4096
Bt64 Bf4096 Bo32768 EM1024 XM0 Bm24175 Ba2 Hs256
> Hf4096 Hx4096 Ha128 Hw64 Bl8192 Bc1024 Bu512 Bv0
Hf256 Hx128 Ha92 Hw92 Bl8192 Bc1024 Bu256 Bv0
メモリの配分はあくまでも個人の必要性ですから,推奨される値はありませんが,
マニュアルのp35やreadme.docの第3章末の記述を参考にXMは使っていません。
あとは,ラインバッファの位置がどこになるのかですね。
ラインバッファとして使用するメモリの途中に 8000h(正負の境界)があると,
不具合を発生させる可能性があることが指摘されています。
メモリの配分を順番に足してゆくのは面倒だと思われたら,次のマクロ…
http://mezala.la.coocan.jp/vz/workshop/mtool.html#csegmap (CSEGMAP.DEF)
…で確認してみてください。(ぱっと見で,この問題は当たらなさそう。)
- aja - さんのマクロは,御本人のサイトへのリンクになっていたので,
サイトの閉鎖にともなってリンクが切れてしまいました。
確認してみて復旧につとめます。
(元データが巨大なので,応急処置しかできないかも。)
やっと時間が取れました。
まずはめざらさんの環境に合わせて試してみようとVZ.DEFを書き換えていたのですがね。
> 参考までに,メモリ関係を並べてみますので,ざっと比較してみてください。 私のVZ.DEF、なんか変。
Bf64
Bm11000
Ba0
という設定になっている。
Hwは記載がないということはデフォルト値なのかな。
でも、BfとBaの値はどこから持ってきているんだろう。
もしかして、これが原因なのか?
Bmについては、めざらさんと同じ値にするとXPのDOS窓ではメモリ不足で起動できなかったので元に戻したら無事に常駐できました。
そこで例のファイルを読み込ませて先頭にファイルを挿入したら・・・ダメ。
行の順番の狂った挿入になってしまいました。残念。
次に、自分の常用DEFに戻して常駐しなおし、CSEGMAP.DEFを実行。
結果。
Cseg map : 2022/04/27_16:49:37
0 1 2 3 4 5 6 7 8 9 A B C D E F
0 @@@@@@@@@@@@@@@XXXXXXXXXXXXXXXXX
1 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
2 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
3 iiiiiiiiiiiiiiiiiiiiiiiiiiiiiioo
4 oooooooooooooooooooooooooooooooo
5 oooooooooooooooooooooooooooooooo
6 ooooooooooooooooooooXXUUUUUUUUUU
7 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
8 UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU
9 UUUUUUUUUUUUUUUUUUUUUUUUUUSSSSSS
A SSSSSUUUUUUUUUUUU-------@@@-----
B --------------------------------
C ---:::::::::::::::::::::::::::::
D :::::::::::::::::::::::::-======
E ================================
F ==========================------
0 1 2 3 4 5 6 7 8 9 A B C D E F
ん〜、正負反転境界あたりはカットバッファとなっていますが、今回の場合、なんとなく、まさにそいつが悪さをしそうな気がするようなしないような。
ということで、これからいよいよ、挿入ファイル・被挿入ファイル自体に手を入れて、1行の最大長を短くすれば症状が発生しないことの確認に入りたいと思います。
追伸。
#4681 に書いていただいた漢字片割れ探索、使ってみましたが、.CGIファイルと.CGファイルのいずれにも、妖しい文字は混じっていないようです。
変というより,前回の値と違っていますよね。(右項が前回の値)> Bf64 ← 4096 > Bm11000 ←6456 > Ba0 ←2 > ん〜、正負反転境界あたりはカットバッファ 用語「カットバッファ」は誤解を招く表現で申し訳ないと思いますが,[del]系の削除文字列バッファです。テキストスタックではないので,一連のファイル挿入マクロでは使わないと思います。ということは「シロ」です。としき環境のラインバッファは,ずっと上位メモリにあるので問題ないと思われます。 …と言うより,正負境界は各種文字列ヒストリとして使っていますね。 ちょっと判別しづらくてすみませんが,UUUSSSUUUとなっている前側が文字列ヒストリでS(システムメニュー)を挟んで後ろ側がカットバッファ(Bc)です。 ちなみに,設定可能なマクロバッファ(Bm)の値は,以下の式で取得できます。 $fdfb+bm-pn..-26
> 変というより,前回の値と違っていますよね。(右項が前回の値) そうなんですよ。 VZ.DEFで設定している値と、なぜ異なるのか。 一応、VZFL.DEFはチェックしてみましたが、いずれも設定していませんでした。 なぜ異なってしまうのか、私にはわかりませんので、もし思い当たることがあれば、お教えいただけると幸いです。 もしかして、EDITFILEのほうが優先される、のか?> 用語「カットバッファ」は誤解を招く表現 あ、なるほど、カットアンドペーストのカットとは違う、ということですね。 了解いたしました。
> もしかして、EDITFILEのほうが優先される、のか? ええ,起動方法と Sr の設定によりますが,前の状態を再現する機能ですので。 としき環境の Sr が 39 とのことですから 0010 0111 ということで, 流石に VZ 起動時に常に editfile を参照する設定にはなっていないですが, 起動バッチが vz @ となっていれば,保存されたオプション値で動作します。 わたしは Sr は 5 で保存していますが,起動時に @ を指定していません。 特に復帰したいときだけマクロで editfile を読み込んでいます。(非推奨) Windows を休止状態で電源断するため,profile 不要なんです。 更新などで再起動したときだけ,必要に応じて…それも滅多にないです。 200LXでも再起動するということはほぼなかったですから,同じかな。
> > もしかして、EDITFILEのほうが優先される、のか? > ええ,起動方法と Sr の設定によりますが,前の状態を再現する機能ですので。 今回に限らず、現象が発現したXPのcommand.comでの常駐方法は、vz -zです。
@は全くつけておりません。が、Srに+8のビットが立っていますから、自動で読み込んでくれるています。
HDDの中に他のEDITFILEがあるかと探してみたら、バックアップを保存しているディレクトリの中にありました。そんなことはないと思いますが、間違ってそちらを読んでいないかと、もう一度、今度は以下の手順で起動してみました。
・cmd.exe起動
・command.com起動
・vzのディレクトリにchdir
・vz -zでvz起動
結果。
#4683 で書いたものと全く同じ値。
なんとなく、BfとBaについては、無効な値を指定しているのでデフォルト値を持ってきました、ということのような気がしてきました。
一応、vzのディレクトリ内をgrepかけてみましたが、Bf4096とかBa2という文字列は引っかかってきませんでした。すなわち、EDITFILEの中にすらなかった。一応、vzでEDITFILEを開いて、その中にBfやBaの設定がないことは確認しました。
Bmについては、opt_lst.defで使っている容量の分だけ値が少なくなっていることがわかりました。これ、私がopt_lst.defを正しく使えていないということなんでしょう。ドキュメントが同梱されていませんでしたので。
ちょっと試してみた結果> なんとなく、BfとBaについては、無効な値を指定しているのでデフォルト値を持ってきました、ということのような気がしてきました。 ますます、そういう気分が強くなってきました。 なにをやったかというと、vz.defでBfとBaを指定している部分をセミコロンで無効化してから新しく起動してみたのです。そしてopt_lst.defすると、 Bf2048 Ba2 という結果となりました。うぅん、なんか期待される挙動と異なる。 場合によっては、めざら資源の「VZマクロ関連覚書」に手を加える必要があるかも。 また、この辺、製品版と高橋版とkonno版で異なる、ということもあるのかもしれません。高橋さんかkonnoさん、あるいはそれ以前の誰かがさらっと書き換えて、それが余り公になっていない、という可能性を疑っています。 お手数をおかけしますが、ぜひともめざらさんにおかれましても追試していていただけませんでしょうか。 なにとぞよろしく願いいたします。
[4692 ]
Re^9: メモリ関連のオプション
konno
2022/04/29(Fri) 23:21
[
4690 ]へのコメント
としきさん> なにをやったかというと、vz.defでBfとBaを指定している部分をセミコロンで無効化してから新しく起動してみたのです。そしてopt_lst.defすると、 > > Bf2048 > Ba2 > > という結果となりました。うぅん、なんか期待される挙動と異なる。 たぶん、デフォルトではその数値になるのでしょう。 私の環境は古いノートPCに変わってしまったのですが、見てみました。 VZ.DEF の Bf は、何故かコメントになっていました。 ;Bf64 ;88 ;66;74;64 ;DOSコマンド用メモリの最小値 (KB) この状態でインスタントマクロで bf を見ると bf2048 になっています。 Bf64 に設定してVZ再起動すると Bf4096 になりました。 64*64=4096 なので、Bfは 64倍されるのだと思います。 とすると、デフォルトは、Bf32 となりますね。 一方、Ba は Ba128 ;256;1024 ;エイリアスバッファ となっていますが、インスタントマクロでは ba130 と表示されます。 Baをコメントにすると Ba2 と表示されます。 Ba2 に設定すると Ba4 になります。 Ba は、設定値+2 になるようですね。 これらは、VZの元からの仕様だと思います。 #B の検証は進んでいません。
Bf の初期値が不思議ですね。 DOS 5.0では Bf32 では command.com も動かないため,Bf64 を指定する必要がある……という話もあって,それを前提とする場合,オリジナルcomでは初期値が64で高橋版以降では32になるというのは,逆な感じがしますね。 まぁ,それは無指定の場合の話だから,問題が生じることは稀でしょうけど。 konnoさんの vz.def が色々と試行錯誤?の跡があるようで面白いですね。 開発者環境の大変さが目に見えるようです。
> Srに+8のビットが立っていますから、自動で読み込んでくれるています。 としき環境の Sr は 39 とのこと(
#4683 )ですから +8 は立ってないですよ。
> なんとなく、BfとBaについては、無効な値を指定しているのでデフォルト値を ふむ。なるほど。そういう可能性は高いですが,カスタマイズエラーにならないのかなぁ……。ならないのか。
> 私がopt_lst.defを正しく使えていないということなんでしょう。 いや,Bm の設定値が正しく出力されないのは「仕様」ですね。
単純に,Bm の〈その時点での〉空きを参照しているだけですから。
> としき環境の Sr は 39 とのこと(#4683 )ですから +8 は立ってないですよ。 あ〜、確かに。
怒涛の1ヶ月あまりが終わろうとしているのですが、気が抜けたせいか、ビットを正しく読み取ることもできなくなっている。まずい。
> ふむ。なるほど。そういう可能性は高いですが, というか、めざらさんのところではどうなりますか?
カスタマイズエラーが出るのですか?
何がデフォルト値で何が仕様どおり、というところで話がすれ違っていそうな気もするので、めざらさんのところでの結果をぜひ教えてください。
> いや,Bm の設定値が正しく出力されないのは「仕様」ですね。 うぅ、ここでも仕様の罠に引っかかってしまったのか。
そんな難しいマクロ、私に使いこなせるわけがない。と思う。
としきさん,だいぶ疲れておられるように見受けられて,ちょっと心配です。 黄金週間はきちんとお休みできますか?(日直とかあるでしょうけど)> 何がデフォルト値で何が仕様どおり デフォルト値はだいたいわかると思いますが,仕様どおりかどうかは…… めざら環境では,Bf Ba を無指定で起動したところ 4096 と 2 です。 上記はオリジナルcom 1.6 で,高橋版以降では 2048 と 2 でした。> そんな難しいマクロ、私に使いこなせるわけがない。と思う。 VZマクロは,コードが取説という噂もありますけどね。(嘘) 単に &?("Bm%u",Bm) だけなので,モジュールメニューで後から読み込んだ分のマクロ(E)のサイズを確認して,それを引かなければならないのは明らかでしょう。
> としきさん,だいぶ疲れておられるように見受けられて,ちょっと心配です。 > 黄金週間はきちんとお休みできますか?(日直とかあるでしょうけど) 今日も日勤で出社でした。 明日からあさってで、また宿直です。 ただ、会社のほうは大したことなくて。 今日も故障が少なかったおかげで事務処理がはかどり、明日も故障件数が少なければ、月締めの仕事は何とか片付くめどが立ちました。あとは5月のどこかに暗黙の締め切りがある仕事が山積していますが、こちらは文字通り全く手付かず、1バイトも進んでいません。夏休みの宿題モードです。 プライベートの事務処理も、4月締めのものは昨日までで全て終わり、5月締めのものは全くありませんが、可及的速やかというやつはやっぱり山積。もういいや。 ただ、事務処理とは全く関係なく。 今日、会社からの帰宅の電車の中で、中学生くらいの女の子から席を譲られてしまいました。たぶん、じじいだと思われて席を譲られたのは生まれて初めて、のはず。違う理由が全く推測できない、という意味で。生まれて初めて、という部分はちょっとアレですが、でも、自分の中でそれほどショックを受けなかった、ということのほうがちょっとショック。あぁ、もうそういう見かけになってしまったということなのね。もちろん、好意を無にするほど性格は悪くないので、きちんと礼を言って座らせていただきました。今でも年に数回程度はヘルプマークや妊娠中バッチをつけている人とか杖をついている人に私のほうが席を譲っていたのですが、これは相手に無用な遠慮を招いてしまうかなぁ。 さて> デフォルト値はだいたいわかると思いますが,仕様どおりかどうかは…… 黒本なり*.DOCなり*.DEFなりにデフォルトと明記してあるものが本当にデフォルトであれば、それは仕様どおりということでしょう。一方で、省略時の値、すなわちデフォルト値が、記載されているものと異なっている場合、それは仕様に外れているとかバグだとかということになると思っています。とはいえ、動いていればバグとはいいづらいという考えはわかりますし、それがいわゆる裏技というヤツかもしれません。 が、仮に製品版において、デフォルト値と記述されているものと実態が異なるものがあれば、それはやはりいささか問題かと。 また、高橋さんがデフォルト値を変更し、それをきちんと公開しはぐったものがあるかもしれません。あるいは、高橋さんが参考にしたという榊原さんの版において変更された値をそのまま準用して、なおかつ榊原さんも高橋さんも公表を忘れているとか、あるいはkonnoさんが変更したデフォルト値があるかもしれません。 もし仮にそのようなものがあるのであれば、版ごとの差異を可能な範囲で記載するように心がけているとされている「覚書」において、なるべく所収していただけるとありがたいかな、と。 ただ、私としてはこの問題、現時点ではこれ以上深追いするつもりはありません。バッファのサイズを変えても私の環境ではファイル挿入の問題が変化しなかったということがわかったところで、この方面からの侵攻はあきらめて一旦撤退し、別方面、すなわちファイルの各行のサイズを変更してみる方向にリソースを振り向けて、Vzの隠された挙動を私の掌中に収めるべく攻めてみるつもりです。
やはり,お仕事は相変わらず大変みたいですね。席を譲られたのも,相当に疲れて見えたのだろうと思います。老人に見えなくとも,立っているのが辛そうな人に席を譲った経験は自分にもありますし。(席を立って扉付近に移動し,降りる駅を間違えたふうに立ちつくすとか。すべて好意的推測に過ぎませんが。) 今回のように裏を取れていない段階で「覚書」の方に明記するのは少々難しいかもしれないですね。現象の報告とか疑念として書ける可能性もありますけれど,ソースが読めないとなかなか。 この件,ソースを比較できる konno さんなら「証言」可能かしら。
なんか、一時的にCSSを変更していたりしていました?
> やはり,お仕事は相変わらず大変みたいですね。
とりあえず、やらないと誰かに迷惑がかかる系の仕事は今のところすべて終わらせた
ので、気は楽です。残っているのは自分の評価にかかわる系のものだけなので、むしろ
締め切り後でもいいかもしれない。厳密に言えば課長に迷惑がかかるかもしれないけど、
知ったことか。それに、そもそも締め切りが知らされていなかったりする。
席を譲られたことに関していえば、大きな荷物を持っていたりとか、自分でも辛くて
それがおもてに現れていることを自覚しているときに譲られたことはあります。
とはいえ、もう数年前になりますが。でも、今回は、そのいずれにも該当していない。
なので、純粋に外見の年齢だけで譲られたと想定。
あまりにも初体験のことなので、ちょっとだけ状況を詳しく書いときます。
席を譲ってくださった方は、見た目、女子中学生。
年配の女性と並んで座って会話されていたのですよ。こちらの女性は見た目は50代
後半か60代前半くらい。ただ、私、女性を見る目がないことは自覚しています。
中学生に見えたのが実はちょっと小柄な高校生とか大柄な小学生ということもある
かもしれない。年配の女性のほうも、若い女性の母親か祖母あたりの年代だと思う
けど、どちらかは不明。車内の騒音で会話はあまり聞き取れず。楽しそうな風情だった
けど。ただ、この女の子、親の教育がいいのだろうということは容易に想起できます。
席を譲った後、この女の子は年配の女性の前に立って、楽しそうに会話を続けて
いました。
電車を降りたのは私のほうが先でしたが、あまり礼を重ねるのもアレかなと思い、
席を立ったときは会釈だけ済ませてしまいましたが、もうちょっとはっきり礼を言った
ほうがよかったかなぁ。
ところで私、デフォルト値ってVZ.DEFなんかで設定していないときに自動で設定される
値だと思っていたのですが、なんか勘違いしているかもしれません。
ためしに、WinXP常用環境のVZ.DEFとVZFL.DEFの「* Oオプション」の部分にcols.defを
使って全て行頭セミコロンで潰してみたものを使って常駐させてみましたが、とりあえず
エラーは出ずに常駐。ただ、この状態だと、マクロバッファが足りなくてOPT_LST.DEFも
起動できない。ということで「* E その他」の1番にVZFLとOPT_LSTを登録して起動させた
結果が以下のとおり。
---------- option.lst --------------------- 2022/05/03 (Tue) 18:52 --------
DOSV VZt z+ St- vw- zk-
Bt64 Bf2048 Bo32768 EM246 XM12416 Bm1026 Ba2 Hs256
Hf128 Hx128 Ha64 Hw64 Bl1024 Bc256 Bu64 Bv1024
SW1 TC10 WD80 We80 PG0 RS3 Ta8 Tb4 Ci4 Co7 WL0
LC25 VM0 CA0 Sr0 Qt0 Qc0 Qw0 RM0
An$07 Ac$05 Al$05 Ah$0D As$0F Ao$0E Ar$0D Am$06 Ab$05 At$05
Aw$07 Af$06 Ai$0F Aj$06 Ak$06 Ag$01 Au$06 Ae$01 Ay$00 vs$00
vy$00 Ad$07
Dl- Dc+ Dt- De+ Ds- Db- Dn- Du- Df- Dp- Dh- Dg- Dr+ Dj- Dv-
FM0 FW256 FV1 FS0 FO3
Ei+ Es+ Ez+ Eb+ Eu- Et+ Eh- Ew+ Ec- Ex- En- Ev- Ek- Ea- RO-
Ej- Eo- El-
RX- ZH- Sx+ Se+ Sd+ Sk- Sy- YN- Sn+ Sq- FP+ FR- FK- FQ- Sz-
Sc- Nd- Vb- Sv- Tv- YM- CH- Hp- Hp- lf- Is- Da- Nf-
Ce0 ml mc Ys$0F Yo$0D Yr$0E
---------- End of option.lst ----------------------------------------------
これが高橋版のデフォルト値ということだと思うのですが、なんか、デフォルト値の
取得方法を間違えていますでしょうか。この方法ではこの部分がまずい、ということを
ご教示いただけると幸いです。
CSS 確かにいじっていました。このツリーが随分と大きくなって,枝の起点がわかりにくくなったので,ツリー表示のインデントを変更しようとしていたところ,変更がまったく反映されなくて首を傾げていたのですが,まったく別のディレクトリにあるCSSを参照していることが発覚したので,アレコレしているときに古いCSSで一時的に表示していたと思います。CGIの関係か,ちょっと表示のタイムラグがあったことも混乱を深めていました。 オプションの初期値ですが,VZ.DEF と VZFL.DEF 両方とも *O の値を潰していれば,おそらく間違いないと思われます。EM や XM の値にびっくりしましたが…。 お仕事の方,ひどい状況でなければ,ゆるゆるお付き合いください。 よろしくお願いします。 一度,区切りをつける意味で,別のスレッドを建てていただければ吉です。
[4653 ]
Re^10: ファイルの挿入
konno
2022/02/28(Mon) 16:52
[
4651 ]へのコメント
めざらさんに上げてもらったマクロを含めて色々試してみました。 軟体にある上村さんのマクロ esc_i.def 製品版と同じ異常が出る if.def 'REP MOVSW 命令ラップアラウンド' でVTDOSが落ちる 今回の上村さんのマクロ insfile.def 正常に動作します めざらさんのマクロ t.def 最初の一回は正常に動作したようです。 その後は、内容が入れ替わっていたり、テンポラリファイルエラーになったり ; &s #_ #> #b #^ #< ek[+, &s #_ #? &s #> #b #^ #< ek[+, このようにしても直らなかったようです #_ #> #b #^ #< ek[+, サイレントをやめたら正常に動作しました。 insfile.def がサイレントのままで正常に動作するので、調べてみます。
[4654 ]
製品版 [ESC]I マクロのバグは #B だった
konno
2022/02/28(Mon) 17:46
[
4653 ]へのコメント
insfile.def を見てみると、ループ中に #B を使っていません。
としきさんが、#B が怪しいとにらんでいるのは正解かもと思い
製品版の [ESC]I マクロを修正してみました。
= esci.def =
製品版の [ESC]I マクロのバグ回避は、#B を使わないこと
*m
8 [ESC]I @I "I カーソル位置へ挿入"
?. (mr==$80)?{ &m(36) . }
&m("カーソル位置へファイルを読み込みます")
n=wn, c=wc,
; #R
#R #m ;★ 直接ファイラーへ
:A (s)?{ &c >A }
(wc==c)? >Z
mr=-1,
&s
#W &#T(n)
:B #W &#T(c+1)
#b #_ (ct)?{ #> #m #x }
; #b #_ (ct|lh)?{ #> #m } ; #x は不要 T.Tanomura 94/01/05 15:48
:C
; #y (mb)?{ #W #< #i (ek)?? #B #W >C }
#y (mb)??>D ;★ ブロックでなければループを抜ける
#W #< ek[+, #i ek], #W >C ;★ #B を使わない
:D #C &#T(n)
#< #i (ek)?? #B
(wc>c)? >B
&d
:Z &m("")
*
これで、今まで VTDOS153 で異常が出ていたファイルも正常に処理出来ました。
サイレントのままでも、試した全てのVZで問題なく動作しました。
結論として、#B にはバグがあるということですね。
そのバグは、VTDOS や NTVDM で出やすいようだというのが今の状況です。
[4655 ]
Re: 製品版 [ESC]I マクロのバグは #B だった
konno
2022/03/02(Wed) 21:09
[
4654 ]へのコメント
> ; #y (mb)?{ #W #< #i (ek)?? #B #W >C } > #y (mb)??>D ;★ ブロックでなければループを抜ける > #W #< ek[+, #i ek], #W >C ;★ #B を使わない これ、よく考えたら1行で済みましたね。 #y (mb)?{ #W #< #i (ek)?? #B #W >C } オリジナルのこの行を #y (mb)?{ #W #< ek[+, #i ek], #W >C } こうするだけでよかったですね。> そのバグは、VTDOS や NTVDM で出やすいようだというのが今の状況です。 すみません、XPでの結論はまだでしたね。>としきさん
[4661 ]
#k にも問題があった?
konno
2022/03/06(Sun) 00:56
[
4653 ]へのコメント
> めざらさんのマクロ
> t.def 最初の一回は正常に動作したようです。
> その後は、内容が入れ替わっていたり、テンポラリファイルエラーになったり
これは私の手持ちの生ログだけで起こるのですが
そういえば、めざらさんは
> これは #B を使っていない
と言っていましたね。
何故異常動作するのか、色々試してみました。
その結果
; #k (mb)?{ #W #< #i #W >b } #C
#y (mb)?{ #W #< #i #W >b } #C
このように、#k を #y に変えてみたら、正常動作しました。
うーん、何が違うんだろう?
コピーするための一時スタック確保の関係?
64kの境界付近でカーソル位置ポインタを算出しまちがえる?
あと、VTDOS だけで起こるのか、XPで試してみないと分かりませんね。
[4635 ]
Re^5: ファイルの挿入
konno
2022/02/17(Thu) 01:58
[
4630 ]へのコメント
手持ちの380kほどの生ログで試してみたところ、VTDOS では、 2022-02-16 00:58:16 VZO(16C5) 16C5:1454 'REPNE SCASB 命令ラップアラウンド' AX=000A BX=0101 CX=FFEF DX=0000 SI=0000 DI=0000 BP=CB12 DS=4477 ES=4477 FLAGS=0646 CS:IP=16C5:1454 16C5:1444 46 C3 51 57 06 1E 07 8B FE B9 FF FF B0 0A F2 AE 16C5:1454 8B F7 07 5F 59 C3 B2 00 EB 1F E8 F9 FF 73 03 FF SS:SP=24EB:C930 24EB:C920 02 00 EE 0E 43 5C 00 00 00 00 01 00 47 02 77 44 24EB:C930 77 54 02 00 D4 DC 42 14 BF 3B 06 3E DD 11 56 12 このようなエラーで、VZが落ちてしまいました。 このマクロで 64k 以上のファイル挿入は、VTDOS では危ないのかもしれません。 オプションや環境の違いもあるかもですが。 オリジナルVZでは、落ちないけど、ファイル挿入が途中までしか出来ていませんでした。 ちなみに、MSDOS Player と、DOSVAXJ3 では、正常に動作したようです。 それで思ったのですが、としきさんの環境は、XPで VZ高橋版でしたよね。> 環境は、自宅内のネットワーク接続の関係で、いにしえのWindowsXP32bit。 > これのcommand.comです。一応、VTDOS1.22も入っていたのですが、状況は > 同じでした。Vzは1.60t03k。 > command.comを新しく開き、vzを常駐させ、他の作業を何もしない全く最初にファイルを開き、続いてすぐにファイルを挿入させても事象は再現しました。 > ところが、vz.comのバージョンはそのままに、製品版のvzibmj.defとvzfl.defを持ってきて起動させると、異常な事象は発生しません。 XPで高橋版VZ常駐の場合、編集とコマンドラインで行き来しているとおかしくなることかあったような。 ファイラーでもコマンドラインと同様問題が出る可能性がもしかしたらあるのかも。 この場合、非常駐なら問題が出ない可能性があるかもしれません。 それで相談なのですが、としきさんのテストしているファイルをメールでいただけませんか。 同じ状況を再現するには、同じファイルでテスト出来ると助かります。 全ての環境を同じには出来ないので、再現できるかはわからないですが。
> それで相談なのですが、としきさんのテストしているファイルをメールでいただけませんか。 かまいませんが、ちょっとお待ちいただけますでしょうか。
前にも書きましたとおり、事象の再現する最小のファイル、というやつを得られないかと思っているわけでして。
とりあえず、来週水曜か木曜日をめど、とさせてください。
ところで、くどいようですが、
#4632 に書いた、[ESC]Iの動作について、どのように動くのか確認させてください。お返事をお待ちしています。
> それで相談なのですが、としきさんのテストしているファイルをメールでいただけませんか。 > 同じ状況を再現するには、同じファイルでテスト出来ると助かります。 ずいぶんお待たせしてしまいました。 妖しいデータファイルをお送りします。 というか、うちのサイトに載せておきます。 tp://27-138-85-108.rev.home.ne.jp:9801/logdata.zip 掲示板のログファイルなんでね、投稿の中身は公開されているものなんで秘密でもなんでもないんですが。投稿者のIPアドレスやらメールアドレスやら、暗号化されているとはいえパスワードなんかが含まれているわけで、それらを一体どうしようか、と悩んでいたわけですよ。結局、半角アルファベットは全て半角小文字のa、約40ばかりの半角数字3文字の並びを999に置換するということで機密を保つことにしました。sedで一気に置換したので、入力ファイルが0006.*に対して出力結果のファイル名を0007.*とさせていただきました。行数およびファイルサイズ数は元ファイルと同一です。また、試した範囲では、ファイルの挿入における正常とは思えない挙動も全く同一です。 さて、このファイル、職場にも送り込んでみようと思います。 職場のVzも高橋版だったと思いますが、実行環境が64bitのWin10にdosvaxなんで、もしかして違う挙動になるかなぁ、というひそかな期待も。でも.defが同じなので、結局同じかな。
logdata.zipの公開は終了しました。> さて、このファイル、職場にも送り込んでみようと思います。 昨夜、宿直だったもので、仕事の休憩時間に試してみました。> 職場のVzも高橋版だったと思いますが、実行環境が64bitのWin10にdosvax 非常駐Vzです。 常用.defで事象発生、製品版.defで事象発生せず。 3つの外部マクロで事象発生せず。 そこで、常用.defのBlを2048に書き換えてから実行したら事象発生せず。 ここまでで時間切れになってしまったのですがね。 ここで、ふと気がつきました。 製品版.defでも、事象が発生するときとしないときがあることに。 うむむ、単純にBlの問題である、とも言い切れないのか。 やはり、めざらさんのおっしゃるとおり、editfileが悪さをしているのかも。 なぜ使ってもいないeditfileが影響するのかなぁ。
[4659 ]
Re^7: ファイルの挿入
konno
2022/03/04(Fri) 20:02
[
4656 ]へのコメント
> 妖しいデータファイルをお送りします。 > というか、うちのサイトに載せておきます。 いただきました。ありがとうございます。 早速試してみました。 VTDOSではオリジナルの[ESC]Iマクロは、&s が有っても無くても同じ症状になります。 78行目から81行目まで相違していて後は一致、どのVZも同じでした。 トレースすると、3度目の #i #B の後、カーソル位置が1バイトズレますね。 つまり、一つ上の行の最後の改行の位置に来ます。 その後、#< で、一つ上の行の先頭に来るので、次の挿入する行がズレるんですね。 #< が無くても同じようです。 オリジナルのVZ.DEFの[ESC]Iマクロは、1バイト増えて、挿入した中身の一部が壊れました。 Bl2048 では足りないのかもしれませんね。 Bl8192 にしたら、78行目から81行目まで相違していて後は一致、となりました。
引用元:nifty:FGALDC/mes/15/07629
「新 insfile.def」 1997/09/13 17:17
======== insfile.def ======== by I.kamimura
#if 0
【カーソル位置へ挿入】
■機能
●挿入ファイル数にはオープン可能なテキスト数(TC)の制限はありません。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
●挿入した全ブロックを1ブロックとして再現できます。
●挿入後のカーソル位置(ブロックの先頭/最後)はオプション Ek に依存
します。
●文字境界ファイル(ファイルの最終行が尻切れ)に対応。ただし、文字境
界ファイルと行境界ファイルを混在して挿入すると、順序が乱れます。
■テクニカルノート
●&Fl によるファイラー選択では &Fi 不要?
●&Fl によるファイラー選択では 交換可能なドライブ (FDなど)でもマ
ークがクリアされない。
#endif
* M
8 [ESC]I @I "I カーソル位置へ挿入"
?.
(mr==$80)? { &m(36). } ;「変更できません」
(wc==tc)? { &m(6). } ;「オープンできません」
#M &m("カーソル位置へファイルを読み込みます")
n=wn,
&Fl(fl+34) &Cr (r)?.
&s i-,
:A &Fg(pr,1) &m(pr)
mx[+, sn[+, pf[=pr, #R #e #m pf], sn], mx],
(s)? { #[ #[ >A }
#W &#T(n) #W
&60 i++,
#C &#T(n) &Fn (r)? >A
:Z mb-, #b #U (ek)? #B #b
&d #] &m(" %d ファイル挿入しました",i)
60: ;---裏窓へファイル全体をコピー---
#^ #< #b #_ (ct)? #>
:A (mb)??.
&m(" %s : %05u --> %s : %05u",wa+$92,wa..5,wb+$92,wb..5)
#y (s==4)? 'y' #W ek[+, #i ek], #W >A
*
======== End of insfile.def ========
[4612 ]
Re^2: ファイルの挿入
konno
2022/02/11(Fri) 21:03
[
4610 ]へのコメント
としきさん 私のVZ.DEFの該当マクロをオリジナルのマクロと比較したところ :B #W &#T(c+1) ; #b #_ (ct)?{ #> #m #x } #b #_ (ct|lh)?{ #> #m } ; #x は不要 T.Tanomura 94/01/05 15:48 :C #y (mb)?{ #W #< #i (ek)?? #B #W >C } このようにコメント部分が変更されていました。 今回の現象と関係があるかはわからないです。 環境が不明なのが気になるので、PCのCPUとOS、VTDOS等使用の有無 VZのバージョンが知りたいです。 それで何かわかるかは不明ですが、場合によってはヒントがあるかもと思いまして。 あと、イベントマクロなどが干渉することはないでしょうか。
> #b #_ (ct|lh)?{ #> #m } ; #x は不要 T.Tanomura 94/01/05 15:48 製品版では,[EOF]の直前に\nがあるファイルの挿入を前提としているのか,weを超える長さの最終行の終端が[EOF]になっている場合に末尾が欠落する可能性があるのを改善するのが田野村さんの変更ってことかな…… …と思ったのですが,#x は 改行直後の mb を文字ブロックから行ブロックに変更するために必要な処理なので,最終行の先頭に空白類があった場合には,逆に「エンバグ」によって余分な空白類を挿入する可能性がありますね。(「エンバグ」は和製英語らしく,新生バグと言うべきかも。) eiやejの設定により余分な空白類が入ってしまう可能性も考慮すると,je[-, #m je], としておくといった「くどい」手も有りだと思います。この場合は文字ブロックで貼り付けしても行連結は起こりません。 なので,としきさんの手元で製品版のままであれば,上記の一手二手を施しておいて,先の現象が改善されるか確認するのもひとつの段階ですね。関係はなさそうに思いますが,試してみるのは悪くないと思います。 イベントはそれぞれの環境で知る由もないため,最終確認事項でしょうか。
[4617 ]
Re^4: ファイルの挿入
konno
2022/02/13(Sun) 00:41
[
4614 ]へのコメント
> …と思ったのですが,#x は 改行直後の mb を文字ブロックから行ブロックに > 変更するために必要な処理なので,最終行の先頭に空白類があった場合には, > 逆に「エンバグ」によって余分な空白類を挿入する可能性がありますね。 あ、そうなんですか。 この元ネタを探してみたんですが見つけられませんでした。 私の思い込みで勝手に変えちゃったのかもしれません。 T.Tanomura さん、不確かなもので名前を挙げてしまいすみませんでした。m(__)m
↑ このページの先頭