新着記事

− 野ざらし言 −

新規投稿は記事一覧のフォームからお願いします

[4867] Re: 連続ステレオ小説_日本沈没 (10回)音源発見

めざら 2022/07/06(Wed) 09:15
[関連記事] [4866]へのコメント
http://mezala.la.coocan.jp/
小沢さま,おはようございます。
(すごく早起きでいらっしゃるのですね。)

きちんと保管されていることに敬服します。
全回お持ちの方は,ごく稀にいらっしゃるくらいだと思いますので,ぜひ大切に保存していただければと思います。わたしは自前では録音できていなくて,コレクターの方にお借りして聴きました。

みなの幸せのため,日本放送協会の番組音源発掘プロジェクトに提供されてはいかがでしょうか。
 https://www.nhk.jp/p/hakkutsur/rs/R11J73PPLJ/

[4866] 連続ステレオ小説_日本沈没 (10回)音源発見

小沢 2022/07/06(Wed) 04:12
[関連記事]

 手持ちの音源を特定したところ、 連続ステレオ小説_日本沈没 (10回)

これが、10回分揃っているみたいです。珍しくもないのかな?

 「 
小松左京:原作,津川泉:脚色.
大八木健治:効果,太田時雄/[いさはいしんじ]:技術,香西久:演出.(NHK東京)
出演:鹿賀丈史,巌金四郎,宮口精二,久米明,島村佳江,大塚国夫,須永宏,綏片達雄,斎藤隆,武田邦久,川久保潔,湯浅実,大久保正信,松村彦次郎,久松保夫,西国成男,堀勝之祐,加藤精三,[たかはしとおる];小林恭治(na);他.

初放送:1980-08-04~15{FM_連続ステレオ小説}, 

[4865] AWKのヴァージョン

文太 2022/07/06(Wed) 00:06
[関連記事] [4727]へのコメント
 こんな長い行を扱うことになるとは……。
 そして日本語化はどうなってたっけ? というわけで、Vectorとかで調べてDLして。
 こんな連中と(様さまと)、お付き合いいただこうか、という次第です。
 mawkは、いろいろとうまくいきません。

>2バイト文字が混在するファイルの場合、jgawkで算出しなければならないところ、
>gawkで計算していました。なので、これらの数値はバイト数ではなく文字数


C:\>jgawk -v	;もっとも伝統的な gawk for DOS
Japanized Gnu Awk (jgawk) 2.15.2 + 1.1(SJIS)
POSIX options:		GNU long options:
	-W version		--version
----------------------------------------------------------------------

C:\>gawk --version
GNU Awk 3.1.0
Copyright (C) 1989, 1991-2001 Free Software Foundation.
----------------------------------------------------------------------

C:\>gawkw --version	;gawk for win32, これをgawkと言いたいんだけど、色々あります
GNU Awk 3.1.5
Copyright (C) 1989, 1991-2005 Free Software Foundation.

本プログラムはフリー・ソフトウエアです。Free Software Foundation 公表の
----------------------------------------------------------------------

C:\>gawkm --version	;gawk with multi-byte
Gnu Awk (gawk) 2.15, patchlevel 6 + multi-byte extension 1.04
----------------------------------------------------------------------

C:\>mawk -W version
mawk 1.3.3MsDOS Nov 1996, Copyright (C) Michael D. Brennan
  Adaptation for MBCS (P. yedoensis R28) by KIMURA Koichi

Microsoft C/C++ _MSC_VER 803
compiled limits:
max NF             32767
sprintf buffer      1020
stack size         32380
----------------------------------------------------------------------

[4864] Re^7: 行入れ替え再現できました

としき 2022/07/05(Tue) 23:59
[関連記事] [4863]へのコメント
http://toshiki.la.coocan.jp/
>  いちばん軽度の行入れ替えは、いちいち確認してませんよね。

当初は、いちいち確認していましたけどね。
ファイル保存して比較、という形で。
#4609とかの、一番最初に報告した当時はそうでした。
今では、挿入後の画面表示が行入れ替えが起きたときの状況であれば、行入れ替えが起こったとみなしていますね。つまり、先般の画面キャプチャで言うところの図2と同じであれば同じ行入れ替えが起こったとみなす、ということ。
なので、図6のように、挿入終了後画面がいつもと異なる場合のみ、ファイルを保存して中を探索、と言う感じ。

> 業務運行をするなら、とりあえず再起動がお勧めな状態なのかもしれませんが。

