一括表示

− 野ざらし言 −

[4021] 終了判定

としき 2011/11/03(Thu) 16:48
http://www1.hinocatv.ne.jp/toshiki/
よく利用していたWEBサイトが一つ、終了してしまったようです。
ではなくて。

今まで、あんまりやったことのないことに手を出そうとしています。
cpを使って、現在のテキストを最初から最後まで全て舐める、ということです。
で、最後尾から先頭までループを回すのならゼロとの比較でいくらでもループを止められるのですが、逆に、先頭から最後まで進む場合は、どうやってテキストの終了を判定するのでしょうか。当然、ファイルサイズは16MBとかあるかもしれないわけですし。

もう一つ。
実用性ではなく、勉強を目的として、変なものを作ろうとしています。
チェックサムというか、ファイルの先頭から最後まで、全ての文字コードをバイト単位で足しこんでいって、下位8ビットの値だけを取り出そうと思っています。
この場合、2バイト文字があることを考えると、cdで取り出した値をckで判別するのが素直なのでしょうか。
頭ごちゃごちゃで、何がなんだか分からなくなってしまいました。
ご教示いただけると幸いです。

[4022] Re: 終了判定

めざら 2011/11/03(Thu) 17:40
[4021]へのコメント http://homepage3.nifty.com/mezala/
> 先頭から最後まで進む場合は、どうやってテキストの終了を判定する

 どのように「進む」かが示されていないと,ちょっと難しいですね。
 一応,EOFの判定というのは ct==0 でやることになっていますが,これはあまり信用できない場合があるので,通常は #d の戻り値で判定します。
 「cpを使って」ということなので,物理的なカーソル移動を行わずに末尾の判定をするということでしょうか。そうなると判定のしかたはちょっと想像が難しいです。いずれにしても cp はオフセットなので,大きなテキストだと使い物になりませんから。


> cdで取り出した値をckで判別するのが素直なのでしょうか。

 そうですね。cdを参照するなら素直に判定するべきだと思います。そういうアセンブリ言語が得意そうな処理だと,ひたすら泥臭くなるのは仕方がないかと。
 ただ,cdで取り出すとなると,文字単位のカーソル移動が前提になるので速度が出ないのではないでしょうか。ラインバッファに入って,メモリ上でアレコレした方が楽なのではないかと思います。
 ラインバッファの末尾のアドレスと先頭アドレスを比較して行のバイト数を算出し,バイトポインタで参照して単純に足し込んでいけば当該行の値は出ます。カーソルの移動は #> と #d だけで各行の値を次々足していき,最後にビット積でマスク(値 & $FF)をかければよいという方法が考えられますね。

 仕様が固まればコードを書くお手伝いはできると思います。

> よく利用していたWEBサイトが

 どちら?

[4023] Re^2: 終了判定

としき 2011/11/04(Fri) 00:48
[4022]へのコメント http://www1.hinocatv.ne.jp/toshiki/
>  どのように「進む」かが示されていないと,ちょっと難しいですね。

あ、なるほど。

>  「cpを使って」ということなので,物理的なカーソル移動を行わずに末尾の判定をするということでしょうか。

用語がよくわかっていないのですが、おそらく、そういう意味だと思います。
つまり、cpをインクリメントして、その位置の文字コードを取得してモゴモゴ、ということです。

= test
* m
1 ^^ "test"
?.
:a
a+=cd,
cpをインクリメント
テキストの末尾でなければ >a
変数aの値を表示(ただし、8ビットで)
*

おおむね、こんなことを考えておりました。
もちろん、cdを直接使うと、2バイト文字のときはマズイと思いますが。

うまく要点をまとめられないのですが。
バイト単位でのテキスト総なめのルーチンはどう作るか、というのが中心にあります。
自力で考えたところでは、cpを使うのではないか、と思いました。
でも、このアプローチが正しいのか否かもわかりません。
さらに、大きなファイルの場合、ポケ3では速度低下が想定されます。
なので、マシン語化も考えています。
速度のことを考えずにローテクでいくのなら、
 #dして
 1文字取り出して
 文字種を判定して
  1バイト文字ならそのまま足しこみ
  2バイト文字なら上下バイトごとに足しこみ
 #dの戻り値でファイル終端を判別
でできてしまうことはわかってきました。

> > よく利用していたWEBサイトが
>  どちら?

Vzとは全く関係のないサイトです。

[4024] Re^3: 終了判定

めざら 2011/11/05(Sat) 00:05
[4023]へのコメント http://homepage3.nifty.com/mezala/
・カーソル移動だと遅いし,1バイト/2バイト文字の判定が必要.
・メモリ上のどこかわからないcpはまるでアテにならないのでちょと危険.