そうなんですけどね。
いちいち再起動も面倒なんで、大抵は、そのままずっと突っ走っています。
おそらく、ごくまれに再現不可能な挙動が発生するのは、そのせいでしょう。
逆に言うと、そういう事象は本当にまれ。
挿入試験だけではなく、時にはテキストを読んだりvz.defを編集したり、.cgiファイルや.cgファイルを編集したり、vztower.defで遊んだりもしますが、そういう小さなファイルをいじっているときに原因不明(または原因明快)な不具合に遭遇したことは全くありません。

>  僕のところでの「異常」のパターンは、以下の4種類。

うん、ここですれ違っている。
私、行入れ替えが発生することも「異常挿入」と称しています。
だって、正常じゃないから。
そして、ピカッと光るということは、全く記憶にありません。
ここで注意喚起。
「全く記憶にない」であって「全く経験にない」ではありません。



なお、後日きちんとまとめて報告しますが。
#4849の最後に.cgのファイルサイズを削ってどうなるか試すようなことを書いています。
これの実験を始めたのですがね。
通常のとしき常用環境、およびオリジナルVz1.60およびBlだけ書き換えたオリジナルvz.defのいずれでも発生する状況です。
過去の実験ではいずれも、挿入完了時、正常挿入だろうが異常挿入だろうが、カーソル位置は論理行頭にあります。ところが.cgファイルのサイズを削っていくと、挿入完了時、カーソルが1つ前の行の論理行末に存在して終了することがある。
おそらく、このことからもめざらさんご指摘のとおり、何らかの不具合発生の際に1バイトずれが発生しているということで間違いないでしょう。
この件、まとまったら報告したいけど、いつまとまるやら。

[4863] Re^6: 行入れ替え再現できました

文太 2022/07/05(Tue) 13:14
[関連記事] [4861]へのコメント
としきさん

 なるほど、なるほど、という話の展開です。先については何も分からないけど。
 被挿入ファイル(.cgi)の状態が「支配的」と。

 ただ、としきさんの「異常挿入」って、マクロ操作後すぐ分かるという判断基準ですよね。
 いちばん軽度の行入れ替えは、いちいち確認してませんよね。そして、この場合、Vzは死んでない。ま、業務運行をするなら、とりあえず再起動がお勧めな状態なのかもしれませんが。

 僕のところでの「異常」のパターンは、以下の4種類。
(1)行入れ替え
(2)としきさんのいう「異常挿入」(最近、僕はみてないけど、昔diffしてNot blank で、文字化けとかしてた場合)=Vz死なず。(化けた@の連続みたいなのは見たことがない)
(3)Vzが止まる(ESCで窓が飛ぶ)
(4)ピカっとVTDOSが飛ぶ。

 (1)と(2)の境界線ぐらいは、曖昧にでも、分かりたいな、ぐらいでしょうか。
 上の4パターンには、OS依存な部分もあるんでしょう。

[4862] Re^6: 行入れ替え再現できました

としき 2022/07/04(Mon) 17:52
[関連記事] [4861]へのコメント
http://toshiki.la.coocan.jp/
> 調子こいて、両方のファイルを2048桁で桁折した場合も正常挿入。

> また、2048桁の.cgiファイルに4096桁の.cgファイルを挿入した場合は正常挿入。

古い記録を確認したら、#4840

> 上記のとおり、27932バイトのファイルで異常が発生しています。
> そこで、ためしに2048バイトで桁折してみました。
> でも、(中略)無事に?異常挿入。

なんですね。
ちょっとここ、追及するべきかな、と思って、いくつか実験。
結果、常用環境で、2048桁で桁折した0007.cgiに0007.cgを挿入する実験では、何回も試したけど、全て正常挿入。ところが、27981バイトの、私のところでは0010.cgiと呼称しているファイルを2048桁に桁折したファイルでは、何回も試して、全て異常挿入。
なんだこりゃ。
念のため、いつもの、Blだけ8192にしたオリジナル.defのVz1.60でも試したけど、やっぱり、2048な0007.cgiだと正常挿入。でも、2048な0010.cgiだと異常挿入。
これってあれですね、文太さんのところでもあったかとおもうのですが、小さいほうのファイルはダメだけど大きいほうのファイルなら大丈夫、みたいな感じの話。

謎が謎を呼ぶなぁ。

[4861] Re^5: 行入れ替え再現できました

としき 2022/07/04(Mon) 17:20
[関連記事] [4860]へのコメント
http://toshiki.la.coocan.jp/
>  はあ? あの掲示板ログにはVzが扱えないS-JIS以外の「文字」が入っている可能性ってあるんですか?

ありません。ないはずです。
でも、桁折したファイルでさえ挿入異常が発生するようなら、論理行長が原因の可能性が排除できるじゃないですか。そうすると、現時点で私が思い当たるものって文字コードしかなかったんですよ。

と、仮定の話をしていても仕方がないので、実験してみました。
0007.*の2ファイルとも72桁で桁折して、異常挿入は発生しませんでした。
よかった。
調子こいて、両方のファイルを2048桁で桁折した場合も正常挿入。
だけど、両方のファイルを4096桁で桁折した場合は異常挿入。
また、2048桁の.cgiファイルに4096桁の.cgファイルを挿入した場合は正常挿入。一方で、4096桁の.cgiファイルに2048桁の.cgファイルを挿入した場合は異常挿入。
ほうほう、なるほど。
やはり、支配的なのは、最初に開いていたほうのファイルみたい。

>  3つ目の場合、4つ目の原因とか、まだあるのかも。

あるでしょうね。高い確率で。
そして、それらがそろった場合に異常が発生する。
ただ、例えば4つの原因があって、AとBとCがそろうと異常挿入だけど、AとCとDがそろうとテンポラリファイルエラー、そしてBとCとDがそろうとメモリエラーで窓がシャットダウン、なんてことになっているような気がする。

[4860] Re^4: 行入れ替え再現できました

文太 2022/07/04(Mon) 12:51
[関連記事] [4858]へのコメント
としきさん

 熱中症がまだ完治しません。腰も頭も痛い、、、。

>再び文字コードとかの問題に戻ってしまう。
 はあ? あの掲示板ログにはVzが扱えないS-JIS以外の「文字」が入っている可能性ってあるんですか?
 秀丸って、S-JIS以外ではないと思うけど、「表現」できない文字があると、「そこ修正しますか?」と聞いてきます。たしかその問いは、このログではなかったと思うのだけど。

>何がなんだか。
 はい、何がなんだか、です。
 ただ、ふと先ほど、ある考えが浮かびました。
 行入れ替えの不具合と、(僕のように極端な場合)窓が落ちる不具合は、別問題なんじゃないか、ということ。
 前者がファイルの接合面で起こる(らしい)のは、かわいい不具合。
 しかし後者はまったくかわいくない不具合。僕の場合、たぶんかなりの高確率で16.txtで起きました。17-20.txtは、予測不能なぐらい不安定な結果を出してました。

 3つ目の場合、4つ目の原因とか、まだあるのかも。

[4859] 不具合発現最小ファイルの見つけ方

文太 2022/07/03(Sun) 21:34
[関連記事] [4842]へのコメント
 ここにぶら下げます。

【うちの結論】
 僕のところでは(Win7 + VTDOS)、

 0007.cgi は、最初の15行のファイル
 と
 0007.cg そのもの

 の組み合わせで発現するとの結果を得ました。

 正確に言うと、0007.cgのほうは、これは80行のファイルなのですが、79行でも発現
します。が、ま、そのままで。

15.txt    29,685  2022-07-03  21:07	; 15行ファイル
0007.cg  132,553  2022-06-18  23:00	; ママ

15.txt   162,238  2022-07-03  20:57	; エスキ後

 これで、Vzが飛ぶことなく、

78,80c78,80
< 78	1246
< 79	2040
< 80	2551
---
> 78	2551
> 79	1246
> 80	2040

 といった具合に、挿入ファイル(0007.cg)の末尾で行反転みたいなことが
起こります。この部分が起こるときだけ、マクロをトレースしたいのですが、
余力なし。

 16, 17, 18, 19, 20 行のファイルでは? 安定しないんです。17-20に関しては、
無事故のこともありました。
 ご存知のとおり、20.txtは(その他も)、15.txtを含んでるんです。なんなんですか?

 話の順番が前後しますが、僕は、0007.cgiの最小値を求めてから、0007.cgの最小値
を求めようとしました。0007.cgiはそのままで、0007.cgを小さくしていったら、違う
結果が出ていたのかもしれません。

 さて、見つけ方。簡単。面倒だけど。まず、(同じやり方なら)あたりをつける。
1.txt, 2.txt, 3.txt ... とかムダです。15.txt, 16.txt, 17.txt あたりからアプローチ
してください。

 以下は、15.txtを作る場合。


sed32 "15q" 0007.cgi	>15.txt
 15.txt 出来上がり。

 調査。まず正解を得ておく。
REM  get the correct answer file
type  0007.cg  15.txt  >  15.ans

 エスキする。

 その結果と模範解答(15.ans)を比べる。