…というわけで,以下が参考になりますでしょうか.

#^ #< #]
a=wm+230, ;ラインバッファ先頭アドレス
c-, ;初期化
:L
#28 ;ラインバッファに入る
wa..19.2-, ;終端をヌルにしてラインバッファを「文字列」化
&Sn(a) b=r, i-, ;長さの測定
(b){ c+=a.i, i++, } ;1バイトずつ足しこむ
#54 ;ラインバッファを破棄(文字列化の後は必須)
#> #d ;次の行へ移動
(r)??>L ;#dの戻り値判定:戻り値が真ならファイルの末尾
c=c&$FF, ;下位の8バイトのみ残す:溢れた分は捨てられている

 こういった手順もあるということで.ただし,行末の改行コードも数えてしまうと思うので,文字のみ加算していくのなら少し工夫が必要かも.

[4025] Re^4: 終了判定

としき 2011/11/05(Sat) 15:22
[4024]へのコメント http://www1.hinocatv.ne.jp/toshiki/
茶漉しって、英語でtea strainerって言うんですね。
解説無しでも英語のつづりを見たら一発で日本語はわかったのですが。
昨日「ティーストレーナー」というカタカナをはじめてみたときには、逆に英語のつづりがわからなかったというか、teeth trainerというつづりを思い浮かべてしまいました。一緒に並んでいたのが「ひと時の幸せなお茶の時間」とかってフレーズで、なんで歯を鍛えるとお茶の時間が幸せになるのか、自分の思い違いに気がつくまで、しばらく頭の周囲を疑問符が飛び交っていました。


本題。

> …というわけで,以下が参考になりますでしょうか.

すごい参考になりました。

>  こういった手順もあるということで.

やはり、1行ずつ処理していくのが定石なんですかね。
ラインバッファに入れないと、今度はその他の判定が煩雑になってしまうということなのでしょうか。
すると、マシン語化する場合には、1行ごとの処理をマシン語化して、行数の分だけ呼び出す、という形になるのかな。
とりあえず、今回は目的がテキスト全体をなめるということなのですが、昔のマクロ師あたりだと、文字境界ブロック対応があるからこのような方法がいい、とか、いろんな意見が出そうな部分かもしれません。

> ただし,行末の改行コードも数えてしまうと思うので,文字のみ加算していくのなら少し工夫が必要かも.

実際には、文字コードが××だったら(例えば、小文字アルファベットだったら)、というような条件判定をループの中に入れて、何かを作り上げることになるでしょう。

[4026] Re^4: 終了判定

としき 2011/11/05(Sat) 17:17
[4024]へのコメント http://www1.hinocatv.ne.jp/toshiki/
> …というわけで,以下が参考になりますでしょうか.

自分でいろいろと試してみて、この手法については、だいたい理解できました。
そこで、もう一つ。
テキストを総なめして、ある条件だったら文字を書き換える、というのはどうするのでしょうか。
無理やりな例題としては、文字列の置換で行えばよっぽど早いかもしれませんが、例えば、半角数字"7"を、奇数回目に出現した場合は"3"に置き換えて、偶数回目に出現した場合は"0"に置き換える、なんて場合です。

よろしくお願いします。

[4027] Re^5: 終了判定

めざら 2011/11/05(Sat) 21:36
[4026]へのコメント http://homepage3.nifty.com/mezala/
> テキストを総なめして、ある条件だったら文字を書き換える、というのはどうするのでしょうか。

 置き換えをするなら,ラインバッファから値を取ることはできなくなりますから,別の処理になりますね。先の処理方法では必ずラインバッファを反映しないで終了させなければならないためです。書き換えるのであれば,カーソルを1文字ずつ移動しての処理になるでしょうか。

[4028] Re^6: 終了判定

としき 2011/11/06(Sun) 22:26
[4027]へのコメント http://www1.hinocatv.ne.jp/toshiki/
>  先の処理方法では必ずラインバッファを反映しないで終了させなければならないためです。

それはなぜ、ということの説明は難しくなってしまうでしょうか。

>  書き換えるのであれば,カーソルを1文字ずつ移動しての処理になるでしょうか。

過去のその手のマクロってどんなものがあるのか知りませんが、どれもそんな感じの処理なのでしょうか。だって、そういう処理だとマシン語化が容易ではないでしょ?

実際、裏をかこうとして、うまく行きませんでした。
どう考えたかというと、先日のめざらさんの示してくれたロジックに対して

・ラインバッファを破棄してしまうから、書き換えても反映されない
・ならば、破棄しなければよい
・でも、文字列化後は必須とある
・ならば、文字列化しないという方法はあるか?
・文字列化しない場合、文字列関数&Snが使えない
・ならば、文字列化して処理を行った後、元に戻せばよいのではないか