REM  get the difference
diff  15.txt  15.ans  >  15.dif

 15.difが0バイトなら外れです。同一ファイルになってる。16.txt作成に戻る。
 0バイト以上で、こんなの何がどう違うのか分らん! という人は下へ進む。

REM  record line length 1
gawk -f line_lst.awk 15.txt > 15.tsl
gawk -f line_lst.awk 15.ans > 15.asl

--- line_lst.awk ---
{ printf("%d	%d\n",NR,(length($0))) }
--------------------

 こうして、2つの行番号と行長のリストが得られた。

 比べてみよう。
REM  get the difference	from listfile
diff  15.tsl  15.asl  >  15.dif


 お疲れ様でした。で? 
 で? の先はありません。

[4858] Re^3: 行入れ替え再現できました

としき 2022/07/03(Sun) 19:50
[関連記事] [4857]へのコメント
http://toshiki.la.coocan.jp/
文太さんに詳しく説明していただいたおかげで、やっと理解できました。
お手数をおかけしました。ありがとうございました。
この問題をみなさんに追試していただいた当初、めざらさんからは、テンポラリエラー発生の報告がありましたね。それと同様に、文太さんはめざらさん異常のシステムの問題があったというか、そもそもVzが異常をきたすだけでは済まず、Vzの下のレイヤごと落ちてしまう、という状況と理解しました。
この辺、めざらさんからも似たようなご指摘がありましたが、人によって、もしくは環境によって挙動が異なる、というのもいやらしいところだと思います。


>  ここからは、あてにならない空想。

文太さんの報告と併せて、私も空想。
まず、単純にファイルサイズだけが問題ではない。
もっと大きなファイルサイズで、全く問題は出ませんものね。
また、論理行の長さが関係する可能性は非常に高い。
そうだ、私、次の機会には、挿入する側される側の両方のファイルを、例えば72桁で桁折して、問題がないことを確認してみよう。それで問題が出るようなら、再び文字コードとかの問題に戻ってしまう。
また、論理行の長さの最大値の問題なのか、ある程度長い論理行の総量なのか、というところもどうなのか。
そしておそらく、最も根本的な問題は、Vzの扱える最大の論理行長の仕様が全くわからない、ということ。常識的に考えて、テキストバッファなりラインバッファを超える論理行を扱うのが難しそうだというのはわかりますが、今回はそういう値も越えていないはずで、何がなんだか。

[4857] Re^2: 行入れ替え再現できました

文太 2022/07/03(Sun) 11:37
[関連記事] [4854]へのコメント
としきさん

>あと、以前のお話では、システムが飛んでいないときはほぼ正常挿入だったということでしたが、今度は相違があるということですよね。すると、何を、またはどこを、変更されたのでしょうか。

 もう少しだけ丁寧な回答を試みます。

 今回の実験とそれまでの実験の何がいちばん大きく違うかといえば、対象のファイルサイズです。ご存知のとおり、不具合発現のファイルサイズ最小値を求めていたので、01.txt(1段落=1論理行のみが内容)から15.txt(1-15行が内容)程度です。ですから、おおかた不具合が出なかったのです。

 15.txt以降で発現し、16, 17, 18, 19, 20 あたりは、実験の初期段階でもう外されてましたから、Vzは固まる、VTDOSは飛ばない、程度で収まっていた、ということです。

 これに対して、としきさんご指摘の「冒頭17行でもう出る」0008.cgiとか0007.cgi全体とかを対象にすれば、それこそ、VTDOSが飛びまくっていてもおかしくはないでしょう。


>何せ、異常挿入か正常挿入かはファイルの中身を分析するまでもなくファイル挿入終了時の画面を見るだけで判断ができるものですから、それを見たことがないということは、

 繰り返しです。
 VTDOSが飛んだら、「ファイル挿入終了時の画面」は存在しないんですよ。ビカっと光るのです。瞬間的に窓が消失する。


 ここからは、あてにならない空想。

 ブロックポインタのずれだけでは、行入れ替え付きの「異常挿入」が起こる程度なのかな? だとすれば、Vzは落ちない。
 「ある一定の長さ以上の論理行」がVzが固まる条件? それもありうるけど、そうとだけとも言えない。反証はあった。しかし、16bitのsedも0007.cgiの論理行の長さに鳴きを入れてた。が、ちゃんと鳴けてシステム(VTDOS)を落とすことはなかった。しかし、Vzには、VTDOSを落とすことができる。
 ファイルサイズ。関係しているのでしょう。だとしたら、テンポラリーファイル?

[4856] Re: 保守的になるための条件