かなりむちゃくちゃな考えですね。
この方針で作ったサンプルが以下のようなもの。

#^ #< #]
a=wm+230, ;ラインバッファ先頭アドレス
c-, ;初期化
:L
#28 ;ラインバッファに入る
z=wa..19.2, ;終端の値を保存 *****
wa..19.2-, ;終端をヌルにしてラインバッファを「文字列」化
&Sn(a) b=r, i-, ;長さの測定
(b){ a.i=' ', i++, } ;1バイトずつ書き換え *****
;#54 ;ラインバッファを破棄しない
wa..19.2=z, ;ヌルにした終端を保存した値に復帰 *****
#> #d ;次の行へ移動
(r)??>L ;#dの戻り値判定:戻り値が真ならファイルの末尾

当然ながら、うまく行かなかったんですがね。
これが、なぜうまく行かなかったのか、ということもわかりません。


そろそろあきらめたいと思いますので、わかりやすく引導を渡していただけると幸いです。

[4029] Re^7: 終了判定

めざら 2011/11/06(Sun) 23:41
[4028]へのコメント http://homepage3.nifty.com/mezala/
> それはなぜ、ということの説明は難しくなってしまうでしょうか。

 いや,難しくはないのですが,必ず回避方法を聞かれると思うので,先回りして説明を……と思ったら,同じことを考えてました。

> 過去のその手のマクロってどんなものがあるのか知りませんが、どれもそんな感じの処理なのでしょうか。だって、そういう処理だとマシン語化が容易ではないでしょ?

 としきさんが先にのべた,「当然、ファイルサイズは16MBとかあるかもしれないわけですし。」が引っかかるわけです。過去,逐一処理を行うような処理はマシン語化するのが常道だったわけです。それでそういう処理をするマクロは,メモリ上で処理を行うわけですが,VZが普通に扱えるメモリというとラインバッファとかテキストバッファ(セグメントは異なる)になるわけですね。すると,64KBくらいまで。速度的にもそのくらいが限界というわけなのでしょう。

> ・ならば、文字列化して処理を行った後、元に戻せばよいのではないか

 「処理」の内容が問題あったのかも。

> z=wa..19.2, ;終端の値を保存 *****

 たぶん,「z」がダウト。zはユーザ変数ではありません。ユーザが汎用変数として使えるのは,a〜y(うちrとsは意図せず勝手に書き換わる)です。未定義のzを使うと結果は保証されていません。

 あと,ラインバッファを書き戻さないとですね。
 #? なんかを使うことになりますかね。あまり馴染みがないかもですが。

> わかりやすく引導を渡して

 ありゃー。
 その前に,より具体的に何をどうしようとしているか解らないと。

 自分がやるとすれば,
・ラインバッファを文字列化して長さを取得したら #54 で一旦戻す
・再度ラインバッファに入ってアレコレ処理する
・書き換えたラインバッファを書き戻す
…というふうにしますね。

 ただやはり,ラインバッファを直接書き換えるというのは,あまりおすすめしません。一部をちょこっと書き換えるのはあまり心配ないのですが,#4028を見るとゴリゴリ書き換えてますよね。ラインバッファの管理はエディタであるVZ本体に任せたほうがいいと思うのでありますよ。

[4030] Re^8: 終了判定

としき 2011/11/08(Tue) 00:12
[4029]へのコメント http://www1.hinocatv.ne.jp/toshiki/
>  過去,逐一処理を行うような処理はマシン語化するのが常道だったわけです。それでそういう処理をするマクロは,メモリ上で処理を行うわけですが,VZが普通に扱えるメモリというとラインバッファとかテキストバッファ(セグメントは異なる)になるわけですね。すると,64KBくらいまで。速度的にもそのくらいが限界というわけなのでしょう。

ごめんなさい。
過去の偉人の作品についての理解が足りないのですが。
すると、過去の作品で、ファイル全体に対して処理を行うようなマクロって、だいたい64KB制限があったということなのでしょうか。
それとも、そもそも、ファイル全体に対して処理を行うようなマクロというものは存在しなかった?
いや、そんなことはないですよね。
めざらさんの説明って、常識の範疇ということで説明をはしょっているのだけど、実はそこが重要というか、私が気がついていない何らかの事項がそこにあって、それで私が理解できていない、というような印象を受けました。

>  たぶん,「z」がダウト。

ぅぉぉ、50枚でも100枚でもカードを引かせていただきます。
そうかぁ、常駐フラグでしたっけ。
この辺、Vzマクロに関して素人丸出しですね。

>  その前に,より具体的に何をどうしようとしているか解らないと。

目的は、あくまでもファイル全体を走査すること。
次に、走査してテキストの中身を読み取る。
例えば、文字コードを全てバイトで足しこむ、など。
最後に、走査して、テキストそのものを書き換える。
例えば、文字コードの値が10進数で32を超える文字は全て半角小文字にする、など。

ここまでの技術を身につければ、どんなマクロも怖くなくなるのではないか、と妄想してみました。

[4031] Re^9: 終了判定

めざら 2011/11/08(Tue) 20:47
[4030]へのコメント http://homepage3.nifty.com/mezala/
 いやいや,わたしだってすべてを把握しているわけではないですし,そもそも機械語化されたマクロを解読することはほとんどできませんから,想像でしか言っていません。

> すると、過去の作品で、ファイル全体に対して処理を行うようなマクロって、だいたい64KB制限があったということなのでしょうか。

 例えば,テキストをすべて処理するマクロとしては,文字コードを変換するようなものがありますね。JIS⇔MS(所謂SJIS)変換みたいな。これはまともにやるとひどく時間がかかりますが,テキストバッファを使って高速化するという試みもありました。こういうのは64KB制限があったのではないかと思います。

> それとも、そもそも、ファイル全体に対して処理を行うようなマクロというものは存在しなかった?

 あったとは思いますが,まるまる置き換えるような処理というと,他に想像がつきません。何かネタがありますかね〜。大抵は何かのマークアップにしても,大幅な書き換えというわけではないですよね。

> 目的は、あくまでもファイル全体を走査すること。

 走査だけで書き換えを伴わないなら,メモリ上で行うのは問題ないですね。
 64KBを超えるファイルであっても,次のような手順でできると思います。
1 全体をブロックする
2 スタックにコピーする
 (スタックからあふれた部分はブロックのまま残っている)
3 テキストスタックを対象に走査する
 (セグメントが異なるので機械語が必須かも)
4 ブロックモードなら 2に戻って繰り返す

 走査して取得したチェックサム様の値をどこに吐き出すかが問題ですが。

[4032] Re^10: 終了判定

としき 2011/11/09(Wed) 00:16
[4031]へのコメント http://www1.hinocatv.ne.jp/toshiki/
ごめんなさい。
ネタを振るだけ振っておいて、なんか勝手に収束してしまいそうです。

>  あったとは思いますが,まるまる置き換えるような処理というと,他に想像がつきません。何かネタがありますかね〜。

例えば、私が自分で作った、HTMLを生テキストに変換するマクロ、これは処理対象と出力結果のサイズが当然のように異なるわけです。この場合、新しいファイルを作って、そちらに出力を行う、というのが素直なアプローチでしょう。
私がサンプルで書いたように、元をそのまま置き換えるとなると、実用マクロとしては、おっしゃるとおり、文字コードの変換くらいしか思いつきません。

一応、先達の作ったマクロをざ〜っと流してみようかと思い、軟体保管計画の作者順の表を見てみました。もちろん、全部は見ません。私の知っている人で、それなりにたくさんマクロを書いている人、ということで上からぼ〜っと見ていきました。
あじゃさん、石田暢彦さん、梅澤哲雄さん、H岡さん、m.gannさん、えむしさん、金近真一さん、上村郁夫さん、・・・おや、上村さんのうえから4番目、テキスト暗号化/解読マクロ、これはテキスト全体を暗号化するようにはなっていないかな、と思い、中身を読ませていただきました。すると、これ、仕組みはよく判らないながらも、1行ごとに処理していることがわかりました。おまけに、
#> #d (r)? >C; 次行へ
こんなコードも使ってある。
なるほど、やっぱりこれが常套手段なわけなのですね。

余談ですが、この暗号化ルーチンを!Openと!Closeのイベントに組み込めば、#3699であかべこさんがおっしゃっていたセキュリティが担保できそうです。今やっている、ファイル全体の走査というのがうまく行ったら、次はイベントマクロの海に乗り出してみようかな。

>  64KBを超えるファイルであっても,次のような手順でできると思います。

この手順も面白そうです。が、ちと難しそう。
考えさせてください。とりあえず、ポインタは必要ですよね。

>  走査して取得したチェックサム様の値をどこに吐き出すかが問題ですが。

&mで表示します。
変数は、この間は z で失敗したので、今度は vn とか GV あたりを使ってみようかな。
#もっと危なそう

[4033] Re^11: 終了判定