文太 2022/07/03(Sun) 01:07
[関連記事] [4852]へのコメント
各ファイルの最大論理長(エスキで挿入後)

 以下を使用して、0007.cg 挿入後のファイルから
--- lmax.awk ---
# lmax.awk; get maxlength info
{ if (maxlen < $2) {maxlen=$2} }
END { print maxlen }
----------------

 以下を得た。
----------------
01.txt	1501
02.txt	1501
03.txt	1513
04.txt	3703
05.txt	4214	;
06.txt	4214
07.txt	4214
08.txt	4214
09.txt	4214
10.txt	4214
11.txt	4214
12.txt	4214
13.txt	4214
14.txt	4214
15.txt	4214	;0007.cgi の 15論理行までのファイル
		;における最大長行
----------------


--- 15.len ---; 15.txtの論理行長(抜粋)
75	759
76	796
77	1069	;(1)
78	1246	;(3)
79	2040	;(4)
80	2551	;(2)
--------------

 ファイル挿入の場面そのもの(2つのファイル結合部)で、Vz(マクロ)の
不具合は発現していて、4214 bytesの行とか、あまり問題になっていない。
1つのポイントだとは思います。
 ゴミの累積とかはあるのかなぁ?
 ただ、やがて(20.txtぐらい?)で、ハングアップになるのですが。

[4855] Re^2: 行入れ替え再現できました

文太 2022/07/03(Sun) 00:09
[関連記事] [4854]へのコメント
としきさん

>飛んでいない、というのは、VzもしくはDOS窓のことですよね。
 さくっと、曖昧に返信

>つまり、システムが飛んでいない、という意味ですよね。
 です。はい、Vzが固まることはあっても、VTDOSが飛ぶということは
ありませんでした。

>あと、以前のお話では、システムが飛んでいないときはほぼ正常挿入だった
>ということでしたが、今度は相違があるということですよね。
 回答は曖昧です。僕が、ここで

>diff
blank!
 書いてきたときまで、きちんと正常挿入を確認をしていました。

 それ以後、「飛んだ」「不具合」というときは、「異常挿入」確認の手段が
そもそもありませんでした。つまり、としきさんのいう「異常挿入」は、僕の
環境では、結果ファイルが得られなかった、ということです。

 ファイルサイズだけでは「正常挿入」は確認できないと気づいたのはごく最近
です(あまり深い意味はありません。だって飛んでたのだもの)。ただ、#4842
あたりから、きっちり行番号・行長を調べ始めてます。
 飛びまくっていたのは、#4828 前後です。