めざら 2011/11/12(Sat) 10:57
[4032]へのコメント http://homepage3.nifty.com/mezala/
> #> #d (r)? >C; 次行へ
> こんなコードも使ってある。
> なるほど、やっぱりこれが常套手段なわけなのですね。

 一番確実ですね。EOF を ct を使って評価しようとすると,まれに \r が末尾にあるファイルだと失敗します。例えば,任意のファイルを開いて EOF にカーソルを置き,インスタントマクロ([ESC]@)で &o($d) を実行して \r(0x0D) を出力してやると,ファイルサイズは1バイト増えますが見た目は変わりません。しかし,EOF 上で ct を見る(インスタントマクロでctと入力・評価)と ct == 1 と戻ってきます。夢幻る〜ぷの原因になって,非常に危険。
 それで,#d でカーソルが移動できたか戻り値で判定します。正常終了なら戻り値は 0 ですから,上の例だとラベルCの飛び先はループさせているルーチンではなく終了ルーチンと思われます。

> &mで表示します。

 ふむ。ところで1バイトのチェックサムって,行単位ではなくてファイル単位ですか? 256分の1で一致することになるってのは,やや(相当猛烈に)心許ないチェックになりませんか?

[4035] Re^12: 終了判定

としき 2011/11/14(Mon) 00:21
[4033]へのコメント http://www1.hinocatv.ne.jp/toshiki/
>  ふむ。ところで1バイトのチェックサムって,行単位ではなくてファイル単位ですか? 256分の1で一致することになるってのは,やや(相当猛烈に)心許ないチェックになりませんか?

や、これは、あくまでも練習用の無理やり作った例題ですから。


無理やりついでに、#4032の関連で、別の例題を思いつきました。
もうちょっと実用っぽい雰囲気をまとわせたというか。
あかべこさんの暗号化関係です。

・!Openと!Closeに実装
・拡張子が特定のものであった場合
・ファイルの最初から最後まで走査する
・文字コードが$20以上の場合、最下位ビットを反転(c=c^1)

こんな簡単なものでも、ちょっと見には全く読めないテキストにできるはずです。えぇっと、もしかしたら64KB制限をつけるべきなのかもしれませんが、全くわかっていません。
確か、イベントマクロの場合は使えないコマンドだったか関数だったかがあったはずですが、よくわかっていません。こうしたらいい、とか、今まで話に出ていたアレが使えない、みたいなものがあったら教えてください。
よろしくお願いします。

[4040] Re^13: 終了判定

めざら 2011/11/18(Fri) 20:31
[4035]へのコメント http://homepage3.nifty.com/mezala/index.html
> ・文字コードが$20以上の場合、最下位ビットを反転(c=c^1)

 この$20以上というのは,何か確信があってのことなのでしょうか。あ,制御コードをナニすると,例えば改行コードが改行コードでなくなると,ラインバッファをあふれる可能性があるということなのかなー。

 で,本文が1バイトの連続の場合は1ビット反転の暗号化というのがばれちゃうかもしれないですね。文中にはそこそこの間隔でよく出現する空白や句読点がパターンとして見えてしまうので,そこを解析されると苦しいと思います。「ちょっと見には全く読めない」程度でよいのであれば特に問題はないわけですが,復号化が単純だと容易に読めてしまうわけで。

> 確か、イベントマクロの場合は使えないコマンドだったか関数だったかが

 イベントの制限については,製品版付属のmac16.docを参照してください。
 基本的には,コマンドが使えません。つまりラインバッファに入るコマンドも,ラインバッファを書き戻すコマンドも使えません。テキストバッファを処理しようとすると,EMSを使っている環境ではどのメモリを使っているかを確認可能である能力も要求されるでしょうし,処理も重そうなので機械語が必須でしょうね。どうやるのかは分かりませんが…。

[4041] Re^14: 終了判定

としき 2011/11/20(Sun) 22:12
[4040]へのコメント http://www1.hinocatv.ne.jp/toshiki/
>  この$20以上というのは,何か確信があってのことなのでしょうか。あ,制御コードをナニすると,例えば改行コードが改行コードでなくなると,ラインバッファをあふれる可能性があるということなのかなー。

ラインバッファについては思い至りませんでした。
単に、非可読文字をいじると、何がどうなるかわからないから怖い、というだけの気持ちでした。

>  で,本文が1バイトの連続の場合は1ビット反転の暗号化というのがばれちゃうかもしれないですね。

だから、練習用なんですってば。
本来なら当然もっと複雑なエンコーディングをするところです。
とりあえず、1バイトを1バイトにマッピングする、しかも可逆で、というところから考えてみました。ここで、全ビットを反転する、というのでもよかったのですが、すると可読文字と非可読文字をいったりきたりすることになって、上にも書いたのと同じ理由でちょっと怖かったので、最下位1ビットの反転というのをでっち上げてみました。

>  イベントの制限については,製品版付属のmac16.docを参照してください。

一番最後の特記事項のところにあったのですね。
どこかで見た記憶はあったのですが、思い出せませんでした。
でも、コマンドが全く使えないとなると、かなり制限されてしまいますね。
ということは、文字コード変換系のマクロは、かなりの大技を使っているということなのでしょう。
うぅ、イベントマクロ対応は私の実力ではちと無理っぽい。
こっちは素直にあきらめるとしましょう。

[4042] Re^15: 終了判定

めざら 2011/11/21(Mon) 08:27
[4041]へのコメント http://homepage3.nifty.com/mezala/index.html
> だから、練習用なんですってば。

 あ,そでした。元々が実用派なものですから,なかなか頭の切り替えができないのです。いや,歳のせいかもしれませんが。

> でも、コマンドが全く使えないとなると、かなり制限されてしまいますね。

 !Open !Close !Filer !Start の話ですけれどね。!Edit !View !Timer !Abort についてはコマンドも使用可能です。今回の例ではファイルのオープン・クローズ時の話ということが明確ですので,制限があると考えました。

 ただ,裏技というのはやはりあるものでして,例えば !Filer においては,むしろ裏技を使って拡張するというのが「一般的」です。もちろん FGALPK(FGALDC) の常識は世間の非常識ですし,「undocumented」ですから敢えて言及していませんでしたけど。

 その裏技というのは榊原知氏の開発したもので,v1.6 の出来当初からフォーラムでは公開されてきたものです。具体的には,「&e("#]") #]」というコードを埋め込むだけですが,その仕組みについては裏技なので説明は困難ですし,副作用もあるので使用は !Filer くらいにとどめたほうがよいとされています。