>すると、何を、またはどこを、変更されたのでしょうか。
 全部(#4850から)を追試をしてもらったほうが早いでしょう。
 数字や長さは違うでしょうが、きっと、似た結果を得られると思います。
 #4828 以降、WinMEはまったく試していません。

 でも、僕はガチンコの原因究明は諦めています。
 いろんな原因が絡まってると(僕ごときから聞きたくないでしょうが)思って
います。純DOSレベルでも(Vz以前に)、起こるのじゃないのかなぁ。

[4854] Re: 行入れ替え再現できました

としき 2022/07/02(Sat) 23:42
[関連記事] [4850]へのコメント
http://toshiki.la.coocan.jp/
>  おお、サイズが同じなのに、相違を出してくる。(つまり飛んでない!)

ごめんなさい、行き違いというか私のほうで勘違いが発生しそうなので、いくつか確認させてください。
飛んでいない、というのは、VzもしくはDOS窓のことですよね。
つまり、システムが飛んでいない、という意味ですよね。
あと、以前のお話では、システムが飛んでいないときはほぼ正常挿入だったということでしたが、今度は相違があるということですよね。すると、何を、またはどこを、変更されたのでしょうか。
これはもしかしたら非常に重要かもしれませんので、わかる範囲で結構ですから、ぜひとも情報提供をお願いしたい。
って、もうこの辺で既に私のほうに勘違いがあるかも。
#4845によると

> 僕はあれらの光景をほぼ見たことがありません。

ということでしたが、見たことがない理由というところを私が誤解しているのかもしれません。まず、ここからはっきりさせたほうがよさそうだな。
つまり、

・[ESC]Iを実行すると、ほぼ確実にシステムが飛んでしまうので、[ESC]I実行後のVzの画面を見たことがない
・[ESC]Iを実行すると、ほぼ確実に正常挿入の画面となってしまい、つまり複数の挿入終了パターンを見たことがない
・[ESC]Iを実行すると、ほぼ確実に異常挿入の画面となってしまい、つまり複数の挿入終了パターンを見たことがない
・[ESC]Iを実行したつもりになって、実は実行していなかった
・その他

といった解釈が私には可能です。
恐れ入りますが、差し支えなければ「見たことがない」理由を明確にご教示いただけますでしょうか。
何せ、異常挿入か正常挿入かはファイルの中身を分析するまでもなくファイル挿入終了時の画面を見るだけで判断ができるものですから、それを見たことがないということは、そこに何かがあると考えるのが妥当だと思われるのです。

恐れ入りますが、なにとぞよろしくお願いいたします。

[4853] Re: 保守的になるための条件

文太 2022/07/02(Sat) 21:41
[関連記事] [4852]へのコメント
追伸

 大昔の話ですが、僕は結局niftyのログファイルはけっこう小さめに刻みました。
たぶん、1MBくらい。ログを修正したくなるときがあったりするし。
 でも、もちろん論理長は長くはない。

in.ejr  4,389,608  2017-03-29  23:06

 これがきっと扱うことのある割と大きめのファイルです。4メガ。辞書『英辞郎』
のファイルを切り刻んだもの。ただ、ファイル属性をリードオンリーにしてるから、
Vzマクロで開けるのですが(グレップではなく)、トラブったことはないです。
中身は(論理行長は)短いです。
 一定の論理行長を超えると、いろんなところでいろんなことが起こる(詳細不明)
という、生き残るための知恵は身につけちゃってますね。MS-DOSのエディタとか、
いまどき(死ぬまで)使ってるのだし。serow版のsedも、あのログファイルに鳴きを
入れてました。
 「思わず使いたくなっちゃう」という状況にあまり遭遇しないのもラッキーなんで
しょうね。

 ちがう。15.txt, 16.txt, 17.txtあたりでのVzの反応はけっこう規則的でした。
ピンポイントに「ここから不具合が発現する」と特定はできませんでしたが。
 これが書きたかったのです。
 

[4852] 保守的になるための条件

文太 2022/07/02(Sat) 21:22
[関連記事] [4851]へのコメント
 まあ、insfile.defを使えばいいのだし、という最初に戻ってしまうのですが。
 「どこで不具合は出始めるのか?」というのをポイントにしました。
 まず

--- 1.bat ---
rem get n line(s) files		(1.bat)

sed32 -e "1q"	0007.cgi > 01.org
sed32 -e "2q"	0007.cgi > 02.org
sed32 -e "3q"	0007.cgi > 03.org
sed32 -e "4q"	0007.cgi > 04.org
sed32 -e "5q"	0007.cgi > 05.org
sed32 -e "6q"	0007.cgi > 06.org
sed32 -e "7q"	0007.cgi > 07.org
sed32 -e "8q"	0007.cgi > 08.org
sed32 -e "9q"	0007.cgi > 09.org
sed32 -e "10q"	0007.cgi > 10.org
sed32 -e "11q"	0007.cgi > 11.org
sed32 -e "12q"	0007.cgi > 12.org
sed32 -e "13q"	0007.cgi > 13.org
sed32 -e "14q"	0007.cgi > 14.org
sed32 -e "15q"	0007.cgi > 15.org
-------------
 これで、1行目のみのファイル(01.org)、1行目と2行目のファイル(02.org)
と15個まで作りました。ほんとは20個だったのだけど、19行、20行でawk
が鳴きました。--- 20行目あたりに地雷がありそうな感触でもあった。

 (sedスクリプトを解説すると、「1q」は、1行目でQuitです。高速です。ただ1行目
は読み込んでからQuit命令=以降ストップ、2行目は読み込みもしない、なので、
1行目だけは出力されます。)

 以下は、オリジナルエスキで、0007.cgを挿入したあと。(以前に15個のファイルを
別ディレクトリーにコピーしておいて、>ren *.org *.txt しました)

2022/07/02  20:32           134,056 01.txt
2022/07/02  20:33           134,880 02.txt
2022/07/02  20:33           136,395 03.txt
2022/07/02  20:33           140,100 04.txt
2022/07/02  20:33           144,316 05.txt
2022/07/02  20:33           146,112 06.txt
2022/07/02  20:34           147,507 07.txt
2022/07/02  20:34           149,333 08.txt
2022/07/02  20:34           151,202 09.txt
2022/07/02  20:35           152,188 10.txt
2022/07/02  20:35           152,845 11.txt
2022/07/02  20:35           155,348 12.txt
2022/07/02  20:35           156,073 13.txt
2022/07/02  20:35           158,213 14.txt
2022/07/02  20:36           162,238 15.txt	;ここで反転おきた。#4850の奴

--- 15.len ---; 15.txtの論理行長(抜粋)
75	759
76	796
77	1069	;(1)
78	1246	;(3)
79	2040	;(4)
80	2551	;(2)
81	1501
82	822
--------------


 原因追求にまったく向かってませんが、これ以降ではもう何が起こるかわからん、
という感じです。
 正解ファイルをtypeで作っておく、line_len.awkで、各状態のときの行の長さを
調べておく、diffで差異を外からみる、などしましたが(6個のバッチファイル)、
うーん、もうダメ。

 15.txt, 16.txt, 17.txt, 18.txtに対して、0007.cgをどこまで小さくすれば……。
 あんまりやる気になってませんねぇ。

 このレベルの作業では、VTDOSが鳴くことはなかったと思う。ピカっと光るのは、
今日は未経験。前に書いたかもしれませんが、Vzのステータスバーがリード
オンリー時の青に変わって、Vzが固まるのは、16行目、17行目あたりで経験
したと思います。
 なんとなく調査範囲を限定したので、割とVzの反応(PCの反応)は、PCらしく
機械的でした。たとえ時にかたまるにせよ。

[4851] 最後でだけ起こる?

文太 2022/07/02(Sat) 18:10
[関連記事] [4850]へのコメント
 結果だけ報告します。
 16行の被挿入ファイル(0008.cgi)に、80行のファイル(0007.cg)を
挿入すると、結果ファイル(挿入後の大きなファイル)の78、79、80の行で、
行反転が起こります。つまり挿入ファイルの末尾でだけ行反転が起こる。
 なぜコピーの最後でだけ起こるのでしょうか?
 ブロックポインタが最後だけずれるのは、論理的でしょうか?
 もっとシステマタィックに(規則的に)ずれるだろう、行反転も規則的に起こる
だろうと思っていたのです。
 いえ、ちょっと驚いただけですなんですが。

 この実験は前回に同じく、模範解答と実験結果ファイルのファイルサイズが同一
という、一見挿入成功に見える場合に発生しました。この不具合発現には、再現性が
あるように感じてます。

--- 模範解答 ---
77	1069
78	2551	; A
79	1246	; B
80	2040	; B
81	1501
----------------

--- 挿入実験 ---
77	1069
78	1246	; B
79	2040	; B
80	2551	; A
81	1501
----------------
 左端の2ケタ数字はNRというか行番号。
 右側の4ケタ数字は論理行長。

 経験的に(笑)、2551とかって、決して長すぎるというわけでもないと思う。
1246+2040とかの長さが関係している?


 あてにはなりませんが、「16行」のファイルを15行、14行と減らしていくと
不具合は出ず、逆に17行、18行と増やしていくと、やがて行反転どころかVzが
あるいはVTDOSが飛ぶ、ということになるように感じています。含まれる行の長さ
も関係してるのかなぁ。

 熱中症はやがて腰が痛くなります。現在、そのフェーズです。

[4850] 行入れ替え再現できました

文太 2022/07/02(Sat) 16:23
[関連記事] [4845]へのコメント
 いちおうここにぶら下げます。


 元々、0007.cgiの最小サイズを俺も調べてやる(きっと値は違うだろうけど)と
着手した実験でした。目的は、曖昧に、「最小サイズが決まる」という事実を
確認すること。

 前回失敗したので、0007.cgiから頭17行(たしか)をとり、これを000.cgiとし、
あらかじめ、typeコマンドで模範解答を用意しておき、000.cgiに0007.cgを挿入。
 結果できたのが、下の上。

000.cgi  162,238  2022-07-02  15:37	;すいません、挿入の結果ファイルです
000_.cgi 162,238  2022-07-02  15:36	;あらかじめ作っておいた模範解答ファイル
					;困ったことにサイズが同じ。

>diff
 だらだらだらだら。

 おお、サイズが同じなのに、相違を出してくる。(つまり飛んでない!)
 では、どう違うのか調査。
 Vzでの比較。違う箇所はいちおう特定できたけど、やだ、このログ、読みづらい、と
別の作戦に変更。awk作戦

--- line_len.awk ---
{ printf("%d	%d\n",NR,(length($0))) }
--------------------
 これで、上記2つの結果ファイルの行番号と行の長さを出し、これをVzで比較


>gawk -f line_len.awk 000_.cgi >kek000_.txt

--- kek000_.txt ---	;こちらは模範解答

1	3970
2	1200
(中略)
77	1069	;(1)
78	2551	;(2)
79	1246	;(3)
80	2040	;(4)
(中略)
81	1501
82	822


 下が、オリジナル・エスキによる結合ファイルの行の状態。

>gawk -f line_len.awk 000.cgi >kek000.txt

--- kek000.txt ---

1	3970
2	1200
(中略)
77	1069	;(1)
78	1246	;(3)
79	2040	;(4)
80	2551	;(2)
(中略)
81	1501
82	822

 ブロックポインタが1バイトずれるだけで、これだけのカオスって起きるの
でしたっけ? 僕の誤解? konnoさんの修正を見たときに、1行だけ反転するのか、
とか空想したのですが……。
 窓が飛んだりするのは、別の原因なのかな? Vzの、あるいはVTDOSの。
(僕のVTDOS環境が脆弱なのだろうと想像しています。Vzのステータスバーが
リードオンリーの青になり、固まる、というのを今日、経験しました。これ、Vzが
固まっているのだと思う。)

 ああ、またしても、時間切れ、あるいは力尽きて、目的の場所までたどり着け
ませんでした。ほんと、次から次に多重出現。

 読んでます。多謝。後日レスします。熱中症になりました。ヘロヘロ。ご自愛
ください。畑仕事には、くれぐれもご注意を。

[4849] Re^4: 改行置換

としき 2022/07/02(Sat) 13:59
[関連記事] [4840]へのコメント
http://toshiki.la.coocan.jp/
> 上記の、桁折した場合の異常挿入について、[ESC]Iのマクロにトレースを入れたりして、もうちょっと詳しく見ていきたいと思います。

見てみました。
さっぱりわかりません。
:Cのループの中でおかしくなっている、というところまではわかりました。
2つ窓を開いて正常挿入のときと異常挿入のときで比較すると、#Bを実行後のところから違いが生じます。
もし仮にソースを読むとしたら、やっぱり#Bのところなんでしょう。

とりあえず、この方向を攻めるのも一旦やめて、0007.cgのファイルサイズの方面の攻略に向かいます。

[4848] Re: 異なる現象の多重出現

としき 2022/07/02(Sat) 09:19
[関連記事] [4846]へのコメント
http://toshiki.la.coocan.jp/
> ・テンポラリファイルエラー(昔からけっこうある)

昨日は宿直明け。
昼間、しっかり仮眠を取ったつもりだったんですがね。
夜、うっかり、板塀の生ログをいじってしまって。
バックアップ側を触っていると思っていたのですが、なんと本番ログ。
そして、よりによって保存のときにテンポラリファイルエラーが出てしまい、あっと思って確認したところ、ログ破壊判明。
すぐに復旧に取り掛かったのですがね。
バックアップのタイミングのせいで最新の発言がないので、単に書き戻すわけにも行かず。そして、古い発言にレスをつけたためにツリーの位置が変わっているので、どこにどの発言をどう戻すか、ということをあれやこれや。おまけに、実は半分眠いということを自覚したものだからそれだけ行動が慎重になり、トラブルの上乗せは避けられたけど、復旧までおおよそ1時間。
この復旧作業も、危険を承知でWinXPなサーバマシンのVzで行っていたんですが、一番重要なところは、やっぱりメモ帳。でも、メモ帳だとファイルの比較ができないので、チェックはVz必須。あと、ちょっとした書き換え、Vzで大丈夫かな、とやってみたときに、たぶん数年ぶりに見かけました、「ラインバッファがいっぱいです」というメッセージ。

> 中途段階のブロックエンドポインタが前の行末にずれることにより,行ブロックの挿入位置が1論理行ずれてしまう現象。

現象としてはそのように見受けられるのですがね。
これが、1バイトずれなのか1行ずれなのか、という部分で、私自身の考えが定まっていません。
あと、いまだに疑っているのが、根本原因は実はテンポラリエラーなんだけどVzの側でそれが検知できていないのではないか、ということ。

>  本来はこの現象の再現性を確認したいのに,その他のエラーも随時からんできて訳がわからない,調査が進まない,条件が確定しないというジレンマに陥っているわけですね。

まさにおっしゃるとおり。
発生確率が数百回に1回、とか言うのなら無視します。
でも、ほぼ確実に再現できる。
そのくせ、一見関係なさそうなBlとかを変えると、全く発現しない。

> 結局,条件が揃えば発現するという状況は避けられない

まぁそうなんですけどね。
最終的には、めざらさんご紹介のマクロを使うなり、本件に限っていえば、いくらでも回避策はあるのですが、ただ、やっぱり、文太さんのおっしゃるところの地雷、いまさら除去はできないのですが、どこにどんな地雷か、というところは確認したいものです。

↑ このページの先頭