> ということは、文字コード変換系のマクロは、かなりの大技を

 文字コード変換はそれほど大技だとは思いません。わたしもローテクでJIS/SJIS 変換マクロを使ったこともありますし,暗号とか文字化けとか結構好きでした。
 小物住所録(http://homepage3.nifty.com/mezala/vz/history/smallmac.html)を見てもらうと,そういうテーマのマクロはそれなりにたくさん見つかると思いますよ。
 ただ,ファイル全体をという話になると,かなり重くなるので実用的なものを作ろうとすると機械語が出てくるのは自然かと思います。
 むしろ厄介なのはイベントでしょうね。

[4043] Re^16: 終了判定

としき 2011/11/22(Tue) 01:20
[4042]へのコメント http://www1.hinocatv.ne.jp/toshiki/
> > ということは、文字コード変換系のマクロは、かなりの大技を
>  文字コード変換はそれほど大技だとは思いません。

あ、いやいや、私が思ったのは、OpenとCloseのイベントで自動的に文字コード変換してくれるアレとかコレとかのことです。ちょこっと覗いてみましたが、案の定というか、マシン語を使っているということしかわかりませんでした。

>  むしろ厄介なのはイベントでしょうね。

そうかぁ。
すると、自動暗号化は難しそうだなぁ。
セキュリティを担保するためには、手動暗号化しかないかな。



>  わたしもローテクでJIS/SJIS 変換マクロを使ったこともありますし,暗号とか文字化けとか結構好きでした。

そういえば、ありましたねぇ、お化けに魂を注入してくれるマクロ。

私自身は、はるかな昔、PC-8801のBASICで漢字コードを変換するルーチンを作った記憶があります。漢字の使えるPC-88のBASICって何種類か種類があったんですが、私の手元にあったのは確か漢字がJISコードのもの。そのBASICで自作したターミナルソフトで草の根のパソコン通信につないだのが私のネットに乗り出した第一歩。モデムは友人からの借り物、1200bps。でも、ネットの海はシフトJISだったんですね。そこで、とりあえずネットの書き込みを読めるだけのものをBASICで実装したのですが、当たり前というか、とにかく遅い。モデムを300bpsまで落としても文字落ち多発。
仕方ないので、変換部分だけZ80のマシン語に書き換えたら、とりあえず300bpsなら使い物になる速度が出ましたけど、1200bpsではやっぱり間に合わない。ここまで来ると、あとはターミナルソフト自体も書き換えないとダメかな、と思っていたあたりで、既製品のターミナルソフトに乗り換えることにより自作ソフトは開発終了。漢字コードの逆変換をつけて書き込み可能にするだけの実力は当時の私にはありませんでしたし。

[4044] オープン・イベント

文太 2011/11/23(Wed) 12:56
[4043]へのコメント

 文脈外しの近況報告、ごめんなさい。

 ちょうど、「何とかならんか。どうも僕には何ともならんなぁ」と悩んだところだったものですから。
 いえ、1500ページの本(3巻本)を全部テキスト化しようなんてすると、色々とありまして、はい。
 1500個のファイルのファイル終端に、条件なしに改行を入れる、というタスクを、Vzマクロで思ったのですが……。

 結局、SiさんのWildとSedの複合技でしのぎました。

Wild "Sed -f c:\t.sed $f >c:\work2\$b.txt" c:\work\*.*

--- t.sed ---
$i\
\
-------------

 が、ファイラで20個のファイルを指定して、全ファイルのどっかにカーソルを飛ばすとか、できたいですね。あるいはエディット系のコマンドを使うとか……。

DC (15) 96/12/28 #03644/ Emmett

 あたりにも制限が書かれてますね。
 イベントが使えないとなると……。なんかマクロで逃げる技はないものなのでしょうか?
 ディレクトリ一括、なら、イベントを使わなくもできるのですけれど。

 マークしたファイル名情報を書き出して、それを対象にエディットしてゆくのか……。
 道具を作るのに時間がかかりすぎるなぁ……。

 別のもう少し込み入った処理では、20個を開けて、セーブ&クローズを最後に仕込んだマクロを[F12]にアサインし、1500/20回の処理もしました。もちろん、[F12]を1500回、押し続けたということです(汗)。正確には75回、[F12]を押しっぱなしで処理してもらいました。それでも、Vzマクロ様々でした(まだ終わってないのですが)。
 書式整形があるので、まだまだスペルチェックに入れません。固有名詞だらけなので、スペルチェックは1年くらいかかりそうな地獄。

 本題からずれました。


 もっとずれますが、僕がインテルを忌避してきたように(困難だった)、東芝、三菱、日立の製品を買わないようにする(難しいでしょう、現実的には)。これぐらいしか、良心の呵責なしに生きる現実策は、思いつけませんでした。
 パナソニック、シャープ、NEC、富士通では家電、足りませんよね。中国製か?

 PC世界は少し落ち着いて、AMDな文太マウスがメインに復帰しています。Core2さんにも数日間、猛烈に仕事してもらったけど。でも実質、数時間でしたけれど。

 上の1500個のファイル(現在は3つに連結されてる)の処理では、カーソル移動の速さとワイド画面の利点により、圧倒的にWinME機(エンデバ君)で処理してます。

[4045] Re: オープン・イベント

としき 2011/11/23(Wed) 21:38
[4044]へのコメント http://www1.hinocatv.ne.jp/toshiki/
>  1500個のファイルのファイル終端に、条件なしに改行を入れる、というタスクを、Vzマクロで思ったのですが……。

その条件なら、私はAWKで処理してしまいます。
Sedよりマクロのほうがいいことって、何があります?
それとも、何か省略されている条件があるのでしょうか。

>  ディレクトリ一括、なら、イベントを使わなくもできるのですけれど。

ディレクトリ一括ができない場合、dirコマンドの出力をVzで加工してバッチなりSedなりで走らせるというソリューションを真っ先に思いつきます。

>  道具を作るのに時間がかかりすぎるなぁ……。

もしかして、マクロなら時間がかからずに処理できる、と暗に言っているのでしょうか。

> 正確には75回、[F12]を押しっぱなしで処理してもらいました。

私もこれはよくやります。
ただ、時々、リピートの聞かないキーにアサインして、何で押しっぱなしで処理できないんだろう、って悩んで、すぐに気がついて、苦笑いしつつキーを書き換える、ということもたまにあります。

>  書式整形があるので、まだまだスペルチェックに入れません。固有名詞だらけなので、スペルチェックは1年くらいかかりそうな地獄。

どんな段取りでスペルチェックするのがいいのでしょうかね。
昔、DCの17階に書いたのは、単語ごとの出現回数をカウントして、出現回数の少ない語からチェックする方式。
あとは、単語の一覧表をsort/uniqして、上下の単語と比較する、という方法が思いつきましたが、いずれにしろ、物量との戦いになりそうですね。
まぁ、敵が物量ならこちらも物量、というか、人海戦術というのもあるかもしれません。

>  パナソニック、シャープ、NEC、富士通では家電、足りませんよね。中国製か?

うむ、ここは一発、最後の原子力大国である中国をヨイショしておきましょう。
2年位前、東北大学の先生だったかな、ベトナムから送電、なんて大法螺としか思えない様な事を言っていた人がいたけど、それに比べたら中国から電気を融通してもらうくらいなんともないことに思えてしまう。

[4046] マークしたファイルの情報

めざら 2011/11/24(Thu) 22:23
[4044]へのコメント http://homepage3.nifty.com/mezala/index.html
>  マークしたファイル名情報を書き出して、それを対象にエディットしてゆくのか……。

 これ,半端無く難しいですよね。
 実はちょっとだけマクロコードを書いてみたのですが,書き出す先が作業ファイルとなると,ファイラから編集モードに戻ったときにマーク情報が参照できなくなってしまって,書き出しのできるのはファイラカーソルのあるファイルだけ。うーむ。

 ファイラから戻らずにスタック用のメモリにでも出力しないと駄目なのかな。

 さてさて。
 やっぱり,としきさんのおっしゃるように,ファイルのリストを取ってシーケンスで処理していくのかなぁ…

[4047] Re: マークしたファイルの情報

文太 2011/11/26(Sat) 00:48
[4046]へのコメント
レス、ありがとうございました。短いレスでごめんなさい。

としきさん

>Sedよりマクロのほうがいいことって、何があります?
>それとも、何か省略されている条件があるのでしょうか。

 色々とものすごく条件が省略されていました。いえ、実際的な事柄に関していえば、オープン・イベントでは、榊原マジックを使ってもコマンド類が使えない、というあたりへの対処の指針がないかな、というぐらいだったのです。

 あらためて言うまでもないと思いますが、細かな作業と緻密な検査、そして何よりさらりと書けて、そして実用性が極めて高い、という意味で、sed, awkよりVzマクロのほうがずっと楽ですよ。たとえば、複行処理とか。

 現在、1500ファイルが3ファイルになってますが(置換用)、ふたたび20ファイルに分割しないと処理が面倒になります。そんな工程なんですよ。これなんかは、awkですね。cut.awk by としき(としきさんが、サイトの表記統一用に、大昔に作った奴。多謝)が大活躍します。

>もしかして、マクロなら時間がかからずに処理できる、と暗に言っているのでしょうか。
 はい、その通りです。マクロを書くのが圧倒的に速いですから。
 処理速度なんて、まったく関係ありません、もちろん。


めざらさん、

>これ,半端無く難しいですよね。

 ですかぁ。条件が半端すぎました。

 (1)マークファイルをすべてオープンして、カーソルを指定行にセットする(当然、マークするのは、TC以下)。
 (2)フィルタ的に、置換とかして、すぐ閉じる。

 これで対処法がずいぶん違ってきますよね。そして、上の2つは分けて考えるべき。場合分けがいい加減ですいませんでした。

>ファイラから戻らずにスタック用のメモリにでも出力しないと駄目なのかな。

 え、僕はまずレスポンス・ファイルにファイル名だけ書き出して、そのファイルをオープンすれば、とか、考えていたのですが、、、。これ、できませんでしたっけ?

[4048] Re^2: マークしたファイルの情報

めざら 2011/11/26(Sat) 21:38
[4047]へのコメント http://homepage3.nifty.com/mezala/index.html
>  (1)マークファイルをすべてオープンして、
> カーソルを指定行にセットする(当然、マークするのは、TC以下)。

 ああ,そんな数でよいのですか。でも,それなら参考にして欲しいのが,
上村さんの insfile.def ですね。(自分が貰ったという思い出あり)
このマクロはマークするファイルの数はTCの制限を受けません。
ぜひ,参考にしてみて。短いので,貼り付けます。

----------^ INSFILE.DEF ( date:2001-08-22 time:20:50 ) -----< cut here
======== 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("カーソル位置へファイルを読み込みます")
        #M &m("[ InsFile ]")
        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)
        #k (s==4)? 'y' #W ek[+, #i ek], #W >A

*
----------$ INSFILE.DEF ( lines:48 ) -----------------------< cut here

 #C の前に mr+ しておけば,目的が達せられるのでは?


>  え、僕はまずレスポンス・ファイルにファイル名だけ書き出して、
> そのファイルをオープンすれば、とか、考えていたのですが、、、。
> これ、できませんでしたっけ?

 レスポンスファイルが作成されるタイミングって,どんなんでしたっけ。
 なんかすっかり忘れちゃいまして。(^^;

[4049] Re^3: マークしたファイルの情報

文太 2011/11/30(Wed) 16:15
[4048]へのコメント
めざらさん、お礼が遅くなりました。

> ああ,そんな数でよいのですか。でも,それなら参考にして欲しいのが,
>上村さんの insfile.def ですね。(自分が貰ったという思い出あり)
>このマクロはマークするファイルの数はTCの制限を受けません。
>ぜひ,参考にしてみて。短いので,貼り付けます。

 うーん、カーソルを止める、だとTC以下以外ありえない、フィルタだと制限なし、と抽象的に考えました。いずれにせよ、参考にさせていただきますね。いえ、連結はたくさんやっていたので、このマクロ、気になっていたはいたのです。
 3メガにファイルを1つにして置換を連発してたら、ファイルを壊してしまった……。半日の作業がパー。やっぱり細かく刻まないと駄目だなぁ……。これから復旧です。

↑ このページの先頭